Análise e Projetos

de Sistema
 Material Teórico
Análise orientada a objetos

Responsável pelo Conteúdo:

Prof. Ms. Rodrigo da Rosa

Revisão Textual:
Profa. Ms. Rosemary Toffoli
 Análise orientada a objetos

• Introdução

• Orientação a Objetos

• Casos de Uso

• Classes

• Análise Orientada a Objetos

• UML – Linguagem de Modelagem Unificada

··Por que entender o conceito de objetos é fundamental para o

desenvolvimento de projetos de sistemas?
··O conceito de abstração como guia para análise orientada a
objetos.
··Quais as diferenças entre os principais mecanismos de análise
de sistemas baseados em objetos?

Para que os objetivos da unidade sejam alcançados, é fundamental que você leia
cuidadosamente todo o material e realize com atenção todas as atividades propostas.
Nesta unidade é importante que, durante as leituras e realização dos exercícios, você
consiga compreender a importância da análise de sistemas baseada em objetos para o
desenvolvimento de projetos de software.

5
 Unidade: Análise orientada a objetos

Contextualização

Desenvolver um projeto de software envolve fatores complexos. A função do analista,

servindo como intermediador entre os usuários e a equipe de desenvolvimento, requer
cuidados específicos para que todos os detalhes sejam atendidos de acordo com as
especificações dos clientes.
Atualmente existem diversas maneiras de se representar o que se espera de um software.
Essas maneiras se enquadram no conceito de modelagem de sistemas ou análise de sistemas,
que emprega um conjunto de técnicas utilizando diagramas para demonstrar as funcionalidades
atendidas pelo sistema. Assim, problemas poderão ser detectados antes mesmo de se iniciar o
processo de criação do software.
Nesta unidade, abordaremos as principais formas de análise de sistemas baseada em objetos.
Você descobrirá que esse tipo de análise se baseia na ideia de observação de um ambiente
para que informações úteis sejam captadas e armazenadas em objetos. Tal conceito requer o
conhecimento do termo abstração de dados.
Para que haja padrão nas técnicas de análise orientada a objetos, foi criada uma linguagem
própria que caracteriza os modelos de análise, denominada Linguagem de Modelagem Unificada,
a UML. Desse modo, os projetos se tornam mais consistentes e fáceis de serem entendidos pelos
usuários, analistas e demais pessoas envolvidas.

6
 Introdução
A Análise Estruturada de Sistemas tem se mostrado um recurso bastante útil nas fases
de desenvolvimento de software, já que os modelos deste conceito se preocupam com a
identificação de elementos de entrada captados em ambientes externos ou internos que são
processados com a finalidade de se produzir alguma informação que tenha real utilidade no
desenvolvimento de um sistema.
A Análise Baseada em Objetos aparece como um complemento do modelo estruturado,
seguindo uma métrica diferente, uma vez que os modelos aqui gerados são fruto da observação
de uma situação com a finalidade de produzir informações relevantes, porém encapsulando-as
no que se denomina objetos.
Nesta unidade abordaremos sobre os conceitos fundamentais envolvidos no termo
Análise de Objetos, como por exemplo, modelagem, classes, objetos, abstração, etc. Além
disso, novas formas de modelagem de sistemas serão apresentadas no intuito de possibilitar
maior compreensão acerca das diversas maneiras de representar as informações. Neste caso
específico os modelos serão aqueles que focam objetos para permitir a análise detalhada do
desenvolvimento de software.

Orientação a Objetos
O ser humano vive em meio a um mundo de complexidade. A ciência busca, até os dias
atuais, explicar fatos que ocorrem na natureza e que do ponto de vista científico não pôde ainda
comprovar. A complexidade existente no mundo fica ainda mais evidente no momento em que
paramos para observá-lo. Uma análise destes pontos de observação se torna difícil se forem
tratados como um todo.
A orientação a objetos age na tentativa de abstrair informações de natureza relevante em um
ambiente complexo, visualizando-as como objetos. Este processo de identificação do que é útil
é chamado de abstração.
Na abstração, a parte complexa é observada e é filtrado somente aquilo que realmente
interessa para um propósito específico. Observe a figura 1 apresentada a seguir:

Figura 1: Abstração sob pontos de

vistas diferentes.

7
 Unidade: Análise orientada a objetos

