Análise de Sistemas Orientada A Objetos

Anlise de Sistemas
Orientada a Objetos
Autor: Prof. Fbio Rossi Versolatto
Colaboradores: Prof. Luciano Soares de Souza
Profa. Ana Carolina Bueno Borges
Professor conteudista: Fbio Rossi Versolatto
Mestre em Engenharia de Software pelo Instituto de Pesquisas Tecnolgicas (IPT) da USP, especializado em
Arquitetura, Componentizao e SOA pela Universidade Estadual de Campinas (Unicamp), ps-graduado em Tecnologia
de Construo de Software Orientado a Objetos pelo Centro Universitrio Senac e bacharel em Cincias da Computao
pelo Centro Universitrio da FEI.
Professor do curso de Anlise e Desenvolvimento de Sistemas da Universidade Paulista (UNIP), no qual leciona e
orienta os alunos no programa Projeto Integrado Multidisciplinar.
Atuando na rea de pesquisa, possui publicaes e participaes em eventos na rea de Engenharia de Software
no Brasil e no exterior, alm de projetos de pesquisa aplicados na rea social.
Atua na rea de desenvolvimento de sistemas de software com larga experincia em sistemas estratgicos em
empresas de grande porte, com nfase em anlise de requisitos, projeto, arquitetura e desenvolvimento de solues
de software.
Dados Internacionais de Catalogao na Publicao (CIP)
V564a Versolatto, Fbio Rossi.
Anlise de Sistemas Orientada a Objetos. / Fbio Rossi Versolatto.

So Paulo: Editora Sol, 2015.
164 p., il.
Nota: este volume est publicado nos Cadernos de Estudos e

Pesquisas da UNIP, Srie Didtica, ano XIX, n. 2-027/15, ISSN 1517-9230.
1. Anlise de sistemas. 2. Projeto de desenvolvimento. 3.

Engenharia de requisitos. I. Ttulo.
CDU 681.3.07
Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida por qualquer forma e/ou
quaisquer meios (eletrnico, incluindo fotocpia e gravao) ou arquivada em qualquer sistema ou banco de dados sem
permisso escrita da Universidade Paulista.
Prof. Dr. Joo Carlos Di Genio
Reitor
Prof. Fbio Romeu de Carvalho

Vice-Reitor de Planejamento, Administrao e Finanas
Profa. Melnia Dalla Torre

Vice-Reitora de Unidades Universitrias
Prof. Dr. Yugo Okida

Vice-Reitor de Ps-Graduao e Pesquisa
Profa. Dra. Marlia Ancona-Lopez

Vice-Reitora de Graduao
Unip Interativa EaD
Profa. Elisabete Brihy

Prof. Marcelo Souza
Prof. Dr. Luiz Felipe Scabar
Prof. Ivan Daliberto Frugoli
Material Didtico EaD
Comisso editorial:
Dra. Anglica L. Carlini (UNIP)
Dra. Divane Alves da Silva (UNIP)
Dr. Ivan Dias da Motta (CESUMAR)
Dra. Ktia Mosorov Alonso (UFMT)
Dra. Valria de Carvalho (UNIP)
Apoio:
Profa. Cludia Regina Baptista EaD
Profa. Betisa Malaman Comisso de Qualicao e Avaliao de Cursos
Projeto grco:
Prof. Alexandre Ponzetto
Reviso:
Rose Castilho
Marina Bueno de Carvalho
Sumrio
Anlise de Sistemas Orientada a Objetos
APRESENTAO ......................................................................................................................................................7
INTRODUO ...........................................................................................................................................................7
Unidade I
1 INTRODUO ANLISE DE SISTEMAS....................................................................................................9
1.1 Introduo ..................................................................................................................................................9
1.2 Sistemas de informao x software ............................................................................................. 11
2 PROJETO DE DESENVOLVIMENTO ............................................................................................................. 15
2.1 Processo de desenvolvimento de software................................................................................ 15
2.2 Modelos de processo de software ................................................................................................. 16
2.2.1 Modelo cascata........................................................................................................................................ 17
2.2.2 Modelo incremental............................................................................................................................... 19
2.2.3 Prototipagem............................................................................................................................................ 21
2.2.4 Modelo espiral .......................................................................................................................................... 23
2.2.5 Processo unicado ................................................................................................................................. 25
2.3 Processo X pessoas............................................................................................................................... 27
2.4 O paradigma da orientao a objetos.......................................................................................... 29
2.4.1 Classe ........................................................................................................................................................... 31
2.4.2 Objeto .......................................................................................................................................................... 32
2.4.3 Abstrao ................................................................................................................................................... 32
2.4.4 Encapsulamento ...................................................................................................................................... 33
2.4.5 Herana ....................................................................................................................................................... 33
2.4.6 Polimorsmo............................................................................................................................................. 34
2.4.7 Ligao e mensagem ............................................................................................................................. 35
2.5 A linguagem de modelagem unicada ....................................................................................... 35
Unidade II
3 ENGENHARIA DE REQUISITOS.................................................................................................................... 40
3.1 Introduo Engenharia de Requisitos ...................................................................................... 40
3.2 Classicao de requisitos ................................................................................................................ 43
3.2.1 Requisitos funcionais ............................................................................................................................ 44
3.2.2 Requisitos no funcionais ................................................................................................................... 45
3.3 Processo de Engenharias de Requisitos ...................................................................................... 50
3.3.1 Elicitao de requisitos ......................................................................................................................... 51
3.3.2 Anlise de requisitos .............................................................................................................................. 54
3.3.3 Documentao de requisitos ............................................................................................................. 55
3.3.4 Validao de requisitos ......................................................................................................................... 56
3.3.5 Gerenciamento de requisitos ............................................................................................................. 57
4 MODELAGEM DE CASOS DE USO.............................................................................................................. 59
4.1 Casos de uso e atores ......................................................................................................................... 61
4.2 Descrio de casos de uso ................................................................................................................ 61
4.3 Diagrama de caso de uso .................................................................................................................. 65
4.4 Estrutura do diagrama de caso de uso ........................................................................................ 66
4.4.1 Relacionamento entre casos de uso ............................................................................................... 66
4.4.2 Relacionamento entre atores ............................................................................................................ 69
Unidade III
5 MODELAGEM DE PROCESSOS DE NEGCIO......................................................................................... 75
5.1 Introduo modelagem de processos de negcio............................................................... 75
5.2 O papel do analista de negcio ...................................................................................................... 78
5.3 Regras de negcio................................................................................................................................ 79
5.4 Mtodos de modelagem de processos de negcio................................................................. 82
5.4.1 UML .............................................................................................................................................................. 83
6 AS VISES DA UML......................................................................................................................................... 95
Unidade IV
7 VISO ESTRUTURAL ESTTICA .................................................................................................................100
7.1 Conceitos fundamentais da orientao a objetos ................................................................102
7.2 Modelo de classes de domnio ......................................................................................................104
7.2.1 Conceitos fundamentais do modelo de domnio ....................................................................104
7.2.2 Relacionamento entre classes .........................................................................................................107
7.2.3 Herana ..................................................................................................................................................... 115
7.2.4 Diagrama de classes............................................................................................................................. 118
7.2.5 Diagrama de objetos........................................................................................................................... 122
8 VISO ESTRUTURAL DINMICA...............................................................................................................124
8.1 Realizao de casos de uso ............................................................................................................125
8.2 Classes de anlise ...............................................................................................................................126
8.2.1 Entidade ................................................................................................................................................... 127
8.2.2 Fronteira .................................................................................................................................................. 127
8.2.3 Controle ................................................................................................................................................... 127
8.3 Comportamento de objetos ...........................................................................................................129
8.3.1 Representando mtodos ................................................................................................................... 129
8.3.2 Polimorsmo...........................................................................................................................................131
8.3.3 Visibilidade de atributos e mtodos ............................................................................................. 132
8.3.4 IInterfaces ............................................................................................................................................... 134
8.3.5 Ciclo de vida de objetos .................................................................................................................... 135
8.4 Comunicao entre objetos ...........................................................................................................137
8.4.1 Mensagem .............................................................................................................................................. 137
8.4.2 Diagrama de sequncia ..................................................................................................................... 138
APRESENTAO
A disciplina Anlise de Sistemas Orientada a Objetos tem como objetivo apresentar ao aluno as boas
prticas para captar e mapear as necessidades das organizaes, inseridas em um mercado cada vez
mais competitivo, de tal forma que essas necessidades captadas de forma eciente se tornem subsdios
para o futuro projeto de software, utilizando para isso o paradigma da orientao a objetos.
Para atingir este objetivo, a disciplina comea contextualizando o aluno com os problemas
que a Engenharia de Software se prope a resolver, traando um paralelo com a linha de tempo
de sua evoluo.
Com o aluno contextualizado na temtica, a disciplina apresenta e discute a importncia das

