DESCRIÇÃO

O desenvolvimento de sistemas orientado a objetos e a Linguagem Unificada de Modelagem

(UML) para criação de modelos, sob a forma de diagramas, com representação dos requisitos
e das soluções de análise e projeto de sistemas de qualquer porte e finalidade.

PROPÓSITO
Compreender a UML no contexto de desenvolvimento de sistemas orientado a objetos (ou não)
como uma ferramenta de construção de diagramas padronizados para ajudar a equipe de
desenvolvimento a entender o que o sistema deve fazer, num primeiro momento, e como o
sistema deve fazer, num momento seguinte. Disponibilizar diagramas que permitam enxergar o
sistema sob cinco diferentes perspectivas e usá-los da forma que convier, em consonância com
qualquer processo de desenvolvimento de sistemas.

PREPARAÇÃO
Antes de iniciar este conteúdo, é indicado ter instalado em seu computador um programa que
permita elaborar modelos sob a forma de diagramas da UML (Linguagem Unificada de
Modelagem). Nossa sugestão inicial é o Astah Free Student License, e será necessário usar
seu e-mail institucional para ativar a licença. Preencha os dados do formulário, envie e aguarde
a liberação de sua licença em seu e-mail institucional. Ao receber a licença, siga as instruções
do e-mail e instale o produto em seu computador.

Sugestões de links adicionais de ferramentas livres para modelagem de sistemas em UML

podem ser encontradas em buscas na internet.
OBJETIVOS

MÓDULO 1

Reconhecer a importância dos modelos na exposição de requisitos e soluções sistêmicas

MÓDULO 2

Distinguir os conceitos e pilares de análise e projeto orientados a objetos

MÓDULO 3

Descrever as visões, a síntese geral e os diagramas da UML

INTRODUÇÃO
Aprenderemos os conceitos básicos de modelagem de sistemas para compreender a realidade
do negócio inerente ao sistema e expor as soluções para atender às necessidades reais de
seus usuários. Iniciaremos pelo conceito de modelo e mostraremos sua aplicabilidade no
contexto de desenvolvimento de sistemas. Vamos compreender que existem diferentes
modelos que devem ser aplicados, sob a forma de templates e diagramas, nas diferentes fases
do processo de desenvolvimento do sistema.

Focaremos no desenvolvimento de sistemas orientado a objetos, compreendendo suas bases

conceituais e seus pilares de sustentação. Dentro desse contexto, conheceremos a Linguagem
Unificada de Modelagem (UML, do inglês Unified Modeling Language) e suas visões integradas
de modelos, sob diferentes perspectivas, para abarcar as diversas necessidades de
modelagem para exposição dos requisitos, das soluções de análise e de projeto do sistema em
construção. A UML é uma linguagem de modelagem independente de tecnologia, que pode ser
aplicada em diferentes processos e metodologias de desenvolvimento de sistemas orientados a
objetos.

MÓDULO 1

Reconhecer a importância dos modelos na exposição de requisitos e soluções

sistêmicas

CONCEITOS

Neste módulo, veremos por que são usados modelos, sob a forma de diagramas, durante o
processo de desenvolvimento de sistemas computacionais para expor as necessidades dos
usuários e as ideias dos desenvolvedores para a construção do novo sistema. Assim, vamos
conceituar e compreender a relevância da modelagem de sistemas.

O QUE SÃO MODELOS E PARA QUE ELES

SERVEM

EXEMPLO

Uma família decide adquirir um imóvel na planta para moradia. Ela vai, então, a um lançamento
imobiliário a convite de um corretor conhecido. Chegando lá, deparam-se com o terreno vazio e
um stand de vendas. Imediatamente, vem a dúvida: como escolher o bloco e o apartamento
para que não sejam devassados, considerando a vizinhança?

O corretor então inicia seu trabalho e leva a todos para conhecerem a maquete do
empreendimento − que nada mais é do que a representação do empreendimento em bloco
único − e a infraestrutura do parque aquático.

A maquete é uma representação, em miniatura, do condomínio real. É um modelo do

empreendimento real. Ou seja, o empreendimento real será construído à imagem e
semelhança da maquete construída.

A maquete é, portanto, um modelo (a base) a partir do qual o empreendimento real será

construído. É uma simplificação da realidade, de forma que decisões prévias possam ser
tomadas antes de sua construção, sob a perspectiva da construtora, e de sua aquisição, sob a
perspectiva do comprador.

No exemplo a seguir, encontramos maquetes de um empreendimento imobiliário, mostrando a

perspectiva externa, dando a visão clara da vizinhança, do posicionamento do imóvel, da
piscina e área de lazer e da entrada.

Podemos estabelecer, então, a primeira finalidade de um modelo: antecipar a existência

de uma realidade para avaliar sua estrutura e seu comportamento.

Voltando ao exemplo do imóvel:

Analisando a maquete e o posicionamento do empreendimento no terreno, os integrantes da

família verificam o bloco e a posição do imóvel que mais lhes interessam, avaliando as
vizinhanças e respectivas distâncias entre eles.

Maquete de um empreendimento

Em seguida, eles se sentam à mesa com o corretor para escolher a unidade no bloco
selecionado. O corretor então apresenta a tabela de preços de cada unidade do bloco
selecionado, informando a metragem, o valor da unidade e as condições de pagamento.

A família seleciona três unidades e pergunta sobre a disposição dos cômodos. O corretor então
apresenta a planta baixa de cada unidade selecionada. A imagem a seguir mostra a planta de
uma das unidades:

Planta de uma unidade de um empreendimento.

A planta ilustrativa da unidade é um segundo exemplo de modelo usado no mercado

imobiliário, que possibilita ao comprador avaliar o posicionamento e a dimensão de cada
cômodo.

A família decide-se pelo imóvel, fecha o negócio e recebe um pen drive contendo outras
plantas da unidade: elétrica, hidráulica, dentre outras. Cada uma dessas plantas representa um
modelo sob uma diferente perspectiva.

Outro exemplo de modelo muito comum atualmente são os protótipos, usados para aumentar
a chance de sucesso dos produtos. A partir de um protótipo inicial, outros modelos podem ser
demandados e aprimoramentos podem ser desenvolvidos. Os setores automobilístico e o de
desenvolvimento de sistemas usam com eficácia protótipos como modelos.

RESUMINDO

Modelo: representação abstrata e simplificada da realidade.

Uma realidade pode demandar diferentes modelos, dependendo da perspectiva com que
precise ser observada.

Finalidade principal: antecipar a existência de uma realidade de forma a avaliar sua

estrutura e comportamento.

MODELOS SE APLICAM AO CONTEXTO DE

DESENVOLVIMENTO DE SISTEMAS?

Na construção ou desenvolvimento de sistemas computacionais, assim como na construção

imobiliária, há uma gradação da complexidade no processo de construção, que depende de
alguns fatores, sendo o tamanho (do sistema ou do empreendimento) um deles.

Os modelos, além da finalidade inicial, funcionam também como instrumento de gerenciamento

da complexidade, considerando a limitação humana em lidar com ela. Os sistemas grandes e
complexos carecem de ser modelados para sua melhor compreensão em sua totalidade.

Modelos são capazes de revelar as propriedades essenciais de um sistema, ajudando no

processo de abstração (concentração nos pontos de interesse) e permitindo que foquem no
que é relevante.

Dentre os benefícios que podemos citar para o uso de modelos em desenvolvimento de

sistemas computacionais, além de tentar prever o comportamento do sistema e gerenciar sua
complexidade, destacam-se:

COMUNICAÇÃO ENTRE AS PESSOAS ENVOLVIDAS

O modelo serve como elemento de comunicação ou difusão de informações entre as pessoas
envolvidas em sua construção.

REDUÇÃO NOS CUSTOS DO DESENVOLVIMENTO

A construção de modelos é bem mais barata que a construção do sistema em si. A descoberta
de erros e falhas em modelos é bem menos onerosa e contribui para a redução dos custos
finais do sistema computacional. Isso também vale para as eventuais necessidades de ajustes
e melhorias no sistema.

