Artigo Engenharia de Software 23 Análise Orientada a Objetos

Prévia do material em texto

2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 1/24
www.devmedia.com.br 
[versão para impressão]
Link original: http://www.devmedia.com.br/articles/viewcomp.asp?
comp=16498
Artigo Engenharia de Softw
are 23 - Análise Orientada a
Objetos
Esse artigo apresenta um conjunto de
princípios de análise e projeto que podem
subsidiar decisões de modelagem e projeto de
sistemas de software.
Esse artigo faz parte da revista Engenharia de
Software 23 edição especial. Clique aqui para ler todos os
artigos desta edição
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 2/24
Projeto
Análise Orientada a Objetos
Essencial para Entendimento e Modelagem de Sistemas
De que trata o artigo:
Apresenta um conjunto de princípios de análise e projeto que podem
subsidiar decisões de modelagem e projeto de sistemas de software.
Para que serve:
Entender o papel da análise orientada a objetos dentro do processo de
desenvolvimento de software, visando a identificação de informações
necessárias às decisões de projeto e modelagem de um sistema.
Em que situação o tema é útil:
Identificação de informações que apóiam as atividades de modelagem,
análise e projeto de sistemas de software.
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 3/24
         Se você é um engenheiro de software cujo papel é entender, analisar e
desenvolver sistemas, você precisa participar de algumas decisões de projeto
como selecionar a técnica de análise e modelagem, linguagem de
programação e ambiente de desenvolvimento adequados. 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 sistemas de software encontram­se,
quase permanentemente, sendo modificados. Essas mudanças ocorrem
devido à necessidade 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.
 
Análise Orientada a Objetos
          A análise orientada a objetos é uma atividade essencial num processo
de desenvolvimento de software. Seu objetivo principal é identificar objetos,
atributos desses objetos e as operações que atuam sobre eles. Os atributos
são características ou propriedades dos objetos, enquanto que as operações
são métodos ou funções que atuam sobre os objetos e afetam o
comportamento dos mesmos. Todavia, antes de iniciar a modelagem com
uma linguagem como a UML, você deve proceder a análise orientada a
objetos, que compreende os seguintes passos:
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 4/24
1. Entender o problema do cliente e identificar e documentar os
requisitos;
2. Descrever os requisitos funcionais usando diagramas de casos de uso
da UML;
3. Identificar objetos e classes a partir das informações no documento de
requisitos, descrição do sistema e especificação de casos de uso;
4. Identificar relacionamentos entre as classes do item 3;
5. Identificar atributos e operações (para as classes identificadas no item
3);
6. Elaborar e analisar os diagramas de classes de sistema, adicionando
e/ou corrigindo atributos e operações, bem como revisando os
relacionamentos identificados.
 
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:
Entidades externas como, por exemplo, outros sistemas (subsistema de
controle de estoque);
         Coisas (livros, cadeiras, mesas, canetas);
Ocorrências ou eventos (transação bancária, compra com cartão de
crédito, requisição de serviços);
Papéis (funções) desempenhados por alguém num sistema (professor,
médico);
Unidades de uma instituição (departamento, divisão, diretoria);
         Lugares (laboratório, salas de aula, estantes, blocos).
 
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 5/24
De um modo geral, você deve procurar pelos elementos acima. 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:
Para as classes identificadas, existem operações que possam mudar o
valor dos atributos?
O objeto pode ser representado como atributo de outro objeto?
É possível definir um conjunto de atributos que se aplica a todas as
ocorrências do objeto?
 
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 sistema, como discutido adiante.
Um processo de desenvolvimento de software compreende um
conjunto de atividades, dentre elas, levantamento de requisitos, 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.
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 6/24
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 casode uso, bem como distribuir comportamento 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 saber 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.
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 7/24
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 contexto, o objetivo principal deste artigo é tratar
essas questões. A próxima seção dá continuidade no estudo da análise
orientada a objetos.
 
Importância da Análise Orientada a Objetos
 
O que é a análise?
A análise visa investigar e resolver um problema. O objetivo da
análise é levar o analista ou projetista a investigar e a descobrir 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 ‘enunciado 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 levantamento 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 – Você deve
identificar os aspectos importantes do problema sob análise (ou
sistema a ser desenvolvido) e ignorar os detalhes. Por exemplo,
engenheiros usam equações e modelos como recursos para abstrair­se
da complexidade de problemas. Isto torna mais fácil o raciocínio.
2. Antecipar modificações no sistema (a ser desenvolvido) – Você precisa
considerar que um sistema de software evolui, ou seja, novas
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 8/24
funcionalidades serão adicionadas e outras modificadas. Portanto, você
deve levar em conta essa necessidade antecipando futuras mudanças.
3. Generalizar o modelo proposto – Seu modelo deve resolver o problema
que você tem em mãos, mas um bom projetista não pensa em
encontrar uma solução única para um problema. Você deve considerar
uma solução mais geral que permita a você reutilizar seu modelo (ou
solução) em outros problemas.
4. Considerar o processo de análise incremental – O processo de
desenvolvimento, e também de análise, é incremental, evoluindo aos
passos. Dessa forma, você deve, no início da análise, investigar as
principais funcionalidades e à medida que você tem maior compreensão
do problema (ou sistema a ser desenvolvido), você enriquece o modelo
(da análise) adicionando detalhes e tornando o modelo mais completo.
 
          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 funcionalidades) 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.
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 9/24
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
comportamento 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 isoladamente. 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 encontrar
classes de análise e identificar persistências. Juntamente 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.
 