atividades de desenvolvimento a serem executadas de forma organizada dentro de um projeto,
apresentando os principais modelos de desenvolvimento e papis a serem desempenhados pelos
integrantes da equipe deste projeto.
Conceitos bsicos e motivaes postos, debate-se a engenharia de requisitos como fase fundamental
dentro de um projeto de desenvolvimento, mostrando as principais tcnicas para elicitao, mapeamento,
modelagem, documentao e gesto de todos os tipos de requisitos de um processo de negcio.
Por m, a disciplina apresenta a UML (Unied Modeling Language) como uma ferramenta para a
representao e a modelagem de um sistema de software, partindo da modelagem dos requisitos e
chegando ao projeto dos componentes do software, utilizando os diagramas da UML como ferramenta
de apoio em todo o processo.
INTRODUO
Desde que o software se estabeleceu como uma ferramenta importante na estratgia competitiva
das grandes empresas, a indstria de desenvolvimento vem passando por transformaes para atender
s necessidades cada vez maiores deste mercado.
O desao lanado no est mais no simples fato de se desenvolver uma srie de linhas de cdigo
que, agrupadas, compem um sistema de software, mas sim em desenvolver este software como um
produto, como uma ferramenta de estratgia competitiva que atenda a uma srie de exigncias e a
determinados padres de qualidade.
O que se espera de um projeto de software que ele seja iniciado e terminado no menor intervalo
de tempo possvel e que seja desenvolvido com um custo competitivo e, principalmente, com alta
qualidade. Balancear essas trs variveis em uma equao chamada projeto de software um dos
grandes desaos da Engenharia de Software.
Se o software deve ser enxergado como uma ferramenta de estratgia competitiva em uma grande
corporao, parece razovel que um projeto no deva tomar um tempo excessivo, anal de contas, em
um mercado cada vez mais competitivo, tem a vantagem aquele que larga na frente.
7
Seguindo a mesma linha de raciocnio, espera-se que um projeto no tenha custos exorbitantes,
o que pode, inclusive, torn-lo invivel. Em casos de projetos malsucedidos, o custo de um processo
de negcio realizado de forma no automatizada pode ser mais vantajoso que automatiz-lo. Logo,
podemos notar que o software deve estar atento relao custo-benefcio.
Sob uma viso ideal, um projeto deve ser executado em um tempo razovel e com um custo vivel.
Como se isso no bastasse, um sistema de software competitivo deve atingir certo nvel de qualidade.
As necessidades do negcio devem ser mapeadas de forma eciente. Automatizar o processo de

negcio de uma empresa uma tarefa rdua, que requer inicialmente e, principalmente, total clareza
de todas as regras e necessidades, ou requisitos, que envolvem este processo a ser automatizado. A
qualidade do software que se pretende entregar passa inicialmente por essa fase.
possvel tambm, em um primeiro momento, que nos deparemos com a necessidade de atendermos
a requisitos no to claros, mas que em hiptese alguma so menos importantes.
Parece razovel, em um mundo onde a tecnologia de hardware evoluiu e segue em constante

evoluo, que devamos nos preocupar em desenvolver sistemas de software que se adaptem s diversas
tecnologias e plataformas de computadores pessoais, sistemas operacionais, dispositivos mveis, entre
outros. Tudo isso sem perder o foco em fornecer uma experincia rica ao usurio nal para que ele tenha
segurana e conforto no uso e, tambm, para que possa realizar suas atividades de maneira produtiva.
Voltando linha de raciocnio anterior, se o software deve ser identicado como uma ferramenta
de estratgia competitiva em uma grande corporao, e que deve ser desenvolvido em tempo e custo
de tal forma a torn-lo efetivamente competitivo, no difcil observar a necessidade de pensarmos
em um projeto que nos possibilite manuteno rpida e eciente. Anal, se o mercado competitivo
muda com muita rapidez, possvel imaginar que um sistema de software tambm deva se adaptar
e essa realidade.
A partir dessa reexo inicial, podemos nos questionar: ser que realmente estamos dando a
devida ateno a todos esses pontos na hora de iniciar um projeto? Por que caractersticas de outras
engenharias, como padronizao e estabelecimento de um processo produtivo, nos parecem to
distantes da Engenharia de Software?
O paradigma da orientao a objetos, iniciada nesta disciplina, tem como objetivo levantar e
responder a essas e outras questes.
Este livro-texto busca oferecer um norte para as melhores prticas de desenvolvimento, de tal forma
que possamos atingir, como produto nal, o software como uma ferramenta de estratgia competitiva
de qualidade.
8
ANLISE DE SISTEMAS ORIENTADA A OBJETOS
Unidade I
1 INTRODUO ANLISE DE SISTEMAS
1.1 Introduo
A evoluo constante das plataformas de hardware, acompanhada do aumento escalar no uso dos
computadores pessoais, mudou a forma como se pensava o desenvolvimento de um sistema de software.
Com essa evoluo, os sistemas de software caram necessariamente mais completos e complexos.
Muito disso se deve necessidade de se utilizar todos os recursos disponveis, recursos estes que faltavam
em outros momentos.
Segundo Stallings (2003), a evoluo dos computadores evidenciada, ao longo dos anos, pelo
aumento da capacidade dos processadores, da memria e da velocidade do mecanismo entrada/sada.
Ainda segundo Stallings (2003), essa evoluo deve-se ao fato de que os componentes, tambm
chamados de transistores, que compem um processador foram diminuindo em tamanho com o passar
do tempo.
Com essa diminuio, foi possvel reduzir o espao entre esses componentes. Diminuindo tambm a
distncia que uma corrente eltrica percorre entre dois ou mais transistores, obtendo um consequente
ganho na velocidade de processamento.
Alm do aumento na velocidade do processamento, a diminuio dos componentes gerou um

espao maior na pastilha dos processadores, que, por sua vez, foram preenchidas por mais transistores,
havendo, consequentemente, um novo ganho de velocidade.
Podemos notar esse ciclo analisando a Lei de Moore (Moore, 1965), proposta por um dos fundadores
da Intel, Gordon Moore, que observou que a quantidade de transistores em um processador duplicava
a cada 12 meses.
Observao
Segundo a Lei de Moore, se ns construssemos um processador hoje

(janeiro de 2015) com uma capacidade de processamento de X, em janeiro
de 2016 construiramos um processador com capacidade 2 X.
9
Unidade I
108
107
Pentium Pro Pentium II
Pentium PPC G3
486 PPC 601
106
386
80286
105
8086
104
4004
103
1970 1975 1980 1985 1990 1995 2000 2005
Figura 1 Crescimento do Nmero de Transistores x Lei de Moore
A figura anterior mostra o crescimento do nmero de transistores dos processadores Intel no

decorrer do tempo em um comparativo com o que prega a Lei de Moore, representada pela linha
central do grfico.
A evoluo do nmero de transistores segue o que foi previsto por Moore, com a nica ressalva que,
nos anos 1970, a duplicao se deu a cada 18 meses, em contrapartida aos 12 meses observados na
teoria de 1965.
Alm do bvio aumento na capacidade de processamento, alguns dos reexos da Lei de Moore:
Diminuio do custo de produo: com o baixo custo de produo dos computadores, foi possvel
reduzir o preo nal e, consequentemente, houve um aumento nas vendas e na produo em
escala dos equipamentos.
Diminuio do consumo de energia: os computadores passaram a consumir menos energia,

tornando-se cada vez mais atrativos a um pblico cada vez mais crescente.
Computadores menores: com componentes menores, os computadores tambm reduziram de

tamanho. Passamos a no ter mais a necessidade de um local fsico especco e especial para o
computador.
Computadores mais conveis: com um maior nmero de transistores em uma pastilha, diminuiu
a necessidade de conexes entre pastilhas. Essas conexes so feitas utilizando solda, que menos
convel se comparadas s conexes feitas entre transistores.
10
Esses fatores geraram uma atmosfera positiva que culminaria, na dcada de 1980, com a massicao
do uso de computadores por usurios comuns, o uso dos computadores pessoais.
Com o problema hardware resolvido, o primeiro desao posto estava em como desenvolver sistemas
que maximizassem o uso do processador. Como utilizar toda a capacidade de processamento paralelo?
Como diminuir a ociosidade de um processador?
Aps a massicao do uso de computadores, surgiram novos desaos. As mquinas passaram a ser
operadas por usurios comuns. No era mais necessrio ser um especialista, os computadores passaram
a ser mais fceis de serem usados. Desao posto: como desenvolver sistemas que acompanhassem a
tendncia da massicao do uso?
Com esses e muitos outros desaos, passamos a ter uma maior preocupao com a informao. A
forma como a informao era trabalhada, trafegada, levada ao usurio e gerenciada passou a ter papel
de fundamental importncia.
Surgiu ento o conceito de sistemas de informao.
Saiba mais
Para mais informaes sobre dispositivos de entrada/sada, processadores,

memria e arquitetura de computadores, leia:
STALLINGS, W. Arquitetura de computadores. So Paulo: Prentice

Hall, 2003.
1.2 Sistemas de informao x software
O que o sistema imunolgico de uma pessoa? De forma resumida e popular, o sistema imunolgico
biolgico a composio de diferentes tipos de clulas, cada qual com sua funo, que atuam
conjuntamente com o objetivo de manter a integridade do organismo que est sendo protegido.
Algumas clulas tm a funo de identicar possveis ameaas e outras, de tomar determinadas

aes em caso de ataque. Essas clulas so independentes entre si, todavia, quando da execuo de
alguma tarefa, agem em conjunto (SILVA, 2001).
De forma anloga, um sistema de informao a composio de informaes (ou dados),

pessoas, processos e tecnologias que tem por objetivo apoiar ou melhorar o processo de negcio
de uma corporao.
Sistemas de informao tem foco na informao gerada em um processo organizacional, de tal

forma a originar valor a esse processo (BEZERRA, 2006).
11
Unidade I
Quando falamos em tecnologia de sistemas de informao, estamos falando de toda plataforma

tecnolgica que d suporte ao processo de negcio, como infraestrutura de rede, servidores,
computadores, sistemas operacionais e sistemas de software.
Observao
Rezende (2005) observa que todo sistema que gera e armazena