FACILIDADE PARA ALTERAÇÕES DO SISTEMA

Depois de pronto, seja ainda na fase de construção ou de manutenção, os sistemas carecem
de ajustes e melhorias. A análise dessas melhorias tende a ser mais efetiva quando elaborada
sobre os modelos construídos, aumentando a assertividade e diminuindo seus custos. Daí a
relevância e a necessidade de manter os modelos sempre atualizados.
DOCUMENTAÇÃO DO SISTEMA
Os modelos servem de consulta e orientação a toda a equipe na construção e na manutenção
do sistema, incluindo pessoas que sejam integradas após o início do desenvolvimento do
sistema. Servem ainda para documentar as decisões tomadas.

DELIMITAR O ESCOPO DO SISTEMA

A modelagem ajuda na delimitação do escopo, ou seja, abrangência do sistema, definindo o
que será ou não tratado pelo sistema.

MODELAGEM DE SISTEMAS
Assim como exemplificamos no mercado imobiliário, no contexto de desenvolvimento de
sistemas computacionais podem ser usados diferentes modelos de um mesmo sistema, em
que cada um apresenta uma perspectiva (uma visão).

EXEMPLO

Um sistema armazena e manipula dados através de funcionalidades e possui determinados

controles. Poderíamos pensar então em três perspectivas e, dessa forma, construir modelos
que representem os dados, as funcionalidades e os controles, cada um focando uma
perspectiva diferente.

Outra perspectiva seria a visão externa, a de um usuário, que enxerga as funcionalidades

necessárias, mas desconhece o que ocorre internamente. Essa seria mais uma perspectiva e
mais um modelo que ajudaria nessa compreensão.

Outra forma de abordar os sistemas computacionais por meio de visões seria:

EXTERNA
COMPORTAMENTAL
ESTRUTURAL
INTERAÇÃO
EXTERNA

modela-se o ambiente em que o sistema está inserido, mostrando sua relação com os usuários
e demais sistemas com que interage.

COMPORTAMENTAL

modela-se o comportamento dinâmico do sistema e como ele reage aos eventos que o afetam.

ESTRUTURAL

modela-se sua estrutura organizacional ou os dados que o sistema processa.

INTERAÇÃO

modela-se as interações de seus componentes ou ainda do sistema e seu ambiente externo.

A construção dos diferentes modelos para um sistema compreende o que denominamos de

Modelagem de Sistemas, onde:

Os modelos são abstratos, deixando de lado os detalhes e concentrando-se nos aspectos

de interesse que são relevantes. A esse processo chamamos de abstração.

Cada modelo apresenta o sistema sob uma diferente visão ou perspectiva da realidade.

Os modelos são descritos em notações gráficas, que denominamos diagramas.

MODELAGEM DE SISTEMA DE SOFTWARE
CONSISTE NA UTILIZAÇÃO DE NOTAÇÕES
GRÁFICAS E TEXTUAIS COM O OBJETIVO DE
CONSTRUIR MODELOS QUE REPRESENTAM AS
PARTES ESSENCIAIS DE UM SISTEMA,
CONSIDERANDO-SE VÁRIAS PERSPECTIVAS
DIFERENTES E COMPLEMENTARES.

(BEZERRA, 2015)

Como veremos mais adiante, a UML é uma linguagem unificada de modelagem que permite a
construção de um conjunto de modelos, na forma de diagramas, sob diferentes visões ou
perspectivas que, em conjunto, integram a solução de modelagem do sistema quando
desenvolvido usando o paradigma orientado a objetos.

O PROCESSO DE DESENVOLVIMENTO DE
SISTEMAS EM FASES
O desenvolvimento de sistemas computacionais é um processo que envolve pessoas e a
necessidade de compreensão de uma realidade muitas vezes complexa e obscura,
principalmente no início do desenvolvimento (vide imagem a seguir), quando o nível de
abstração é alto e pouco se conhece da realidade.

Conforme as fases em que o processo de desenvolvimento é particionado se sucedem, o

conhecimento sobre o sistema aumenta, diminuindo, consequentemente, o nível de abstração
da realidade. Essa complexidade aumenta na medida em que o tamanho do sistema cresce,
requerendo um maior planejamento dos recursos a serem usados. O principal recurso no
desenvolvimento de um sistema são pessoas, profissionais capacitados.
 Realidade X Sistema

Num primeiro momento, precisamos compreender com muita clareza as necessidades das
pessoas que serão usuárias do sistema, o que elas precisam que o sistema faça para que
possam cumprir suas funções.

Esse entendimento passa, também, pela necessidade da confirmação dessa compreensão

pelas pessoas que estão construindo o sistema (os profissionais especializados).

Mas como entender e confirmar a compreensão numa linguagem ambígua como a nossa, tanto
a falada como a escrita?

Se construirmos o sistema diretamente na linguagem de programação, a partir de um suposto

entendimento da realidade, certamente teremos problemas de interpretação inadequada, e o
sistema tende a não atender às necessidades de seus usuários, sendo então abandonado.
Para representar adequadamente a realidade e entender o que se passa no contexto do
sistema a ser construído, precisamos traduzir a realidade em modelos.

FASES COMUNS E MAIS RELEVANTES DO

PROCESSO DE DESENVOLVIMENTO
Dentro desse raciocínio, os modelos nos ajudam a entender a realidade e discutir essa
compreensão, reduzindo a complexidade e o nível de abstração.

Os modelos são, portanto, uma representação simplificada da realidade, representando os

elementos de interesse naquele momento, permitindo abstrair o que não interessa e concentrar
naquilo que de fato é relevante para o desenvolvimento do sistema.

Desde os anos 1960, muitos processos, métodos e diversas técnicas de desenvolvimento de

sistemas foram criados e postos em prática, visando à construção de sistemas computacionais
robustos, eficientes e de fácil manutenção.

Objetivando um melhor gerenciamento da complexidade, os processos e as metodologias de

desenvolvimento de sistemas costumam ser divididos em fases.

Cada processo ou metodologia cria sua própria divisão, mas, de maneira geral, podemos citar
que (haverá exceção, logicamente) compreendem as fases de:

EXPLORANDO FERRAMENTAS E TÉCNICAS

DE LEVANTAMENTO DE REQUISITOS
Neste vídeo, vamos explorar a importância do levantamento de requisitos no processo de
Desenvolvimento de Software. Apresentaremos diversas ferramentas e técnicas utilizadas para
identificar, documentar e compreender as necessidades dos stakeholders.

IDENTIFICAÇÃO DOS REQUISITOS

requisitos podem ser entendidos como as necessidades que os usuários têm e que devem
estar contidos nas funcionalidades e propriedades do sistema a ser construído.

ANÁLISE
com base nos requisitos, compreende-se o que o sistema deve fazer em prol de seus
usuários.

PROJETO
compreende a adequação dos requisitos a como eles serão implementados, usando a
tecnologia adequada para tal, definindo sua arquitetura e seus componentes. Define-se ainda
toda a infraestrutura do ambiente computacional que será usada na construção do sistema,
como: redes de computadores, banco de dados, linguagem de programação, dentre outros
elementos.

IMPLEMENTAÇÃO
diz respeito à identificação dos programas necessários e sua codificação na linguagem de
programação selecionada na fase de projeto, bem como o banco de dados que será usado.

MODELOS COMO ELEMENTOS DE

COMUNICAÇÃO
Os modelos atuam em mão dupla enquanto elementos de comunicação no processo de
desenvolvimento de sistemas, ajudando:
a) no entendimento e na validação dos modelos junto aos usuários; e
b) no entendimento do sistema por membros da equipe de desenvolvimento.

ENTENDIMENTO E VALIDAÇÃO DOS MODELOS

JUNTO AOS USUÁRIOS

A partir dos modelos, compreendemos e nos certificarmos do correto entendimento da

