1

Sumário
Introdução ..................................................................................................................................................................... 1
Conceitos de Orientação a Objetos .............................................................................................................................. 2
O objeto .................................................................................................................................................................... 2
A classe ...................................................................................................................................................................... 2
Relacionamentos entre objetos ................................................................................................................................ 3
A importância dos conceitos - classes e objetos e seus relacionamentos................................................................ 4
Processo de Desenvolvimento de Software ................................................................................................................. 5
Qualidade de Software ............................................................................................................................................. 5
Processo de Software................................................................................................................................................ 6
Modelo de Processo.................................................................................................................................................. 8
Importância da Análise no Processo de Desenvolvimento de Software .................................................................... 11

2
Introdução

Este material visa introduzir a disciplina de Análise de Sistemas Orientados a Objetos, a iniciar por uma
pequena revisão nos principais conceitos de Orientação a Objetos (OO), descrevendo os conceitos centrais da OO e
seus papéis frente a Análise de Sistemas, assim como refletir sobre os conceitos de Processo de Software, detalhando
os processos mais conhecidos e, por fim, apontar as principais atividades, dentro do processo, voltadas à Análise,
como fase, com ênfase na identificação e elaboração de requisitos.

1
Conceitos de Orientação a Objetos

Uma boa compreensão sobre o paradigma da Orientação a Objetos é demasiadamente importante para o
profissional que conduzirá projetos de software OO. Trata-se de uma base sólida sobre a qual construir-se-á os
conceitos mais relevantes acerca do Domínio do Problema.

O Domínio do Problema é o contexto ao qual o profissional está voltado para o desenho de soluções. Trata-se
da situação fática do mundo em que os problemas precisam de solução, das informações que precisam do devido
tratamento.

Neste sentido, Domínio do Problema pode ser, mais claramente, o ambiente para o qual está se construindo
o software em questão, ex.: Pet Shop, Universidade, Indústria de Calçados e etc. Dentro de cada Domínio do Problema,
o profissional se concentrará em entender os conceitos e informações mais relevantes para serem devidamente
tratadas.

A identificação dos conceitos mais relevantes, de acordo com cada Domínio de Problema, levará o profissional
à identificação de objetos do mundo real, dos quais são armazenadas informações.

O objeto
Essa atenção voltada ao entendimento e identificação de objetos é alvo da Análise, que nos leva ao conceito
central da Orientação a Objetos que é, sem sombra de dúvidas, o próprio objeto.

O objeto é a representação de objetos do mundo real, possuindo atributos que o descrevem e operações que
definem seu comportamento.

Figura 1: Objeto da Classe Pessoa conforme a UML

Conforme a Figura 1, que representa um objeto da classe Pessoa, cada objeto, ao ganhar materialidade, passa
a ter valores definidos e, possivelmente, diferentes para cada caso.

Além de descrever e definir objetos, dentro do Domínio do Problema, a OO preocupa-se em identificar e

analisar as relações entre tais objetos. Essa troca de mensagens entre os objetos é importante para entender as
interações existentes, para que delas possam ser esclarecidas as responsabilidades de cada objeto.

A classe
Os objetos com atributos e comportamentos semelhantes, são agrupados em classes, que podem ser definidas
como meras descritoras de objetos com atributos e comportamento em comum.

Todo objeto pertencente a uma determinada classe possui os atributos que a classe descreve e também
recebe o comportamento padrão que a classe estabelece. Assim, um objeto é a materialização de uma classe. Ambos
estão umbilicalmente ligados, pois o primeiro é a concretização do segundo.

2
 Figura 2: Classe Pessoa conforme a UML

Em uma analogia, poderíamos comparar uma classe com uma planta de uma casa, enquanto o objeto seria a
casa propriamente construída. Conforme a planta, que dita todas as especificações para a construção de novas casas,
a classe dita também todas as especificações para a criação de novos objetos.

Conforme a Figura 2, que contém uma classe de exemplo denominada Pessoa, representada conforme a
Linguagem de Modelagem Unificada (UML), todos os objetos criados a partir de tal classe deverão conter os atributos
“Nome”, “CPF” e “DataNascimento” e, ainda, conter as operações discriminadas logo abaixo aos atributos.

Relacionamentos entre objetos

Os objetos se relacionam e tais relacionamentos são de grande importância para o contexto da Análise, pois
através de tais relacionamentos é possível entender o papel de cada objeto no Domínio do Problema, assim como
delinear as responsabilidades de cada um.