Nesta ilustração percebemos que a galinha analisa o ovo como sendo um elemento que em
breve dará a ela o seu filhote. Para uma pessoa, o mesmo elemento ovo é analisado como uma
possível refeição.
Evidentemente cada observador deve buscar elementos de interesse próprios ou daquele
para o qual está empenhado em desenvolver algo, pois pontos de vistas diferentes podem
determinar diferentes resultados.

Ideias Chave
Objeto é uma entidade existente no mundo real que possui atributos e um comportamento no sistema.

Suponha que você possua um rádio relógio antigo chamado de ‘barulhento’ que você utiliza
para atender várias necessidades e/ou vontades. O ‘barulhento’ possui certos atributos que o
caracterizam, por exemplo: é preto; tamanho 15 cm x 10 cm x 4,5 cm; é arredondado. Quanto
ao seu comportamento (método), dizemos que toca música, emite um som de alarme, registra
o dia e a hora e sintoniza rádios. Neste sentido, temos que:

• Os atributos são: cor, tamanho e formato;

• Os métodos são: tocar música, soar alarme, registrar data e hora e
sintonizar rádios.
Podemos afirmar, então, que o barulhento é um ‘objeto’.

Os objetos podem ser concretos (carros, pessoas, etc.) ou mesmo abstratos (compra de ações,
prestação de serviços, etc.).

Casos de Uso

Como já é que nosso entendimento, a palavra sistema no contexto computacional é descrita

como um conjunto de objetos ou elementos que estão organizados com o propósito de processar
dados de entrada para se obter informações de interesse. Não existe sistema cujos objetos
envolvidos atuem separadamente. Eles devem sempre atuar em conjunto com outros sistemas,
objetos e até mesmo com o ser humano.
Caso de Uso é um termo utilizado para demonstrar o comportamento que um sistema deverá
possuir, ação por ação, diante das expectativas determinadas pelos usuários.

Segundo definição de Pfleeger (2004, p. 216), um caso de uso descreve a funcionalidade específica
que um sistema, supostamente, deve desempenhar ou exibir, por meio da modelagem do diálogo
que um usuário, um sistema externo ou outra entidade terá com o sistema a ser desenvolvido.

8
 Em outras palavras, caso de uso é a descrição da interação entre o sistema e o usuário e/ou
outros sistemas computacionais. A entidade que possui a interação com o sistema, segundo o
mesmo autor, é chamada de ator e pode ser um usuário, um dispositivo ou outro sistema.
Os atores podem receber e transmitir informações aos sistemas ou podem fazer apenas uma
das duas tarefas.
Casos de uso devem ser identificados quando os primeiros passos estão sendo dados no
desenvolvimento do projeto, no momento em que os requisitos são levantados pelo analista,
porém mesmo que isso não aconteça é possível identificá-los durante as etapas seguintes.
Por exemplo, durante a entrevista com o usuário nota-se que uma das exigências é que o
sistema libere o portão principal da empresa quando um cliente visitante for identificado
pelo porteiro. O modo como este porteiro interage com o sistema neste processo pode ser
descrito por caso de uso.

Classes

Uma classe nada mais é do que a integração de objetos que possuem comportamentos/
métodos comuns.
Lembra-se do nosso exemplo do seu rádio relógio antigo, o ‘barulhento’? Pois bem, estudamos
que ele se enquadra na definição de um objeto. Mas o que seria a classe? Classe, para este caso,
seria rádio relógio, pois tanto o seu como qualquer outro possuem métodos similares.
Sendo assim, o ‘barulhento’ é um objeto da classe rádio relógio.
Para que fique ainda mais claro, vamos a outro exemplo. Observe a seguinte figura:

A classe gato é um conjunto de objetos (Duque, Milk e Tango) que possuem comportamentos
comuns (rolar, miar, beber leite, dormir).
A definição de classes é o princípio fundamental da modelagem orientada a objetos.

9
 Unidade: Análise orientada a objetos

Análise Orientada a Objetos

Quando tratamos desta definição estamos nos referindo à identificação de todas as classes
que possuem real significado na resolução de um determinado problema, modelando-as através
de algumas técnicas que agregam valores aos métodos convencionais.
Mas qual é a diferença básica entre os métodos convencionais de modelagem (análise
estruturada) e a modelagem orientada a objetos?