informao pode ser considerado um sistema de informao,
independentemente se utiliza tecnologia ou no.
Imagine um sistema de informao que tem como objetivo controlar o processo de um call center.
Qual valor estratgico e competitivo esse sistema de informao est produzindo empresa?
Poderamos trabalhar com a ideia de que esse sistema proporcionaria atendimento mais ecaz e
eciente ao cliente, e geraria informaes importantes que serviriam de apoio gerencial, como a denio
do perl do cliente. Ainda poderamos pensar como um valor importante estar apto legislao de
apoio e atendimento ao consumidor, que est em constante aperfeioamento.
importante ter em mente quais so os objetivos que o sistema deve atingir, pois eles servem de
norte para todo o restante.
No exemplo do processo de um call center, importante o mapeamento do processo a ser executado,

como representado de forma simplicada na gura a seguir. Qual a sequncia de atividades a serem
executadas a partir do momento que o cliente atendido, quem so as pessoas que executam cada
atividade e qual informao gerada no decorrer do processo.
Atendente
recebe ligao
do cliente
Reclamao Sugesto
Gerar Gerar sugesto

reclamao
Protocolo de Protocolo de
reclamao sugesto
Gerente l
protocolos
Figura 2 Mapeamento simplicado de um processo de atendimento
12
Na plataforma tecnolgica, deveramos nos atentar a detalhes como como e onde essa informao
seria armazenada e qual o melhor projeto de rede para suportar o trfego dessa informao.
Modelar um sistema de informao no tarefa das mais simples e, dentro disso tudo, importante
pensarmos qual parte do processo seria automatizada por um sistema de software.
Projetar um sistema de software compreende termos a noo de que ele um componente de

um sistema de informao, ou seja, que ele parte de um todo e que precisa estar harmoniosamente
encaixado neste todo.
Diversas foram as abordagens e tcnicas criadas para modelar sistemas de software at chegarmos
abordagem foco deste livro: orientao a objetos. Por ora, entenda que a orientao a objetos uma
forma de se projetar um sistema de software. Adiante, detalharemos melhor o assunto.
O quadro a seguir mostra a evoluo das formas de se desenvolver sistemas, que anda em paralelo
com a evoluo dos computadores j debatida anteriormente.
Quadro 1 Evoluo da modelagem de sistemas de software
Perodo Cenrio Abordagem de modelagem

Desenvolvimento sem planejamento inicial, Fluxogramas e/ou diagramas de
Dcadas de 1950 e 1960 devido simplicidade dos sistemas de software. mdulos.
Surgimento de computadores mais acessveis
e avanados.
Sistemas de software mais complexos com Projeto estruturado e programao
Dcada de 1970 necessidades mais especcas, como tempo estruturada.
real e multiusurio.
Surgimento dos primeiros bancos de dados
relacionais.
Massicao do uso de computadores.
Surgimento dos primeiros conceitos de
Dcada de 1980 Anlise estruturada.
sistemas distribudos e sistemas inteligentes.
Necessidade de interfaces mais ricas.
Computadores mais avanados.
Conceitos de computao paralela passam a se
sedimentar. Paradigma da orientao a objetos.
Surgimento dos conceitos de sistemas
Dcada de 1990 especialistas e sistemas para mobilidade.
Criao da linguagem de modelagem
Necessidade cada vez maior de produtividade. unicada UML.
Chave: Conceitos de reso.
Necessidade de uma linguagem nica de
representao e modelagem de sistemas (*).
Adaptado de: Bezerra (2006, p. 12).
Um sistema de software tambm pode ser identicado como o conjunto de vrios componentes
que, quando executados, produzem um resultado previamente desejado.
13
Unidade I
Esses componentes podem ser chamados de componentes de software, que so desenvolvidos

utilizando mtodos e processos que estabelecem uma relao entre a necessidade do cliente e um
cdigo executado em uma mquina (PRESSMAN, 2006).
Desenvolver um sistema de software vai alm da simples digitao de linhas de cdigo, mas est
ligado ao entendimento das necessidades do cliente, as fronteiras dele dentro de um sistema de
informao, de tal forma que software possa atender a certos parmetros de qualidade, sendo, assim,
ecaz e eciente dentro do processo organizacional.
A Engenharia de Software tem por objetivo apoiar o desenvolvimento de software fornecendo

tcnicas para especicar, projetar, manter e gerir um sistema (SOMMERVILLE, 2010). Ela baseada em
trs pilares:
Mtodos: provm um conjunto de atividades com nfase no como fazer para desenvolver um
sistema de software.
Ferramentas: mecanismos que do suporte execuo das atividades descritas no mtodo. Um

assunto que est sempre em pauta, quando estamos falando de ferramentas, so as chamadas
ferramentas CASE (Computer-Aided Software Engineering), que fornecem e consomem
informaes geradas nas atividades especicadas nos mtodos da Engenharia de Software.
Se utilizadas em conjunto, de forma sistmica e organizada, fornecem suporte ao processo de
desenvolvimento de software.
Saiba mais
Saiba mais sobre a seleo e utilizao de ferramentas CASE na

seguinte norma:
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/

INTERNATIONAL ELECTROTECHNICAL COMMISSION. 14102: information
technology guideline for the evaluation and selection of case tools.
Geneve: ISO, 2008.
Processos: proveem o elo entre mtodos e ferramentas. Denem o quando e onde fazer, indicando
a sequncia de execuo das atividades, quais ferramentas utilizar e quem deve ser o responsvel
pela atividade.
Observao
Roger Pressman (PRESSMAN, 2006) e Iam Sommerville (SOMMERVILLE,

2010) so considerados dois dos maiores expoentes da Engenharia de Software.
14
Em resumo, a Engenharia de Software compreende um conjunto de atividades a serem executadas em

uma determinada sequncia, com o uso de ferramentas de suporte, dentro de um projeto de desenvolvimento.
2 PROJETO DE DESENVOLVIMENTO
2.1 Processo de desenvolvimento de software
O processo de desenvolvimento de software, conforme dito anteriormente, resume-se a um

conjunto de atividades executadas em uma determinada sequncia. Esse conjunto de atividades
tambm pode ser chamado de etapas da Engenharia de Software ou paradigmas da Engenharia de
Software (PRESSMAN, 2006).
A escolha de um processo de desenvolvimento passa principalmente pela natureza do problema

a ser resolvido. Existem muitos paradigmas aplicados e que detalharemos nas prximas sees.
Todavia, qualquer que seja o paradigma, segundo Sommerville (2010), obrigatria a presena de
quatro macroatividades:
Quadro 2 Atividades fundamentais para a Engenharia de Software
Atividade Descrio
Fase na qual so denidas e especicadas as funcionalidades do
Especicao de software software, seus requisitos e suas regras de execuo.
Fase na qual os requisitos so transformados em sistema de software.
Projeto e implementao de software Quando so projetados e construdos os componentes de software e
suas integraes.
Validao de software Fase na qual o software validado frente aos requisitos especicados.
Evoluo de software Fase na qual so traadas estratgias para que o sistema de software
possa ser mantido e evoludo na medida.
Adaptado de: Sommerville (2010, p. 28).
Dizemos que essas atividades so macroatividades pelo fato de que elas podem, e devem, possuir
subatividades e/ou atividades que as suportem, por isso dizemos que so macro ou complexas.
Se zermos uma analogia com a Engenharia Civil, podemos imaginar que a atividade de especicao
produz os requisitos de uma casa, como a metragem, a quantidade de quartos, tipo de cozinha,
quantidade de banheiros etc. Enquanto a fase de projeto ir produzir a planta da casa, transformar os
desejos do proprietrio em projeto. Se utilizar boas ferramentas, o projetista da casa poder exibir um
modelo quase que nal da casa para o seu cliente, com detalhes que inicialmente poderiam at passar
despercebidos, como a cor das paredes.
Na implementao ou construo, a casa comea a se concretizar sicamente. Os requisitos do

proprietrio, que viraram um projeto consistente, tomam corpo com tijolos e cimento.
Quem j passou por uma situao parecida saber muito bem do que estamos falando. Com o
andamento das obras, difcil segurar a ansiedade de dar uma olhada.
15
Unidade I
comum que, com a obra tomando forma, mudemos nossa forma de ver. O que antes era uma
planta, um projeto, passa a se tornar algo concreto, palpvel. Nessa hora, solicitamos pequenos ajustes
no projeto, o que acaba invariavelmente reetindo na prpria obra.
Chamamos de validao o ato de analisarmos se o que est sendo construdo est em conformidade
com o que foi desejado e/ou se est em conformidade com o que foi projetado. A possibilidade de
correes e ajustes grande nessa fase.
Se o projeto e a construo da casa foram feitos utilizando bons padres e boas ferramentas, temos
a garantia, ou uma boa probabilidade, de que no tenhamos grandes problemas.
No entanto, mesmo que acontea algum tipo de problema ou que desejssemos algum tipo de
mudana, temos a garantia de que a manuteno ter o menor custo possvel.
Feito esse paralelo, voltemos para o processo de desenvolvimento de software. Cada atividade possui:
Pr e ps-condies: qual o cenrio pr e ps-execuo de uma atividade. Por exemplo: para

validao de um software, necessrio que este esteja implementado, aps execuo da validao,
espera-se que o software esteja validado.
Papis: quem o responsvel pela execuo da tarefa. Por exemplo: o analista de testes
responsvel pela validao.
Produtos: tambm chamados de artefatos, o que produzido como sada de uma determinada
atividade. Por exemplo: espera-se como artefato de sada da atividade de especicao de software
um documento contendo a descrio detalhada de todas as necessidades do negcio.
Saiba mais
A norma IEE 12207 (2006), na seo processo de desenvolvimento,