Os relacionamentos serão detalhados em material específico que tratará dos Diagramas Estruturais e
Comportamentais da UML.

Com o intuito de introduzir o assunto, os relacionamentos podem ser do tipo Associação, que representa
basicamente a ligação entre dois objetos que apenas participam de um relacionamento, onde cada objeto possui um
ciclo de vida próprio e autônomo, cuja existência independe do relacionamento em questão. Para consolidar, pode-se
imaginar como exemplo um relacionamento entre Pessoa e Cidade, que pode significar tão somente que uma Pessoa
está residindo em uma determinada Cidade. Se quebrado for o relacionamento entre ambos os objetos, ambos
continuarão a existir no mundo fático.

Porém, existem casos em que o relacionamento entre objetos ganha maior significado quando expressa que
os objetos de fato fazem parte um do outro. Desse modo podemos dizer que um conceito agrega ao outro. Trata-se
do relacionamento do tipo Agregação. Neste sentido poderíamos certamente usar de um relacionamento do tipo
Agregação para expressar o relacionamento entre Item de Pedido e Produto, sendo que o Produto é condição para a
existência de um Item de Pedido. Numa certa visão semântica, podemos dizer que neste tipo de relacionamento um
conceito agrega informação ao outro.

Neste mesmo sentido, existem casos em que o relacionamento entre os objetos visa demonstrar certos
objetos não possuem vida própria sem que haja, primeiro, um determinado objeto. Como exemplo fático podemos
dizer que só é possível a existência de Item de Pedido se antes existir um Pedido de Compra. Neste caso trata-se do
relacionamento do tipo Composição. A riqueza semântica que tal tipo de relacionamento acrescenta é que
determinados objetos são compostos por outros, em relação de todo-parte. Isso significa dizer que só existe Item de
Pedido se antes existir Pedido ou ainda dizer que Pedido é composto por Item de Pedido.

Por fim, ainda existe outro tipo de relacionamento que visa dar um significado mais sofisticado quando, por
exemplo, demonstra que há uma relação de especialização ou generalização entre objetos. Neste tipo de

3
relacionamento, um conceito herda os atributos e comportamento de outro conceito. Normalmente fixa-se um
conceito como conceito base e outro como conceito filho, onde conceito filho é especializado pois possui, além dos
atributos do conceito base conceitos específicos.

A importância dos conceitos - classes e objetos e seus relacionamentos

Com a identificação dos objetos do mundo fático, pertencentes ao Domínio do Problema e o consequente
agrupamento desses objetos em classes, que definem estrutura (atributos) e comportamento (operações ou
métodos), surgem os conceitos.

Os conceitos – classes, objetos e seus relacionamentos, emergem como o alvo das atividades de Análise. A
Análise visa modelar - estrutural e comportamental, os conceitos relevantes identificados, segundo o Domínio do
Problema.

A importância desses conceitos para a Análise é que deles serão obtidos, verificados e validados os Requisitos
que serão, posteriormente, utilizados para o Projeto do sistema em questão.

De um levantamento prévio de conceitos, do qual resultarão inúmeras classes de objetos, com atributos e
comportamentos descritos e, ainda, os relacionamentos entre tais objetos, não se pode concluir pela maturidade dos
Requisitos descobertos. A Análise se preocupa em dar mais consistência em tais Requisitos.

4
Processo de Desenvolvimento de Software

A discussão acerca de Processo de Desenvolvimento de Software (PDS) está incluída em todo um contexto de
discussão acerca de Qualidade de Software, que é o resultado final almejado pelo processo.

A qualidade de software pode ser subdividida em qualidade do produto e qualidade do processo. O foco de
todo processo é desenvolver software (sistema) de qualidade, porém, a qualidade é relativa e depende do ponto de
vista da qual é definida.

Qualidade de Software
A qualidade de um sistema se expressa do ponto de vista do usuário pode ser expressa como facilidade de
uso, eficiência, confiabilidade ou simplesmente satisfação de suas necessidades, refletindo o ponto de vista externo
da qualidade. Por um outro lado, para um profissional que atua na construção e desenvolvimento contínuo de um
sistema, a qualidade possa ser definida como facilidade de manutenção, refletindo um ponto de vista interno ao
processo de desenvolvimento. Porém, para um cliente, proprietário de um negócio, a qualidade de um sistema pode
ser expressa como sendo a capacidade que este sistema tem de agregar valor ao seu negócio.

