







     
      
     
     
     
    
     






    

    
    
     
    


S
e você é um engenheiro de softwa-
re cujo papel é entender, analisar e
desenvolver sistemas, você precisa
participar de algumas decisões de proje-
to como selecionar a técnica de análise e
modelagem, linguagem de programação
e ambiente de desenvolvimento adequa-
dos. Neste cenário, é importante refletir
sobre a ordem em que suas atividades
são executadas. Por exemplo, antes de
escolher uma linguagem de programa-
ção e ambiente de desenvolvimento,
você deve definir a estratégia de análise
e modelagem de sistemas.
Além disso, observa-se que os siste-
mas de software encontram-se, quase
permanentemente, sendo modificados.
Essas mudanças ocorrem devido à ne-
cessidade de corrigir erros existentes no





     
      

  





software ou de adicionar novos recursos
e funcionalidades.
Em razão disto, você pode questionar:
Por que modelar um sistema? Porque à
medida que o sistema cresce, também
cresce o código, tornando mais difícil
seu desenvolvimento e mais ainda sua
manutenção. É mais fácil raciocinar
e fazer a manutenção em um sistema
para o qual você tem um modelo. Para
tanto, a modelagem é essencial no

desenvolvimento de qualquer sistema. A análise orientada
a objetos serve para ajudar no entendimento e decisões de
projeto, tema esse tratado neste artigo.

- sistema, como discutido adiante.
O primeiro passo, a partir do momento em que você já fez o
levantamento de requisitos junto ao cliente, é identificar objetos
e classes. Nesse momento, você é o projetista e, portanto, deve
examinar a declaração do problema procurando identificar
objetos, os quais podem ser:
De um modo geral, você deve procurar pelos elementos aci-
ma. Outra dica é procurar identificar substantivos na descrição
do sistema e/ou documentos de requisitos. No momento de
buscar identificar candidatos a classes, você pode responder
a questões como:
   
Cabe ressaltar que os objetos identificados não devem ser
confundidos ou tratados como operações. Note que pode tanto
existir um objeto que representa uma transação quanto pode
haver as operações transferir, sacar e consultar.
Note que a análise é essencial para criação de um modelo
de classes do sistema a partir dos casos de uso (da etapa de
levantamento de requisitos). O objetivo da análise é identificar
as classes necessárias para implementar os casos de uso do
Um processo de desenvolvimento de software compreende
um conjunto de atividades, dentre elas, levantamento de re-
quisitos, análise e projeto como etapas iniciais do processo de
desenvolvimento de software.
Inicialmente, você deve entender o problema do cliente para
documentar o conjunto de requisitos. Após isso, você começa
a etapa de análise de requisitos fazendo uso das informações
do documento de requisitos e especificação de casos de uso.
Com isso, você deverá gerar um primeiro modelo do sistema a
partir dessas informações. Este modelo é chamado de modelo
de análise.
A análise orientada a objetos utiliza as informações dos
casos de uso. Em outras palavras, os casos de uso servem de
guia para a etapa de análise. É importante você observar que a
análise produz uma visão estática do sistema, que é o diagrama
de classes. Além disso, cada caso de uso deve ser analisado
isoladamente, identificando-se as classes que implementam
aquela funcionalidade. Nesse sentido, a análise orientada a
objetos ajuda você a encontrar as classes iniciais do sistema e
distribuir o comportamento dos casos de uso entre elas. Vale
lembrar que cada classe tem suas responsabilidades, atributos
e associações.
Adicionalmente, você precisará identificar persistências e
classes para cada caso de uso, bem como distribuir compor-
tamento entre elas, descrever responsabilidades e descrever
atributos e associações, como apresentado adiante.
Entretanto, identificar os elementos da UML e conhecer
os diagramas não é tudo. Você também precisa saber como
identificar os componentes essenciais desses diagramas e sa-
ber como relacionar uns aos outros. Nesse sentido, é de suma
importância conhecer os passos do processo de análise para
que você possa adequadamente explorar as informações do
sistema (sob análise) e identificar os componentes da UML
que melhor representam eles.
É importante você observar que conhecer uma linguagem
(como a UML) não implica na habilidade de saber usá-la para
produzir artefatos úteis. Mas, por quê? Porque você precisa
se preocupar com a estrutura do software. A estrutura do
software deve ser intrinsecamente mais fácil de compreender,
além de ser bem documentado, permitindo ser compreendido
em nível global ou em detalhes. Pensar e projetar um software
dessa forma é torná-lo mais fácil de ser modificado e, portanto,
quando alguma de suas características é mudada, ele continua
funcionando.
Perceba que seu papel como projetista vai muito além do de
apenas conhecer a UML, você também precisa saber fazer a