especifica, dentro de um parmetro de boas prticas, as atividades
e a sequncia de execuo para o desenvolvimento de um produto
de software:
INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS. 12207:

standard for information technology software life cycle processes. New
York: IEEE, 2008.
2.2 Modelos de processo de software
Muitos so os modelos de processos aplicados e debatidos atualmente. Nesta seo, abordaremos alguns
dos diversos modelos de processos de software utilizados atualmente na indstria de desenvolvimento.
16
2.2.1 Modelo cascata
Tambm chamado de waterfall ou tambm citado na literatura como ciclo de vida clssico, o modelo
cascata composto de cinco atividades.
Anlise de requisitos
Nesta fase so elicitados e documentados os requisitos do sistema. Existem tcnicas e processos de

elicitao de requisitos, que sero detalhadas mais adiante.
Projeto
Nesta fase so denidos os componentes do software e como eles iro interagir para atingir os
requisitos elicitados na fase de anlise dos requisitos.
tambm nesta fase que so definidas as necessidades e as restries de software e hardware,

como banco de dados, sistemas operacionais e configuraes mnimas de espao em disco e
processamento necessrias para o projeto de software. neste momento que a arquitetura do
sistema comea a ser definida.
Codicao
Nesta fase os componentes do software so desenvolvidos em linguagem de mquina.
comum que nesta fase sejam feitos testes unitrios, ou tambm chamados de testes de
desenvolvimento, que tm como intuito a deteco, se houver, e correo de pequenas falhas
unitariamente em cada componente de software.
Testes
Nesta fase o software construdo submetido validao com o objetivo de encontrar e corrigir
possveis no conformidades com os requisitos avaliados, com a arquitetura denida ou at mesmo
erros de construo.
Saiba mais
Existem inmeros processos que tm como objetivo a garantia da

qualidade do software. Saiba mais na obra:
CORTS, M. L.; CHIOSSI, T. C. dos S. Modelos de qualidade de software.

Campinas: Unicamp, 2001.
17
Unidade I
Implantao e manuteno
A fase de implantao e manuteno a fase mais longa do ciclo de vida de um software e tem
incio quando o sistema colocado para uso por parte do usurio nal.
Na prtica, dizemos que o sistema est em ambiente produtivo, ou seja, o resultado de suas operaes
ou falhas afetaro diretamente o processo da organizao.
Nesta fase, possvel que o sistema passe por alteraes, seja para correo de algum erro no
encontrado na fase de testes ou mudanas nos requisitos provocadas pelas mais diversas razes.
Lembrete
Uma das importantes caractersticas que um sistema de software deve

possuir ser manutenvel, ou seja, a capacidade e a facilidade de adaptao de um
software. Quanto melhor a manutenibilidade, melhor a qualidade do software.
Anlise de
requisitos
Projeto
Codicao
Testes
Implantao e
manuteno
Figura 3 Sequncia de execuo das atividades no modelo cascata
No modelo cascata, as atividades so executadas de forma sequencial. Assim, uma atividade no iniciada
at que sua predecessora seja completamente nalizada. Isso nos permite armar, por exemplo, que a construo
no iniciada at que seja nalizada a arquitetura do sistema de software na fase de projeto, que, por sua vez,
no iniciada at que todos os requisitos sejam levantados, documentados e aprovados pelo usurio.
justamente nesse ponto que est uma das maiores fragilidades deste modelo.
A fase de projeto no se inicia at que todos os requisitos sejam elicitados, documentados e aprovados
pelo usurio. comum que requisitos novos surjam e sejam alterados no curso do projeto, pelas mais diversas
18
razes, entre elas a falta de habilidade do analista em extrair e captar as necessidades do processo de negcio.
A mudana nos requisitos pode ocorrer durante a fase de projeto, codicao ou at mesmo na fase de testes,
assim como problemas na arquitetura podem ser identicados na construo ou na implantao.
Esse cenrio nos expe duas situaes:
Alto custo em cada atividade: cada atividade acaba por levar mais tempo para ser nalizada,
justamente para minimizar os impactos de possveis falhas.
Alto custo de retrabalho: no caso de encontrarmos alguma falha em algum produto produzido em
alguma atividade, o custo de correo alto.
Por exemplo, se encontrarmos uma desconformidade originada de requisitos mal levantados na

fase de testes, teremos que voltar at a fase de anlise, arquitetura e a construo para novamente
chegarmos aos testes e tudo isso passando pela validao e aprovao de todos os produtos gerados
em cada atividade.
Em contrapartida, o modelo espiral muito ecaz em projetos nos quais temos o escopo e as
necessidades bem denidas e com poucas chances de mudana, como em sistemas de misso crtica,
cujos modelos matemticos so feitos e validados exausto antes que seja desenvolvido qualquer tipo
de modelo ou linha de cdigo.
Observao
Chamamos de retrabalho o processo de realizar novamente uma

atividade que j tenha sido dada como concluda em um momento anterior.
2.2.2 Modelo incremental
O modelo incremental, tambm chamado de iterativo, , em sua essncia, bem parecido com o
modelo cascata.
Observao
No confunda iterativo, com interativo! O termo interao usado no sentido

da ao recproca entre usurio e equipamento. Iterao signica repetio.
No modelo iterativo, as atividades e a sequencia de execuo so exatamente as mesmas do modelo

cascata. Mas ento qual a diferena entre os dois modelos?
A diferena que no modelo incremental no necessrio que todos os requisitos estejam mapeados
para se iniciar o ciclo de desenvolvimento.
19
Unidade I
O ciclo iniciado a partir de blocos de requisitos e no a partir de todos os requisitos, como

pregado no modelo clssico. A partir da, a metodologia a mesma, ou seja, cada atividade somente
iniciada depois que a predecessora nalizada e validada.
Cada bloco de requisitos, quando implantado, corresponde a uma parte do sistema de software,
tambm chamado de incremento. O ciclo repetido tantas vezes quanto necessrio, at que todos os
incrementos do software sejam implantados, da o termo modelo iterativo, ou seja, modelo que se
repete inmeras vezes.
O modelo iterativo no diminui o custo total do projeto, mas reduz o custo de cada atividade. Com
escopo reduzido, o tempo gasto para executar cada tarefa tende a ser menor tambm. Um exemplo disso
pode ser notado na fase de testes. O tempo gasto para validar um nmero menor de funcionalidades
inversamente proporcional ao tempo gasto na validao de um escopo mais amplo.
Interao
N
Total de funcionalidades
Segunda
interao
Primeira
interao
Tempo de projeto
Anlise de
requisitos
Projeto
Codicao
Testes
Implantao e
manuteno
Figura 4 Modelo iterativo
Um dos pontos positivos na adoo do modelo incremental a reduo do retrabalho. O nmero

menor de requisitos reduz a chance de problemas na anlise, projeto e construo.
20
Ademais, com um bom planejamento de execuo, possvel priorizar partes de requisitos crticos
para o negcio, requisitos que gerem valor ao processo, abrindo a possibilidade da vantagem competitiva
para a organizao no mercado.
Nada impede que um ciclo de desenvolvimento seja iniciado antes da implantao de um que j
esteja em andamento. Desde que no haja nenhuma dependncia entre os requisitos ou componentes
de software, essa uma alternativa vivel e atrativa do ponto de vista da produtividade.
A chave para aumentarmos a ecincia na produo de um sistema de software utilizando o modelo

incremental : bom planejamento.
O modelo incremental serviu de base para muitos outros processos largamente utilizados e debatidos
na literatura, como: prototipagem, modelo espiral e processo unicado, que iremos detalhar na sequncia.
Saiba mais
O modelo iterativo tambm serviu como base para o desenvolvimento

dos Mtodos geis, leia o manifesto gil para saber mais sobre o que so eles:
<http://agilemanifesto.org/iso/ptbr/>.
2.2.3 Prototipagem
Segundo o dicionrio, prottipo um primeiro tipo, um primeiro exemplar. Em Engenharia de Software

podemos pensar que o prottipo a primeira verso de um sistema de software (SOMMERVILLE, 2010).
Esse prottipo de software tem como objetivo a prova de conceitos. Vericar e demonstrar se
os requisitos mapeados esto de acordo com a necessidade do usurio ou validar uma soluo de
projeto. fato que a prototipagem utilizada com o objetivo de antecipar mudanas que possam
vir a ser mais custosas no desenvolvimento de um sistema de software. O modelo de prototipagem
possui quatro atividades:
planejamento;
denio das funcionalidades;
construo;
validao.
21
Unidade I
Planejamento
Denio das
Validao funcionalidades
Construo
Figura 5 Ciclo de atividades de prototipao
Como sabemos quando usar a prototipao? Pressman (2006) faz algumas observaes bem
interessantes:
Se nosso usurio tem uma boa noo, mas no tem, no momento, uma viso detalhada do que
precisa ser feito, positivo que usamos a prototipao como um primeiro passo.
O cliente precisa ter a total noo de que o prottipo no o sistema de software. A comunicao
fundamental.
Toda a equipe de desenvolvimento tambm precisa ter a total noo que o prottipo no o
sistema de software. Ele foi desenvolvido descartando muitas das boas prticas de projeto, como
a manutenibilidade.
Rosemberg et al. (2008) utilizaram uma abordagem voltada prototipao e obtiveram bons
resultados em seu projeto. Os autores trabalharam com o que chamamos de prottipo de baixa
delizao, que d nfase na interao com o usurio e na estrutura geral do sistema de software, no
se preocupando em fazer prottipos que produzissem uma imagem real do sistema.
Prottipos de baixa delizao foram ecientes e viveis para demonstrar para os usurios as
funcionalidades a serem implementadas pelo sistema.
Outro fato interessante observado foi a viabilidade econmica do prottipo: barato na construo
e na alterao.
Alguns dos bons resultados obtidos nesse projeto: rapidez no processo de captao dos requisitos e
antecipao dos problemas.
22
Saiba mais
Leia mais sobre os resultados obtidos e a metodologia utilizada pelos