realidade junto aos usuários, conforme ilustrado a seguir (Momento 1, Momento 2 e Momento
3):

Equipe levantando dados junto aos usuários

Momento 1: A equipe de desenvolvimento se reúne com os usuários e, usando técnicas de

levantamento de dados, compreende a realidade e as necessidades que os usuários têm,
visando a que sejam implementadas no sistema. Os dados levantados são registrados e
usados na construção dos modelos. Esse momento acontece com maior intensidade na fase
de requisitos, mas também se faz presente nas fases de análise e de projeto.
Equipe construindo os modelos.

Momento 2: A equipe de desenvolvimento constrói os modelos que julga pertinentes para que
se possa compreender e destacar os aspectos relevantes da realidade. Esse momento
acontece nas fases de requisitos, análise e projeto.

Equipe validando dados junto aos usuários.

Momento 3: A equipe de desenvolvimento se reúne com os usuários, apresentando e

discutindo os modelos construídos, visando validá-los e responder à pergunta base: os
modelos que construímos representam de fato a realidade dos usuários? Em caso positivo,
prossegue-se no desenvolvimento; caso contrário, os modelos são ajustados e confirmados
novamente junto aos usuários, até que estejam adequados. Esse momento acontece nas fases
de requisitos, análise e projeto.
ENTENDIMENTO DO SISTEMA POR MEMBROS
DA EQUIPE DE DESENVOLVIMENTO

Outra finalidade dos modelos no desenvolvimento de sistemas é orientar membros da equipe

quanto a suas tarefas no processo.

EXEMPLO

O programador deve construir os programas, mas não tem livre acesso aos usuários e nem
precisa, pois os modelos servem como elementos de comunicação com todos da equipe. Os
projetistas do software devem compreender a realidade dos requisitos para construir os
modelos de projeto, por isso precisam ler os modelos das fases de requisitos e de análise. Os
programadores consultam os modelos de seu interesse e conversam com os membros que
fizeram o levantamento de dados e a modelagem para compreenderem melhor o contexto e
desenvolverem com mais eficiência os programas necessários.

Outro exemplo seria um projetista de interface, que precisa conhecer o funcionamento de

determinado recurso para criar a interface necessária, então ele consulta o modelo que exibe a
comunicação do usuário com o sistema para a referida funcionalidade. Esse momento
acontece em todas as fases do projeto, pois sempre haverá desenvolvedores recebendo
tarefas e consultando os respectivos modelos pertinentes.

A imagem a seguir ilustra a consulta de diferentes pessoas da equipe aos modelos

desenvolvidos.

Equipe consultando os modelos

APLICAÇÃO DOS MODELOS AO
DESENVOLVIMENTO DE SISTEMAS
O especialista Marcelo Vasques de Oliveira resume os conceitos sobre modelagem e a sua
aplicação no contexto do processo de desenvolvimento de sistemas.

VERIFICANDO O APRENDIZADO
MÓDULO 2

Distinguir os conceitos e pilares de análise e projeto orientados a objetos

CONCEITOS

Neste módulo, compreenderemos os conceitos, pilares, princípios e as orientações do

paradigma orientado a objetos. Veremos também as visões, os objetivos e as entregas dos
momentos de análise, projeto e implementação (em camadas), independentemente de
processo ou metodologia de desenvolvimento de software.

PARADIGMA ORIENTADO A OBJETOS

Com o aumento do tamanho do código e da complexidade dos programas, o paradigma
estruturado, que antecedeu o paradigma orientado a objetos, começou a apresentar limitações
nos sistemas sob o ponto de vista da dificuldade de manutenção e reuso de programas e
rotinas padronizadas.

Vamos, inicialmente, definir o termo paradigma como a maneira de abordar um

problema.

A orientação a objetos surge como solução a esses problemas, permitindo − mediante

propriedades como abstração, encapsulamento, herança e polimorfismo − maior organização,
reaproveitamento e extensibilidade de código e, consequentemente, programas mais fáceis de
serem escritos e mantidos.

O principal foco do paradigma orientado a objetos é permitir o desenvolvimento de sistemas de

forma mais rápida e confiável.

Um dos criadores do paradigma orientado a objetos, Alan Kay, imaginou um sistema como um
conjunto de agentes autônomos, os objetos, que interagem entre si.

Ele definiu os princípios centrais da orientação a objetos:

Qualquer coisa do mundo real é um objeto

Objetos realizam tarefas requisitando serviços a outros objetos

Os objetos similares são agrupados em classes e cada objeto pertence a uma classe

A classe determina o comportamento possível a um objeto

Classes são organizadas em hierarquias

O PARADIGMA DA ORIENTAÇÃO A OBJETOS

VISUALIZA UM SISTEMA DE SOFTWARE COMO
UMA COLEÇÃO DE AGENTES
INTERCONECTADOS CHAMADOS OBJETOS.
CADA UM DELES É RESPONSÁVEL POR
REALIZAR TAREFAS ESPECÍFICAS E, PARA
CUMPRIR COM ALGUMAS DAS TAREFAS SOB
SUA RESPONSABILIDADE, UM OBJETO PODE
TER QUE INTERAGIR COM OUTROS. É PELA
INTERAÇÃO ENTRE ELES QUE UMA TAREFA
COMPUTACIONAL É EXECUTADA. UM SISTEMA
DE SOFTWARE ORIENTADO A OBJETOS
CONSISTE, PORTANTO, EM OBJETOS
COLABORANDO PARA REALIZAR AS
FUNCIONALIDADES DESSE SISTEMA. É GRAÇAS
À COOPERAÇÃO ENTRE OS OBJETOS QUE A
COMPUTAÇÃO DO SISTEMA SE DESENVOLVE.

(BEZERRA, 2015)

ATENÇÃO

Observação: Ao longo do texto, abreviaremos o termo "orientação a objetos" como O.O.

CONCEITOS FUNDAMENTAIS DA
ORIENTAÇÃO A OBJETOS
A orientação a objetos enfatiza a identificação, a representação e a organização dos objetos
necessários ao funcionamento de um sistema. Tem por base os conceitos de objetos, classes,
operação, mensagem e estado, e está calcada em quatro pilares fundamentais: abstração,
encapsulamento, herança e polimorfismo, discutidos na sequência.

Neste tópico, adentraremos nesses conceitos fundamentais da orientação a objetos.

OBJETOS E CLASSES

Um objeto pode referenciar qualquer coisa do mundo real: um aluno, uma disciplina, um
curso, um professor, entre outros, considerando um sistema acadêmico como contexto. Ou
seja, um objeto é qualquer coisa do mundo real, de interesse no contexto em estudo.
Quando analisamos os objetos pertinentes a um contexto, não estamos preocupados com um
objeto específico como, por exemplo, o aluno “José Carlos Aragão”, e sim com todos os alunos
envolvidos no estudo. Surge então o conceito de classe que, conceitualmente, reúne (agrupa)
um conjunto de objetos com as mesmas propriedades. Ou seja, estamos interessados em
todos os alunos e não apenas em “José Carlos Aragão”. Usando o princípio da abstração (que
detalharemos mais adiante), temos que uma classe agrupa objetos com as mesmas
características ou propriedades, que são seus dados (atributos) e seus procedimentos
(métodos) que implementam os serviços que essa classe vai prestar.

A classe ALUNO agrupa “José Carlos Aragão” e os demais alunos envolvidos. Um objeto é um
elemento específico de uma classe, ou ainda uma instância de uma classe.

As classes são, portanto, abstrações que definem uma estrutura que encapsula dados
(chamados de atributos) e um conjunto de operações possíveis de serem usados, chamados
métodos. Por exemplo, a classe ALUNO encapsula um conjunto de dados que identifique os
alunos − matrícula, nome, endereço (rua, número, complemento, estado e CEP), CPF e
Identidade − e um conjunto de métodos: Incluir Aluno, Matricular Aluno, Cancelar Matrícula,
dentre outros.

