Escolar Documentos
Profissional Documentos
Cultura Documentos
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.
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.
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.
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.
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.
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.
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.
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.
• 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.
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.
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.
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
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.
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