autores:
ROSEMBERG C. et al. Prototipao de software e design participativo: uma

experincia do atlntico. In: SIMPSIO BRASILEIRO DE FATORES HUMANOS
EM SISTEMAS COMPUTACIONAIS, 8.,2008, Porto Alegre. Proceedings of the
VIII Brazilian Symposium on Human Factors in Computing Systems. Porto
Alegre: Sociedade Brasileira de Computao, 2008.
Note tambm como o autor trabalhou o conceito de design participativo.
2.2.4 Modelo espiral
O modelo espiral, ou tambm citado na literatura como modelo de Boehm (1988), tem como raiz o
modelo iterativo incremental e como preocupao central a mitigao de riscos.
A diferena fundamental do modelo espiral para os outros modelos que discutimos at agora
que cada ciclo completo, ou cada iterao, no modelo proposto por Boehm em 1988, no produz ou
implementa um sistema ou uma parte do sistema de software.
Diferentemente do modelo incremental, no qual temos como resultado ao nal da fase de

implementao, que corresponde ao m de um ciclo, um conjunto de requisitos especicados,
documentados, projetados, construdos e validados, ao nal do ciclo de um modelo espiral poderamos
ter como produto apenas a especicao de requisitos.
O modelo espiral composto de quatro fases:
Denio dos objetivos.
Mitigao dos riscos.
Desenvolvimento do produto.
Planejamento da prxima fase.
23
Unidade I
Denio dos Mitigao dos

objetivos riscos
Planejamento da Desenvolvimento
prxima fase do produto
Figura 6 Modelo espiral
A gura anterior representa o modelo espiral proposto por Boehm (1988). Cada linha da espiral, em
cada fase, corresponde a uma sequncia de atividades. Por exemplo: na fase de Desenvolvimento do
Produto podemos ter Elicitao de Requisitos, Documentao e Validao dos Requisitos.
A nfase na diminuio do risco se d pelo fato de que entre a definio do que precisa
ser feito e o efetivo desenvolvimento, existe a fase de mitigao dos riscos. Nela, os riscos so
identificados, mitigados e, a partir disso, so traadas estratgias para minimizar os impactos
para as fases seguintes.
Saiba mais
Existem algumas variantes do modelo espiral adotadas por outros

autores, saiba mais sobre essas variantes e sobre o modelo espiral em:
BOEHM, B.; HANSEN, W. J. Spiral development: experience, principles,

and renements. Pittsburg: CMU/SEI,, 2000. Disponvel em: <http://csse.
usc.edu/csse/TECHRPTS/2000/usccse2000-525/usccse2000-525.pdf>.
Acesso em: 18 dez. 2014.
Observao
Software Engineering Institute (SEI) um centro de pesquisa

e desenvolvimento ligado Universidade Carnegie-Mellow que
tem nfase no estudo da Engenharia de Software. Veja mais em:
<http://www.sei.cmu.edu/>.
24
2.2.5 Processo unicado
Idealizado por Jacobson, Rumbaugh e Booch (1999), o Processo Unicado, tambm conhecido como
UP (Unied Process), tem em seu fundamento a estrutura do modelo iterativo incremental.
Observao
Iar Jacobson, James Rumbaugh e Grady Booch so considerados trs

dos maiores expoentes da Engenharia de Software.
O UP composto por quatro fases:
Iniciao: nesta fase denido algo muito importante para qualquer projeto de software, o
escopo do projeto, que a relao das necessidades que sero atendidas no projeto de software
e aquelas que no sero.
Elaborao: o objetivo desta fase detalhar o escopo, produzindo o modelo de requisitos do

sistema. A partir dos requisitos, so elaboradas solues para atender a essas necessidades, que
podemos chamar de arquitetura do sistema. No decorrer de toda essa fase, so identicados os
riscos do projeto e quais estratgias sero usadas para reduo dos riscos. Nesta fase pode-se
produzir o plano de projeto, ou plano de desenvolvimento, que consiste no mapeamento dos
requisitos, as solues de software desenvolvidas para soluo de cada requisito e o planejamento
dos riscos associados para cada soluo.
Construo: esta fase est associada ao desenvolvimento do projeto, que consiste em projetar,
codicar e testar o sistema de software.
Transio: nesta fase, o sistema de software entregue para o usurio nal, sendo comum que
existam correes e adaptaes a serem feitas, decorrentes das mais diversas naturezas, como
adaptao ao ambiente nal do usurio ou novas demandas.
Segundo os prprios autores, o UP baseado em trs pilares:
Dirigido por casos de uso.
Centrado na arquitetura.
Iterativo e Incremental.
25
Unidade I
Observao
Caso de uso , de forma genrica, a descrio detalhada dos requisitos

de um sistema de software que seguem uma determinada metodologia e
um determinado padro. Iremos detalhar essa abordagem adiante.
Uma variao importante do modelo de processo unicado, que utilizada largamente pelas grandes
organizaes atualmente, o RUP (Rational Unied Process) (KRUCHTEN, 2003).
O RUP um modelo de processos, desenvolvido pela Rational, que associou o Modelo de Processo
Unicado s melhores prticas da Engenharia de Software, que so:
Desenvolva iterativamente.
Gerencie requisitos.
Use arquitetura de componentes.
Modele visualmente.
Verique continuamente a qualidade.
Gerencie mudanas.
O modelo proposto pela Rational especica, de forma sistemtica, a sequncia que as atividades, ou
tambm chamadas de disciplinas, devem ser realizadas dentro de cada fase, quem so os responsveis e
quais produtos so resultantes de cada atividade.
Observao
A Rational Software uma empresa privada, fundada na dcada de

80 com o objetivo de desenvolver ferramentas, tcnicas e prticas para
Engenharia de Software. Em 2003, foi adquirida pela IBM.
As fases do RUP so as mesmas denidas no UP: iniciao, elaborao, construo e transio.
A relevncia do RUP, no contexto desse trabalho, d-se pelo fato de que o modelo incorpora como
ferramenta de apoio, a modelagem visual, particularmente utilizando a Linguagem de Modelagem
Unicada UML (Unied Modeling Language).
Alm do mais, o modelo d nfase utilizao da orientao a objetos como boa prtica de
Engenharia de Software quando incorpora a utilizao da arquitetura de componentes.
26
Abordaremos ambos os assuntos UML e Orientao a objetos detalhadamente adiante.
Saiba mais
O RUP um processo proprietrio da Rational, de tal forma que no

permitido o seu uso sem licena. O OpenUP, a exemplo do RUP, um
modelo de processo unicado e seu uso gratuito. Saiba mais em:
<http://epf.eclipse.org/wikis/openup/>.
2.3 Processo X pessoas
Como abordamos anteriormente, qualquer modelo de processo de Engenharia de Software se

preocupa em denir quem produz o que, como e quando:
O que ser produzido: qual o produto ou o artefato do processo.
Como: atividade, ou sequencia de atividades, a serem realizadas, em uma determinada sequncia

para produo do artefato do processo.
Quando: denio de qual momento o artefato ser produzido, denio das pr-condies e
ps-condies.
Quem: indicao do responsvel pela atividade.
Quais as responsabilidades de uma equipe dentro de um projeto? Qual o papel da pessoa dentro
do processo de desenvolvimento?
O RUP, por exemplo, no tem nfase no indivduo, mas sim no papel. O papel o responsvel pela
execuo de uma determinada tarefa, que responsvel por um determinado artefato (KRUCHTEN,
2003). Segundo a empresa Wthreex (s.d.), o papel dene o comportamento e as responsabilidades de
um indivduo ou de um conjunto de indivduos que trabalham juntos como uma equipe, no contexto de
uma organizao de engenharia de software.
exatamente o que ocorre nas organizaes de desenvolvimento de software. Um indivduo

desempenha um ou mais papis dentro de um projeto de desenvolvimento. Os papis e as
responsabilidades variam de acordo com cada modelo de processo.
No caso do RUP, os papis so sistematicamente denidos, por exemplo: o analista de sistemas

responsvel, entre outras coisas, por desenvolver o plano de gerenciamento de requisitos e o arquiteto
de software executa, entre outras atividades, a estruturao do modelo de implantao.
27
Unidade I
Bezerra (2006) tem ideia semelhante e destaca que o componente humano fator importante
no desenvolvimento de um sistema de software, uma vez que ele composto de tarefas altamente
cooperativas. Ele ainda destaca, de forma semelhante ao RUP, que uma pessoa pode desempenhar
diversas funes que tipicamente um projeto de desenvolvimento de software possui, na grande maioria
dos casos, independentemente do modelo de processo adotado, que so os seguintes papis:
Gerente de projetos
Prossional responsvel por gerir o projeto, que compreende, entre muitas coisas, coordenar e
acompanhar as atividades do projeto e alocar as pessoas para as funes determinadas.
Saiba mais
Saiba mais sobre as atribuies e responsabilidades do Gerente de