RESUMINDO

Classe: abstração das características de um grupo de coisas do mundo real.

Objeto: um elemento específico de uma classe ou uma instância de uma classe.

A seguir, temos a representação de uma classe em três compartimentos: o nome da classe

(ALUNO), seus atributos (Matrícula... Identidade) e métodos (Incluir Aluno... Cancelar
Matrícula).
 Classe ALUNO

A seguir, temos a representação de dois objetos da classe ALUNO:

Objeto − Aluno 1 da classe ALUNO.

Objeto Aluno 2 da classe ALUNO

OPERAÇÃO, MENSAGEM E ESTADO

Um sistema orientado a objetos consiste na cooperação entre seus objetos. Cada um tem uma
responsabilidade no sistema, correspondendo à parte das funcionalidades que lhes são
atribuídas. Em outras palavras, uma tarefa computacional é realizada pela interação entre seus
objetos, cada um executa parte da tarefa.

OPERAÇÃO
MENSAGEM
ESTADO

OPERAÇÃO

Operação é o nome dado a cada ação (função) que o objeto sabe realizar. Mas um objeto não
realiza nenhuma ação sem uma motivação, sem um estímulo.

MENSAGEM

Chamamos esse estímulo de mensagem, que chega a um objeto e solicita que ele realize uma
de suas operações. Uma operação, por sua vez, pode ser implementada por meio de pelo
menos um método.

Em outras palavras, cada objeto presta um serviço. Quando um objeto precisa de um serviço
da responsabilidade de outro, ele precisa enviar uma mensagem a ele. Cada mensagem ativa
uma das operações do objeto.

ESTADO

Já sabemos que um objeto contém atributos, que são dados necessários para prestar os
serviços que cabem a esse objeto. Por definição, chama-se estado do objeto o conjunto de
valores de seus atributos em dado momento. Uma mensagem enviada a um objeto pode (ou
não) alterar o seu estado, na medida em que pode alterar um ou mais valores de seus
atributos.

OBJETO

Imagine, por exemplo, que o objeto Notas_Aluno contenha as notas do aluno em determinada
disciplina. Em dado momento, é recebida uma mensagem informando uma nova nota a ser
armazenada. O estado desse objeto foi alterado, pois um de seus atributos recebeu a nova
nota. Agora suponha que determinado objeto enviou uma mensagem a Notas_Aluno
solicitando que seja exibida a média atual; nesse caso, não houve alteração de estado, pois as
notas foram consultadas, e a média foi calculada (não fica armazenada) e exibida.

Partes de um objeto

OS PILARES DA ORIENTAÇÃO A OBJETOS

Dentre as principais características do paradigma orientado a objeto (O.O.), destacamos:

ABSTRAÇÃO
É um processo mental que permeia toda a orientação a objetos, como um princípio básico que
serve de base aos demais princípios. A abstração permite que, ao estudar algo, ponhamos
nossa concentração nos aspectos relevantes e deixemos de lado os menos importantes.
Permite, portanto, gerenciar a complexidade de um objeto para que possamos nos ater às suas
propriedades essenciais. E os aspectos essenciais de um objeto dependem, claro, do contexto
no qual os analisamos, podendo variar. Ou seja, uma propriedade de um objeto pode ser
relevante em um contexto e não ser em outro.

ENCAPSULAMENTO
O objeto esconde (encapsula) seus dados (atributos) do acesso indevido por outros objetos e
somente permite que eles sejam acessados por operações implementadas pelos seus próprios
métodos (funcionalidades que implementam o comportamento do objeto). Com isso, o
encapsulamento protege os dados do objeto do uso arbitrário ou não intencional, como pode
ser visualizado na figura seguinte. O encapsulamento é uma técnica para minimizar a
interdependência entre as classes, pois apenas os métodos da respectiva classe podem alterar
seus dados (atributos), facilitando a identificação de erros e a alteração dos programas. Em
outras palavras, garante que apenas os métodos da própria classe possam alterar o estado de
um objeto.

Encapsulamento

HERANÇA
Mecanismo para derivar novas classes a partir da definição de classes existentes, com base
em um processo de refinamento. Uma classe derivada ou descendente herda os dados
(atributos) e o comportamento (métodos) da classe base ou ancestral ou ascendente. A
implementação da herança garante a reutilização de código, que, além de economizar tempo e
dinheiro, propicia mais segurança ao processo de desenvolvimento, posto que as
funcionalidades da classe base podem ter sido usadas e testadas.

POLIMORFISMO
A palavra polimorfismo deriva do grego e significa “muitas formas”. A partir do momento em
que uma classe herda atributos e métodos de uma (herança simples) ou mais (herança
múltipla) classes base, ela tem o poder de alterar o comportamento de cada um desses
procedimentos (métodos). Isso amplia o poder do reaproveitamento de código promovido pela
herança, permitindo que se aproveite alguns métodos e se altere (redefina) outros. Dessa
forma, um método com mesmo nome em classes distintas pode ter diferentes comportamentos.

EXEMPLIFICANDO HERANÇA E POLIMORFISMO

Acompanhe o exemplo da imagem a seguir, na qual identificamos uma herança: Pagamento

em Dinheiro, Pagamento em CC (Cartão de crédito) e Pagamento em Cheque herdam da
classe Pagamento, o atributo Valor e o método Pagar.

Herança e polimorfismo

Observe que, em cada classe filha (Pagamento em Dinheiro, Pagamento em Cartão e

Pagamento em Cheque), o método PagarConta é escrito de forma diferente, com distintos
parâmetros e códigos internos, conforme exige a respectiva forma de pagamento. Essa
possibilidade ocorre pelo princípio do polimorfismo.

ORIENTAÇÃO A OBJETOS COMO

ELEMENTO DE REUSABILIDADE E
EXTENSIBILIDADE
A orientação a objetos minimiza a gestão da complexidade na medida em que permite uma
organização mais adequada de seus componentes, além de seu reaproveitamento. Um dos
principais motivos para a baixa produtividade na construção de sistemas computacionais é a
dificuldade de reutilização de código.

As hierarquias de classes (herança) são estruturas que permitem o seu reaproveitamento entre
aplicações que, se bem projetadas, podem ser reutilizadas em vários sistemas, otimizando
tempo e dinheiro.

Além disso, tais estruturas podem ser estendidas (usando o princípio do polimorfismo) sem
corromper o que já existe. Dessa forma, pode-se concluir que a orientação a objetos traz em si
os seguintes benefícios:

REUSABILIDADE
EXTENSIBILIDADE

REUSABILIDADE

O uso de componentes já escritos pode ser a base para outros softwares (através da herança).

EXTENSIBILIDADE

Novos componentes podem ser desenvolvidos a partir de outros, já desenvolvidos, sem afetar
o comportamento do componente de origem (mediante o princípio do polimorfismo) e
permitindo que esse comportamento seja alterado, estendido para um novo contexto.

ANÁLISE DE SISTEMAS ORIENTADA A

OBJETOS
Antes de adentramos no universo da análise sob o enfoque do paradigma orientado a objetos,
vamos tecer rápidos comentários acerca do que seja a atividade de análise no contexto do
desenvolvimento de software.

De forma simples, pode-se dizer que a atividade de análise visa identificar o que os usuários e
os demais interessados (que juntos formam os stakeholders) precisam que o sistema faça.

Análise de sistemas implica numa investigação dos problemas e dos requisitos (necessidades
dos usuários) de um contexto, em particular, visando a construção de um sistema
automatizado.

ATENÇÃO

O foco da atividade de análise é estudar e entender o funcionamento de um sistema sob pelo

menos alguns pontos de vista: da estrutura que sustenta o sistema (os dados); dos
procedimentos e processos intervenientes no sistema; da dinâmica de funcionamento do fluxo
de informações e dados, dentre outros aspectos que podem ser adicionados, dependendo da
especificidade do sistema em construção.

