ANÁLISE E ORIENTADA A OBJETOS I

Visão geral

Apresentação da disciplina:
Olá ! Seja bem-vindo a nossa WEBAULA!
Vamos refletir sobre a formação do pedagogo e sua atuação nos espaços não escolares e
conhecer um pouquinho sobre qual é a função do pedagogo com a pedagogia social, pedagogia
empresarial, pedagogia hospitalar e a educação do campo. Porém, precisamos ter claro que
esses não são alguns, mas não os únicos espaços de atuação do pedagogo fora da escola.

Objetivos:
Olá, Caro Aluno! Seja bem vindo à disciplina de Análise Orientada a Objetos I. É com imenso
prazer que eu, professora Iolanda Cláudia Sanches Catarino, apresento a você a nossa webaula,
contemplando uma visão geral da atividade de Análise de Sistemas, conforme o Paradigma
Orientado a Objetos e o Processo Unificado, abordando os conceitos básicos do paradigma e as
técnicas iniciais de modelagem.
Nessa disciplina, você será levado a compreender a importância da modelagem de um sistema
computacional para documentar a atividade de Análise de Sistemas, através das técnicas de
modelagem de um método de desenvolvimento de software, bem como estudar, especificar e
consistir as técnicas de modelagem textuais e diagramais do software.

Conteúdo Programático:
Unidade de estudo 1: Paradigma Orientado a Objetos e o Processo Unificado:

 Fundamentos da Análise de Sistemas.

 Paradigma Orientado a Objetos.

 Fundamentos do Processo Unificado.

Unidade de estudo 2: Introdução à Análise de Sistemas:

 Visão Geral das Técnicas de Modelagem da Unified Modeling Language (UML).

  Modelagem de Casos de Uso.

 Modelagem de Classes.

Metodologia:
Em cada Unidade de Estudo, você será conduzido à leitura do texto e das figuras, ao acesso aos
objetos de aprendizagem e a especificar técnicas de modelagem da atividade de Análise de
Sistemas em uma ferramenta CASE, para consolidar o seu processo de aprendizagem.
Os conteúdos programáticos ofertados nessa disciplina serão desenvolvidos por meio das tele
aulas de forma expositiva e interativa (chat - tira dúvidas em tempo real), aula atividade
por chat para aprofundamento e reflexão e web aulas, que estarão disponíveis no Ambiente
Colaborar, compostas de conteúdos de aprofundamento, reflexão e atividades de aplicação dos
conteúdos e avaliação. Serão também realizadas atividades de acompanhamento tutorial,
participação em Fórum, atividades práticas e estudos independentes (auto estudo), além do
material didático da disciplina.

Avaliação Prevista:
Em conformidade com o modelo de ensino vigente da UNOPAR.
O sistema de avaliação da disciplina compreende em assistir a teleaula, participação no fórum,
produções textuais interdisciplinares (Portfólio), realização das avaliações virtuais e avaliação
presencial embasada no material didático, teleaulas, webaulas e material complementar.

Critérios para Participação dos Alunos no Fórum:

Quando houver fórum de discussão o aluno será avaliado quanto ao conteúdo de sua postagem,
onde deverá comentar o tópico apresentando respostas completas e com nível crítico de
avaliação pertinente ao nível de pós-graduação. Textos apenas concordando ou discordando de
comentários de outros participantes do fórum sem a devida justificativa ou complementação não
acrescentam em nada ao debate da disciplina, sendo assim, devem ser evitados. Os textos
devem sempre vir acompanhados das justificativas para a opinião do discente sobre o conteúdo
discutido, para que assim, possamos dar continuidade ao debate em nível adequado. Além disso,
podem ser utilizados citações de artigos, livros e outros recursos que fundamentem a opinião ou
deem sustentação a sua posição crítica sobre o assunto. Deve ser respeitado o tópico principal
do fórum, evitando debates que não tem relação com o tema selecionado pelo professor.

Habilidades e competências
Unidade 1

 Competências: Conhecer e compreender os fundamentos da atividade de análise e

princípios e conceitos do paradigma orientado a objetos. Conhecer e compreender o
Processo Unificado.

 Habilidades: Raciocinar de forma lógica. Abstrair e especificar requisitos. Analisar e

interpretar. Negociar e liderar.

Unidade 2

 Competências: Conhecer e compreender os métodos de desenvolvimento de sistemas na

atividade de Análise de Sistemas. Conhecer e aplicar as técnicas de modelagem para
documentar e especificar a atividade de Análise de Sistemas.

 Habilidades: Raciocinar de forma lógica. Abstrair e especificar objetos. Analisar e

interpretar. Negociar e liderar.
 Unidade 1 – Paradigma Orientado A Objetos e O Processo Unificado

WEBAULA 1

1. Fundamentos da Análise de Sistemas

Com o crescimento da complexidade nos processos de negócio, a modelagem organizacional
tem sido amplamente adotada para que a transição entre negócios e Tecnologias de Informação
(TI) ocorra de forma tranquila e consistente, para atender os requisitos dos usuários, ou seja, as
funcionalidades/serviços que o sistema deverá contemplar. Para desenvolver um Sistema de
Informação (SI), o gerente de projetos de TI e sua equipe, entre eles o analista de sistemas,
devem definir uma metodologia de desenvolvimento de sistemas que contemple procedimentos,
um ou mais métodos com suas técnicas de modelagem e as tecnologias a serem adotadas no
desenvolvimento do sistema, visando à qualidade do software. A Figura 1.1 ilustra a
interpretação, compreensão e definição dos requisitos de um sistema, atividade comum entre o
analista de sistemas e os usuários.

Figura 1.1 – Interpretação e Definição de Requisitos

Fonte: < [Link]