Neste sentido, a qualidade é relativa e depende do ponto de vista do qual é analisada, sendo que ainda cabe
salientar que a mesma pode ser considerada em diferentes aspectos, como: usabilidade, confiabilidade, eficiência,
manutenibilidade, portabilidade, segurança, produtividade, custo, tempo e etc.

Qualidade do Produto
A discussão que envolve a qualidade de software (sistema) tem por objetivo principal a qualidade do produto,
ou seja, do sistema. Entende-se por produto, o sistema pronto e entregue ao usuário. Porém a preocupação que
insurge é como garantir a qualidade do sistema sem que haja garantia de qualidade no processo de construção do
sistema?

Constatar que o software (sistema), como produto final de um processo, tem qualidade é uma abordagem
indesejável para todo profissional do ramo de desenvolvimento de software, pois isso deve ser auferido no decorrer
do desenvolvimento do sistema.

Qualidade do Processo
Ao final de todo o desenvolvimento, constatar que o sistema não atende ou atende parcialmente aos
requisitos inicialmente identificados, pode implicar em altos custos financeiros para o projeto. A análise visa, em boa
dose, evitar este tipo de incidente.

Em todo o processo de Análise, Projeto, Implementação, Testes e Implantação, devem ser agregadas
atividades com o objetivo de garantir a qualidade do produto final, levando a concluir que a qualidade do produto
dependerá, em alto grau, da qualidade do processo empregado.

A premissa por detrás dessa afirmativa é a de que processos bem estabelecidos, que incorporam mecanismos
sistemáticos para acompanhar o desenvolvimento e avaliar a qualidade, no geral, conduzem a produtos de qualidade.

5
Processo de Software

Entende-se por processo de software, como sendo uma abordagem de Engenharia de Software, que envolve
diversas atividades que podem ser classificadas quanto ao seu propósito de aplicação. Tais atividades podem ser
classificadas como Atividades de Gerência de Projeto, Atividades de Garantia da Qualidade e Atividades de
Desenvolvimento (ou Técnicas ou de Construção).

Cada conjunto de atividades visa dar consistência ao processo de software adotado, visando que as atividades
desempenhadas no curso do trabalho possam garantir a qualidade do produto final, considerando os requisitos do
projeto, principalmente em relação custos e prazos.

Tabela 1: Tipos de Atividades de Processo de Software

São aquelas relacionadas ao planejamento e

Atividades de Gerência de Projeto
Atividades de Garantia da Qualidade
Atividades de Desenvolvimento
acompanhamento gerencial do projeto, tais
como realização de estimativas, elaboração
de cronogramas, análise dos riscos do projeto
etc.
São aquelas relacionadas com a garantia da
qualidade do produto em desenvolvimento e
do processo de software utilizado, tais como
revisões e inspeções de produtos
(intermediários ou finais) do
desenvolvimento.
São as atividades diretamente relacionadas
ao processo de desenvolvimento do
software, ou seja, que contribuem
diretamente para o desenvolvimento do
produto de software a ser entregue ao
cliente. São exemplos de atividades de
desenvolvimento: Especificação, Análise de
Requisitos, Projeto e Implementação.

Conforme a Tabela 1, pode-se entender que o processo de software é um conjunto de atividades, nem sempre
voltadas à implementação do software (sistema) em si, mas todas com o mesmo objetivo: garantir que haja
qualidade no processo (durante a construção) para que haja qualidade no produto (sistema).

Para se construir um produto ou sistema, seja de que natureza for, é necessário seguir uma série de passos
previsíveis, isto é, um guia, que ajude a chegar a um resultado de qualidade, dentro do tempo previsto. No caso do
desenvolvimento de software, esse “guia” é o processo de software.

Um processo de software pode ser visto como o conjunto de atividades, métodos, práticas
e transformações que guiam pessoas na produção de software.

Um processo eficaz deve, claramente, considerar as relações entre as atividades, os artefatos produzidos no
desenvolvimento, as ferramentas e os procedimentos necessários e a habilidade, o treinamento e a motivação do
pessoal envolvido.
6
Objetivo de um processo de software
Desse modo, podemos concluir que o objetivo de um processo de software é: favorecer a produção de
sistemas de alta qualidade, atingindo as necessidades dos usuários finais, dentro de um cronograma e um
orçamento previsíveis.

Elementos de um processo de software