A atividade de análise, por ser muito abrangente, costuma ser dividida em: levantamento de
requisitos (investigação dos requisitos) e análise dos requisitos.

Inicialmente, entendemos a realidade, identificamos a abrangência do sistema e capturamos as

necessidades dos usuários desse sistema, usando técnicas específicas (levantamento de
requisitos).

Posteriormente, analisamos e entendemos essas necessidades e o funcionamento e a

dinâmica da organização (análise dos requisitos), visando à construção de modelos que
representem o sistema a ser desenvolvido, em sua concepção lógica, sem preocupação com
qualquer recurso tecnológico que venha sustentar o seu funcionamento.

A atividade de análise não leva em consideração nenhum recurso tecnológico que possa ser
utilizado pelo sistema em construção. A ideia é construir uma estratégia de solução sem
considerar como (com que tecnologia) essa estratégia será construída.

A preocupação da atividade de análise é identificar: O QUE o sistema deve fazer para atender
às necessidades de seus usuários.

A sua finalidade é construir a melhor solução, que possa ser implementada em qualquer
tecnologia (plataforma operacional, linguagem de programação e banco de dados), de acordo
com as disponíveis no mercado, naquele momento.

No contexto da orientação a objetos, foca-se na identificação, no entendimento e na definição

dos objetos de software e em como eles irão colaborar para que os requisitos dos usuários
sejam respondidos satisfatoriamente.

LEVANTAMENTO DE REQUISITOS

Nesta fase, o foco é conversar com as pessoas envolvidas com o sistema (patrocinadores,
gestores, usuários atuais e futuros e demais envolvidos) e compreender as necessidades e
desejos de cada um. O foco, portanto, é na compreensão do problema.

As necessidades e os desejos que os usuários têm são, tecnicamente, chamados de

requisitos. Os desenvolvedores e as demais pessoas envolvidas se reúnem, visando à
identificação dos requisitos do sistema, considerando o contexto específico e o domínio do
problema (área do conhecimento ou atividade específica) a que o sistema se aplica.

REQUISITOS

Requisito pode ser definido como sendo uma condição ou capacidade que deve ser alcançada
por um sistema para satisfazer uma necessidade.

Para que os desenvolvedores possam identificar as necessidades dos usuários do sistema, é

usado um conjunto de técnicas de levantamento de dados, desde as tradicionais entrevistas,
reuniões, observação do ambiente do usuário e questionários até técnicas mais sofisticadas
como brainstorm.

O produto gerado por essa fase é o documento de requisitos, que contém todos os requisitos
necessários ao sistema, classificados em :
REQUISITOS FUNCIONAIS
Declaram as funcionalidades necessárias ao sistema.

REQUISITOS NÃO FUNCIONAIS

Apresentam algumas características associadas a uma, algumas ou todas as funcionalidades,
e dizem respeito a aspectos de qualidade, confiabilidade, desempenho, portabilidade,
segurança e usabilidade do sistema.

EXEMPLO

Imagine um sistema financeiro, no qual haja a necessidade das seguintes funcionalidades:

Cadastramento dos pagamentos, Quitação dos pagamentos, Cadastramento das
receitas, Quitação das receitas e Emissão das faturas.

Cada uma das cinco funcionalidades anteriores representa um requisito funcional do sistema.
Imagine, então, que o sistema precise ser touch screen. Tal característica da funcionalidade
Emissão das faturas é um requisito não funcional de usabilidade (relacionada com uma
interface de qualidade). Outro requisito não funcional de segurança seria a necessidade de um
backup diário da base de dados.

A correta identificação e seu registro no documento de requisitos são cruciais para a precisão
e a qualidade do processo de desenvolvimento do sistema. Um requisito faltante ou outro mal
definido pode ser fatal para seu sucesso.

DICA

O documento de requisitos seguirá como base da comunicação entre os desenvolvedores e

os usuários, devendo ser validado por estes, uma vez que servirá de norte para as atividades
subsequentes do desenvolvimento do sistema. É, portanto, fundamental a participação ativa e
efetiva dos usuários do sistema na fase de levantamento de requisitos.

No documento de requisitos estará definido, também, o escopo do sistema.

O principal ponto da fase de levantamento de requisitos é compreender profundamente no

sistema antes de iniciar a sua construção.
ANÁLISE DE REQUISITOS

A fase de análise de requisitos é a transposição dos registros dos requisitos funcionais e não
funcionais para os modelos que a equipe pretende usar.

A principal atividade é desdobrar os requisitos funcionais em funcionalidades do sistema, uma

vez que não necessariamente há uma relação de 1 para 1, ou seja, um requisito funcional pode
demandar mais de uma funcionalidade e uma funcionalidade pode agregar mais de um
requisito funcional.

A análise de requisitos tem, minimamente, duas perspectivas ou visões:

ANÁLISE DO DOMÍNIO (OU DO NEGÓCIO)

Visa a identificar ou modelar os objetos que serão usados na aplicação. Por exemplo,
Pagamento é um objeto no contexto do sistema financeiro, usado para exemplificar os
requisitos funcionais. Logo, Pagamento é um objeto do domínio, assim como Recebimento e
Fatura.

ANÁLISE DA APLICAÇÃO
Em geral, sucede a análise do domínio. Nela, são identificados os objetos de análise que não
fazem sentido para os analistas de domínio, mas que são fundamentais para atender às
funcionalidades necessárias ao sistema, a aplicação em si (daí seu nome). Por exemplo, uma
interface de cadastramento de pagamentos é um objeto de aplicação do sistema de controle
financeiro. Nesse momento, o foco é apenas a identificação desse objeto, sem especificar sua
implementação, o que será detalhado na fase de Projeto (descrita adiante).

Análise do domínio

Objetos do domínio (relacionado ao problema)

Análise da aplicação

Objetos da aplicação (relacionado a aspectos computacionais de alto nível)

Os principais diagramas UML usados nas fases de análise são: diagramas de casos de uso e
diagrama de classes. Além desses, ajudam também diagramas de interação e de estados, em
alguns casos.

Análise pode ser traduzida em ”faça a coisa certa”.

PROJETO (DESENHO) DE SISTEMAS

ORIENTADO A OBJETOS
A atividade de projeto denota uma solução, voltada a atender aos requisitos identificados na
fase de análise, considerando os recursos tecnológicos necessários para implementar os
objetos do domínio e os objetos da aplicação.

O objetivo é decidir “como o sistema funcionará” para atender aos requisitos. Em geral, o
projeto enfoca a definição da arquitetura do sistema, determinando suas partes e a relação
entre elas, o padrão de interface gráfica, o ambiente computacional (sistema operacional e
computacional), a linguagem de programação o gerenciamento do banco de dados.

O projeto, portanto, deriva da análise e produz uma descrição dos recursos computacionais e
de como o sistema deve executar no dia a dia. Muitas vezes algumas restrições tecnológicas
podem ser impostas como, por exemplo, desenvolver na linguagem X, pelo fato de os sistemas
da organização estarem nessa linguagem (claro, se ainda existir no mercado), ou usar o
sistema gerenciador de banco de dados Y, pelo fato de a base corporativa da organização estar
nele.

A fase de projeto pode ser dividida em:

PROJETO DA ARQUITETURA
Ato de distribuir as classes de análise em subsistemas com seus componentes, bem como
distribuir os componentes pelos recursos de hardware disponíveis. Dentre os diagramas da
UML, usamos aqui os diagramas de pacotes, componentes e implantação.

PROJETO DETALHADO
Compreende atividades como modelagem das colaborações entre os objetos, projeto da
interface, projeto do banco de dados e aspectos computacionais de alto nível (concorrência e
distribuição de processamento e dados). O projeto de algoritmos pode ser considerado aqui
também, detalhando aspectos do que for relevante para o projeto. Dentre os diagramas UML
usados aqui, destacam-se: diagrama de interação (sequência ou comunicação), atividades (se
demandar detalhamento de um método ou método com processamento paralelo),
detalhamento do diagrama de classes, de estados, dentre outros detalhados adiante.