[Link] >. Acesso em: 30 out. 2015.
A Engenharia de Software é uma parte da Engenharia de Sistemas que se ocupa de todos os
aspectos da produção de software (SOMMERVILLE, 2011). Na concepção de Pressman (2011),
a Engenharia deSoftware abrange um conjunto de três elementos: métodos, ferramentas e
procedimentos. Dessa forma, possibilita ao gerente o controle do processo de desenvolvimento
do software e oferece ao profissional uma base para a sua construção com qualidade.
O método proporciona os detalhes de “como fazer” para construir o software. Envolve um amplo
conjunto de atividades que inclui: planejamento, análise de requisitos, análise e projeto,
implementação e testes, como ilustra a Figura 1.2. Para Sommerville (2011), um método é uma
abordagem estruturada para o desenvolvimento de software, facilitando a sua produção com
qualidade e uma boa relação custo-benefício.
 Figura 1.2 – Integração entre as Atividades de um Ciclo de Vida Básico

 Fonte: Acervo da autora (2015).

 Importante!
Na literatura, há vários métodos de desenvolvimento de software renomados, como o
método de Coad & Yourdon (OOAD), Grady Booch (Booch Method), Ivar Jacobson
(OOSE), James Rumbaugh (OMT), etc. Os métodos abrangem as atividades ou fases de
desenvolvimento e apresentam para cada atividade as técnicas de modelagem
representadas por diagramas ou de forma descritiva. Um conjunto de diagramas constitui
um modelo do sistema.
Acesse um exemplo em: .

As ferramentas proporcionam apoio automatizado aos métodos de desenvolvimento de software,

como as ferramentas CASE (Computer Assited Software Engineering – Engenharia
de SoftwareAssistida por Computador) de modelagem, de banco de dados e de linguagens de
programação. Os procedimentos referem-se às decisões que serão tomadas quanto ao
planejamento do projeto, à escolha do método com as técnicas de modelagem que serão
especificadas e demais padrões adotados, no desenvolvimento do software.
Vídeo
Assista ao vídeo para fixar os conceitos abordados!
Disponível em: < [Link] >.

A Figura 1.3 representa um ciclo de vida do processo de desenvolvimento de software chamado

Processo Unificado, sendo as principais atividades: Comunicação (Modelagem Organizacional),
Planejamento (Levantamento de Dados ou Análise de Requisitos), Modelagem (Análise e
Projeto), Construção (Implementação – Programação e Testes) e Implantação (Instalação e
Manutenção).
 Figura 1.3 – Processo de Desenvolvimento de Software – Processo Unificado

Fonte: < [Link] >. Acesso em: 30 out.

2015.

Na atividade de Comunicação realiza-se a especificação da modelagem organizacional,

identificando os processos de negócio. Na atividade de Planejamento realiza-se a identificação
dos requisitos do sistema e faz o estudo de sua viabilidade. Na atividade de Modelagem define–
se o que e como vai ser desenvolvido o software, adequando o projeto de acordo com as
tecnologias que serão adotadas para o seu desenvolvimento. Na atividade de Construção
realiza-se a implementação correspondente à programação e testes do software e, por fim, na
atividade de Implantação é feita a instalação do sistema para o usuário e, posteriormente, a sua
manutenção.
A realização bem executada das três primeiras atividades de um ciclo de vida básico do projeto
é essencial para o sucesso e qualidade do software desenvolvido.

Acesse o link para saber mais a respeito de Visão Geral de Desenvolvimento:

Um analista de sistemas é um profissional essencial em qualquer projeto de desenvolvimento de
sistemas. Ele, na atividade de Análise de Requisitos, deve identificar, definir e especificar os
requisitos funcionais e não funcionais do sistema. Na atividade de análise, define-se a solução
do sistema, especificando o que será desenvolvido. Posteriormente, os demais profissionais da
equipe de desenvolvimento definem como o software será desenvolvido e o implementam com
consistência e qualidade técnica.

O profissional analista de sistemas precisa ter habilidades e competências para: analisar, projetar
e desenvolver sistemas computacionais, principalmente sistemas de informação; definir o uso
adequado de Tecnologias de Informação e Comunicação (TIC), conforme o domínio dos projetos;
visualizar o sistema computacional de várias perspectivas, abstraindo soluções lógicas e físicas
satisfatoriamente; e trabalhar com pessoas em equipe, mediar conflitos de ideias e gerenciar
situações que exigem tomadas de decisão.
 Importante!
Um Requisito Funcional (RF): representa um serviço ou uma funcionalidade que o
sistema deve fornecer para atender uma necessidade do usuário.
Exemplo: Cadastrar Cliente; Realizar Orçamento; Emitir Nota Fiscal de Venda; Consultar
Clientes e Gerar Relatório de Vendas.
Um Requisito Não-Funcional (RNF): representa restrições que o software deve atender
ou qualidades específicas que ele deve ter.
Exemplo: O relatório de vendas deve ser gerado automaticamente às 18h, diariamente;
Toda nota fiscal de venda será enviada para o endereço eletrônico do cliente, no prazo
máximo de 24 horas, após e efetivação de uma venda.

Para Refletir
Vamos, agora, refletir sobre os Fundamentos da Análise de Sistemas: como o analista de
sistemas pode garantir que os requisitos funcionais de um sistema sejam implementados
com sucesso?

2. Paradigma Orientado a Objetos

Segundo Bezerra (2007), pode-se dizer que o termo “paradigma da orientação a objetos” é uma
forma de abordar um problema, visualizando um sistema de software como uma coleção de
agentes interconectados chamados objetos, sendo cada um responsável por realizar tarefas
específicas. A programação orientada a objetos teve início na década de 70, com a linguagem
SIMULA, parte da linguagem Smalltalk, mas ganhou grande visibilidade na década de 80. Os
métodos de modelagem orientados a objetos surgiram no final da década de 80, sendo que na
década de 90 uma grande diversidade de autores lançou seus métodos, praticamente com
propostas semelhantes.

No início da década de 90, os pesquisadores Grady Booch, Ivar Jacobson e James Rumbaugh
uniram as melhores práticas de seus métodos e construíram um padrão de referência para
modelagem orientada a objetos, lançando a Unified Modeling Language (UML - Linguagem de
Modelagem Unificada).
Vídeo
Assista ao vídeo para conhecer um pouco mais sobre a história das linguagens de
programação!
Disponível em: <[Link] >.