análise orientada a objetos e utilizar ambos os conhecimentos
para fazer a modelagem de um sistema. Dentro desse contex-
to, o objetivo principal deste artigo é tratar essas questões. A
próxima seção dá continuidade no estudo da análise orientada
a objetos.


A análise visa investigar e resolver um problema. O objetivo
da análise é levar o analista ou projetista a investigar e a desco-
brir como tratar o problema que ele tem em mãos. Perceba que
quando você finalizar a análise, você terá uma compreensão
completa do problema (muitas vezes denominado de ‘enuncia-
do do problema’) e, portanto, o projeto será a sua solução.
Note que a qualidade do processo de análise é de suma
importância porque um erro de concepção (durante o levanta-
mento de requisitos) resolvido na fase de análise tem um custo.
Entretanto, a descoberta de erros na fase de projeto tem um
custo maior, sendo maior ainda na fase de implementação. E se
você o descobre apenas na fase de implantação do sistema, esse
custo será bastante elevado. Dessa forma, você deve considerar
o conjunto de princípios de análise e projeto abaixo:
1. Usar abstração no processo de levantamento e análise
- encontrar classes de análise e identificar persistências. Jun-
3. Generalizar o modelo proposto
4. Considerar o processo de análise incremental
- de sistemas ou engenheiro de software. Um engenheiro de
- Além disso, ele precisa saber se expressar e comunicar bem a
A análise é uma etapa essencial para criação de um modelo
de classes do sistema a partir da especificação de casos de
uso. O principal objetivo da análise é identificar as classes
necessárias para implementar os casos de uso (ou funciona-
lidades) do sistema.
Você deve ter em mente que essa sequência de passos não é
uma regra, mas sim uma orientação para você (projetista). A
apresentação de um exemplo englobando diagramas da UML

é feita na seção seguinte. Antes disso, contudo, é importante
você observar que, para cada caso de uso, você deve identificar
a classe (ou classes) que implementa aquele caso de uso (isto
é, funcionalidade). Dentro desse contexto, no terceiro passo
da análise, você precisa dos tipos (ou estereótipos) de classes:
fronteira, entidade e controle. Esses tipos ou estereótipos de
classes são identificadas separadamente para cada um dos
casos de uso que você tenha no seu sistema.
A classe de fronteira é uma classe que fornece uma área
intermediária para comunicação entre um sistema e atores
externos (usuário ou qualquer outro subsistema). Note que
esse tipo de classe serve para modelar a interação entre um
ator e o sistema. Neste caso, você deve criar uma classe de
fronteira (a qual possui o estereótipo boundary) que suporte
cada interação entre um ator e um caso de uso.
A classe de entidade é identificada a partir da sequência de
eventos do caso de uso, servindo para modelar a informação
manipulada pelo sistema. Pode ser persistente ou não. Quando
você identifica uma classe de entidade, esta classe possui o
estereótipo entity.
A classe de controle serve para controlar a sequência de
execução do caso de uso. Geralmente, você deve criar uma
classe de controle para cada caso de uso, e esta classe terá
o estereótipo control. Serve de interface entre uma classe de
fronteira e uma classe de entidade, além de controlar o com-
portamento do caso de uso.
Observe que a análise ajuda você a obter a visão ‘estática’ do
sistema, onde cada caso de uso deve ser analisado isoladamen-
te. Seu papel como projetista (ou analista) é de encontrar as
classes iniciais do sistema e distribuir o comportamento dos
casos de uso entre elas.
Cabe destacar ainda que, para cada caso de uso, você deve
tamente com isso, para cada classe, você precisa distribuir
o comportamento entre elas, bem como descrever atributos
e associações dessas classes. Para entender melhor, vamos
analisar um exemplo.

A modelagem com a UML deve ser feita por um analista
software é um profissional que deve ter a habilidade de an-
tecipar e gerenciar mudanças de requisitos de um produto.
fim de capturar e registrar adequadamente o documento de
requisitos. Os principais problemas num desenvolvimento de
um sistema de software decorrem do entendimento errado en-
tre engenheiro de software (produtor) e usuário (consumidor),
onde o primeiro é responsável em apresentar o documento de
requisitos e projeto (modelagem) do sistema.
A modelagem e o documento de requisitos de um sistema de
software devem ser claros, consistentes e completos, porque
esses documentos servirão de referência aos desenvolvedores,
gerente de projeto, engenheiros de software (responsáveis
pelos testes e manutenção do sistema), além de servir de base