Observação: Projeto pode ser traduzido em “faça certo a coisa”.

DESENVOLVIMENTO DE SISTEMAS EM
CAMADAS
Abordaremos, inicialmente, a arquitetura de projeto de software em camadas de uma forma
geral, sem nos atermos a um modelo em especial. O foco é separar o desenvolvimento do
código em camadas, diminuindo sua complexidade e facilitando a sua manutenção. Camadas
separam as responsabilidades e gerenciam as dependências.

No início da computação, os sistemas eram monolíticos, ou seja, todo o código ficava

confinado numa única camada, onde misturavam-se comandos de processamento, de
construção e manipulação de interface, bem como de acesso e persistência de dados em
SGBD. “Tudo junto e misturado”.

Quando era preciso fazer manutenção no código, havia dificuldade no entendimento e na

separação do que de fato precisava ser alterado, sem contar a interferência em uma parte do
código quando se alterava outra, em princípio sem relação entre si.
À medida que os sistemas cresceram e se tornaram complexos, a manutenção ficou mais difícil
e a divisão em camadas foi uma das soluções encontradas para o projeto de arquitetura de um
software.

Num primeiro momento, a rede cliente-servidor, naturalmente, dividiu o software em duas

camadas: a camada de código que roda no cliente (camada de interface com usuário) e a
camada servidor (camadas de lógica do negócio e persistência dos dados). Posteriormente,
com o advento da web, separou-se em três e depois em quatro camadas. Atualmente, pode-se
criar tantas camadas quantas sejam necessárias, em função do tipo de aplicação.

As camadas em geral:

• Possuem alta coesão e baixo acoplamento, ou seja, concentram atividades afins (coesão) e
são independentes umas das outras.
• Possuem propósito bem definido.
• A camada superior tem conhecimento apenas da imediatamente inferior, que fornece os
serviços, por uma interface.

No caso da orientação a objetos, as classes são organizadas em módulos maiores, as

chamadas camadas. Uma camada somente pode usar serviço (de outras classes) da camada
imediatamente inferior.

A seguir, as vantagens e desvantagens do desenvolvimento de software em camadas:

VANTAGENS
- Torna o código mais organizado e legível.
- Permite o desenvolvimento, o teste e a manutenção das camadas isoladamente.
- Permite melhor reuso do código ou dos objetos.
- Pode substituir uma tecnologia que implemente uma camada, de forma simples, sem interferir
nas demais. Por exemplo, para trocar o SGBD de SQL Server para PostgreSQL, basta alterar a
camada de persistência. As demais permanecem como estavam.
- Disciplina as dependências entre as camadas.
- Mais adaptável a uma quantidade maior de usuários.

DESVANTAGENS
- Aumenta o número de classes do sistema.
- A adição de camadas torna o sistema mais complexo.
- Potencialmente, reduz o desempenho do software.

Como exemplo, podemos citar o modelo de camadas mais usado nos últimos anos, o de três
camadas, que engloba as camadas de:

APRESENTAÇÃO
Compreende as classes do sistema que permitem a interação com o usuário, as chamadas
classes de fronteira.

NEGÓCIO
Compreende as classes responsáveis pelos serviços e pelas regras do negócio, ou seja, reúne
as classes de controle e negócio.

DADOS
Responsável pelo armazenamento e pela recuperação dos dados persistentes do sistema, ou
seja, as classes de persistência de dados.

RESUMO DAS FASES DE ANÁLISE E

PROJETO DE SISTEMAS ORIENTADOS A
OBJETOS
O especialista Marcelo Vasques de Oliveira resume as fases de análise e projeto de sistemas
orientados a objetos.

VERIFICANDO O APRENDIZADO

MÓDULO 3

Descrever as visões, a síntese geral e os diagramas da UML

CONCEITOS

Neste módulo, conheceremos a UML (Unified Modeling Language ou Linguagem Unificada

de Modelagem). Essa linguagem padronizada oferece um conjunto de diagramas, sob
diferentes visões, que permitem a modelagem de sistemas orientada a objetos, independente
de tecnologia e de processos e metodologias de desenvolvimento de sistemas, cabendo seu
uso em qualquer contexto de desenvolvimento orientado a objetos.

O QUE É UML, AFINAL?

No final dos anos 1990, as linguagens de programação orientadas a objeto já eram uma
realidade, e cada profissional que desenvolvia atividade de análise e projeto de sistemas criava
seus próprios modelos, baseados em suas necessidades e realidade. Ou seja, não havia
consenso no mercado sobre os modelos a serem usados para modelagem de sistemas
desenvolvidos sob a tecnologia de orientação a objetos.

Três competentes profissionais despontavam com seus modelos naquele momento:

• Ivar Jacobson, idealizador do método OOSE (Object-Oriented Software Engineering).

• James Rumbaugh, criador do método OMT (Object, Modeling Technique).
• Grady Booch, criador do método que leva seu nome.

A UML foi então adotada pela OMG (Object Management Group), em 1997, oriunda da
integração dos três métodos anteriormente descritos, como uma linguagem de modelagem
padrão para sistemas desenvolvidos sob o paradigma orientado a objetos.

UML TORNOU-SE O PADRÃO PARA MODELAGEM

GRÁFICA, NÃO APENAS PARA OBJETOS E, DE
FATO, FAZ SENTIDO ESSA AFIRMATIVA, POIS A
UML PODE SER A LINGUAGEM DE MODELAGEM
PARA DIAGRAMAR SISTEMAS CONCORRENTES
E DISTRIBUÍDOS.

(FOWLER, 2005.)

Desde sua versão inicial, a UML sofreu mudanças substanciais e atualmente encontra-se em
sua versão 2.5.1, de dezembro de 2017.

A UML é, portanto, uma linguagem padrão para construção de projetos de sistemas, voltada
para a visualização, a especificação, a construção e a documentação de artefatos de um
sistema. Foi projetada para ser independente do método ou processo de desenvolvimento
utilizado.

A UML é uma linguagem de modelagem, não é um método de desenvolvimento nem

tampouco uma metodologia ou um processo de desenvolvimento de sistemas, uma vez
que não determina a ordem e nem como os diagramas devem ser usados. Simplesmente
disponibiliza os diagramas, sob as várias visões necessárias ao desenvolvimento de sistemas,
e cada empresa (ou equipe de desenvolvimento) a utiliza da forma como lhe convenha, ou
seja, adequando a UML ao seu processo ou metodologia de desenvolvimento de sistemas.

A UML é uma linguagem destinada a:

VISUALIZAÇÃO
ESPECIFICAÇÃO
CONSTRUÇÃO

VISUALIZAÇÃO

A modelagem gráfica facilita a compreensão do sistema e das decisões tomadas em análise e

projeto, além de melhorar a comunicação entre a equipe, permitindo sua interpretação sem
ambiguidades.

ESPECIFICAÇÃO

Permite a construção de modelos precisos, não ambíguos e completos sob diferentes visões e
atendendo às necessidades de modelagem das diferentes fases do processo de
desenvolvimento de software, independentemente do processo ou modelo usado.

CONSTRUÇÃO

Os diagramas UML podem ser integrados às principais e mais populares linguagens de

programação do mercado, tais como Java e C++. Mas, para isso, terá que buscar uma solução
integrada de ferramenta CASE (Computer-Aided Software Engineering) que gere código
fonte (para linguagens específicas) a partir de alguns diagramas UML.
 RESUMINDO

A UML é uma linguagem de modelagem padronizada.

• A UML é independente de tecnologia, adequando-se a todo método, metodologia ou processo

de desenvolvimento.
• A UML não diz quais diagramas usar e nem em que ordem, pois a metodologia de
desenvolvimento ditará essa ordem.
• A UML disponibiliza diagramas sob diferentes visões ou perspectivas.

A UML SE TORNOU NÃO SOMENTE A NOTAÇÃO