Faça a leitura do artigo para conhecer mais sobre o Paradigma Orientado a Objetos e seus
pilares! .
A seguir, apresentamos uma definição dos principais conceitos da abordagem orientada a
objetos, suas correlações e exemplos.
Objeto:
Um objeto pode ser definido como qualquer coisa concreta ou abstrata com existência no mundo
real, com características e comportamento próprio, sendo possível identificá-lo como único. Na
definição de Booch; Jacobson e Rumbaugh (2006, p. 456), um objeto é “uma entidade com uma
fronteira bem-definida e uma identidade que encapsula o estado e comportamento”. Os objetos
são descritos por seus atributos e operações. Um atributo é uma característica particular
possuída por todos os objetos. Uma operação é uma ação que um objeto executa ou está
sujeito, ou seja, é uma ordem que faz um objeto reagir. A implementação de uma operação é
chamada de método. Um método representa o conjunto de passos (lógica) que um objeto
executa para reagir a uma operação. Ele pode receber ou não parâmetros e pode retornar
valores ao ser executado. Parâmetros são os valores utilizados durante a execução do método.
A Figura 1.4 ilustra alguns exemplos de objetos concretos, como telefones e carro, e o objeto
abstrato nota fiscal.
Figura 1.4 - Exemplos de Objetos Concretos e Abstratos

Fontes das imagens: < [Link]

[Link] >. Acesso em: 30 out. 2015.
< [Link] >. Acesso em:
30 out. 2015.
< [Link] >. Acesso
em: 30 out. 2015.

Abstração:
O conceito de abstração consiste na concentração dos aspectos essenciais e relevantes de um
objeto, inerentes ao contexto e ao domínio do sistema. Na definição de Rumbaugh (1994, p.
599), o conceito de abstração representa a “habilidade mental que permite aos seres humanos
visualizarem os problemas do mundo real com vários graus de detalhe, dependendo do contexto
corrente do problema”. A Figura 1.5 ilustra atletas realizando esportes, abstraindo, assim, as
características relevantes desses objetos, define-se a classe Esporte.
Figura 1.5 – Exemplo do Conceito de Abstração
Fontes das imagens: < [Link]
content/uploads/2015/10/[Link] >. Acesso em: 30 out. 2015.
<[Link]
FihrlSuVXbKkGminDsQwFCoGUleXQXyB>. Acesso em: 30 out. 2015.
Classe:
Uma classe representa um grupo de objetos do mundo real que possui tipos de características e
de comportamento em comum. Cada ocorrência de um objeto representa uma instância da
classe. Na definição de Rumbaugh (1994, p. 32), uma classe “descreve um grupo de objetos
com propriedades semelhantes (atributos), o mesmo comportamento (operações), os mesmos
relacionamentos com outros objetos e a mesma semântica”.
A Figura 1.6 ilustra objetos reais de um domínio, por exemplo, funcionários de uma empresa.
Observando as características relevantes para o domínio em questão, abstraímos as
características comuns entre eles, definindo os seus atributos: matrícula, nome, data de
nascimento, etc; assim, representamos na modelagem do sistema a classe Funcionário.
Figura 1.6 – Exemplo da Classe Funcionário

Fonte: < [Link] >. Acesso em: 30 out. 2015.

Vídeo
Assista ao vídeo para fixar os conceitos abordados!
Disponível em: <[Link] >.

Evento e Estado:
Eventos são os acontecimentos que fazem os objetos mudarem de estado. Na definição de Para
Rumbaugh (1994, p. 114-115), um evento é “um estímulo individual de um objeto para outro; é
algo que acontece em certo momento. É uma transmissão ou informação unidirecional de um
objeto para outro”. Um estado representa a abstração de uma forma de apresentação dos objetos
de uma classe em um determinado instante de tempo. Na definição de Booch; Jacobson e
Rumbaugh (2006, p. 290), um estado é “uma condição ou situação na vida de um objeto durante
a qual o objeto satisfaz alguma condição, realiza alguma atividade ou aguarda um evento. Um
objeto permanece em um estado por uma quantidade finita de tempo”. A transição de estado
representa a mudança de estado de um objeto como resposta à chegada de um evento. Os
eventos, assim como os estados, dependem da abstração aplicada, especificamente, a um
contexto. A Figura 1.7 a seguir ilustra um exemplo de um objeto do tipo Livro, que num instante
de tempo (t1) encontra-se no estado fechado e a partir de um evento (abrir, uma ação humana)
o objeto reage e muda o seu estado para aberto, no instante de tempo seguinte (t2).
Figura 1.7 – Exemplo da Ocorrência e um Evento

Fonte:
< [Link]
Book+[Link] >. Acesso em: 30 out. 2015.
< [Link] >. Acesso em: 30 out.
2015.
Um evento, ao ser disparado, envia uma mensagem a uma operação do objeto, o qual o método
correspondente é executado. O mecanismo de invocação de uma operação representa uma
mensagem, ou seja, é a forma de conseguir executar um método.

Encapsulamento:
Representa o ato de reunir em uma estrutura chamada classe, as características e o
comportamento dos objetos, sendo uma forma de organizá-los, permitindo que um objeto proteja
a integridade de suas partes. Na definição de Rumbaugh (1994, p. 10), o conceito de
encapsulamento é “também chamado de ocultamento de informações, consiste na separação
dos aspectos externos de um objeto, acessíveis por outros, dos detalhes internos da
implementação daquele objeto, que ficam ocultos dos demais objetos”. A Figura 1.8 ilustra um
objeto real Calculadora. Ela tem internamente seus registradores, sendo que apenas as funções
(serviços) de somar, subtrair, multiplicar e outras funções são disponibilizadas ao usuário,
através de uma interface, Os detalhes dos processos pelos quais se obtém um resultado não
estão diretamente visíveis para o usuário da calculadora.
Figura 1.8 – Exemplo do Conceito de Encapsulamento