para definir o escopo das funcionalidades a serem registradas
num contrato. Perceba que os requisitos compreendem o cerne
de qualquer produto e mudanças sobre eles podem ocorrer ao
longo do ciclo de vida de um software.
É importante ressaltar que desenvolver um sistema de sof sof-
tware requer um processo (como o RUP), o qual informa um
conjunto de atividades a serem realizadas, quem as executam,
quais artefatos de entrada são necessários e quais artefatos de
saída são produzidos. Nesse sentido, detectar erros ou quais-
quer outros problemas como, por exemplo, inconsistência e
falta de clareza, é de suma importância de modo a tornar o
processo mais efetivo sob ponto de vista de custo.
Você também deve perceber que envolver o usuário no pro-
cesso é determinante para o sucesso do produto e do processo.
Dentro deste contexto, entender adequadamente o requisito
é essencial e essa é tarefa do engenheiro de software. Um
requisito compreende uma característica ou funcionalidade
que o sistema deve possuir ou uma restrição que ele (sistema)
deve satisfazer para atender uma necessidade do usuário.
Dessa forma, você, ao desempenhar o papel de engenheiro
de requisitos (ou analista), deve executar duas atividades
essenciais para a elaboração do documento de requisitos e
modelagem de um sistema:
Elicitação de requisitos
Análise de requisitos
stakeholders
Considera-se ainda que a elicitação de requisitos objetiva
definir características do sistema sob a perspectiva do cliente,
enquanto que a análise de requisitos visa obter a especificação
de requisitos, do ponto de vista técnico, conforme entendimen-
to dos desenvolvedores.
Durante a realização dessas atividades, você (como engenhei-
ro de software) deve estar preocupado em levantar, entender,
analisar, documentar os requisitos e fazer a modelagem do
sistema. Para tanto, deve se concentrar nas características
do sistema e atributos de qualidade, e não em como obtê-los.
Aqui, é preciso identificar quais requisitos fazem parte ou
não do escopo do sistema a ser desenvolvido, ou em outras
palavras, entender a interface do sistema considerado e o
ambiente externo.
É importante ressaltar a necessidade de definir o ‘limite’,
ou também denominado escopo, do sistema a fim de tratar
os requisitos funcionais e não funcionais do sistema. Entre-
tanto, quando você estiver fazendo levantamento e análise
de requisitos, você deve levar em consideração os diferentes
pontos de vistas dos stakeholders de modo que os documentos
resultantes (especificação de requisitos e modelagem) possam
comunicar adequadamente o conjunto de requisitos do sistema
a ser construído.
Para iniciar a modelagem, precisamos da descrição do sistema
a ser desenvolvido. Essa descrição informa a você, analista ou
   
engenheiro de software, os principais elementos do sistema e
que tipo de problema você deve solucionar. O que você deve
fazer agora?
A primeira coisa é obter a descrição do sistema. Para enten-
der, considere o seguinte exemplo:
Uma escola está interessada em automatizar o processo de cadastro e
empréstimo de livros da biblioteca. O processo que hoje é feito manu-
almente exige que os funcionários do atendimento façam o cadastro de
usuários em fichas de papel, similarmente ao que é feito no cadastro
do acervo de livros. Também, toda vez que o aluno necessita fazer
uma consulta de livro, dos livros que esse usuário possui emprestado,
empréstimo de livros, devolução de livros ou renovação, então, em
todas essas ocasiões o usuário deve se dirigir ao balcão de atendimento,
procurando pelo funcionário da biblioteca, no qual tudo é registrado
em fichas de papel (para usuários e livros). Após automatizar esse
sistema, além de todas as funcionalidades descritas acima, o sistema
deverá também possibilitar que os usuários renovem empréstimos
de livros via Internet. Tudo isso visa prover melhor atendimento e
agilidade, resultando em maior satisfação para os usuários.
Com essa descrição de um sistema exemplo, seu papel e pri-
meira atividade é identificar atores e casos de uso. Lembre-se
de que os casos de uso especificam o comportamento de um
sistema, ou parte de um sistema. Trata-se de uma sequência
de ações que geram algum resultado.
Além disso, o ator é a entidade que interage com o caso de uso.
Neste caso, o ator pode ser um ser humano, um subsistema ou
algum dispositivo. Cabe ainda destacar a necessidade de você
também identificar as associações com atores que se comu-
nicam com o caso de uso (enviando e recebendo mensagens).
Para a descrição do sistema acima, você deve buscar inicial-
mente por possíveis atores como aluno e funcionário. Já os
casos de uso se referem a funcionalidades do sistema como
cadastro de usuários, consulta de livros, empréstimo de livros,
dentre outros requisitos funcionais. Isso é capturado no dia-
grama mostrado na Figura 1.