Projetos no site do PMI (Project Management Institute) em: <http://www.
pmi.org/>.
L voc poder ter os primeiros contatos com o PMBOK, que contm as

melhores prticas para a prosso.
Analista
Analista de sistemas, muitas vezes chamado de analista de negcios, responsvel por captar as
necessidades do negcio e transform-las em requisitos do sistema de software.
Alguns conhecimentos e habilidades so necessrios, como: conhecimento ou familiaridade com o

negcio, boa capacidade de comunicao oral e escrita, conhecimento de computao, entre outros.
Bezerra (2006) cita algo de importante destaque: o analista de sistemas deve ser tico, uma vez que,
em muitas situaes, se depara com informaes e contratos que envolvem condencialidade.
Projetista
Responsvel por produzir uma soluo computacional para os problemas identicados. Por exemplo:
um projetista de interface grca do usurio, que especialista em fornecer solues para interfaces
padro para sistemas operacionais da Apple ou da Microsoft.
Arquiteto de software
Responsvel pela elaborao da arquitetura do sistema. Como e quais sero os componentes internos
do sistema de software e como esses componentes iro se comunicar para atender a uma determinada
necessidade.
28
Geralmente, o arquiteto trabalha em contato com o gerente de projetos, ajudando a organizar o

desenvolvimento e estimando tamanho e tempo de desenvolvimento, e com o corpo tcnico, orientando
decises tcnicas de desenvolvimento.
Desenvolvedores
Tambm chamados de programadores, os desenvolvedores tm a responsabilidade de implementar o

projeto. Transformar a arquitetura e a soluo do projeto em soluo computacional.
Clientes
O usurio parte fundamental do processo de desenvolvimento, ele precisa estar envolvido e com
foco desde o momento do levantamento de requisitos at a validao.
Avaliadores de qualidade
So responsveis por garantir que o sistema de software atenda a todas as necessidades do negcio.
Saiba mais
A discusso sobre o processo de qualidade ampla. Leia:
COSTA, I. et al. Qualidade em tecnologia da informao. So Paulo.

Atlas, 2013.
A participao do prossional no processo de desenvolvimento de um sistema de software

fundamental, independentemente do modelo a ser seguido. Ela fundamental, inclusive, na escolha de
um modelo de processo a ser adotado.
Entre os vrios processos aqui discutidos, e entre os outros tantos que existem, cabe ao prossional
levar em considerao as caractersticas do projeto e as caractersticas do modelo de processo para
saber qual a melhor deciso.
Na Engenharia de Software, o indivduo tem papel fundamental.
2.4 O paradigma da orientao a objetos
Antes de entendermos o que o paradigma da orientao a objetos, vamos entender o que um

paradigma: Um paradigma um conjunto de regras que estabelecem fronteiras entre o que certo e
errado, entre o que verdadeiro e o que falso, entre o que se deve fazer e o que no se deve fazer[...]
Ele funciona como um conjunto de categorias que dene e orienta o comportamento das pessoas
(CHIAVENATO, 2008, p. 8).
29
Unidade I
O paradigma da orientao a objetos uma forma de se desenvolver um sistema de software que

o enxerga como um conjunto de componentes que interagem entre si para resolver um determinado
problema. A cada componente, d-se o nome de objeto.
A motivao da abordagem orientada a objetos se d pela tentativa de aproximar o desenvolvimento

de software quilo que acontece no mundo real.
Imagine a seguinte situao do nosso cotidiano: um cliente de uma agncia bancria vai at um
terminal de autoatendimento para sacar uma determinada quantia em dinheiro. O cliente possui algumas
caractersticas importantes nesse processo, como nmero de agncia, nmero de conta e senha. Alm disso,
ele executa algumas aes para efetuar o saque, como inserir carto, informar senha e retirar dinheiro.
Outro componente importante dessa cena o prprio terminal de autoatendimento, que, por sua
vez, tambm possui caractersticas e comportamentos importantes, como dispensar dinheiro.
Se pensarmos no paradigma da orientao a objetos, podemos interpretar que temos dois objetos
no processo: cliente e terminal. Tanto um quanto o outro possuem caractersticas, comportamentos, e
executam determinadas aes.
Em orientao a objetos, cada objeto tambm possui caractersticas, denominadas atributos, e a

ao a ser executada por esse objeto, que tem o nome de mtodo.
Dentro desse cenrio, os dois, cliente e terminal, devem interagir para que o processo seja efetuado
com sucesso. De maneira anloga, na orientao a objetos, dois objetos interagem entre si para executar
uma determinada tarefa computacional por meio da troca de mensagens.
Uma mensagem pode ser interpretada como a requisio que um objeto faz a outro objeto para que
ele execute um determinado servio.
Bezerra (2006) interpreta a orientao a objetos como uma tcnica para modelar sistemas que
diminui a diferena semntica entre a realidade sendo modelada e os modelos construdos.
Antes do paradigma da orientao a objetos atingir sua plenitude, no incio da dcada de 1990, o
paradigma estruturado era amplamente utilizado para modelagem de sistemas.
O paradigma estruturado baseado em dois elementos: informaes (dados) e processos. Nesse

pensamento, os processos agem diretamente sobre os dados para a execuo de uma determinada tarefa.
Observao
Na dcada de 1990, o termo processamento de dados era utilizado para

descrever a rea de desenvolvimento de sistemas, muito em funo do
paradigma estruturado.
30
O grande problema enfrentado pelo paradigma estruturado foi a atomicidade dos processos. As
unidades de processamento eram organizadas em poucos e grandes blocos ou muitas vezes em um
nico bloco responsveis pela realizao de toda a tarefa.
Essa organizao levou a sistemas muito complexos e de difcil manuteno, o que no combinou
com a crescente necessidade do mercado, que j debatemos anteriormente.
Em contrapartida, o paradigma orientado a objetos produz modelos com componentes autnomos,

chamados objetos, que possuem suas prprias caractersticas e informaes e seus prprios
comportamentos responsveis pela manuteno dessa informao.
A diviso de responsabilidades proposta pela orientao a objetos proporciona algumas vantagens:
A modelagem prxima ao mundo real gera modelos mais fceis de entender e manter.
Aumento do reso de cdigos.
Aumento da manutenibilidade: sistemas mais manutenveis, mudanas nos requisitos no

implicam necessariamente na alterao do sistema todo.
O paradigma da orientao a objetos baseado nos seguintes pilares:
classes;
objeto;
abstrao;
encapsulamento;
herana;
polimorsmo;
ligao, mensagem.
2.4.1 Classe
Classe de objetos pode ser denida como um grupo de objetos com as mesmas propriedades
(atributos), comportamentos (operaes), relacionamentos e semntica. A classe dos prossionais de
engenharia qumica, por exemplo. Todos devem possuir curso superior em engenharia qumica, registro
no CREA e podem executar apenas determinadas tarefas, como desenvolver laudos.
31
Unidade I
Ou ainda, voltando ao nosso exemplo do terminal de autoatendimento, podemos entender que o

nosso cliente faz parte da classe Cliente do banco, pois todos os clientes do banco possuem agncia,
nmero de conta, senha. Alm disso, todos eles podem efetuar saques.
As classes representam o bloco de construo mais importante de qualquer sistema orientado a objetos,
pois so utilizadas para capturar o domnio do problema no qual o sistema est sendo desenvolvido.
Classes devem possuir responsabilidades bem denidas, cada responsabilidade representa um

contrato ou obrigaes dela, sendo assim, podemos entender que uma classe uma especicao
de um objeto.
2.4.2 Objeto
J vimos que um objeto um elemento do mundo real, que possui relevncia para soluo de um
determinado problema e que esse objeto possui caractersticas e executa determinadas aes (mtodos).
Esse conjunto de informaes, tambm chamado de atributos, identica um objeto em uma

determinada classe de objetos.
Voltando novamente ao nosso exemplo do terminal de autoatendimento, os clientes que fazem parte
da classe Cliente do banco possuem agncia, nmero de conta, senha. Podemos entender, portanto,
que um objeto do tipo Cliente identicado pelo conjunto dessas informaes.
Por exemplo: Joo um cliente do banco XYZ, nmero de agncia 1234 e nmero de conta corrente
12345-0. No existe, no banco XYZ, nenhum outro cliente com essas informaes. Sendo assim, podemos
armar que todo objeto possui uma identidade, representada por um conjunto de informaes atribudas
s suas caractersticas. Podemos armar tambm que todo objeto possui um estado, denido tambm
pelo conjunto dessas informaes.
Suponhamos que o cliente possua tambm o atributo Saldo de conta-corrente. A informao desse
atributo dene seu estado em funo do tempo de vida desse objeto. Por exemplo: Joo tem um saldo
de R$ 900,00 na conta-corrente em um determinado dia. No dia seguinte, Joo efetua um saque de R$
100,00, passando a ter um saldo de R$ 800,00.
Diante dessa situao, podemos armar tambm que o estado de um objeto pode ser alterado pelos
seus mtodos.
2.4.3 Abstrao
No tratamento de problemas mais complexos, onde seja exigido um