Os processos de software são, geralmente, decompostos em diversos processos, tais como processo de
desenvolvimento, processo de garantia da qualidade, processo de gerência de projetos etc.

Os processos são compostos de atividades e para cada atividade é importante saber quais as suas
subatividades, pré-atividades, os artefatos de entrada e de saída, os recursos necessários e os procedimentos
(métodos, técnicas, modelos de documento etc.) a serem utilizados na sua realização.

Definição de um processo de software

Um processo de software não pode ser definido de forma universal, se aplicando, portanto, a todo e qualquer
tipo de software (sistema) desejado. Para ser eficaz e conduzir à construção de produtos de boa qualidade, um
processo deve ser adequado às especificidades do projeto em questão.

Assim, os processos devem ser definidos caso a caso, considerando-se as características da aplicação (domínio
do problema, tamanho, complexidade etc.), a tecnologia a ser adotada na sua construção (paradigma de
desenvolvimento, linguagem de programação, mecanismo de persistência etc.), a organização onde o produto será
desenvolvido e a equipe de desenvolvimento.

No centro da arquitetura de um processo de desenvolvimento estão as atividades-chave desse processo

relacionadas a:

• planejamento
• análise e especificação de requisitos,
• projeto,
• implementação e testes, e
• entrega e implantação

7
A escolha do modelo processo de software
A definição de um processo envolve a escolha de um modelo de processo, o detalhamento (decomposição)
de suas macro-atividades, a escolha de métodos, técnicas e roteiros (procedimentos) para a sua realização e a
definição de recursos e artefatos necessários e produzidos.

Um modelo de processo, geralmente, organiza as macro-atividades básicas do processo, estabelecendo

precedência e dependência entre as mesmas.

Para a definição completa do processo, cada atividade descrita no modelo de ciclo de vida deve ser
decomposta e para suas subatividades, devem ser associados métodos, técnicas, ferramentas e critérios de qualidade,
entre outros, formando uma base sólida para o desenvolvimento.

Adicionalmente, outras atividades tipicamente de cunho gerencial, devem ser definidas, entre elas atividade
de gerência de projetos e de controle e garantia da qualidade.

Os seguintes fatores influenciam a definição de um processo e, por conseguinte, a escolha do modelo de

processo a ser usado como base:

• tipo de software (p.ex., sistema de informação, sistema de tempo real etc.),

• paradigma de desenvolvimento (estruturado,
orientado a objetos etc.),
• domínio do problema,
• tamanho e complexidade do sistema,
• estabilidade (volatilidade) dos requisitos,
• características da equipe etc.

Modelo de Processo

Um modelo de processo pode ser entendido como uma representação abstrata de um esqueleto de processo,
uma forma ou uma série de recomendações, contando, ainda, com algumas atividades principais.

Necessário é acrescentar que, entre tais recomendações, é necessário que haja uma ordem de precedência
entre elas e, opcionalmente, artefatos requeridos e produzidos por cada uma delas.

Um modelo de processo descreve uma filosofia de organização de atividades, estruturando as atividades do

processo em fases e definindo como essas fases estão relacionadas, não descrevendo um curso de ações exato,
recursos, procedimentos e restrições, pois isso se aplica caso a caso, sendo apenas um ponto de partida para definir
como o projeto deve ser conduzido. A adoção de um determinado modelo não é o suficiente para guiar e controlar
um projeto de software na prática, ou seja, não garante a qualidade do processo e do produto.

8
Fases recomendadas
Ainda que os processos tenham de ser definidos caso a caso, de maneira geral, o ciclo de vida de um
software envolve, pelo menos, as seguintes fases:

• Planejamento,
• Análise e Especificação de Requisitos,
• Projeto,
• Implementação,
• Testes,
• Entrega e Implantação
Tabela 2: Fases recomendadas para um processo de software

O objetivo do planejamento de projeto é