Fonte: < [Link]

[Link] >. Acesso em: 30 out. 2015.
Generalização:
O conceito de generalização representa a propriedade pela qual uma classe pode herdar
características e comportamento de outra, para obter o reaproveitamento dos atributos e
operações. Quando a herança é de uma única superclasse, ela é denominada herança simples
e se for de várias superclasses, é denominada herança múltipla. Na definição de Para Rumbaugh
(1994, p. 4), o conceito de herança é “o compartilhamento de atributos e operações entre classes
com base em um relacionamento hierárquico. Uma classe pode ser definida de forma abrangente
e depois refinada em sucessivas subclasses mais definidas”. A Figura 1.9 ilustra um exemplo de
herança representado pelo relacionamento de generalização entre as classes Veículo
(superclasse) e as classes Carro, Caminhão e Ônibus (subclasses). Fazendo a leitura da figura,
carro é um tipo de veículo.
Figura 1.9 – Exemplo de Herança entre Classes

Fonte: A autora.

Polimorfismo:
O conceito de polimorfismo representa uma mesma operação se comportando de diferentes
formas, em diferentes classes. Uma operação polimórfica possui o mesmo nome em classes
distintas, mas em cada classe o método implementado é diferente. Na definição de Rumbaugh
(1994, p. 4), polimorfismo “significa que a mesma operação pode atuar de modos diversos em
classes diferentes; a mesma operação pode se aplicar a muitas classes diferentes”.

Para Refletir
Vamos, agora, refletir sobre o Paradigma Orientado a Objetos: Quais são os principais
pilares/características que sustentam o Paradigma Orientado a Objetos?

Visualize o link e leia o Capítulo 1:

3. Fundamentos do Processo Unificado
O Processo Unificado foi criado para apoiar o desenvolvimento orientado a objetos com a UML,
fornecendo uma forma sistemática de especificar sistemas de softwares para diferentes
domínios e tamanhos de projetos. O ciclo de vida do Processo Unificado é iterativo e incremental.
Segundo Bezerra (2007), o ciclo de vida de processo incremental e iterativo abrange duas
dimensões: dimensão temporal e dimensão de atividades (fluxos de trabalho). Na dimensão
temporal, o processo é estruturado em fases, sendo que em cada uma delas há uma ou mais
iterações. Cada iteração tem uma duração preestabelecida e, ao final de cada iteração, é
produzido um incremento – uma parte do sistema. Os ciclos de desenvolvimento são organizados
em quatro fases sucessivas - Concepção, Elaboração, Construção e Transição, e cada uma
delas integra um conjunto de atividades iterativas - Requisitos, Análise e Projeto, Implementação
e Teste, como mostra a Figura 1.10. Em cada uma das fases, diferentes artefatos
de software são produzidos e a cada iteração, novos detalhes são adicionados a eles, resultando
na geração de uma nova versão de um protótipo a cada fase realizada.

Importante!
No modelo de ciclo de vida incremental e iterativo, um sistema de software é desenvolvido em
vários passos similares (iterativo). Em cada passo, o sistema é estendido com mais
funcionalidades (incremental), incentivando a participação do usuário nas atividades de
desenvolvimento, para validar os requisitos do sistema através da prototipagem (BEZERRA,
2007).

Figura 1.10 – Ciclo de Vida do Processo Unificado

Fonte: Adaptado de MEDEIROS, 2006, p. 16.

Vídeo
Assista ao vídeo para fixar os conceitos abordados!
Disponível em: < [Link] >.

Na fase de Concepção define-se a ideia geral do negócio do sistema e a delimitação do escopo

do projeto para obter um desenvolvimento bem fundamentado nos requisitos do usuário. Um
planejamento de alto nível do desenvolvimento é realizado para identificar, definir e analisar os
requisitos do sistema. Em síntese, a fase de concepção se concentra na delimitação da fronteira
e do contexto do sistema, com a identificação e definição dos requisitos. Na fase de Elaboração
define-se como o sistema será construído a partir da definição dos requisitos do sistema,
estabelecendo a arquitetura e mecanismos para especificar o sistema. Concentra-se na
especificação dos requisitos funcionais do sistema nas atividades de Análise e Projeto,
principalmente. A atividade de análise consiste em identificar o que o sistema deve fazer em uma
visão lógica do negócio, e a atividade de projeto consiste em definir como o software será
desenvolvido, ou seja, fazendo uma transição da modelagem lógica da análise para a
modelagem física do software, de acordo com a escolha do Sistema Gerenciador de Banco de
Dados (SGBD), linguagens de programação, frameworks, etc. Ainda, algum trabalho de projeto
e implementação pode ser realizado, desenvolvendo a prototipagem do software, conforme
mostra a Figura 1.11 a seguir:
Figura 1.11 – Protótipo da Interface Gráfica de um Caso de Uso

Fonte: < [Link] >. Acesso em: 01 dez.

2015.
Na fase de Construção, concentra-se na implementação e testes das funcionalidades, através
do desenvolvimento iterativo e incremental do sistema. A atividade principal concentra-se no
projeto e na implementação, visando validar e melhorar a prototipagem inicial, até obter o
primeiro produto operacional. Na fase de Transição, o sistema é entregue aos usuários treinados
com acompanhamento constante, devido à demanda de novas funcionalidades ou adequações
no sistema. A atividade principal é a de testes, visando garantir que o sistema atenda aos
requisitos do usuário satisfatoriamente. Em cada fase é realizado um conjunto de iterações,
envolvendo as atividades em um ciclo de desenvolvimento. Contudo, de uma iteração para outra
e de uma fase para a próxima, a ênfase sobre as várias atividades muda, como mostra a Figura
1.10, a qual ilustra a concentração das atividades em uma determinada fase.
Faça a leitura dos artigos para conhecer mais sobre o Processo
Unificado! e .