GRÁFICA DOMINANTE DENTRO DO MUNDO
ORIENTADO A OBJETOS, COMO TAMBÉM UMA
TÉCNICA POPULAR NOS CÍRCULOS NÃO
ORIENTADO A OBJETOS.

(FOWLER, 2005)

VISÕES DA UML
Assim como vimos nos exemplos do empreendimento imobiliário, as plantas das unidades, a
planta elétrica, a planta hidráulica, dentre outras, cada modelo tinha uma perspectiva de
compreensão da mesma realidade (unidades residenciais em um empreendimento). No mundo
de sistemas computacionais, o mesmo acontece com relação à modelagem de sistemas com
UML. Os autores da UML entendem que um sistema deve ser visto sob cinco diferentes
perspectivas ou visões, descritas a seguir:

VISÃO DE CASOS DE USO

Assim como a maquete permite uma perspectiva geral do empreendimento imobiliário, sob o
ponto de vista externo (visão do comprador), a visão de caso de uso permite olhar o sistema
sob o ponto de vista externo, do usuário, descrevendo seu comportamento por conjunto de
interações usuário-sistema. Tal qual a maquete, é a primeira perspectiva de um
empreendimento; a visão de caso de uso é criada no estágio inicial do desenvolvimento e guia
todas as demais visões, na medida em que captura os requisitos funcionais que definem o
sistema.

VISÃO DE PROJETO (OU LÓGICA)

Permite visualizar o sistema sob o ponto de vista de sua estrutura interna e seu
comportamento, em resposta às funcionalidades externamente percebidas por seus usuários.
Enfatiza os pacotes, as classes, as interfaces, os subsistemas (pacotes) e as colaborações.

VISÃO DE IMPLEMENTAÇÃO (OU DE

DESENVOLVIMENTO)
Compreende o gerenciamento das versões do sistema, ou seja, de suas implementações
utilizáveis por seus usuários. Compreendem os componentes, subsistemas e arquivos que
compõem fisicamente o sistema.

VISÃO DE IMPLANTAÇÃO (OU FÍSICA)

Enfatiza a distribuição física do sistema em suas partes (subsistemas e componentes) e as
respectivas conexões entre elas. Enfatiza também a organização física dos computadores e as
conexões entre eles (a rede de computadores).

VISÃO DE PROCESSO
Enfatiza aspectos físicos mais peculiares como concorrência, sincronismo entre sistemas e
desempenho (performance, confiabilidade, tolerância a falhas e outros aspectos) do sistema,
considerando os processos e os processadores.

A UML implementa diagramas que atuam nas cinco visões descritas anteriormente, permitindo
ampla modelagem sobre todos os aspectos (visões) relevantes do sistema.

Nem todas as perspectivas ou visões são úteis em todo desenvolvimento, pois dependem das
características, tipo e complexidade do sistema. A imagem a seguir mostra a ideia central da
visão de casos de uso, influenciando todas as demais.
 Visões da UML

UML E INTEGRAÇÃO COM PROCESSOS DE

DESENVOLVIMENTO
A UML é independente de metodologia e processo de desenvolvimento. Isso é positivo para os
fabricantes de software que implementam UML, pois não limita seu mercado.

Sendo assim, cabe a cada empresa ou equipe de desenvolvimento a integração da UML com
sua metodologia de desenvolvimento de sistemas computacionais, permitindo uma modelagem
eficiente.

A UML pode ser usada de diversas formas, desde esboços manuais para interação com
usuários ou equipe, passando pelo uso de ferramentas de diagramação UML até sofisticadas
ferramentas CASE, que integram os modelos e geram código em linguagens específicas.

A UML então pode ser adaptada em qualquer processo, seja ele:

EM CASCATA
Com e sem retroalimentação, onde as fases se sucedem, a seguinte inicia quando a anterior
termina. A desvantagem é que, se for sem retroalimentação, não há opção de retorno à fase
anterior. Por exemplo, se na fase de projeto identificamos novos requisitos, estes não podem
ser considerados, pois a fase de análise congelou os requisitos identificados. Se a
retroalimentação for permitida, esse problema pode ser minimizado, mas não solucionado. O
grande problema é que o usuário interage com a equipe de desenvolvimento no início do
processo e ao final, quando o sistema é entregue.

ITERATIVO
Onde o sistema é dividido em subconjuntos de funcionalidades (com mínimo de dependência
com os demais conjuntos), e as atividades de análise, projeto, implementação, teste e
implantação são realizadas a cada subconjunto. Isso significa que a cada subconjunto haverá a
implantação de uma parte do sistema, permitindo que ajustes das partes encerradas ocorram
em paralelo com o novo subconjunto de funcionalidades que está sendo construído.

ÁGIL
Os processos são ditos ágeis porque compartilham um conjunto de valores e princípios definido
pelo manifesto ágil. O foco aqui é permitir modificação sempre que preciso e no
desenvolvimento de código. A modelagem existe, mas em menor escala e com ênfase na
comunicação com usuário e equipe de desenvolvimento. Visa a pouca formalidade nos
processos ágeis. Mais usados: Extreme Programming (XP), Scrum, FDD (Feature Driven
Development).

RUP (RATIONAL UNIFIED PROCESS)

O mercado muito fala da integração UML e RUP, mas, como os demais processos, o RUP é
independente da UML. O RUP, na verdade, é uma estrutura de processo, que vai usar casos de
desenvolvimentos (processo a ser usado), a maioria deles iterativos. O RUP não se adapta a
processo em cascata.

VISÃO GERAL DOS DIAGRAMAS UML

Vamos nos ater aqui à versão mais recente da UML, a 2.5.1, que traz 14 diagramas divididos
em estruturais e comportamentais, conforme imagem a seguir.

OS DIAGRAMAS ESTRUTURAIS
OS DIAGRAMAS COMPORTAMENTAIS
OS DIAGRAMAS ESTRUTURAIS

Dizem respeito às estruturas estáticas necessárias ao sistema, como os pacotes, as classes,

os objetos, os componentes e a estrutura de nós (estruturas computacionais). Também são
chamados de estruturas estáticas.

OS DIAGRAMAS COMPORTAMENTAIS

Evidenciam o comportamento (funcionamento) de parte de um sistema ou processo de negócio

relacionado ao sistema, segundo determinada perspectiva. Dizem respeito às funcionalidades
do sistema, aos estados de um objeto em seu ciclo de vida, às interações entre os objetos,
dentre outros aspectos. Também são chamados de diagramas dinâmicos.

Diagramas da UML

A seguir, uma breve descrição de cada diagrama da UML:

Diagrama Especificação

Permite a definição de tipos padronizados, como estereótipos,

Diagrama de perfil restrições e valores rotulados. O foco é a adequação aos
modelos UML para diferentes plataformas, por exemplo.
 Descreve, para cada classe, suas propriedades (atributos e
Diagrama de
métodos) e seus relacionamentos com as demais classes.
classes
Classe é a base estrutural dos sistemas orientados a objetos.

Diagrama de Possibilita a descrição de colaborações internas de classes,

estruturas interfaces ou componentes, visando a especificação de uma
compostas funcionalidade.

Diagrama de Apresenta a estrutura e as conexões entre os componentes de

componentes um sistema.

Especifica o ambiente computacional sobre o qual o sistema vai

Diagrama de
operar, além de distribuir os artefatos (pacotes, classes e
implantação
componentes) nos nós (elementos computacionais).

Diagrama de É um diagrama de classes instanciado, ou seja, mostra

objetos exemplos de instâncias de classes.

Descreve estruturas hierárquicas que englobam outros

Diagrama de elementos, como outros pacotes, casos de uso, classes. Usado
pacotes para modularizar logicamente um sistema em suas partes
relevantes (subsistemas).

Descreve o comportamento de procedimentos, processos de

Diagrama de
negócios e fluxos de trabalho, suportando processamento
atividades
sequencial e paralelo.

Mostra como os usuários (atores) interagem com o sistema, do