fornecer uma estrutura que possibilite ao
Planejamento
gerente realizar estimativas de recursos,
custos e prazos.
O conhecimento sobre o domínio do
problema, bem como a funcionalidade e o
comportamento esperados são
fundamentais. Identificados os requisitos
Análise e Especificação de Requisitos do sistema a ser desenvolvido, estes
devem ser modelados, avaliados e
documentados. Essa fase de preocupa em
descrever o “quê deve ser feito” e não
como “deve ser feito”.
Esta fase é responsável por incorporar
requisitos tecnológicos aos requisitos
essenciais do sistema, modelados na fase
Projeto
anterior e, portanto, requer que a
plataforma de implementação seja
conhecida.
A fase de implementação realiza esta
Implementação tarefa, isto é, cada unidade de software do
projeto detalhado é implementada
A fase de testes é imprescindível para a
garantida da qualidade do processo e do
Testes produto. Pode ser aplicada, conforme o
caso, em todas as outras fases do processo,
cada qual com sua especificidade.
Nesta fase o projeto é entregue de forma a
Entrega e Implantação constatar que as necessidades do usuário
(requisitos) foram satisfeitas.

Modelos de Processos existentes

Existem diversos modelos de processos que, de maneira geral, contemplam as fases, identificadas conforme
a Tabela 2, sendo: Planejamento, Análise e Especificação de Requisitos, Projeto, Implementação, Testes e Entrega e
Implantação.

9
 Os modelos sequencias são modelos que organizam o processo em uma sequência linear de fases, requerendo
que para a entrega do produto final, todas as fases tenham de ser executadas, não admitindo entregas intermediárias.
São exemplos de modelos sequenciais: Modelo Cascata e Modelo em “V”.

Existem também os modelos incrementais, que são modelos onde o software (sistema) almejado é dividido
em subsistemas ou módulos e os incrementos (versões) do software são acrescidos a cada ciclo de trabalho e entregue
ao usuário. São exemplos de Modelos Incrementais: Modelo Incremental e Modelo RAD.

Por fim, os modelos evolutivos surgiram da admissão de que os requisitos podem sofrer mudanças. Tal
modelo se adequa bem em situações onde a volatilidade e incerteza dos requisitos é patente. Os modelos evolutivos
concentram suas preocupações na clarificação dos requisitos, onde, com a consistência de requisitos busca-se a
entrega de software pronto e que agregue valor ao usuário. São exemplos de modelos evolutivos: Modelo Espiral e
Modelo Iterativo.

Modelo Iterativo
O modelo Iterativo é um tipo de modelo evolutivo e é amplamente utilizado me metodologias ágeis de
desenvolvimento de software.

Uma característica muito forte deste modelo, em contraposição aos demais já apresentados, é que ele
preconiza a imediata programação e teste de um sistema parcial em ciclos repetidos.

Dessa forma, considera que o desenvolvimento inicia sem que os requisitos estejam totalmente definidos,
aceitando, dessa forma, mudanças dos requisitos que são atendidas a cada iteração.

Figura 3: Modelos formais vs Modelos Ágil (Iterativos)

As iterações são na verdade ciclos bem definidos de tempo, de requisitos alvos definidos, que serão analisados,
desenvolvidos e entregues, ou seja, ciclos onde as fases recomendadas serão aplicadas, tendo por pressuposto que,
ao final de cada iteração, o software entregue, mesmo sendo apenas uma porção dos requisitos, será um software
plenamente capaz de utilização, conforme a Figura 3.

10
Importância da Análise no Processo de Desenvolvimento de Software

Qualquer que seja o modelo de processos adotado, dentre as fases recomendadas, a fase de Análise ganha
certo protagonismo, pois é a fase responsável por investigar o Domínio de Problema em busca de identificar, refinar
e documentar os principais requisitos a serem atingidos.

Enquanto outras fases se preocupam com resultados mais palpáveis em termos de resultados, propriamente
ditos, como códigos gerados, aplicativos e etc. a Análise se preocupa na identificação de conceitos, e mais ainda, na
relevância destes conceitos dentro do problema em questão.

Pode-se dizer que a Análise visa identificar “o quê” deverá ser feito, enquanto as demais fazes, a exemplo da
fase de Projeto, se preocupa em “como” fazer.

Portanto, o estudo das técnicas de identificação de requisitos é demasiadamente importante, pois grande
parte dos problemas existentes na produção de software (sistemas) está relacionada a más execuções da fase de
Análise, gerando retrabalho e aumentando, consequentemente, os custos e prazos antes estabelecidos.

O termo “análise” tem um significado amplo, podendo tão somente assumir termos como “análise de
requisitos” enquanto investigação dos requisitos, pontos mais importantes dessa fase; ou ainda “análise orientada a
objetos” que visa identificar os objetos e seus relacionamentos, como conceitos mais relevantes de um Domínio de
Problema.

Em resumo, para fazer a coisa certa requer Análise e para fazer certo a coisa requer Projeto.

11