Pressman (1995, p.317) relata que a análise orientada a objetos (OOA) é um complemento a outros
métodos de análise. Em vez de examinar um problema usando o clássico modelo de entrada-
processamento-saída (fluxo de informações) ou um modelo derivado exclusivamente de estruturas
de informação hierárquicas, a OOA introduz uma série de novos conceitos.

No método estruturado um sistema é composto por programas responsáveis por executarem

processos sobre dados de entrada que resultarão em informações úteis e relevantes.
O modelo orientado a objetos considera um conjunto de objetos interagindo entre si, a partir
da observação de uma realidade.
Nos anos 90, devido à popularização da abordagem orientada a objetos, muitos métodos se
tornaram conhecidos, dentre os quais destacamos:
• BOOCH: Grady Booch possuía uma simbologia complexa e entendia que um sistema
deveria ser analisado por uma certa quantia de visões descritas por diagramas.
• OMT (Object Modeling Technique): era da General Electric, representada por Rumbaugh.
O método ficou conhecido como Técnica de Modelagem de Objetos cuja característica
era testar os modelos desenvolvidos através de análise de requisitos.
• OOSE (Engenharia de Software Orientada a Objetos): de Ivar Jacobson, que utilizava
casos de uso como base no desenvolvimento de sistemas.
Para que uma linguagem unificada fosse estabelecida e servisse como recurso de
desenvolvimento de software, os três responsáveis pelas metodologias acima apresentadas se
uniram e criaram a UML, Linguagem de Modelagem Unificada.

UML – Linguagem de Modelagem Unificada

A Linguagem de Modelagem Unificada é uma linguagem padrão de modelagem de objetos através

de diagramas. Sua função é especificar, documentar e permitir a visualização do desenvolvimento
de um sistema de software, identificando problemas, caso ocorram durante o processo.

10
 Pfleeger (2004, p. 220) comenta que a UML é uma abordagem de notação muito utilizada para
descrever soluções orientadas a objetos. Ela pode ser adaptada para se adequar a diferentes situações
de desenvolvimento e ciclos de vida de software. Organizações como o Object Management Group
(OMG) adotaram a UML como notação padrão.

A UML é muito utilizada quando se pretende desenvolver softwares complexos. E-commerce

e de e-business são exemplos de áreas favorecidas com a UML na construção de seus sites.

Você Sabia ?
E-commerce, também conhecido como comércio eletrônico, se refere ao comércio que é realizado
utilizando troca de dados pela Internet.
E-business, também conhecido como negócio eletrônico, se refere aos negócios que são
realizados pela Internet. Nem sempre envolve um comércio e por isso não deve ser confundido
com o termo e-commerce.

Atualmente, de acordo com a Object Management Group, são aproximadamente 14

diagramas descritos pela UML, conforme figura 4:

Diagramas da UML.

11
 Unidade: Análise orientada a objetos

Para que você tenha uma visão clara das possíveis diferenças e utilidades de dos diagramas
da UML, abaixo os descreveremos sucintamente alguns deles.
Diagrama de Caso de Uso: utilizado para descrever como são visualizadas as
funcionalidades do sistema por atores participantes no processo. Atua desde a fase de
levantamento e análise de requisitos.

Diagrama de caso de uso.

Neste modelo o cliente poderá executar o caso de uso “escolhe produto”, enquanto que
a loja virtual poderá interagir com o caso de uso “disponibiliza produto” e a transportadora
executa o caso de uso “transporta produto”.
Diagrama de Classe: dentre todos os diagramas, este é o mais utilizado e representa um
auxílio para os demais. Descrevem classes envolvidas nos sistemas e seus relacionamentos,
porém não apresentam valores armazenados neles.

Diagrama de classes.
12
 Os diagramas de classe possuem características muito semelhantes às do Diagrama
Entidade-Relacionamento.
Por exemplo:
Diagrama de Classes Diagrama Entidade-Relacionamento
Classes Entidades
Atributos Atributos
Associações Relacionamentos
Tabela 1: Comparação entre Diagrama de Classes e Diagrama Entidade-Relacionamento.

As formas de representação também são coincidem.

Comparação entre Diagrama de Classes e Diagrama Entidade-Relacionamento.

As classes em um Diagrama de Classes são implementadas em uma linguagem de programação

orientada a objetos, desde que tenham suporte para isso.