Diagrama de casos
ponto de vista externo, evidenciando as funcionalidades com as
de uso
quais interagem.

Diagrama de Mostra como os eventos que afetam o sistema alteram o estado

 estados dos objetos ao longo de seus ciclos de vida.

Diagrama de Mostra como os objetos interagem, evidenciando a linha de

sequência tempo (a sequência das interações).

Diagrama de Mostra como os objetos interagem, evidenciando as conexões

comunicação e colaborações entre eles.

Diagrama de visão Um mix de diagrama de sequência e de atividades. Uma

geral de interação especialização do diagrama de atividades para interações.

Diagrama de interação, com foco nas restrições de

Diagrama de
temporização, como, por exemplo, para evidenciar as
tempo
mudanças no estado de um objeto ao longo do tempo.

Tabela: Marcelo Vasques de Oliveira

Atenção! Para visualização completa da tabela utilize a rolagem horizontal

DIAGRAMAS UML E SUA UTILIZAÇÃO NAS

FASES
O descrito a seguir não é recomendado ou estipulado pela UML, pois a UML não determina
quais diagramas devem ser usados e tampouco em que ordem devem ser elaborados. São
dicas práticas.

Dificilmente usamos todos os diagramas da UML em um único sistema. Há um conjunto de 4 a

8 diagramas que são os mais usados: pacotes, casos de uso, classes, sequência (ou
comunicação), estados, atividades, componentes e implantação. Todos os mencionados são
relevantes, mas os em negrito são os essenciais.

No módulo 1, descrevemos as atividades das fases de análise (levantamento e análise de

requisitos) e projeto independentemente do processo de desenvolvimento por entender que
ambas estarão presentes em qualquer processo que usemos. Agora, partindo desse mesmo
pressuposto, vamos descrever os diagramas UML que podem ser usados em cada uma dessas
três fases. Citaremos apenas os diagramas mais usados.

DIAGRAMAS UML NA ATIVIDADE DE ANÁLISE

Levantamento de requisitos Análise de requisitos

Esboço inicial do diagrama de

pacotes, para grandes sistemas, Detalhamento e aprofundamento do
evidenciando a necessidade de diagrama de pacotes
particionamento

Esboço inicial do diagrama de casos Detalhamento e aprofundamento do

de uso diagrama de casos de uso

Esboço inicial do diagrama

Detalhamento e aprofundamento do
conceitual de classes, em alto nível
diagrama conceitual de classes
(sem detalhes)

Diagrama de estados, para os objetos mais

complexos durante seu ciclo de vida

Diagrama de atividades, para elucidar um

processo ou fluxo de trabalho relevante ou
ainda para elucidar um caso de uso mais
complexo

Tabela: Marcelo Vasques de Oliveira

Atenção! Para visualização completa da tabela utilize a rolagem horizontal

Nota: o diagrama conceitual de classes evidencia as classes (com principais atributos e

inicialmente sem métodos) e os principais relacionamentos (em geral apenas associações, que
são os relacionamentos de classes mais elementares).

Os diagramas usados no levantamento de requisitos são, em geral, esboços para a própria

pessoa ou para debater com colegas da equipe. Já na fase de análise de requisitos, alguns
diagramas, em geral pacotes e casos de uso, são usados para conversas com usuários.

DIAGRAMAS UML NA ATIVIDADE DE PROJETO

Adição de detalhes ao diagrama conceitual de classes, que passa a ser o diagrama

de classes de projeto.

Diagrama de sequência ou diagrama de comunicação, para cenários de uso mais

relevantes, o que ajuda a identificar métodos das classes envolvidas na interação.

Detalhamento dos diagramas de estados elaborados na atividade de análise, podendo

modelar de outros objetos percebidos.

Diagrama de componentes, caso o software use algum já pronto ou a ser construído.

Diagrama de implantação, evidenciando as unidades computacionais e alocando os

componentes nelas.

Diagrama de atividades, esclarecendo métodos de classes mais complexos ou que

usem processamento paralelo.

Tabela: Marcelo Vasques de Oliveira

Atenção! Para visualização completa da tabela utilize a rolagem horizontal

Nota: o diagrama de classes de projeto deriva do diagrama conceitual de classes, agregando

novos atributos, todos os métodos necessários, identificando os corretos relacionamentos entre
as classes (e não apenas associações), adicionando as multiplicidades e outros elementos
relevantes da UML.
USO DOS DIAGRAMAS UML NAS FASES DE
ANÁLISE E PROJETO DE SISTEMAS
O especialista Marcelo Vasques de Oliveira resume a UML, demonstrando dicas práticas para
uso dos seus diagramas nas fases de análise e projeto de sistemas.

VERIFICANDO O APRENDIZADO
CONCLUSÃO

CONSIDERAÇÕES FINAIS
Vimos que o desenvolvimento de sistemas é uma atividade complexa, que envolve pessoas
estudando um sistema que também será usado por outras pessoas. Ou seja, existe muita
subjetividade envolvida nesse processo. Para minimizar essa subjetividade, o processo de
desenvolvimento de um software é divido em fases, de forma que inicialmente tenhamos uma
visão geral do sistema e, à medida que nos aprofundamos, conhecemos mais detalhes da
estrutura e do funcionamento desse sistema.

Vimos ainda que os processos de desenvolvimento usam diagramas, que são modelos que
expressam a realidade sob determinada perspectiva, para melhorar a comunicação com os
usuários e entre os membros da equipe de desenvolvimento.

Conforme apresentado, os sistemas foram crescendo em tamanho e complexidade, e as

técnicas usadas passaram a não atender às demandas. Percebeu-se, então, uma nova forma
de visualizar os sistemas, com objetos do mundo real que interagem. Nasceu, assim, um novo
paradigma de desenvolvimento: o paradigma orientado a objetos.

Esse novo paradigma, porém, precisou de modelos compatíveis, pois os modelos dos
paradigmas anteriores não atendiam à nova forma de ver e de construir sistemas. Os melhores
profissionais do mercado produziram seus próprios modelos e, em 1997, criaram uma
linguagem unificada, em padrão relativamente aberto: a UML (em português, Linguagem
Unificada de Modelagem), que vem evoluindo substancialmente desde sua criação, estando
em sua versão 2.5.1, de 2017.

A UML é uma linguagem de modelagem independente de tecnologia, que se aplica a qualquer

processo de desenvolvimento (orientado a objetos ou não). Ela especifica um conjunto de
diagramas sob cinco diferentes visões que podemos ter sobre um sistema: visão de casos de
uso (central), visão de projeto ou lógica, visão de implementação (ou desenvolvimento), visão
de implantação (ou física) e visão de processo. Os diagramas de cada versão da UML atendem
a uma ou mais dessas perspectivas e são usados nas diferentes fases de um processo de
desenvolvimento.
 PODCAST
Agora, o especialista Marcelo Vasques de Oliveira encerra fazendo um resumo de todo o
conteúdo.

AVALIAÇÃO DO TEMA:

REFERÊNCIAS
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 3. ed. Rio de Janeiro:
Elsevier, 2015.

BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML: guia do usuário. 2. ed. Rio de Janeiro:
Elsevier, 2005.

FOWLER, M. UML essencial: um breve guia para a linguagem-padrão de modelagem de

objetos. Trad. João Tortello. 3. ed. Porto Alegre: Bookman, 2005.

LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a

objetos e ao processo unificado. 3. ed. Porto Alegre: Artmed, 2007.

EXPLORE+

Visão geral do desenvolvimento em camadas: trabalhando com desenvolvimento em

 camadas utilizando C#.

Desenvolvimento em três camadas: conceitos.

Modelagem de sistemas através da UML: uma visão geral.

UML (Unified Modeling Language) e Unified Software Development Process (Unified

Process).

Pesquise na internet:

O diagrama da arquitetura em camadas, publicado no cogle.it, sob forma de infográfico de

domínio público.

CONTEUDISTA
Marcelo Vasques de Oliveira

CURRÍCULO LATTES