Para Refletir
Vamos, agora, refletir sobre os Fundamentos do Processo Unificado: como funciona a evolução
iterativa e incremental do ciclo de vida do Processo Unificado?

Resumo da Unidade de Ensino

Esta unidade apresentou uma contextualização do processo de desenvolvimento de software,
especificamente o Processo Unificado, com suas principais fases e atividades. Nas primeiras
atividades do processo de desenvolvimento, as atividades de Requisitos (ou Comunicação e
Planejamento), Análise e Projeto, o profissional analista de sistemas tem a responsabilidade de
abstrair e identificar os processos de negócio e, posteriormente, conceber e elaborar o software,
definindo, para isso, um ou mais métodos de desenvolvimento de sistemas com suas técnicas
de modelagem para especificar todos os requisitos do sistema. Posteriormente, foram
apresentados e exemplificados os principais conceitos do paradigma Orientado a Objetos, que
serão utilizados para compreender as técnicas de modelagem da UML e aplicá-los na
implementação do software.

Pratique!
Faça um levantamento das ferramentas CASE que contemplam a modelagem das atividades de
Requisitos, Análise e Projeto, conforme a UML, e escolha uma ferramenta CASE para você
instalar em seu computador e começar a se familiarizar.
Bom trabalho!

REFERÊNCIAS
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 2. ed. Rio de
Janeiro: Elsevier, 2007.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. 2. ed. Rio de
Janeiro: Elsevier, 2006.
MEDEIROS, Ernani Sales de. Desenvolvendo software com UML 2.0: definitivo. São Paulo:
Pearson, 2006.
PRESSMAN, Roger S. Engenharia de software: uma abordagem profissional. 7. ed. Porto
Alegre: McGraw-Hill, 2011.
RUMBAUGH, James et al. Modelagem e projetos baseados em objetos. Rio de Janeiro:
Campus, 1994.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
 Unidade 2 – Introdução à Análise de Sistemas

WEBAULA 1

2.1 Visão Geral da Unified Modeling Language (UML)

A UML foi criada a partir da fusão de três métodos dos autores - Booch, Rumbaugh (OMT- Object
Modeling Technique) e Jacobson (OOSE – Object-Oriented Software Engineering). A
concretização da UML aconteceu em 1997. Atualmente, a última versão da UML é 2.5 e a OMG
é a organização responsável em manter e administrar a UML. A Figura 2.1 ilustra o nome de
vários métodos orientados a objetos.
Conforme Booch; Jacobson e Rumbaugh (2006, p. 13), a UML é “uma linguagem padrão para a
elaboração da estrutura de projetos de software. A UML é uma linguagem para visualização,
especificação, construção e documentação de artefatos que façam uso de sistemas complexos
desoftware”.
Figura 2.1 – Métodos Orientados a Objetos

Fonte:
< [Link]
pg >. Acesso em: 30 out. 2015.
A UML apresenta um conjunto de técnicas de modelagem gráficas, integrando vários elementos
(objetos, classes, atributos, etc.) do paradigma orientado a objetos. A UML não se aplica,
exclusivamente, a uma etapa (fase ou atividade) do processo de desenvolvimento de software e
nem a um Modelo de Engenharia de Software, mas se apoia no desenvolvimento incremental e
iterativo, através de modelos (um conjunto de diagramas) que podem evoluir com a inclusão de
novos detalhes.
Importante!
Um modelo é uma descrição simplificada da realidade, apresentado a partir de uma perspectiva
específica e criado para proporcionar uma melhor compreensão do sistema. Cada modelo pode
ser expresso em diferentes níveis de precisão, constituindo um conjunto de diagramas
consistentes entre si e acompanhados de técnicas de modelagem textuais. Um diagrama é uma
visão sobre um modelo, o qual proporciona uma representação parcial do sistema (Booch,
Jacobson e Rumbaugh 2006).

Booch, Jacobson e Rumbaugh (2006) consideram as principais características da UML:

a) Centrado na arquitetura: a arquitetura do sistema é utilizada como principal artefato para a
conceituação, construção, gerenciamento e evolução do sistema em desenvolvimento,
representando uma visão do projeto como um todo;
b) Orientado a Use Cases (Casos de Uso): os use cases são utilizados como o principal artefato
para o estabelecimento do comportamento desejado do sistema;
c) Processo iterativo: refere-se ao gerenciamento de sequências de versões executáveis e
incrementais, sendo que cada nova versão incorpora os artefatos incrementais em relação às
demais, conforme mostra a Figura 02, a seguir.
Figura 2.2 – Métodos Orientados a Objetos
Figura 2.2 – Métodos Orientados a Objetos
Fonte: < [Link] >. Acesso
em: 01 dez. 2015.
A UML 2.0 abrange quatorze técnicas de modelagem, classificadas em estruturais e
comportamentais. As técnicas estruturais enfatizam a estrutura dos elementos estáticos, a partir
da identificação dos objetos. As técnicas de modelagem comportamentais enfatizam o
comportamento dinâmico e a interação entre os elementos do sistema.
Quadro 2.1 - Relação das técnicas de modelagem da UML 2.0
Fonte: BEZERRA (2007)

Saiba mais sobre a UML: e .

As técnicas de modelagem propostas pela UML não estão vinculadas, diretamente, a uma
atividade (Análise, Projeto, Implementação e Testes) do processo de desenvolvimento
de software e não dizem quem deve fazer o que, quando e como. Bezerra (2009) e demais
autores, sugerem a adoção do Diagrama e Documentação de Casos de Uso, do Diagrama de
Classes, do Diagrama de Objetos e do Diagrama de Estruturas Compostas para modelar a
atividade de análise e, posteriormente, fazer um refinamento dessas técnicas e complementar
com os diagramas de iteração para modelar a atividade de projeto, representando uma visão
física de desenvolvimento.

Conheça o material oficial da UML 2.5.: .

Vamos, agora, refletir sobre a Unified Modeling Language (UML):
A UML consiste da fusão de três métodos, abrangendo atualmente quatorze técnicas de
modelagem. Qual foi a contribuição de cada método (Booch, Jacobson e Rumbaugh) na criação
da UML?