Linguagem de programação orientada a objetos ou programação orientada a

objetos (POO) é uma forma de programação utilizada para escrita de programas
baseados em objetos, métodos, relacionamentos, etc. Faz uso de uma visão do
mundo real para o desenvolvimento do programa.

As principais linguagens de programação orientadas a objetos são:

• JAVA
• C++
• Python
• Object Pascal
• Object-C

As principais linguagens de programação que possuem suporte a objetos são:

• ActionScrit
• JavaScript
• PHP
• Visual Basic
• ColdFusion
13
 Unidade: Análise orientada a objetos

Diagrama de Objetos: utilizado como um complemento do diagrama de classes, uma vez

que é possível visualizar os valores armazenados por cada objeto, em qualquer etapa do projeto.

Diagrama de Pacotes: organiza as classes de objetos em grupos, chamados pacotes, e

permite esta visualização. Os pacotes podem se relacionar com outros pacotes que vão sendo
inseridos no projeto.

Os diagramas de pacotes são descritos por um retângulo com uma espécie de aba e no seu
interior há uma nomenclatura que define qual é a classe de objetos que está sendo ali agrupada.
Abaixo um exemplo de diagrama de pacotes:

Diagrama de Interação: utilizado para demonstrar uma sequência de troca de mensagens

(método) entre os objetos relacionados. Existem dois tipos de diagramas desta classificação: O
diagrama de sequencia e o de colaboração.
Diagrama de Colaboração ou Diagrama de Comunicação: os objetos são apresentados por
um retângulo com um nome e as setas são as mensagens. A sequência das mensagens trocadas
é representada por números.

14
 Diagrama de Sequência: cada objeto é representado por um retângulo que recebe o nome
deste objeto. Abaixo dele é colocada uma linha tracejada na posição vertical, chamada de linha
da vida do objeto, pois demonstra os fatos ocorridos (ou passíveis de ocorrência) no objeto (sua
vida). As setas entre as linhas da vida dos objetos descrevem as mensagens trocadas por eles.

Diagrama de Transição de Estados: utilizado para demonstrar a situação dos objetos

de um sistema e também os motivos que estes possuem para mudar de situação. Os estados
são descritos aqui por retângulos cujos cantos são arredondados e possuem um nome. Já as
possíveis transições são simbolizadas por setas.

Diagrama de Atividades: utilizado para demonstrar os procedimentos necessários para

término de uma atividade. Apresenta o fluxo de atividades de um sistema. É possível demonstrar
decisões e/ou condições a serem satisfeitas e, caso não sejam, sofreram ações diferentes.

Assim que uma ação for processada, um novo estado é assumido.

15
 Unidade: Análise orientada a objetos

Além destes diagramas, outros são adotados pela UML:

Diagrama de Estrutura Composta: utilizado para detalhar a estrutura interna de classes,

pacotes e/ou componentes.

Diagrama de Implementação: utilizado para apresentar os elementos de software e

hardware envolvidos no processo de desenvolvimento. Considera arquitetura e configuração
do sistema.

Diagrama de Componente: utilizado para demonstrar a relação existente entre os softwares,

através de código-fonte, tabelas de banco de dados e até mesmo bibliotecas de programação.

16
Material Complementar

• http://www.portalarquiteto.com.br, portal da Internet com notícias e artigos sobre o

assunto Arquitetura de Softwrare.
• http://www.omg.org, site da organização Object Management Group, que analisa e define
padrões de desenvolvimento de projetos orientados a objetos.
• PAULA FILHO, W. P.. Engenharia de Software: fundamentos, métodos e padrões.
Rio de Janeiro. LTC, 2009, disponível na biblioteca virtual da Unicsul.
• PRESSMAN, R. S.. Engenharia de Software. São Paulo. Pearson, 2011, disponível na
biblioteca virtual da Unicsul.

17
 Unidade: Análise orientada a objetos

Referências

PFLEEGER, S. L. Engenharia de Software: teoria e prática. 2ª ed. São Paulo: Prentice

Hall, 2004.

PRESSMAN, R. S. Engenharia de Software. São Paulo: Pearson Makron Books, 1995.

18
Anotações

19
www.cruzeirodosulvirtual.com.br
Campus Liberdade
Rua Galvão Bueno, 868
CEP 01506-000
São Paulo SP Brasil
Tel: (55 11) 3385-3000