mtodo de resoluo mais longo, torna-se interessante estabelecer
etapas menores e mais simples no mtodo de resoluo para depois,
compondo essas etapas menores, alcanar a resoluo do problema
(MARTINS; RODRIGUES, 2006, p. 85).
32
O conceito de abstrao est ligado nossa capacidade, enquanto analistas, de resolver problemas,
de selecionar determinados aspectos do problema e isolar o que importante do que no para um
determinado propsito. Abstrao dar nfase quilo que essencial.
Se zermos uma analogia com as fases de um projeto de construo de uma casa, seria algo como
pensarmos na planta em vez dos tijolos. Pensar em como organizar o sistema eltrico e hidrulico em
vez de pensar em luminrias, lmpadas e torneiras.
Alm disso, abstrao est ligada nossa capacidade de estabelecer um modelo de objetos bem
decomposto, de tal forma que cada objeto seja uma unidade autnoma, estabelecer a dependncia
apenas entre objetos que tenham alguma colaborao em um determinado momento do processo.
2.4.4 Encapsulamento
Encapsulamento signica deixar visvel apenas o que necessrio para a comunicao entre dois
objetos, como detalhes da implementao ou a lgica algortmica de um mtodo.
Voltando ao nosso exemplo do terminal de autoatendimento, o objeto do tipo Cliente precisa saber
o que o terminal faz para dispensar o dinheiro? Se ele efetua contagem das notas, se existem outros
objetos que fazem parte do processo? A resposta no. Contanto que a comunicao entre eles, cliente
e terminal, esteja funcionando corretamente, no existem problemas pelo fato do cliente no conhecer
detalhes da implementao do mtodo de dispensar dinheiro.
2.4.5 Herana
No mundo real existem objetos que possuem caractersticas semelhantes, mas que esto em classes
diferentes? Clientes Pessoa Fsica (PF) e Clientes Pessoa Jurdica (PJ) de um banco, por exemplo, possuem
caractersticas e operaes semelhantes?
Sim, no mundo real existem objetos que possuem caractersticas semelhantes, mas que esto em
classes diferentes. Temos, nesses casos, o conceito de superclasse e subclasse.
Por exemplo, ces, gatos e roedores so exemplos de mamferos, possuem caractersticas e

comportamentos semelhantes aos de todos os mamferos, mas possuem tambm suas diferenas. Nessa
situao podemos dizer que ces, gatos e roedores so subclasses de mamfero, que uma superclasse.
Se pensarmos em uma estrutura hierrquica, podemos dizer que ces, gatos e roedores so
especializaes de mamferos, ou seja, possuem tudo o que os mamferos possuem e algo a mais que
os diferenciam, enquanto isso, mamfero uma generalizao de ces, gatos e roedores, seguindo
exatamente a mesma lgica.
Em orientao a objetos, temos exatamente o mesmo conceito. Todos os mtodos e atributos da

classe me, ou superclasse, estaro presentes nas classes lhas, ou subclasses, sem que haja a necessidade
de reescrev-los.
33
Unidade I
A gura a seguir mostra um exemplo de herana de objetos. A classe Cliente possui os seguintes
atributos: ContaCorrente, NumeroAgencia e NumeroBanco alm de possuir o mtodo EfetuarSaque.
As subclasses ClientePF e ClientePJ possuem os mesmos atributos e mtodos da classe Cliente e

outros que os diferenciam.
Cliente
ContaCorrente
NumeroAgencia
NumeroBanco
efetuarSaque()
ClienteCPF ClientePJ
Nome CNPF
CPF RazaoSocial
efetuarEmprestimoPF() efetuarEmprestimoPJ()
Figura 7 Exemplo de herana
Alm de possuir os atributos da classe me, ClientePF e ClientePJ possuem suas prprias caractersticas:
CPF e Nome; CNPJ e RazaoSocial, respectivamente. E seus prprios mtodos: efetuarEmprestimoPF e
efetuarEmprestimoPJ, respectivamente.
Existem dois tipos de herana:
Simples: quando uma classe lha herda caractersticas de apenas uma classe me.
Composta: quando uma classe lha herda caractersticas de mais de uma classe me.
O mecanismo de herana, tambm chamado de generalizao-especializao, um dos fundamentos

da orientao a objetos mais importantes, principalmente por proporcionar reso.
2.4.6 Polimorsmo
Polimorsmo quando um objeto tem um comportamento diferente para a mesma ao.
Fazendo novamente uma analogia aos animais, podemos ter a classe caranguejo e a classe co.
Ambas so subclasses de animais, que realizam a ao andar. Se zermos com que um caranguejo ande
cinco metros, certamente o comportamento ser diferente se enviarmos a mesma mensagem para o
co, muito embora eles respondam mesma mensagem e o resultado seja exatamente o mesmo: ambos
andaro cinco metros.
Em orientao a objetos, polimorsmo signica que um mtodo denido na classe me redenido,

tem uma nova implementao, na classe lha, sendo obrigatria a mesma assinatura para o mtodo.
34
Observao
A assinatura de um mtodo, assim como a assinatura de uma funo

em algoritmos, composta de: tipo de retorno + nome do mtodo +
parmetros de entrada (tipo de dado, nome do parmetro).
2.4.7 Ligao e mensagem
Mensagem um meio de comunicao entre objetos com o objetivo de ativar um processamento.

Para que um objeto execute um mtodo, ou seja, tenha um determinado comportamento, necessrio
enviar a este objeto uma mensagem solicitando a execuo deste mtodo.
Se um objeto envia uma mensagem para outro, eles possuem uma ligao, chamada de associao
simples, ou seja, uma ligao que acontece apenas em um determinado momento.
Pode acontecer que um objeto tenha em sua composio outro objeto. Neste caso existe uma relao
todo-parte. Por exemplo: o objeto terminal de autoatendimento composto dos objetos monitor, leitora
de carto e dispensador de dinheiro. Assim, seguindo na mesma nomenclatura, a leitora de carto
parte do objeto terminal de autoatendimento.
A composio todo-parte entre dois objetos determina o ciclo de vida de um objeto. Quando o
objeto que compe outro no existe fora desse contexto, dizemos que existe uma associao do tipo
composio. Por exemplo: o objeto item de nota scal faz parte do objeto nota scal, todavia, ele, por
si s, no existe sem a existncia de uma nota scal.
Quando o objeto que compe o outro existe fora do contexto, dizemos que h uma associao do tipo
agregao. Podemos citar o objeto livro, que faz parte do objeto biblioteca, todavia, ele existe mesmo se no
existir o objeto biblioteca para um determinado contexto, por exemplo, a automao de uma universidade,
onde o livro existe mesmo que no esteja na biblioteca, mas ela composta por uma coleo de livros.
2.5 A linguagem de modelagem unicada
O que uma linguagem? O dicionrio Michaelis (1998) dene linguagem como um conjunto de sinais falados
(gltica), escritos (grca) ou gesticulados (mmica), de que se serve o homem para exprimir suas ideias e sentimentos.
Vamos nos atentar linguagem escrita. Eu, por exemplo, escolhi um conjunto de caracteres para
escrever este material. Em uma sequncia lgica, esses caracteres expressam uma linguagem escrita.
Voc, que est lendo este material, olha esses caracteres e entende a linguagem utilizada, ou seja, o que
eu estou querendo dizer, porque sabe interpretar a sequncia deles.
Quando estamos desenvolvendo um sistema de software, escolhemos uma linguagem de

programao. Essa linguagem tambm uma sequncia lgica de smbolos. Algumas composies de
smbolos constituem uma palavra reservada, que, via de regra, cada linguagem possui a sua.
35
Unidade I
O compilador interpreta essa linguagem, esse conjunto de caracteres, inclusive as palavras reservadas,
e produz o resultado que voc, desenvolvedor, esperava.
Caso voc no tenha escrito algo que faa coerncia, seu cdigo no compilado. Isso acontece
porque o modelo de cdigo produzido no interpretado pelo compilador.
A Linguagem de Modelagem Unicada, ou Unied Modeling Language, conhecida como UML,

uma linguagem para modelar sistemas orientados a objetos.
Por se tratar de uma linguagem, ainda que visual, tambm composta por elementos (grcos) que
tambm seguem algumas regras.
Regra de sintaxe: cada elemento deve ser desenhado, representado, seguindo um padro.
Regra semntica: dene o signicado de cada elemento dentro de um contexto.
Por exemplo: se combinarmos que a gura a seguir representa uma impressora, todas as vezes que
voc, leitor, ver o smbolo, vai entender que estou querendo representar uma impressora e que qualquer
smbolo diferente dele no a representao de uma impressora.
Figura 8 Representao grca de uma impressora
Seguindo a mesma lgica, se combinarmos que um retngulo a representao de uma folha

de papel e que uma linha tracejada representa uma agregao, voc ir olhar a gura a seguir e ir
interpretar que esse modelo representa algo como uma impressora possui folhas de papel.
Figura 9 Representao grca de um modelo impressora/papel
Concorda que esse um modelo que vale apenas para mim e para voc, leitor, nos comunicarmos?
Isso porque ns combinamos o jogo. Em contrapartida, qualquer outro que olhar esse modelo vai
enxergar apenas um tipo de mquina ligada a um retngulo por uma linha tracejada. Portanto, a
minha linguagem de representao no eciente para que eu me comunique em larga escala.
36
A UML surgiu da necessidade de se desenvolver uma linguagem que fosse padro para modelagem
de sistemas orientada a objetos e que fosse interpretvel por qualquer um: usurios, desenvolvedores,
arquitetos e gerentes.
Os elementos grcos so utilizados para representar uma determinada viso do sistema, que vai
desde a representao dos requisitos at a viso de implementao. O que nos permite armar que, se
pensarmos no modelo de processo da Engenharia de Software, enquanto o paradigma da orientao a
objetos tem sua rea de contribuio restrita fase de projeto, a UML uma ferramenta que d suporte
a todo o processo, desde a anlise de requisitos, passando pelo projeto, construo e at a validao.
Segundo os criadores da UML, Booch, Jacobson e Rumbaugh (2006), um sistema de software