2.1 Diagrama de Use Cases (Casos de Uso) e Documentação

Vamos iniciar o estudo das técnicas de modelagem da UML, começando com o Diagrama de
Casos de Uso e o Diagrama de Classes.
O Diagrama de Casos de Uso representa as funcionalidades do sistema (requisitos funcionais
do sistema) e os elementos externos ao sistema que interagem com ele. É um diagrama abstrato
e flexível com poucos elementos de notação, que representa a interação entre os elementos Ator
e Casos de Uso, indicando os serviços ou funcionalidades que o sistema disponibiliza para os
usuários. Posteriormente, deve ser feita a documentação de cada Caso de Uso e ainda a sua
especificação através dos diagramas de Atividades, Sequência ou Comunicação, consistindo e
validando os casos de usos com os objetos que são manipulados durante a execução de um
Caso de Uso. Segundo Bezerra (2007), o Modelo de Casos de Uso (MCU) é uma representação
das funcionalidades do sistema e dos elementos externos ao sistema que interagem com ele.
Um Diagrama de Casos de Uso é representado pelos elementos Atores, Casos de Uso e
Relacionamentos. A Figura 2.3 ilustra um Diagrama de Casos de Uso:
Figura 2.3 – Exemplo de um Diagrama de Casos de Uso

Fonte: A autora (2016).

Os Casos de Uso (use cases) representam qualquer interação de serviços (funcionalidades)
entre um Ator e o sistema, sem revelar a estrutura e o comportamento interno do sistema. Cada
serviço deve ser representado, individualmente, como um Caso de Uso. Eles são representados
por uma elipse, contendo uma breve descrição dentro do seu símbolo que identifica qual serviço
o Caso de Uso assume. Recomenda-se nomeá-lo com o verbo no infinitivo mais o substantivo(s).
Exemplo: Cadastrar Curso ou Manter Curso, Realizar Avaliação, Lançar Nota de Avaliação. Os
Atores representam os papéis desempenhados por pessoas, hardware ou outro sistema que
pode utilizar ou interagir com as funcionalidades do sistema. Um ator primário é responsável em
fornecer os dados para que ocorra a execução do serviço.
Os Atores são representados por símbolos de “bonecos magros”, identificados com um nome
que representa qual o papel assumido no contexto do sistema. Cada Ator deve representar um
único papel. A interação entre um Ator e um Caso de Uso é representada por um relacionamento,
os quais são possíveis: associação, generalização, extensão e inclusão.
Vídeo
Assista ao vídeo para fixar os conceitos abordados!
Disponível em: < [Link] >. Acesso em: 16 nov.
2015

A Associação é um tipo de relacionamento entre os Atores que interagem com o sistema. Ela
pode ser estabelecida entre o Ator e Caso de Uso ou entre um Caso de Uso e outros Casos de
Uso. Uma associação estabelecida entre um Ator e Casos de Uso representa que o Ator utiliza-
se, de alguma maneira, da função representada pelo Caso de Uso. A Generalização é um tipo
de relacionamento entre Casos de Uso ou entre Atores. A Generalização de Atores é uma
representação abstrata de papéis e a Generalização de Casos de Uso representa dois ou mais
Casos de Uso que apresentam características semelhantes. A Figura 2.4 ilustra um exemplo de
Generalização de Atores e Casos de Uso.
Figura 2.4 – Notação de Generalização

Fonte: A autora (2016).

Faça a leitura dos materiais para conhecer mais sobre o Diagrama de Casos de
Uso! .

O relacionamento de Extensão representa um relacionamento de dependência entre Casos de

Uso, indicado pelo estereótipo <<extend>>. A Extensão é utilizada para descrever cenários
opcionais de um Caso de Uso, que somente ocorrerão se uma determinada condição for
satisfeita (GUEDES, 2008). O relacionamento de dependência <<extend>> é representado por
uma seta que parte do Caso de Uso “estendido” para o Caso de Uso “base”. A Figura 2.5 ilustra
um exemplo de Extensão entre os Casos de Uso.
Figura 2.5 – Exemplo do Relacionamento de Extensão

Fonte: A autora (2016).

O relacionamento de Inclusão representa um relacionamento de dependência entre Casos de
Uso, indicado pelo estereótipo <<include>>. Esse relacionamento é utilizado quando existe uma
situação ou rotina comum a mais de um Caso de Uso. A inclusão indica uma obrigatoriedade
com outro Caso de Uso, sendo que a execução do primeiro obriga também a execução do
segundo. O relacionamento de dependência <<include>> é representado por uma seta que parte
do Caso de Uso “base” para o Caso de Uso “incluído”. A Figura 2.6 ilustra um exemplo de
Inclusão entre os Casos de Uso:
Figura 2.6 – Exemplo do Relacionamento de Inclusão

Fonte: A autora (2016).

Saiba mais sobre Modelar Sistemas em UML - Casos de Uso no link: .

Após a criação do Diagrama de Casos de Uso, eles são complementados com uma
documentação. Não existe um formato específico de documentação para Casos de Uso definido
pela UML. O formato de documentação de um Caso de Uso é flexível, permitindo que se
documente o Caso de Uso da forma que se considerar melhor, até mesmo através do uso de
pseudocódigo ou de código de uma linguagem de programação. A seguir, é exemplificada a
documentação do Caso de Uso “Cadastrar Curso” no formato descritivo em cenários,
especificando-os em Cenário Principal e Cenário(s) Alternativo(s). O cenário principal apresenta
uma descrição de uma tarefa que represente o mundo perfeito, sem exceções, e o cenário
alternativo relata qualquer situação que represente uma exceção (condição) do cenário principal.
Exemplo de Formato Descritivo Numerado:
Número: 001
Caso de Uso: Cadastrar Curso
Descrição: Autor informa os dados para realizar o cadastro de um curso.
Ator: Autor