Exemplo de Modelagem
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 10/24
A modelagem com a UML deve ser feita por um analista de sistemas
ou engenheiro de software. Um engenheiro de software é um profissional que
deve ter a habilidade de antecipar e gerenciar mudanças de requisitos de um
produto. Além disso, ele precisa saber se expressar e comunicar bem a fim
de capturar e registrar adequadamente o documento de requisitos. Os
principais problemas num desenvolvimento de um sistema de software
decorrem do entendimento errado entre 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 documentode 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 software
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 quaisquer 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.
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 11/24
Você também deve perceber que envolver o usuário no processo é
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 – atividade na qual os requisitos do sistema a
ser desenvolvido são levantados;
Análise de requisitos – atividade na qual os requisitos são analisados e
confirmados pelos principais interessados do projeto (isto é, os
stakeholders) que incluem cliente, usuário final, gerente de projetos,
dentre outros.
 
          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 entendimento dos desenvolvedores.
Durante a realização dessas atividades, você (como engenheiro 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.
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 12/24
É 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. Entretanto, 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 entender,
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 manualmente 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
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 13/24
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 primeira
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 comunicam com o caso de uso (enviando e
recebendo mensagens).
Para a descrição do sistema acima, você deve buscar inicialmente 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
diagrama mostrado na Figura 1.
 
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 14/24
Figura 1. Exemplo de diagrama de caso de uso.
 
 
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 extensã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, 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.
1.    Nome do caso de uso
2.    Descrição ou sumário do caso de uso
3.    Fluxo principal (ou básico) de eventos
4.    Fluxo excepcional (ou alternativo)
5.    Pré­condição
6.    Pós­condição
7.    Ponto de extensão
8.    Autor
9.    Data
 
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 15/24
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 dadosdo 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 notifica 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 implementam essas funcionalidades. Esse processo de
modelagem desse sistema exemplo é continuado na seção seguinte.
 
Modelagem de Sistema usando UML
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 16/24
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.
Figura 2. Exemplo de herança num diagrama de caso de uso.
 
Outro tipo de associação é include, onde você tem o reuso de um
caso de uso, evitando repetir a descrição de um mesmo fluxo de eventos.
Assim, você deve identificar comportamentos comuns. Isso ocorre com o
caso de uso CadastrarLivro que requer e, portanto, reutiliza o caso de uso
ValidarUsuário. A especificação do caso de uso CadastrarLivro é apresentada
abaixo.
 
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
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 17/24
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 operação é
cancelada
 
Outro tipo de associação é extend, que incorpora condicionalmente 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éstimo, 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.
 
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 18/24
Figura 3. Classes identificadas do caso de uso ValidarUsuário.
 
No entanto, se alguma classe de entidade precisa ser persistente,
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] ValidarUsuá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.
 
Figura 4. Classes identificadas do caso de uso CadastrarLivro.
 
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 19/24
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.
 
Figura 5. Diagrama de sequência do caso de uso ValidarUsuário.
 
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.
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 20/24
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
implementam esse caso de uso, então você deve obter um diagrama de
sequência como mostrado na Figura 6.
 
Figura 6. Diagrama de seqüência do caso de uso CadastrarLivro.
 
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.
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 21/24
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 classesdos casos de uso ValidarUsuário e CadastrarLivro, respectivamente.
(a)                                                                  (b)
Figura 7. Diagramas de classes dos de usos ValidarUsuario e CadastrarLivro.
 
Note que o seu trabalho ainda não acabou. Você ainda precisa
adicionar modificadores de visibilidade aos métodos e atributos, 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ê necessitará 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.
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 22/24
Figura 8. Refinamento do diagrama de classes do sistema de biblioteca.
 
Perceba que o objetivo é refinar o modelo anterior, que possui classes
que implementam casos de usos (isto é, funcionalidades), mas que estavam
separados. Aqui, uma 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 respectivas
implementações. Observe que a construção, revisão e refinamento desses
modelos com a UML é feito com o auxílio de ferramentas de modelagem.
Conclusão
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 23/24
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 modelagem 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.
 
Links
História da Indústria de Software
www.softwarehistory.org
 
Recursos da UML
http://www.rational.com/uml/resources/documentation/
 
Lista de ferramentas UML
http://en.wikipedia.org/wiki/List_of_UML_tools
 
JUDE – Ferramenta de modelagem UML
http://jude.change­vision.com/jude­web/index.html
 
Processo de Desenvolvimento de Software
http://pt.wikipedia.org/wiki/Processo_de_desenvolvimento_de_software
 
Curso Online sobre Modelagem OO e UML
http://gentleware.com/fileadmin/media/synergy/Course/index.htm
 
por Antonio Mendes
Engenharia de software lover 
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)
2017­6­28 Artigo Engenharia de Software 23 ­ Análise Orientada a Objetos
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=16498 24/24
R
ec
eb
a 
no
tif
ic
aç
õe
s 
:)