Agora, para cada caso de uso, você deve fazer a especificação
dos fluxos principal (FP) e fluxo excepcional (FE), além de
descrever as pré-condições, pós-condições, e ponto de exten-
são (se houver). De um modo geral, a especificação de casos
de uso compreende a descrição dos casos de uso seguindo

a um template
template, ou modelo, que contém um conjunto de itens
como descrito abaixo. Note que essa relação de itens não tem
o objetivo de ser completa.
Considerando o diagrama de caso de uso da Figura 1, se você
precisa fazer a descrição de um caso de uso (ou use case UC001,
ou seja, o primeiro caso de uso) como ValidarUsuário, então
você deve seguir ao modelo apresentado abaixo:
Nome: [UC001] ValidarUsuário
Pré-condição: o usuário deve ter sido cadastrado na
biblioteca
Fluxo de eventos principal (FP):
1. O sistema espera pela entrada de dados do usuário
2. O usuário fornece login e respectiva senha para acesso ao
sistema
3. O sistema autentica dados do usuário
4. Se os dados do usuário forem válidos, o sistema valida o
usuário
5. O caso de uso termina
Fluxo excepcional (FE):
1. O usuário pode cancelar a operação a qualquer momento
2. Se o usuário entrar com dados inválidos, o sistema notifi-
ca o usuário com uma mensagem na tela informando que os
dados digitados são inválidos.
Pós-condição: o usuário é validado ou a operação é
cancelada.
Observe que o foi feito para o caso de uso ValidarUsuário deve
ser feito para os demais casos de uso. Com as especificações
de casos de uso, bem como a descrição do sistema, você fica
numa condição melhor para derivar as classes que implemen-
tam essas funcionalidades. Esse processo de modelagem desse
sistema exemplo é continuado na seção seguinte.
Modelagem de Sistema usando UML
Na Figura 1 você tem uma generalização de atores, onde o
ator Aluno e o ator Funcionário são especializações do ator
Usuário. Note que você pode precisar identificar associações
entre atores e entre casos de uso. Por exemplo, você poderia ter
dois outros casos de uso (ValidarSenha e ValidarDigital) como
especializações do caso de uso ValidarUsuário. Isso é ilustrado
na Figura 2. É importante você observar que herança entre
casos de uso serve para adicionar, redefinir ou especializar
comportamento.
include

Nome: CadastrarLivro
Pré-condição: o usuário deve ser cadastrado na escola
Fluxo de eventos principal (FP):
1. Include (ValidarUsuário)
2. O usuário fornece os dados do livro para cadastro no
sistema
3. O sistema verifica se existe algum livro com dados
similares
4. Se não há dados similares, o sistema cadastra o novo
livro
5. O caso de uso termina
Fluxo excepcional (FE):
1. O usuário pode cancelar a operação a qualquer momento
2. Se o funcionário entrar com dados de livro já cadastrado,
então o sistema notifica o funcionário com uma mensagem
informando que os dados digitados estão vinculados a um
livro já cadastrado e pergunta se deseja consultar livro.
Pós-condição: o usuário é cadastrado no sistema ou a ope-
ração é cancelada

Outro tipo de associação é , que incorpora condi-
cionalmente o comportamento de outro caso de uso em um
determinado ponto do modelo. Em tal situação, o caso de uso
pode ser usado para especificar um comportamento opcional
existente. Isto ocorre com o caso de uso ConsultarEmprés-
timo, que pode ser utilizado opcionalmente como ilustrado
na Figura 1.
E, agora, depois que você obtiver o diagrama de casos de uso e
respectivas descrições de cada caso de uso, o que fazer?
Você deve obter as classes. Mas, quais classes preciso obter?
Você precisará de, pelo menos, uma classe para cada caso de
uso. Em tal situação, você precisa de uma classe de fronteira
para lidar com a interação dos atores com o sistema, uma
classe de entidade para representar as informações relevantes
do aluno e de uma classe de controle para gerenciar o fluxo de
execução do caso de uso. Para o caso de uso ValidarUsuário,
as classes obtidas são mostradas na Figura 3.