pode ser dividido em cinco vises, sendo que, dependendo da complexidade, nem todas precisam ser
desenvolvidas:
Caso de Uso: representa o sistema de um ponto de vista externo, como ele interage com agentes
externos, como usurios ou outros sistemas.
Projeto: representa a arquitetura do sistema de software.
Implementao: representa os componentes e subsistemas.
Implantao: representa a distribuio fsica do sistema e seus componentes e como estes iro se
comunicar.
Processo: d nfase na representao do paralelismo e sincronizao dos componentes do sistema.
Cada viso composta por um ou mais diagramas UML. Um diagrama UML uma composio de
elementos grcos com o objetivo de representar alguma perspectiva do sistema.
Nas pginas seguintes, detalharemos cada uma das vises e diagramas, sempre traando um paralelo
com as atividades do processo de desenvolvimento da Engenharia de Software.
Lembrete
Com a evoluo da tecnologia e dos computadores, a forma como

a informao era trabalhada, trafegada, levada ao usurio e gerenciada
passou a ter papel de fundamental importncia.
Saiba mais
A especicao e a denio completas da UML esto disponveis no

site da OMG. Saiba mais em: <http://www.uml.org/>.
37
Unidade I
Resumo
Esta unidade apresentou os conceitos introdutrios e fundamentais

sobre anlise e desenvolvimento de sistemas.
O aumento no uso dos computadores pessoais, ou PCs, associados

notria evoluo das estruturas de hardware, mudou as estruturas de
como os sistemas de software eram construdos. Um dos motivadores do
aumento do uso de computadores pode ser atribudo teoria de Moore,
tambm conhecida como Lei de Moore, que resultou em computadores de
maior capacidade, menores e mais baratos.
A informao passou a ter papel fundamental nas grandes organizaes. Passa

ao papel principal a maneira como essa informao chega at o usurio, como ela
trabalhada, trafegada e gerenciada at que chegue ao seu destino nal.
Surgiu ento o conceito de sistemas de informao, um conceito formado

por alguns pilares: informaes (ou dados), pessoas, processos e tecnologias
com o objetivo apoiar ou melhorar o processo de negcio de uma empresa.
Sistemas de informao do nfase na informao gerada em um

processo de uma organizao, com o objetivo de que o tratamento dessa
informao gere valor ao processo e a organizao (BEZERRA, 2006).
Ao tratarmos de tecnologia de sistemas de informao, abordamos

irrestritamente toda plataforma tecnolgica que apoia o processo de
negcio: infraestrutura de rede, servidores, computadores, sistemas
operacionais e sistemas de software.
O desenvolvimento de sistemas de software tambm passou, ento,

por uma fase de desaos. Como desenvolver sistemas de software que
atendessem s crescentes necessidades?
O objetivo da Engenharia de Software apoiar o desenvolvimento de

software a partir de tcnicas para especicar, projetar, manter e gerir um
sistema de software (SOMMERVILLE, 2010). Ela baseada em trs pilares:
mtodos, ferramentas e processos.
O processo de desenvolvimento de software se resume a um conjunto

de atividades executadas em uma determinada sequncia e que tem por
objetivo garantir a qualidade do produto que ser entregue no nal do
processo: o sistema de software.
38
Existem muitos modelos de processo que podemos aplicar a um projeto

de desenvolvimento, como o modelo cascata e o modelo iterativo, cada um
com as suas caractersticas.
A escolha de um processo de desenvolvimento passa principalmente

pela natureza do problema a ser resolvido. Todavia, todos possuem as
seguintes atividades fundamentais: especicao de software, projeto e
implementao de software, validao de software e evoluo de software.
Qualquer que seja o modelo adotado, o indivduo tem papel fundamental.

Os prossionais que fazem parte de uma equipe de projeto desempenham
determinados papis.
Papis esses que so responsveis pela execuo de determinadas

atividades e produo de determinados resultados. Alguns dos papis comuns
em um projeto so: gerente de projetos, analista de sistemas, projetista,
arquiteto, desenvolvedor, analista de qualidade e, principalmente, cliente.
Mudando nossa nfase para mtodos na Engenharia de Software, vimos

que o paradigma da orientao a objetos surgiu como uma alternativa
para uma modelagem prxima ao mundo real, para gerarmos modelos
mais fceis de entender e manter. Alm de proporcionar ganhos que
outros paradigmas no proporcionam, como aumento do reso de cdigo
e da manutenibilidade, que a capacidade de um sistema de software ser
facilmente manutenvel.
O paradigma da orientao a objetos apoiado nos seguintes pilares: classes,

objeto, abstrao, encapsulamento, herana, polimorsmo, ligao e mensagem.
Com enfoque em ferramentas, vimos a necessidade de termos uma

ferramenta que desse suporte a todo o processo de desenvolvimento de
um software orientado a objetos. Uma linguagem que pudesse ser padro
para a comunicao entre todos os envolvidos em um projeto.
Surgiu a UML, uma linguagem de modelagem visual de sistemas orientada

a objetos, que possuem elementos grcos de modelagem que representam
vises de um sistema de software e que possuem regras de sintaxe e semntica.
Por tudo isso, notamos uma evoluo e uma maturidade no

desenvolvimento de software.
39

Idioma

Análise de Sistemas Orientada A Objetos

Enviado por

Dados do documento

Descrição:

Título original

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Descrição:

Direitos autorais:

Análise de Sistemas Orientada A Objetos

Título original:

Enviado por

Descrição:

Direitos autorais:

Anlise de Sistemas

Dados Internacionais de Catalogao na Publicao (CIP)

V564a Versolatto, Fbio Rossi.

Anlise de Sistemas Orientada a Objetos. / Fbio Rossi Versolatto.

Nota: este volume est publicado nos Cadernos de Estudos e

1. Anlise de sistemas. 2. Projeto de desenvolvimento. 3.

Prof. Fbio Romeu de Carvalho

Profa. Melnia Dalla Torre

Prof. Dr. Yugo Okida

Profa. Dra. Marlia Ancona-Lopez

Unip Interativa EaD

Profa. Elisabete Brihy

Material Didtico EaD

Com o aluno contextualizado na temtica, a disciplina apresenta e discute a importncia das

As necessidades do negcio devem ser mapeadas de forma eciente. Automatizar o processo de

Parece razovel, em um mundo onde a tecnologia de hardware evoluiu e segue em constante

Alm do aumento na velocidade do processamento, a diminuio dos componentes gerou um

Segundo a Lei de Moore, se ns construssemos um processador hoje

Figura 1 Crescimento do Nmero de Transistores x Lei de Moore

A figura anterior mostra o crescimento do nmero de transistores dos processadores Intel no

Diminuio do consumo de energia: os computadores passaram a consumir menos energia,

Computadores menores: com componentes menores, os computadores tambm reduziram de

Surgiu ento o conceito de sistemas de informao.

Para mais informaes sobre dispositivos de entrada/sada, processadores,

STALLINGS, W. Arquitetura de computadores. So Paulo: Prentice

1.2 Sistemas de informao x software

Algumas clulas tm a funo de identicar possveis ameaas e outras, de tomar determinadas

De forma anloga, um sistema de informao a composio de informaes (ou dados),

Sistemas de informao tem foco na informao gerada em um processo organizacional, de tal

Quando falamos em tecnologia de sistemas de informao, estamos falando de toda plataforma

Rezende (2005) observa que todo sistema que gera e armazena

No exemplo do processo de um call center, importante o mapeamento do processo a ser executado,

Gerar Gerar sugesto

Figura 2 Mapeamento simplicado de um processo de atendimento

Projetar um sistema de software compreende termos a noo de que ele um componente de

Quadro 1 Evoluo da modelagem de sistemas de software

Perodo Cenrio Abordagem de modelagem

Adaptado de: Bezerra (2006, p. 12).

Esses componentes podem ser chamados de componentes de software, que so desenvolvidos

A Engenharia de Software tem por objetivo apoiar o desenvolvimento de software fornecendo

Ferramentas: mecanismos que do suporte execuo das atividades descritas no mtodo. Um

Saiba mais sobre a seleo e utilizao de ferramentas CASE na

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/

Roger Pressman (PRESSMAN, 2006) e Iam Sommerville (SOMMERVILLE,

Em resumo, a Engenharia de Software compreende um conjunto de atividades a serem executadas em

2.1 Processo de desenvolvimento de software

O processo de desenvolvimento de software, conforme dito anteriormente, resume-se a um

A escolha de um processo de desenvolvimento passa principalmente pela natureza do problema

Quadro 2 Atividades fundamentais para a Engenharia de Software

Adaptado de: Sommerville (2010, p. 28).

Na implementao ou construo, a casa comea a se concretizar sicamente. Os requisitos do

Pr e ps-condies: qual o cenrio pr e ps-execuo de uma atividade. Por exemplo: para

A norma IEE 12207 (2006), na seo processo de desenvolvimento,

INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS. 12207:

2.2 Modelos de processo de software

2.2.1 Modelo cascata

Nesta fase so elicitados e documentados os requisitos do sistema. Existem tcnicas e processos de

tambm nesta fase que so definidas as necessidades e as restries de software e hardware,

Nesta fase os componentes do software so desenvolvidos em linguagem de mquina.

Existem inmeros processos que tm como objetivo a garantia da

CORTS, M. L.; CHIOSSI, T. C. dos S. Modelos de qualidade de software.