Cenário Principal:
1. Autor solicita cadastro de curso.
2. Sistema exibe o cadastro de cursos.
3. Autor informa código do curso.
4. Sistema verifica que não existe código do curso cadastrado.
5. Autor informa demais dados.
6. Sistema verifica que categoria de curso está cadastrada.
7. Sistema recupera dados da categoria de curso.
8. Autor confirma o cadastro.
9. Sistema registra curso.
10. Sistema emite Msg 1, informando que o curso foi cadastrado com sucesso.
11. Sistema encerra o caso de uso.
Cenário Alternativo 4:
4. Sistema verifica que existe código do curso cadastrado.
4.1 Sistema recupera dados do curso associado ao código.
4.2 Sistema permite alteração ou exclusão do curso.
4.3 Autor escolhe a opção de alteração.
4. 4 Autor informa dados (nome, descrição, objetivo e carga horária) a serem alterados.
4.5 Autor confirma alteração dos dados.
4.6 Sistema atualiza dados do curso.
4.7 Sistema encerra o caso de uso.
Cenário Alternativo 4.3:
4.3. Autor escolhe a opção de exclusão.
4.3.1 Sistema verifica que o curso não está associado a outro objeto.
4.3.2. Sistema emite Msg 04, confirmando a exclusão do curso.
4.3.3. Autor confirma a exclusão do curso.
4.3.4. Sistema exclui o curso.
4.3.5. Sistema encerra o caso de uso.
Vamos, agora, refletir sobre o Diagrama de Casos de Uso:
O Diagrama de Casos de Uso, conforme a classificação das técnicas de modelagem da UML é
uma técnica comportamental. Assim, qual é a aplicabilidade do Diagrama de Casos de Uso?

2.1 Diagrama de Classes

O Diagrama de Classes é a principal técnica de modelagem da UML, assim, vamos explorar
nesta seção os seus principais componentes, tratando-o como um diagrama da fase de
análise. O Diagrama de Classes representa a modelagem da parte estática do sistema,
representando um conjunto de classes com seus atributos, operações e relacionamentos. O
objetivo do Diagrama de Classes é permitir a visualização das classes utilizadas pelo sistema e
como estas se relacionam. Ele apresenta uma visão estática de como as classes estão
organizadas, preocupando-se em definir sua estrutura lógica (GUEDES, 2008).
Considerando que o Diagrama de Casos de Uso está concluído, a próxima etapa é analisá-los
para iniciar o trabalho de identificação das classes de objetos. A partir da elaboração de um
primeiro estágio do Diagrama de Classes, o mesmo evoluirá à medida que o sistema é
desenvolvido, o qual o diagrama deve ser incrementado com novos detalhes. A seguir,
apresentamos os principais elementos do Diagrama de Classes.
Classe:
Uma Classe é representada por um retângulo com, no máximo, três partes. Na primeira parte
(de cima para baixo) é exibido o nome da Classe. Por convenção, o nome é apresentado no
singular e com as palavras compostas começando por letra maiúscula. Na segunda parte, são
declarados os atributos e na terceira parte, são declaradas as operações.
O nome de um atributo é declarado por um substantivo, tipicamente, em letra minúscula e para
palavras compostas usa-se concatená-las, sendo que a partir da segunda palavra inicia-se com
letra maiúscula, por exemplo, dataNascimento. O nome de uma operação é declarado por um
verbo, usando a mesma convenção de letras minúsculas e maiúsculas dos atributos. A Figura
2.7 ilustra alguns exemplos de representação de Classes:
Figura 2.7 – Notação de Classe

Fonte: A autora (2016).

Relacionamentos:
Na UML, os modos pelos quais os itens podem estar conectados a outros, isto é, logicamente
ou fisicamente, são modelados como relacionamentos, que permitem compartilhar informações
e colaboram para a execução dos processos pelo sistema (GUEDES, 2008).
Existem quatro tipos de relacionamentos:
a) Associações: são relacionamentos estruturais entre instâncias. Tipos de associações:
Unária (autoassociação ou reflexiva), binária, ternária, classe associativa e agregação.
b) Generalizações: conectam classes generalizadas a outras mais especializadas, o que é
conhecido como relacionamento Generalização e Especialização;
c) Dependências: são relacionamentos de utilização entre casos de uso, classes, pacotes e
anotações;
d) Realizações: são relacionamentos que especificam um contrato de execução entre classes
e interfaces.
O relacionamento do tipo Associação é representado por uma reta, ligando as classes
envolvidas. Pode-se indicar um nome na associação e a navegabilidade na extremidade das
associações que indicará o sentido em que as informações são transmitidas entre os objetos das
classes associadas. As Associações podem, também, possuir nomes (títulos). A Figura 2.8 ilustra
a notação de Associação:
Figura 2.8 – Notação de Associação

Fonte: A autora (2016).

O atributo a ser transmitido na Associação é implícito, não sendo apresentado na classe para a
qual foi transmitido. Em cada extremidade da associação deve ser definida a sua multiplicidade,
a qual depende de pressupostos e de como são definidas as fronteiras de um problema,
conforme as regras de negócio. O quadro a seguir ilustra os tipos de multiplicidade:
Quadro 2.3 – Tipos de Multiplicidades
Multiplicidade Significado
0..1 Nenhum e no máximo um. Representa que os objetos associados não
precisam obrigatoriamente estar relacionados, mas se houver
relacionamento indica que apenas uma instância da classe se relaciona
com as instâncias da classe associada.
1..1 Um e exatamente um. Representa que apenas uma instância da classe
se relaciona com as instâncias da classe associada.
0..* Nenhum e no máximo muitos. Representa que pode ou não haver
instâncias da classe participando do relacionamento e que muitas
instâncias da classe participam da classe associada.
* Muitos. Representa que multas instâncias da classe estão envolvidas no
relacionamento.
1..* No mínimo 1 e no máximo muitos. Representa que há pelo menos uma
instância da classe envolvida no relacionamento, podendo haver muitos
objetos envolvidos.
 Intervalo Representa um intervalo inicial e final, indicando que existe pelo menos