No entanto, se alguma classe de entidade precisa ser persis-
tente, então você necessitará de uma classe para realizar as
tarefas de persistência de dados. Dessa forma, para cada classe
de entidade que precise ser persistente, é criada uma nova classe
com o estereótipo entity collection, como mostra a Figura 3.

Agora, o que foi feito para o caso de uso [UC001] ValidarU-
suário deve também ser feito para os demais casos de uso. A
Figura 4 ilustra as classes identificadas para o caso de uso
[UC002] CadastrarLivro.

Perceba que foi adotado procedimento similar ao caso de uso
anterior. Nesse momento, é importante você observar que as
funcionalidades de um sistema não são isoladas como ‘ilhas de
funcionalidades’, mas elas interagem umas com as outras. Para
identificar como a interação ocorre, você (no papel de analista
de sistemas ou projetista) deve entender como, por exemplo,
o usuário (funcionário) interage com o sistema. Analisando a
descrição do caso de uso [UC001] ValidarUsuário você obtém
a interação capturada pelo diagrama de sequência mostrado
na Figura 5.

   
Note que o propósito do diagrama de sequência é representar
aspectos dinâmicos do sistema através da troca de mensagens
entre objetos das classes identificadas. Dessa forma, você deve
construir um diagrama de sequência para cada caso de uso,
utilizando seu respectivo fluxo de eventos (capturando fluxo
principal e depois fluxos excepcionais), além das informações
das classes daquele caso de uso.
Perceba ainda que os objetos comunicam-se uns com os
outros por meio de mensagens para realizar a funcionalidade
associada àquele caso de uso. Agora, se você proceder de forma
similar ao diagrama anterior, isto é, você deve analisar o fluxo
de eventos que há para o caso de uso [UC002] CadastrarLivro,
bem como observar as informações das classes que implemen-
tam esse caso de uso, então você deve obter um diagrama de
sequência como mostrado na Figura 6.

Na linguagem UML, há dois tipos de diagramas que são
essenciais para capturar os requisitos e a modelagem do
sistema: diagrama de caso de uso e diagrama de classes. O
diagrama de caso de uso é composto de atores e casos de uso.
Estes últimos servem para descrever os requisitos funcionais
ou funcionalidades de um sistema. No entanto, é a partir deles
que identificamos as classes.
Uma vez que você tenha obtido os casos de uso, identificado
as classes para cada caso de uso e analisado a interação entre
os objetos dessas classes usando diagramas de sequência,
então você já pode identificar os relacionamentos entre as
classes, os métodos e os atributos das classes. Cada iteração no
diagrama de sequência corresponde a um relacionamento no
diagrama de classe. As Figuras 7a e 7b ilustram os diagramas
de classes dos casos de uso ValidarUsuário e CadastrarLivro,
respectivamente.
Note que o seu trabalho ainda não acabou. Você ainda precisa
adicionar modificadores de visibilidade aos métodos e atribu-
tos, definir os tipos dos atributos, definir o tipo do retorno e
dos parâmetros dos métodos, além de analisar a possibilidade
de utilizar herança. Trata-se de um refinamento do modelo
de classes visando aperfeiçoar o projeto. Com isso, você ne-
cessitará juntar as classes em um só diagrama para obter o
diagrama do projeto do sistema. Fazendo isso, você irá obter
um diagrama similar ao mostrado na Figura 8.
Perceba que o objetivo é refinar o modelo anterior, que
possui classes que implementam casos de usos (isto é,
funcionalidades), mas que estavam separados. Aqui, uma

 e refinamento desses modelos com a UML é feito com o
auxílio de ferramentas de modelagem.


Este artigo tratou da análise e modelagem de sistema. Aqui,
o foco recai em entender e explorar os princípios de análise e
projeto e aplicá-los em conjunto com uma linguagem de mo-
delagem como a UML. Além disso, tivemos a oportunidade de
explorar mais o uso da UML e conhecer situações onde você pode
empregar seus diagramas que servem de apoio na especificação
de sistemas de software. Para ilustrar os conceitos apresentados,
exemplos foram utilizados para ilustrar os passos da análise e
uso da UML.














de suas tarefas é juntar as partes num único modelo e
outra tarefa é detalhar adicionando métodos (ou funções)
e atributos. Além disso, uma nova classe denominada de
fachada foi usada para agregar as funcionalidades. Essa
classe é encarregada de disponibilizar serviços do sistema.
Adicionalmente, a classe fachada serve como um ‘elo’ entre
a chamada de serviços (ou funcionalidades) e suas respec-
tivas implementações. Observe que a construção, revisão











