Unidade III - Análise orientada a objetos

Prévia do material em texto

Análise e Projetos 
de Sistema 
Análise orientada a objetos
Material Teórico
Responsável pelo Conteúdo:
Prof. Ms. Rodrigo da Rosa 
Revisão Textual:
 Profa. Ms. Rosemary Toffoli 
5
• Introdução
• Orientação a Objetos
• Casos de Uso
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.
 · 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?
Análise orientada a objetos
• Classes
• Análise Orientada a Objetos
• UML – Linguagem de Modelagem Unificada
6
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.
7
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.
8
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. 
9
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.
10
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.
11
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.
12
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.
13
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
14
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.
15
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.
16
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 
hardwareenvolvidos 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.
17
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.
http://www.portalarquiteto.com.br
http://www.omg.org
18
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.
19
Anotações
www.cruzeirodosulvirtual.com.br
Campus Liberdade
Rua Galvão Bueno, 868
CEP 01506-000
São Paulo SP Brasil 
Tel: (55 11) 3385-3000
http://www.cruzeirodosulvirtual.com.br