específico um número específico de instâncias iniciais envolvidas no
relacionamento com um número limite de instâncias, exemplo 1-5.
Fonte: Booch; Jacobson e Rumbaugh (2006)
A Associação Unária ou Reflexiva ocorre quando existe um relacionamento de um objeto com
objetos da mesma classe, em que cada um tem um papel distinto nessa associação. A Figura
2.9 ilustra a notação e um exemplo de Associação Unária.
Figura 2.9 – Notação e Exemplo de Associação Unária

Fonte: A autora (2016).

A Associação Binária ocorre quando são definidos relacionamentos entre objetos de duas
classes. A existência de uma associação entre dois objetos possibilita a troca de mensagens
entre eles. A Figura 2.10 ilustra a notação e um exemplo de Associação Binária:
Figura 2.10 – Notação e Exemplo de Associação Binária

Fonte: A autora (2016).

Vídeo
Assista ao vídeo para fixar os conceitos abordados!
Disponível em: < [Link] >. Acesso em: 16 nov.
2015

A Classe Associativa também é chamada de classe de associação. Em vez de estar ligada a

outras classes, ela está ligada à associação, a qual, normalmente, aparece quando duas ou mais
classes estão associadas e é necessário manter características (atributos) específicas da
Associação, sendo que uma classe associativa pode participar de outros relacionamentos. A
Figura 2.11 ilustra a notação e um exemplo de Classe Associativa.
Figura 2.11 – Notação e Exemplo de Classe Associativa

Fonte: A Autora (2016)

A Agregação demonstra que um objeto (chamado objeto-todo) precisa ser complementado com
um ou mais objetos de outra classe (chamados objeto-parte), sendo essa associação conhecida
como “Todo-Parte”. Ambas as classes podem “viver” de forma independente, ou seja, não existe
uma ligação forte entre as duas. O símbolo de Agregação difere do de Associação por conter
um losango na extremidade da classe que contém os objetos-todo. Essa análise dependerá do
domínio do problema em estudo. A Figura 2.12 ilustra a notação e um exemplo de Agregação.

Figura 2.12 – Notação e Exemplo de Agregação

Fonte: A autora (2016)

Outro tipo de Agregação é a Composição. Essa Associação é uma variação da Agregação, na
qual é estabelecido um vínculo mais forte entre o objeto-todo e os objetos-parte, demonstrando
que os objetos-parte devem se associar a um único objeto-todo. Utiliza-se um losango
preenchido para indicar a Composição. A Figura 2.13 ilustra a notação e um exemplo de
Associação Composição. Ambas as classes “vivem” unidas de forma dependente, ou seja, existe
uma ligação forte entre as duas. Os objetos da classe parte são dependentes, em termos de
existência, da classe todo, ambas são partes de um único todo. Os objetos da classe parte não
podem viver quando o todo é destruído. Utiliza-se um losango preenchido para indicar a
Composição.
Figura 2.13 – Notação e Exemplo de Composição

Fonte: A autora (2016)

Faça a leitura dos materiais para conhecer mais sobre o Diagrama de Classes!

O relacionamento do tipo Generalização representa uma classe genérica com características e

comportamentos comuns a outras classes especializadas, demonstrando a ocorrência de
herança e possivelmente de métodos polimórficos nas classes especializadas. A herança é a
possibilidade de uma classe utilizar os atributos e métodos de outra como se fossem seus. Na
representação desse relacionamento, a classe generalizada é chamada de “superclasse” e as
especializadas são chamadas de “subclasses”. Ainda na representação desse relacionamento,
pode ocorrer que uma subclasse herde atributos e operações de duas ou mais superclasses, o
qual indica uma herança múltipla. A Figura 2.14 ilustra a notação e um exemplo de Herança e
Herança Múltipla, o qual a subclasse Extensão herda características das superclasses Curso e
Evento.
Figura 2.14 – Notação e Exemplo de Herança e Herança Múltipla

Fonte: A autora (2016)

Saiba mais sobre a UML no link:

Vamos, agora, refletir sobre o Diagrama de Classes:

O Diagrama de Classes, conforme a classificação das técnicas de modelagem da UML é uma
técnica estrutural. Assim, qual é a aplicabilidade do Diagrama de Classes? Como é possível
consistir o Diagrama de Casos de Uso com o Diagrama de Classes?

RESUMO DA UNIDADE DE ENSINO:

Esta unidade apresentou uma contextualização UML e suas técnicas de modelagem,
classificadas em estruturais e comportamentais, que integram vários elementos (objetos,
classes, atributos, etc.) do paradigma orientado a objetos. Iniciou o estudo das técnicas de
modelagem da UML com o Diagrama de Casos de Uso, que é constituído dos elementos
gráficos Atores, Casos de Uso (Use Cases) e relacionamentos, para representar as
funcionalidades do sistema e suas interações. Após a especificação do Diagrama de Casos de
Uso, se faz a documentação de cada um, sendo o formato descritivo o mais recomendado.
Posteriormente, inicia-se uma primeira versão do Diagrama de Classes, que é constituído dos
elementos gráficos Classes e relacionamentos, conforme a abstração das regras de negócio do
sistema, para depois refiná-los em outras versões e visões até atender completamente a
solução proposta.
PRATIQUE!
Execute a ferramenta CASE que você instalou, conforme sugerimos na Unidade de Ensino 1, e
desenhe todos os diagramas que foram exemplificados nesta Unidade.
Bom trabalho!
REFERÊNCIAS
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 2. ed. Rio de Janeiro: Elsevier, 2007.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. 2. ed. Rio de Janeiro: Elsevier,
2006.
GUEDES, Gilleanes T. A. UML: uma abordagem prática. 3. ed. São Paulo: Novatec, 2008.
MEDEIROS, Ernani Sales de. Desenvolvendo software com UML 2.0: definitivo. São Paulo: Pearson, 2006.