Você está na página 1de 182

ENGENHARIA DE

SOFTWARE

Professora Me. Mrcia Cristina Dadalto Pascutti


Professora Esp. Janana Aparecida de Freitas
Professora Esp. Talita Tonsic Gasparotti

GRADUAO

Unicesumar
Reitor
Wilson de Matos Silva
Vice-Reitor
Wilson de Matos Silva Filho
Pr-Reitor de Administrao
Wilson de Matos Silva Filho
Pr-Reitor de EAD
Willian Victor Kendrick de Matos Silva
Presidente da Mantenedora
Cludio Ferdinandi

NEAD - Ncleo de Educao a Distncia


Direo Operacional de Ensino
Ktia Coelho
Direo de Planejamento de Ensino
Fabrcio Lazilha
Direo de Operaes
Chrystiano Mincoff
Direo de Mercado
Hilton Pereira
Direo de Polos Prprios
James Prestes
Direo de Desenvolvimento
Dayane Almeida
Direo de Relacionamento
Alessandra Baron
Head de Produo de Contedos
Rodolfo Encinas de Encarnao Pinelli
Gerncia de Produo de Contedos
Gabriel Arajo
Superviso do Ncleo de Produo de
Materiais
Ndila de Almeida Toledo
Superviso de Projetos Especiais
Daniel F. Hey
Coordenador de Contedo
Fabiana de Lima
Design Educacional
C397 CENTRO UNIVERSITRIO DE MARING. Ncleo de Educao a Yasminn Zagonel
Distncia; PASCUTTI, Mrcia Cristina Dadalto; FREITAS, Janana
Aparecida de; GASPAROTTI,Talita Tonsic. Iconografia
Isabela Soares Silva
Engenharia de Software. Mrcia Cristina Dadalto Pascutti;
Janana Aparecida de Freitas; Talita Tonsic Gasparotti.
Projeto Grfico
(Reimpresso revista e atualizada) Jaime de Marchi Junior
Maring-Pr.: UniCesumar, 2016. Jos Jhonny Coelho
2 edio revista e atualizada
Arte Capa
184 p.
Graduao - EaD. Andr Morais de Freitas
Editorao
1. Engenharia. 2. Software . 3. EaD. I. Ttulo. Matheus Felipe Davi
CDD - 22 ed. 005.1 Qualidade Textual
CIP - NBR 12899 - AACR/2 Hellyery Agda
Pedro Barth
Ficha catalogrfica elaborada pelo bibliotecrio Nayara Valenciano
Joo Vivaldo de Souza - CRB-8 - 6828
Ilustrao
Marta Sayuri Kakitani
Viver e trabalhar em uma sociedade global um
grande desafio para todos os cidados. A busca
por tecnologia, informao, conhecimento de
qualidade, novas habilidades para liderana e so-
luo de problemas com eficincia tornou-se uma
questo de sobrevivncia no mundo do trabalho.
Cada um de ns tem uma grande responsabilida-
de: as escolhas que fizermos por ns e pelos nos-
sos faro grande diferena no futuro.
Com essa viso, o Centro Universitrio Cesumar
assume o compromisso de democratizar o conhe-
cimento por meio de alta tecnologia e contribuir
para o futuro dos brasileiros.
No cumprimento de sua misso promover a
educao de qualidade nas diferentes reas do
conhecimento, formando profissionais cidados
que contribuam para o desenvolvimento de uma
sociedade justa e solidria , o Centro Universi-
trio Cesumar busca a integrao do ensino-pes-
quisa-extenso com as demandas institucionais
e sociais; a realizao de uma prtica acadmica
que contribua para o desenvolvimento da consci-
ncia social e poltica e, por fim, a democratizao
do conhecimento acadmico com a articulao e
a integrao com a sociedade.
Diante disso, o Centro Universitrio Cesumar al-
meja ser reconhecido como uma instituio uni-
versitria de referncia regional e nacional pela
qualidade e compromisso do corpo docente;
aquisio de competncias institucionais para
o desenvolvimento de linhas de pesquisa; con-
solidao da extenso universitria; qualidade
da oferta dos ensinos presencial e a distncia;
bem-estar e satisfao da comunidade interna;
qualidade da gesto acadmica e administrati-
va; compromisso social de incluso; processos de
cooperao e parceria com o mundo do trabalho,
como tambm pelo compromisso e relaciona-
mento permanente com os egressos, incentivan-
do a educao continuada.
Seja bem-vindo(a), caro(a) acadmico(a)! Voc est
iniciando um processo de transformao, pois quando
investimos em nossa formao, seja ela pessoal ou
profissional, nos transformamos e, consequentemente,
Diretoria de
transformamos tambm a sociedade na qual estamos
Planejamento de Ensino
inseridos. De que forma o fazemos? Criando oportu-
nidades e/ou estabelecendo mudanas capazes de
alcanar um nvel de desenvolvimento compatvel com
os desafios que surgem no mundo contemporneo.
O Centro Universitrio Cesumar mediante o Ncleo de
Educao a Distncia, o(a) acompanhar durante todo
Diretoria Operacional
este processo, pois conforme Freire (1996): Os homens
de Ensino
se educam juntos, na transformao do mundo.
Os materiais produzidos oferecem linguagem dialgica
e encontram-se integrados proposta pedaggica, con-
tribuindo no processo educacional, complementando
sua formao profissional, desenvolvendo competn-
cias e habilidades, e aplicando conceitos tericos em
situao de realidade, de maneira a inseri-lo no mercado
de trabalho. Ou seja, estes materiais tm como principal
objetivo provocar uma aproximao entre voc e o
contedo, desta forma possibilita o desenvolvimento
da autonomia em busca dos conhecimentos necess-
rios para a sua formao pessoal e profissional.
Portanto, nossa distncia nesse processo de cresci-
mento e construo do conhecimento deve ser apenas
geogrfica. Utilize os diversos recursos pedaggicos
que o Centro Universitrio Cesumar lhe possibilita. Ou
seja, acesse regularmente o AVA Ambiente Virtual de
Aprendizagem, interaja nos fruns e enquetes, assista
s aulas ao vivo e participe das discusses. Alm dis-
so, lembre-se que existe uma equipe de professores
e tutores que se encontra disponvel para sanar suas
dvidas e auxili-lo(a) em seu processo de aprendiza-
gem, possibilitando-lhe trilhar com tranquilidade e
segurana sua trajetria acadmica.
AUTORES

Professora Me. Mrcia Cristina Dadalto Pascutti


Possui graduao em Processamento de Dados pela Universidade Estadual
de Maring (1989) e mestrado em Cincia da Computao pela Universidade
Federal do Rio Grande do Sul (2002). Atualmente, professora no Instituto
Federal do Paran - Campus Umuarama e est cursando o doutorado na PUC-
PR. Atua, principalmente, nos seguintes temas: arquitetura de computadores,
engenharia de software, processamento de imagens, reconhecimento de
padres, viso computacional.

Professora Esp. Janana Aparecida de Freitas


Possui graduao em Informtica pela Universidade Estadual de Maring
(2010). Especializao em MBA em Teste de Software pela Universidade
UNICEUMAR, Brasil. (2012). Trabalhou na iniciativa privada, na rea de Analise
de Sistemas e Testes de Software. Tem experincia na rea de Engenharia
de Software com nfase em Anlise de Requisitos, Gesto de Projetos de
Software, Mtricas e Estimativas, Qualidade e Teste de Software. Atualmente
cursando o curso Tcnico em Qualidade no Senac-PR e Licenciatura em Letras
- Portugus/Ingls na UniCesumar.

Professora Esp. Talita Tonsic Gasparotti


Possui formao em Anlise e Desenvolvimento de Sistemas - PD,
especializao em Gesto e Coordenao Escolar e especialista em Educao
a Distncia e as Tecnologias Educacionais
APRESENTAO

ENGENHARIA DE SOFTWARE

SEJA BEM-VINDO(A)!
Prezado(a) acadmico(a), com muito prazer que apresento a voc o livro de engenha-
ria de software. A engenharia de software possui uma gama imensa de tpicos, que
no seria possvel abarcar em cinco unidades (como este livro est organizado), ento
abordei os assuntos iniciais, sem os quais no seria possvel entender todo o contexto da
disciplina. Se voc gostar da disciplina e quiser se aprofundar, pode consultar os livros
citados durante as unidades. Neles, com certeza, voc aprender muitos outros assun-
tos e poder ter certeza de que a engenharia de software realmente muito importante
quando tratamos de software, como um todo.
Este livro est organizado em cinco unidades, sendo que todas esto estreitamente re-
lacionadas.
Na unidade I, apresentarei alguns conceitos referentes disciplina. Voc notar, durante
a leitura das outras unidades, que esses conceitos so utilizados com frequncia.
A engenharia de software surgiu da necessidade de tornar o desenvolvimento de sof-
tware confivel, com etapas bem definidas, com custo e cronograma previsveis, o que,
at a poca de 1968, quando o termo engenharia de software foi proposto, no aconte-
cia. Gostaria de ressaltar que software compreende, alm dos programas, toda a docu-
mentao referente a ele, sendo que a engenharia de software a disciplina que trata
dessa documentao.
Depois, na segunda unidade, comearemos a aplicar os conceitos j estudados e mos-
trarei a voc que um processo de software genrico composto de algumas etapas b-
sicas que faro parte de qualquer modelo de processo de software. Essas etapas bsicas
so: i) a especificao dos requisitos do software a ser desenvolvido; ii) o projeto e a im-
plementao do software; iii) a validao do software e, finalmente iv) a evoluo do sof-
tware. Nesta unidade, abordarei trs modelos de processo de software, mas a literatura
traz outros modelos. Meu objetivo mostrar alguns modelos propostos pela literatura,
mas, ao final dessa unidade, voc poder elaborar o seu prprio modelo, colocando as
etapas na ordem que voc achar melhor para a sua empresa.
A unidade III bastante especfica, tratando apenas dos conceitos relacionados a requi-
sitos de software, j que, para o desenvolvimento de um software da forma esperada
pelo cliente, fundamental que todos os requisitos tenham sido claramente definidos.
Um requisito deve estabelecer o que o sistema deve fazer, bem como as restries sobre
seu funcionamento e implementao, podendo ser classificado em requisito funcional e
no funcional. Os requisitos funcionais dizem respeito aos servios que o software deve
fornecer, por exemplo, o cadastro dos pacientes de uma clnica odontolgica, a emisso
de um relatrio de vendas. Todos esses requisitos, tanto os funcionais quanto os no
funcionais, devem ser claramente definidos no documento de requisitos, pois a par-
tir desse documento que o sistema ser modelado, projetado, implementado, ou seja,
todo o desenvolvimento do sistema ser baseado nesse documento. Em alguns casos,
o documento de requisitos pode servir como um contrato entre o cliente e a empresa
desenvolvedora do software.
APRESENTAO

Para voc ter uma ideia de como um documento de requisitos, mostrarei o de uma
locadora de filmes na unidade III. O exemplo bem simples, mas contm detalhes
suficientes para a continuidade do processo de desenvolvimento de software.
Ento, de posse do documento de requisitos, comearemos a estudar a penltima
unidade do nosso livro, a unidade IV que trata da modelagem do sistema. Nessa
unidade, utilizaremos os conceitos de orientao a objetos e de UML estudados na
primeira unidade. A modelagem a parte fundamental de todas as atividades rela-
cionadas ao processo de software, sendo que, os modelos que so construdos nessa
etapa servem para comunicar a estrutura e o comportamento desejados do sistema,
a fim de que possamos melhor compreender o sistema que est sendo elaborado.
Outro ponto importante que necessrio deixar registrado, que de nada vale uma
documentao desatualizada, por isso, importante utilizar uma ferramenta CASE
para criar e manter a documentao. Representaremos estes modelos por meio de
diagramas, utilizando a UML como notao grfica. Na primeira unidade j explica-
mos a importncia da UML e agora comearemos a utiliz-la de fato. A UML tem
diversos diagramas, mas, em nosso material, trataremos somente do Diagrama de
Casos de Uso e do Diagrama de Classes. A fim de auxiliar o entendimento de cada um
deles, elaborei uma espcie de tutorial explicando a sua elaborao passo a passo.
Isso foi feito para facilitar o seu entendimento, pois esses diagramas so os mais im-
portantes e os mais utilizados da UML, servindo de base para os demais diagramas.
E, finalmente, chegamos ltima unidade do nosso material. Essa unidade o fe-
chamento das etapas do processo de software, ou seja, tratar das etapas de pro-
jeto, implementao, teste e manuteno de software. Assim, voc compreender
todo o processo de software com as etapas que o englobam.
O projeto de software onde so definidas as interfaces do sistema. importante que o
usurio participe ativamente deste processo, afinal, ser ele quem vai passar a maior par-
te do tempo interagindo com o sistema. Depois disso, o sistema pode ser implementado,
ou seja, hora de transformar todo o trabalho realizado at o momento em cdigo fonte.
medida que o sistema vai sendo desenvolvido, cada programa vai sendo valida-
do pelo desenvolvedor, mas isso s no basta. muito importante que a etapa de
validao seja cuidadosamente realizada pela equipe de desenvolvimento, pois
preciso assegurar que o sistema funcionar corretamente.
Depois que o sistema colocado em funcionamento, ele precisa evoluir para conti-
nuar atendendo as necessidades dos usurios. Em todas estas etapas importante
a aplicao das tcnicas da engenharia de software.
Assim, chegamos ao final do nosso livro. Espero, sinceramente, que sua leitura seja
agradvel e que esse contedo possa contribuir para seu crescimento pessoal, aca-
dmico e profissional.
Prof. Mrcia.

Prof. Janana.

Prof. Talita.
09
SUMRIO

UNIDADE I

INTRODUO ENGENHARIA DE SOFTWARE

15 Introduo

16 Conceitos Bsicos Sobre Software

18 Histria da Engenharia De Software

22 Tipos de Aplicaes de Software

25 Software Legado

28 Consideraes Finais

33 Referncias

34 Gabarito

UNIDADE II

PROCESSOS DE SOFTWARE

37 Introduo

38 Processos de Software

40 Modelos de Processo de Software

48 Atividades Bsicas do Processo de Software

54 Consideraes Finais

60 Referncias

61 Gabarito
10
SUMRIO

UNIDADE III

REQUISITOS DE SOFTWARE

65 Introduo

66 Requisitos de Software

72 O Documento de Requisitos de Software

78 Engenharia de Requisitos

91 Consideraes Finais

95 Referncias

96 Gabarito

UNIDADE IV

MODELAGEM DE SISTEMAS

101 Introduo

102 Modelagem de Sistemas

104 Diagrama de Casos de Uso

114 Diagrama de Classes

131 Ferramentas Case (Computer-Aided Software Engineering)

134 Conceitos Bsicos de Orientao a Objetos

142 Uml Unified Modeling Languag

144 Consideraes Finais

149 Referncias

150 Gabarito
11
SUMRIO

UNIDADE V

PROJETO, IMPLEMENTAO, TESTES E MANUTENO DE SOFTWARE

157 Introduo

158 Projeto de Software

164 Implementao de Software

168 Teste de Software

173 Manuteno de Software

176 Consideraes Finais

182 Referncias

183 Gabarito

184 CONCLUSO
Professora Me. Mrcia Cristina Dadalto Pascutti
Professora Esp. Talita Tonsic Gasparotti

I
INTRODUO

UNIDADE
ENGENHARIA DE
SOFTWARE

Objetivos de Aprendizagem
Entender o que engenharia de software e qual a sua importncia.

Plano de Estudo
A seguir, apresentam-se os tpicos que voc estudar nesta unidade:
Conceitos bsicos sobre Software
Histria da Engenharia de Software
Tipos de Aplicaes de Software
Mitos Relativos ao Software
Software Legado
15

INTRODUO

Caro(a) aluno(a), nesta primeira unidade, trataremos alguns conceitos relacio-


nados engenharia de software como um todo, que sero fundamentais para o
entendimento de todas as unidades.
O termo engenharia de software foi proposto, inicialmente, em 1968, em
uma conferncia organizada para discutir o que era chamado de crise de sof-
tware. Essa crise foi originada em funo do hardware, que nessa poca tinha seu
poder de processamento e memria aumentados, sendo que o software deveria
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

acompanhar esse avano. E o que se notou, na poca, que o desenvolvimento


de grandes sistemas de maneira informal, sem seguir regras ou etapas pr-defi-
nidas, no era suficiente.
O software desenvolvido, at ento, no era confivel, no era desenvolvido
dentro do tempo e custos previstos inicialmente, seu desempenho era insatisfa-
trio e era difcil de dar manuteno. Os custos em relao ao hardware estavam
caindo, em funo de que a sua produo passou a ser em srie, porm, o custo
do software no acompanhava essa queda, muitas vezes, sendo aumentado.
A ideia inicial da engenharia de software era tornar o desenvolvimento de
software um processo sistematizado, em que seriam aplicadas tcnicas e mto-
dos necessrios para controlar a complexidade inerente aos grandes sistemas
(SOMMERVILLE, 2007, p. 4).
A engenharia de software to vasta que o software atual est envolvido
intrinsecamente em nosso cotidiano, portanto impossvel ignorarmos sua
importncia.
A engenharia de software moderna tem como objetivo elaborar metodolo-
gias baseadas na evoluo, ou seja, os softwares modificam-se continuamente e
tambm novos softwares so construdos a partir dos antigos.
Neste livro, abordaremos somente alguns tpicos da engenharia, pois, com
certeza, precisaramos de dezenas de livros como esse para esgotar esse assunto,
portanto, gostaria de deixar claro, que aqui estudaremos somente uma pequena
parte dessa abrangente disciplina.

Introduo
16 UNIDADE I

CONCEITOS BSICOS SOBRE SOFTWARE

O software um segmento de instru-


es que sero analisadas e processadas
pelo computador, ele dar significado a
elas com o objetivo de executar tarefas
especficas, pois so os softwares que
comandam o funcionamento de qual-
quer computador; o software a parte

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
lgica que fornece explicaes para o
hardware do computador.
Pressman (2011 p. 32) afirma que:
Software de computadores continua a
ser uma tecnologia nica e mais impor- shutterstock

tante no cenrio mundial.


Podemos observar outra percepo do que o software:
Software de computador um produto desenvolvido por profissionais
de software que tambm do suporte a ele a longo prazo e abrange pro-
gramas executveis em computadores de diversos portes ou arquitetu-
ra, contedos que so apresentados quando programas so executados,
informaes descritivas em forma impressa ou virtual.(MEDEIROS,
2016, online).

De acordo com Sommerville (2007), o software composto no somente pelos


programas, mas tambm pela documentao associada a esses programas.
Para Pressman (2011), o software possui, pelo menos, trs caractersticas
que o diferenciam do hardware:
1. Software desenvolvido ou passa por um processo de engenharia, no
sendo fabricado no sentido clssico.
Apesar de existir semelhanas entre o desenvolvimento de software e a
fabricao de hardware, essas atividades so muito diferentes. Os custos
de software concentram-se no processo de engenharia, por causa disso
os projetos de software no podem ser conduzidos como se fossem pro-
jetos de fabricao.

INTRODUO ENGENHARIA DE SOFTWARE


17

2. Software no se desgasta.
Normalmente, o hardware apresenta taxas de defeitos mais altas no incio
de sua vida, porm esses defeitos so corrigidos tendo assim a taxa decres-
cida, ou seja, atingindo um nvel estvel. Porm, com o uso, o hardware
pode se desgastar devido poeira, m utilizao, temperaturas extremas
e outros. J com o software diferente, ou seja, ele no est sujeito aos
problemas ambientais, como o hardware. Em relao aos problemas ini-
ciais, com o software tambm acontece assim, pois alguns defeitos ainda
podem passar pela etapa de validao do software.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Quando um componente de hardware se desgasta, ele normalmente tro-


cado por um novo componente e o hardware volta a funcionar. Com o
software, isso no acontece, no tem como simplesmente trocar o com-
ponente, pois quando um erro acontece no software, pode ser de projeto,
de requisito mal definido, levando o software a sofrer manuteno, que
pode ser considerada mais complexa que a do hardware.
3. Embora a indstria caminhe para a construo com base em componentes,
a maioria dos softwares continua a ser construda de forma personali-
zada (sob encomenda).
A reutilizao de componentes de hardware parte natural do seu pro-
cesso de engenharia, j para o software algo que apenas comeou a ser
alcanado (PRESSMAN, 2011, p. 34). Os componentes reutilizveis de
software so criados para que o desenvolvedor possa se concentrar nas
partes do projeto que representam algo novo. Esses componentes encap-
sulam dados e o processamento aplicado a eles, possibilitando criar novas
aplicaes a partir de partes reutilizveis.

Software no se desgasta, mas ele se deteriora. autor desconhecido.

Conceitos Bsicos Sobre Software


18 UNIDADE I

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
shutterstock

HISTRIA DA ENGENHARIA DE SOFTWARE

A engenharia do software se define: [...] o estabelecimento e o emprego de slidos


princpios de modo a obter software de maneira econmica, que seja confivel
e funcione de forma eficiente em mquinas reais (MEDEIROS, 2016, online).
A principal caracterstica da engenharia do software so seus mtodos e tc-
nicas que so utilizados para o desenvolvimento do software.
Segundo Tsui e Karam (2013), o termo engenharia do software foi mencio-
nado pela primeira vez em uma conferncia da OTAN (Organizao do Tratado
do Atlntico Norte) conduzida na Alemanha em 1968.
Tendo como objetivo aplicar tcnicas e utilizar ferramentas na rea da com-
putao, para o desenvolvimento e a produo de software, preciso planejar a
curto e longo prazo a equipe que vai ser montada e a qualidade do produto e do
seu processo, e tudo isso est presente no nosso dia a dia; as pessoas no perce-
bem, mas estamos ligados engenharia de software no nosso cotidiano.
Segundo Sommerville (2011), a engenharia de software uma disciplina cujo
foco o desenvolvimento de sistemas de software de alta qualidade por um custo
acessvel. Alm disso, preciso ter em conta que o software abstrato e intangvel,

INTRODUO ENGENHARIA DE SOFTWARE


19

e que esta engenharia preocupada com todos os aspectos da produo de software,


desde os estgios iniciais de especificao de um sistema at a manuteno do sis-
tema aps ter sido posto em uso (TSUI; KARAM 2013).
Essa disciplina ou rea de conhecimento surgiu em decorrncia da preocupao
em contornar a crise que estava se abatendo no software e dar a ele um tratamento
de engenharia. Isso aconteceu em 1970, fazendo formar a engenharia do software,
que veio para implementar sistemas mais complexos. Segundo Sommerville (2011),
quando falamos de engenharia de software, no se trata apenas do programa em si,
mas de toda a documentao associada e dados de configuraes necessrios para
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

fazer este programa operar corretamente. Alm disso:


Para ser considerada como prtica de engenharia profissional deve in-
cluir o cdigo e os regulamentos que seus membros devem seguir. Por-
tanto, a engenharia do software tambm inclui diretivas para a aqui-
sio de conhecimento por parte de seus membros e diretivas para as
prticas comportamentais de seus membros (TSUI; KARAM, 2013, p.
36).

As pessoas que trabalham diretamente com a engenharia do software esto


envolvidas e dirigem seus conhecimentos para o desenvolvimento do software,
atentas manuteno e adequao, bem como aos seus diferentes processos
produtivos.
De acordo com Sommerville (2011), a engenharia de software uma dis-
ciplina cujo foco est em todos os aspectos da produo de software, desde os
estgios iniciais da especificao do sistema at sua manuteno.
Para Sommerville (2011, p. 5), a engenharia de software importante por
dois motivos:
1. A sociedade, cada vez mais, depende de sistemas de software avanados,
portanto preciso que os engenheiros de software sejam capazes de pro-
duzir sistemas confiveis de maneira econmica e rpida.
2. A longo prazo, normalmente, mais barato usar mtodos e tcnicas
propostos pela engenharia de software, ao invs de somente escrever os
programas como se fossem algum projeto pessoal. Para a maioria dos sis-
temas, o maior custo est na sua manuteno, ou seja, nas alteraes que
so realizadas depois que o sistema implantado.

Histria da Engenharia De Software


20 UNIDADE I

A PRTICA DA ENGENHARIA DE SOFTWARE

De acordo com Pressman (2011, p. 43), devemos utilizar os seguintes princ-


pios e conceitos:
1. Compreender o problema: nem sempre fcil o quanto pensamos.
Quem tem interesse na soluo do problema? Quais so os interessados?
Quais recursos, dados e funes so necessrios para resolver apropria-
damente o problema?

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
O problema pode ser compartimentalizado? possvel representar em
problemas menores? Talvez seja mais fcil para ser compreendido.
O problema pode ser representado graficamente? possvel termos um
modelo analtico?

2. Planejar uma soluo: realize um pequeno projeto.


Voc j viu problemas similares anteriormente? Existem padres que so
reconhecveis em um potencial de solues? Existe algum software que
implemente os dados, as funes e caractersticas necessrias?
Algum problema similar j foi resolvido? Em caso positivo, existem ele-
mentos da soluo que podem ser reutilizados?
possvel definir subproblemas? Em caso positivo, existem solues apa-
rentes e imediatas para eles?
possvel representar uma soluo de maneira que conduza a uma imple-
mentao efetiva? possvel criar um modelo de projeto?
3. Executar o plano: podem surgir desvios inesperados, mas possvel
descobrirmos caminhos melhores; se seguirmos o planejamento, conti-
nuaremos sem nos perder.
Verificar se a soluo se adequa ao plano? O cdigo fonte pode ser atri-
budo ao projeto?
Projeto e cdigos foram revisados? Os componentes da soluo esto pro-
vavelmente corretos?

INTRODUO ENGENHARIA DE SOFTWARE


21

4. Examinar resultado para ter preciso: no podemos ter certeza de que


uma soluo seja perfeita, porm asseguramos que testes so suficientes
para revelar um nmero maior de erros.
Podemos testar cada parte componente da soluo? Foi implementado
uma estratgia de testes?
Os resultados da soluo se adequam aos dados, funes e caractersti-
cas? O software foi validado em relao s solicitaes dos interessados.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

PRINCPIOS GERAIS

De acordo com Pressman (2011), so:


1. A razo de existir: antes de especificar uma necessidade do sistema todas
as decises deveriam ter princpios voltados aos seus usurios, verificar
se realmente vai haver agregao diante da necessidade.
2. KISS (Keep it simple, ou seja, Faa de forma simples): h diversos
fatores a ser considerados em qualquer esforo do projeto, um software
com qualidade de fcil manuteno e menos propensos a erros.
3. Mantenha a viso: para o sucesso, preciso mantermos uma viso clara,
sem ela o projeto se torna ambguo; corre-se o risco de transformar o pro-
jeto em vrios recortes, comprometendo, ento, a viso clara .
4. O que um produz, os outros consomem: o sistema de fora industrial
construdo e utilizado de forma isolada. Outras pessoas podero documen-
tar, manter e usar. Sendo assim, projete e implemente ciente de que algum
mais dever entender o que voc est desenvolvendo, dessa forma voc
agrega mais valor ao sistema e facilita o trabalho de todas outras pessoas.
5. Esteja aberto para o futuro: jamais desenvolva projetos limitados, pois
um software com maior tempo de vida mais tem valor.
6. Planeje com antecedncia: alcanar o nvel de reuso indiscutivelmente
a meta mais difcil de ser atingida quando se desenvolve um software, pois
a reutilizao economiza tempo e esforo.
7. Pense: a forma mais clara e qual produz melhores resultados sempre!

Histria da Engenharia De Software


22 UNIDADE I

TIPOS DE APLICAES DE SOFTWARE

Atualmente, com o software sendo utilizado em praticamente todas as ativida-


des exercidas pelas pessoas, existe uma grande variedade de aplicaes. Vamos
ver algumas delas:
Software de sistema de acordo com Pressman (2011, p. 34),
so aqueles programas desenvolvidos para atender a outros
programas, por exemplo, editores de texto, compila-
dores e sistemas operacionais.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Software de aplicao so programas
desenvolvidos para solucionar uma necessi-
dade especfica de negcio, processando dados
comerciais ou tcnicos de forma que ajude nas
operaes comerciais ou tomadas de deciso pelos
administradores da empresa.
Software cientfico/de engenharia so apli-
shutterstock caes que vo da astronomia vulcanologia, da
biologia molecular fabricao automatizada, normal-
mente utilizando algoritmos para processamento numrico pesado.
Software embutido controla ou gerencia dispositivos de hardware, como
celular, painel do micro-ondas, controle do sistema de freios de um veculo.
Software de inteligncia artificial utiliza algoritmos no numricos
para solucionar problemas complexos que no poderiam ser solucionados
pela computao ou anlise direta, por exemplo, sistemas especialistas,
robtica, redes neurais artificiais.

MITOS RELATIVOS AO SOFTWARE

Mitos de software so caracterizados como uma srie de falsas verdades, pois


apresentam uma sensao intuitiva, distorcendo a verdadeira face do processo
de engenharia. Atualmente, profissionais com muita experincia na engenha-
ria de software reconhecem os mitos e as atitudes enganosas que representam.

INTRODUO ENGENHARIA DE SOFTWARE


23

Podemos observar alguns exemplos a seguir de acordo com Presmann (2011,


p. 46-47).
1. Mitos de Gerenciamento:
Mito: temos um livro com padres e procedimentos para desenvolver
software.
Realidade: o livro pode existir, mas ele usado? Os praticantes sabem que
ele existe? O livro reflete a prtica moderna da engenharia de software?
adaptvel, est alinhado para melhorar o tempo de entrega, mantendo o
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

foco na qualidade? Em muitos casos, a resposta para essas perguntas no.


Mito: se o cronograma atrasar, poderemos acrescentar mais programa-
dores e ficarmos em dia?
Realidade: o desenvolvimento de software no um processo mecnico
como os das fbricas. Nas palavras de Brooks[Bro95]: acrescentar pes-
soas num projeto de software atrasado o tornar mais atrasado ainda.
O que ocorre com a chegada de novas pessoas em um projeto, as que j
estavam tero de gastar tempo situando os recm-chegados, reduzindo
consequentemente o tempo destinado ao desenvolvimento produtivo.
Para que sejam inseridas novas pessoas esta ao dever ser de forma
planejada e coordenada.
Mito: posso terceirizar o projeto de software e simplesmente relaxar e dei-
xar a essa empresa realiz-lo.
Realidade: caso essa organizao no saiba gerenciar e controlar projetos
de software, provavelmente ir se deparar com dificuldades.
2. Mitos de Clientes:

importante sabermos que os clientes solicitantes do software podem ser pes-


soas comuns, ou seja, no necessariamente preciso conhecimento especfico
na rea computacional, porm, necessrio saber da sua regra de negcio.
Mito: definio geral suficiente para comear a escrever os programas.
Realidade: nem sempre ser possvel uma definio ampla e estvel dos
requisitos. Estes so obtidos somente por meio da comunicao entre
cliente e desenvolvedor, sendo assim nem sempre possvel.

Tipos de Aplicaes de Software


24 UNIDADE I

3. Mitos de profissionais da rea:


Tem residido por mais de 50 anos de cultura de programao. Modos e
atitudes antigos dificilmente so esquecidos.
Mito: uma vez feito programa e colocado em uso, nosso trabalho est
terminado?
Realidade: uma vez que algum j disse que o quanto antes se comea a
codificar, mais tempo levar para termina-lo.
Mito: at que um programa entre em funcionamento, no h maneira de

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
avaliar sua qualidade.
Realidade: um dos mecanismos de garantia da qualidade de software mais
eficaz pode ser aplicado desde a concepo de um projeto.
Mito: o nico produto passvel de entrega o programa em funcionamento.
Realidade: um programa funcionando somente uma parte de uma con-
figurao de software que inclui muitos elementos.
Mito: a engenharia de software nos far criar documentao volumosa
e desnecessria.
Realidade: a engenharia de software no trata de criao de documentos,
mais sim da criao de um produto de qualidade.
Ter cincia das realidades dos profissionais que trabalham com software
o primeiro passo para buscar solues prticas na engenharia de software.
Por isso, muitos profissionais de software reconhecem com facilidade om
mitos que acabamos de descrever.

Se o processo estiver correto, os resultados falaro por si mesmos.


Takashi Osada

INTRODUO ENGENHARIA DE SOFTWARE


25

SOFTWARE LEGADO

Denominam-se aos softwares antigos os que so foco de contnua ateno e pre-


ocupao desde os anos 1960. Dayani-Fard e seus colegas [Day99] descrevem
software legado da seguinte forma:
Sistemas de software legado... Foram desenvolvidos h dcadas atrs e
em sido continuamente modificado para se adequar a mudanas dos
requisitos de negcio e a plataformas computacionais. A proliferao de
tais sistemas est causando dores de cabea para grandes organizaes
que consideram dispendiosos de manter e arriscado de evoluir.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Liu e seus colegas [Liu98] observaram que muitos sistemas legados permane-
cem dando suporte para funes de negcios vitais e so indispensveis para
o mesmo.
Softwares legados, por sua vez, podem apresentar projetos no expans-
veis, cdigo intrincado, documentao inexistente ou escassa, testes que nunca
foram arquivados. E que, mesmo assim, esses softwares possuem funes vitais
de negcios e so indispensveis para ele. Surge-nos, ento, a pergunta, o que
devemos fazer? Nada, isso mesmo, nada, at que o software legado se submeta
a modificaes significativas.
Vale lembrarmos que, caso o software legado atenda s necessidades de seus
usurios, possibilitando confiana e vitalidade, no precisa ser consertados.
Entretanto, esses sistemas evoluem com o passar do tempo, por uma ou mais
das seguintes razes (Pressman 2011):
O software deve ser adaptado para atender s necessidades de novos
ambientes ou de novas tecnologias computacionais.
O software deve ser aperfeioado para implementar novos requisitos de
negcio.
O software deve ser expandido para torn-lo interopervel com outros
bancos de dados ou softwares mais modernos.
O software deve ser rearquitetado para torn-lo vivel dentro de um
ambiente de rede.

Software Legado
26 UNIDADE I

O objetivo da engenharia de software moderna de elaborar metodologias


baseadas na evoluo, ou seja, os softwares modificam-se continuamente e que
novos softwares so construdos a partir dos antigos... [Day99].

INTRODUO QUALIDADE DE SOFTWARE

Para que o software possa ser funcional e prtico, preciso qualidade na pro-
duo e na manuteno. A qualidade em software se refere s caractersticas

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
dos produtos que atendam requisitos de funcionalidade. Esses requisitos esto
ligados, diretamente, com a rea de utilizao do programa. Para cada requi-
sito, temos um campo de abrangncia, uma especificidade. Esses requisitos so:
funcionalidade, confiabilidade, usabilidade, eficincia, manutenibilidade, por-
tabilidade, estabilidade.
Esses requisitos fazem parte da qualidade do software de forma que cada
produto, cada programa, possa atender s necessidades tecnolgicas,
econmicas, sociais, intelectuais e prticas do setor ao qual se
destinam, observando as especificidades de cada rea onde o produto
utilizado. Assim deve se levar em considerao a utilizao do produto.
Em reas econmicas certos requisitos sero mais necessrios do que
na rea educacional, onde os requisitos de um programa atendem
as necessidades daquele pblico em particular. (VASCONCELOS,
ROUILLER, MACHADO, MEDEIROS, 2006).

Ao observar essas especificidades, o software responde aos anseios de um mer-


cado em particular. Sem deixar de levar em considerao o que cada um precisa.
reas de lazer precisam de certos requisitos, reas educacionais outros, reas
sociais outros. O programa atende s necessidades de cada setor, sem perder a
sua qualidade.

INTRODUO ENGENHARIA DE SOFTWARE


27

A qualidade se torna uma parte importante em todo o processo de pro-


duo de um software, em que se leva em considerao no apenas aspectos
tecnolgicos, econmicos ou sociais, mas a praticidade do mesmo, as funes
que desempenha, a facilidade de uso, a capacidade de ser reciclado, manuten-
o, entre outros. A qualidade visa apresentar um produto completo que atenda
a todas as necessidades do setor a qual se destina.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

O que engenharia reversa?


O nome engenharia reversa define muito bem o conceito do que ela faz.
Trata-se do estudo de um objeto, seja um processador, um monitor, um pro-
grama ou at mesmo um simples relgio, desmontando-o e analisando suas
peas, seus componentes, seus comandos e seu comportamento (no caso
de programas). Isso feito para descobrir como ele foi fabricado, como ele
poderia ser melhorado e que outras funes ele poderia realizar.
Fonte: Hautsch (online).1

Software Legado
28 UNIDADE I

CONSIDERAES FINAIS

Nesta primeira unidade, foram apresentados alguns conceitos bsicos sobre enge-
nharia de software que sero utilizados no decorrer de todo o livro, por isso,
muito importante que esses conceitos fiquem bem claros para voc.
A engenharia de software foi proposta para tentar levar a preciso da enge-
nharia para o desenvolvimento de software, pois at aquela poca, desenvolver
um software era algo que no podia ser mensurado, nem em relao ao tempo,
nem em relao ao custo, levando-se, normalmente, muito mais tempo do que

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
o previsto. E o que acontecia era que no se tinha uma regra, uma sequncia de
atividades para o desenvolvimento. Voc vai ver, na prxima unidade que, para
tentar solucionar esse problema, os estudiosos da engenharia de software pro-
puseram vrios modelos de processos de software, sendo que a empresa pode
escolher o que melhor se adequa a ela. Isso tem ajudado muito o desenvolvimento
de software. Voc vai perceber isso durante o estudo das prximas unidades.
Outro conceito importante que foi tratado nesta primeira unidade o con-
ceito de software. Algumas pessoas que conheo acham que desenvolver software
simplemesmente sentar em frente ao computador e escrever as linhas de cdigo.
Voc percebeu que sim, isso faz parte do software, mas que desenvolver software
muito mais abrangente, pois o software envolve, alm dos programas, a docu-
mentao, as pessoas, os procedimentos envolvidos. A engenharia de software
trata de todos esses aspectos, mas em nosso livro trataremos mais especifica-
mente da modelagem de um software, desde o levantamento dos requisitos at
a elaborao de vrios diagramas. No trataremos da implementao propria-
mente dita, pois isso voc ver em outras disciplinas do curso. A implementao
muito importante, por isso, voc ter disciplinas dedicadas a essa tarefa.
Essa primeira unidade foi somente um aperitivo. Agora vamos passar a estu-
dar assuntos especficos da disciplina e voc vai perceber que a engenharia de
software muito importante para o desenvolvimento de um software.

INTRODUO ENGENHARIA DE SOFTWARE


29

1. Segundo Pressman, assinale quais alternativas diferenciam o software do


hardware?
I. Software no fabricado no sentido clssico.
II. Software se desgasta.
III. Software possui componentes reutilizveis.
IV. Software no possui segmento de instrues.
V. Software a parte lgica.
So verdadeiras:
a. Somente I e II.
b. Somente I, III e V.
c. Somente I, III e V.
d. Todas esto corretas.
2. Quando falamos de engenharia de software, no se trata apenas do
______________ em si, mas de toda a _____________ associada e dados de con-
figuraes necessrios para fazer este programa operar corretamente.
3. Quais so os tipos de aplicaes de software?
30

DESENVOLVIMENTO GIL DE SOFTWARE


Kend Beck (2001) e outros dezesseis renomados que trabalhavam na rea de desen-
volvimento, consultoria, do sistema de software assinaram o Manifesto para o desen-
volvimento gil de Software. O objetivo era sanar fraquezas que fossem perceptveis
na engenharia de software, para que esse mtodo funcionasse era necessrio observar
alguns itens: a satisfao do cliente, a maneira como se acolhe os pedidos de alteraes,
dar preferncia a intervalos mais curtos de entrega, trabalhar em conjunto, motivao
constante tanto para elaborar o projeto como da equipe que ir realiz-lo, sempre ter
uma conversa aberta com a equipe, o software sempre deve estar em funcionamento,
ter sempre um ritmo constante, ateno contnua, simplicidade, auto organizao da
equipe, avaliao da equipe em tempos regulares. Segundo Pressman (2011, p. 86) o
desenvolvimento gil foca talentos e habilidades de indivduos, moldando o processo
de acordo com as pessoas e as equipes especficas.
Quando falamos de desenvolvimento gil da engenharia do software, nos deparamos
com inmeras definies, pois as suas prticas variam muito, mas os princpios so
iguais, a entrega rpida do projeto, a agilidade da equipe, e a constante participao di-
reta do cliente com seus fornecedores, que so os engenheiros de software, estes tm o
enfoque no software em si, e no em sua concepo e documentao. Segundo Steffen
(2016, p. 1):
gil uma nova forma de gesto e desenvolvimento de Software que
usa uma abordagem de planejamento e execuo iterativa e incremental
voltado para processos empricos (complexos, caticos ou com muita
incerteza, tm mudanas ao longo do processo, no so repetitivos e
so imprevisveis) que divide o problema em produtos menores e que
visa entregar software funcionando regularmente, visa a aproximao
e maior colaborao do time de desenvolvimento com os experts de
negcios, comunicao face-to-face, reduo dos riscos associados s
incertezas dos projetos, abraar e responder as mudanas de forma mais
rpida e natural e claro a satisfao final dos clientes por meio da ado-
o de prticas de gesto e de engenharia de software com foco nos
valores e princpios doLeane doagile, resumindo, seu principal objetivo
entregar o produto que o cliente realmente deseja e que ser til e
com qualidade.

Podemos notar que a engenharia gil de software tem como prioridade melhorar a sua
produtividade, tendo como foco a contnua comunicao com seu cliente, o que muda
na sua estrutura, mas s um pouco, essa engenharia planeja apenas o que ser feito,
com todos os detalhes, se acaso acontecer de ter algum erro, esse pode ser corrigido
rapidamente, no deixando a equipe se desmotivar.
31

Nos dias de hoje, as empresas operam em um ambiente global, com mu-


danas rpidas. Assim precisam responder a novas oportunidades e no-
vos mercados, a mudanas nas condies econmicas e ao surgimento
de produtos e servios concorrentes. Softwares fazem parte de quase
todas as operaes de negcios, assim novos softwares so desenvolvi-
dos rapidamente para obterem proveito de novas oportunidades e res-
ponder s presses competitivas (SOMMERVILLE. p. 39).

O mtodo gil no fechado em si, tendo vrias vertentes ou campos de atuao, como:
A Extreme Programming (XP) uma metodologia de desenvolvimento de software, nas-
cida nos Estados Unidos no final da dcada de 90. Destaca-se, em diversos pases, por
auxiliar o desenvolvimento de sistemas de melhor qualidade, que so produzidos em
menos tempo e de forma mais econmica que o habitual. Os objetivos so alcanados
por meio de um pequeno conjunto de valores, princpios e prticas, que diferem subs-
tancialmente da forma tradicional de se desenvolver software. Propondo que somente
a documentao estritamente necessria seja gerada, com o cdigo e os testes de uni-
dade servindo como documentao.
Scrum uma metodologia de desenvolvimento que surgiu no incio dos anos 90, seu
nome foi originado a partir de uma atividade durante a partida de rugby.
Incorpora atividades estruturais, sendo elas: requisitos, anlise, projeto, evoluo e en-
trega. Para cada atividade metodolgica, utilizado padres de processo:
Registro pendente de trabalhos (Backlog): lista de requisitos e prioridades ou funciona-
lidades que fornecem valor comercial aos clientes.
Urgncias (sprints): consiste em realizar ajustes dentro de prazo pr-estabelecido.
Alteraes: permitem que membros trabalhem em curto prazo, porm estveis.
Reunies: so realizadas diariamente pela equipe com durao mxima de 15 minutos.
Demos: demonstrao ao cliente das funcionalidades implementadas, lembrando que
esta poder no ter todas as funcionalidades.
Por meio desses mtodos a engenharia de software pode aplicar em seus projetos,
sendo eles no muito complexos, de maior rapidez, pois os ciclos so mais curtos, o
planejamento mais funcional, tolerncia a mudanas, maior proximidade da equipe
com seu cliente e vice versa e o foco geral no ambiente de trabalho e de seus colabora-
dores.
MATERIAL COMPLEMENTAR

Fundamentos de Engenharia de Software


Frank Tsui e Orlando Karam
Editora: LTC
Sinopse: Em sua segunda edio,Fundamentos da Engenharia
de Softwareconsiste em uma introduo abrangente de temas e
metodologias essenciais sobre o desenvolvimento de software. Ideal
para estudantes universitrios e para profissionais experientes
procura de uma nova carreira no setor de tecnologia da informao
ou reas afins , esta obra apresenta o ciclo de vida completo de
um sistema de software da concepo at a liberao e o suporte
ao usurio.
Fundamentos da Engenharia de Software constitui um texto
excepcional para aqueles que esto ingressando no estimulante
mundo do desenvolvimento de software.
33
REFERNCIAS

MEDEIROS, H. Princpios da engenharia de software. Disponvel em: <http://


www.devmedia.com.br/principios-da-engenharia-de-software/29630>. Acesso em
11 de fev. de 2016.
PRESSMAN, R. S. Engenharia de software. Uma abordagem profissional. 7. Ed. Por-
to Alegre: AMGH, 2011.
SOMMERVILLE, I. Engenharia de software. 9. Ed. So Paulo: Pearson Prentice Hall,
2011.
STEFFEN, J. B. O que so essas tais de metodologias geis? Disponvel em: <ht-
tps://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/
mas_o_que_s_c3_a3o_essas_tais_de_metodologias__c3_a1geis?lang=en>. Aces-
so em 11 de fev. de 2016.
TSUI, F. ; KARAM, O. Fundamentos de engenharia de software. 2. Ed. Rio de Janei-
ro: LTC, 2013.
VASCONCELOS, A. M. L. de; ROUILLER, A. C.; MACHADO, C. . F.; MEDEIROS, T. M.
M. de. Introduo engenharia de software e qualidade de software. Lavras:
UFLA/FAEPE, 2006. Disponvel em: <http://www.cin.ufpe.br/~if720/downloads/
Mod.01.MPS_Engenharia&QualidadeSoftware_V.28.09.06.pdf>. Acesso em 11 de
fev. de 2016.
GABARITO

1. C
2. - Programa, Documentao
3.
Software de sistema: programas desenvolvidos para atender a outros pro-
gramas.
Software de aplicao: programas desenvolvidos para solucionar uma ne-
cessidade especfica de negcio.
Software cientfico/de engenharia: so aplicaes que vo da astronomia
fabricao automatizada.
Software embutido: controla ou gerencia dispositivos de hardware.
Software de inteligncia artificial: solucionar problemas complexos que
no poderiam ser solucionados pela computao ou anlise.
Professora Me. Mrcia Cristina Dadalto Pascutti

II
UNIDADE
PROCESSOS DE SOFTWARE

Objetivos de Aprendizagem
Compreender os conceitos de processo de software e modelos de
processo de software.
Mostrar as atividades bsicas do processo de software.
Mostrar trs modelos de processo de software.

Plano de Estudo
A seguir, apresentam-se os tpicos que voc estudar nesta unidade:
Processos de Software
Modelos de Processo de Software
Atividades Bsicas do Processo de Software
37

INTRODUO

Caro(a) aluno(a), na primeira unidade, voc aprendeu alguns conceitos bsi-


cos relacionados Engenharia de Software. A partir de agora, voc comear a
estudar assuntos mais especficos da disciplina e voc ver que seu estudo ficar
cada vez mais interessante.
Nos ltimos tempos, o desenvolvimento de software uma das reas da tec-
nologia que mais cresceu, e com esse crescimento vieram, tambm, problemas
que vo desde o no cumprimento dos prazos estabelecidos para o seu desen-
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

volvimento at a falta de qualidade do software desenvolvido.


Um software no pode ser desenvolvido de qualquer jeito, sem seguir cri-
trios, sem que se saiba qual o prximo passo a ser dado. Por isso, os conceitos
relacionados engenharia de software devem ser utilizados. Hoje em dia, a
empresa precisa definir qual o seu processo de software.
Nesta unidade, voc aprender o que um processo de software e conhe-
cer alguns modelos de processo que j existem em nossa literatura e que so
utilizados por muitas empresas. Esses modelos so: modelo em cascata, desen-
volvimento incremental e engenharia de software baseada em componentes.
importante, porm, ressaltar que no preciso seguir um desses modelos que j
esto prontos, ou seja, a empresa que vai desenvolver software pode criar o seu
prprio modelo. imprescindvel que esse modelo seja seguido.
Existem algumas atividades bsicas que fazem parte de um processo de sof-
tware. Estudaremos cada uma dessas atividades: especificao de software, projeto
e implementao de software, validao de software e evoluo de software. Voc
perceber que os modelos de processo de software apresentados nesta unidade
possuem todas essas atividades, e que, s vezes, a atividade possui um nome
diferente, mas com o mesmo significado. Voc ver tambm que uma atividade
pode se desdobrar em vrias etapas ou subatividades.

Introduo
38 UNIDADE II

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
shutterstock

PROCESSOS DE SOFTWARE

Para que um software seja produzido, so necessrias diversas etapas, compostas


por uma srie de tarefas em cada uma delas. A esse conjunto de etapas d-se o
nome de processo de software. Essas etapas podem envolver o desenvolvimento
de software a partir do zero em uma determinada linguagem de programao
(por exemplo, o Java ou C) ou, ento, a ampliao e a modificao de sistemas
j em utilizao pelos usurios.
Segundo Sommerville (2011), existem muitos processos de software diferen-
tes, porm todos devem incluir quatro atividades fundamentais para a engenharia
de software:
1. Especificao de software: necessrio que o cliente defina as
funcionalidades do software que ser desenvolvido, bem como defina
todas as suas restries operacionais.
2. Projeto e implementao de software: o software deve ser confeccio-
nado seguindo as especificaes definidas anteriormente.

PROCESSOS DE SOFTWARE
39

3. Validao de software: o software precisa ser validado para garantir que


ele faz o que o cliente deseja, ou seja, que ele atenda s especificaes de
funcionalidade.
4. Evoluo de software: as funcionalidades definidas pelo cliente durante
o desenvolvimento do software podem mudar e o software precisa evo-
luir para atender a essas mudanas.

Vamos estudar detalhadamente cada uma das atividades mencionadas acima


durante a nossa disciplina, inclusive utilizando ferramentas automatizadas (fer-
ramentas CASE) para nos auxiliar na elaborao dos diversos documentos que
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

sero necessrios.
Conforme Sommerville (2011, p. 19), os processos de software so comple-
xos e, como todos os processos intelectuais e criativos, dependem de pessoas para
tomar decises e fazer julgamentos. No existe um processo ideal, a maioria das
organizaes desenvolve os prprios processos de desenvolvimento de software.
O que acontece que nem sempre as empresas aproveitam as boas tcnicas
da engenharia de software em seu desenvolvimento de software. E, normal-
mente, o software no atende aos requisitos do usurio, acaba demorando mais
tempo para ser desenvolvido do que o previsto, aumentando assim, o valor do
custo do software.
As atividades mencionadas por Sommerville podem ser organizadas pelas
empresas da forma como ela achar melhor, porm, importante ressaltar que
todas essas atividades so de extrema importncia e o processo de software ado-
tado pela empresa no deve deixar de considerar nenhuma das etapas.
importante ressaltar que mesmo as empresas que possuem um processo
de software bem definido e documentado, para determinados softwares que ela
desenvolve, pode ser utilizado outro processo de software, ou seja, dependendo
do software a ser desenvolvido, pode ser utilizado um determinado processo de
software. Na prxima seo, veremos alguns modelos de processo de software e
veremos tambm que possvel a empresa adotar um processo de software pr-
prio, que atenda suas necessidades.

Processos de Software
40 UNIDADE II

MODELOS DE PROCESSO DE SOFTWARE

Como foi discutido anteriormente, um processo de software composto por um


conjunto de etapas que so necessrias para que seja produzido. Sommerville
(2007) afirma que um modelo de processo de software uma representao abs-
trata, simplificada de um processo de software. Os modelos de processo incluem
as atividades que fazem parte do processo de software (voc est lembrado das
atividades descritas no item anterior?), os artefatos de software que devem ser
produzidos em cada uma das atividades (documentos) e tambm os papis das

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
pessoas envolvidas na engenharia de software. Alm disso, cada modelo de pro-
cesso representa um processo a partir de uma perspectiva particular, de uma
maneira que proporciona apenas informaes parciais sobre o processo.
Na literatura, existem diversos modelos de processo de software. Aqui, irei
mostrar somente trs desses modelos e, em seguida, mostrarei as atividades bsicas
que esto presentes em, praticamente, todos os modelos de processos de software.
Os modelos de processo que mostrarei foram retirados de Sommerville
(2011, p.20) e so:
1. Modelo em Cascata: esse modelo considera as atividades de especifi-
cao, desenvolvimento, validao e evoluo, que so fundamentais ao
processo e as representa como fases separadas, como a especificao de
requisitos, o projeto de software, a implementao, os testes e assim por
diante (SOMMERVILLE, 2011).
2. Desenvolvimento Incremental. esse modelo intercala as atividades de
especificao, desenvolvimento e validao. Um sistema inicial rapida-
mente desenvolvido a partir de especificaes abstratas, que so refinadas
com informaes do cliente, para produzir um sistema que satisfaa suas
necessidades, produzindo vrias verses do software (SOMMERVILLE,
2011).
3. Engenharia de Software Orientada a Reuso: esse modelo parte do prin-
cpio de que existem muitos componentes que podem ser reutilizveis.
O processo de desenvolvimento do sistema se concentra em combi-
nar vrios desses componentes em um sistema, em vez de proceder ao
desenvolvimento a partir do zero, com o objetivo de reduzir o tempo de
desenvolvimento (SOMMERVILLE, 2011).

PROCESSOS DE SOFTWARE
41

O MODELO EM CASCATA

O modelo cascata ou ciclo de vida clssico,


considerado o paradigma mais antigo da
engenharia de software, sugere uma abor-
dagem sequencial e sistemtica para o
desenvolvimento de software, comeando
com a definio dos requisitos por parte do
cliente, avanando pelas atividades de projeto
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

e implementao de software, testes, implan-


tao, culminando no suporte contnuo do
software concludo.
shutterstock

Segundo Sommerville (2007, p. 44), os


principais estgios do modelo em cascata demonstram as atividades fundamen-
tais do desenvolvimento:
1. Anlise e definio de requisitos: as funes, as restries e os objeti-
vos do sistema so estabelecidos por meio da consulta aos usurios do
sistema. Em seguida, so definidos em detalhes e servem como uma espe-
cificao do sistema.
2. Projeto de sistemas e de software: o processo de projeto de sistemas
agrupa os requisitos em sistemas de hardware ou de software. Ele esta-
belece uma arquitetura do sistema geral. O projeto de software envolve
a identificao e a descrio das abstraes fundamentais do sistema de
software e suas relaes.
3. Implementao e teste de unidades: durante esse estgio, o projeto de
software compreendido como um conjunto de programas ou unida-
des de programa. O teste de unidades envolve verificar que cada unidade
atenda a sua especificao.
4. Integrao e teste de sistemas: as unidades de programa ou programas
individuais so integrados e testados como um sistema completo a fim de
garantir que os requisitos de software foram atendidos. Depois dos tes-
tes, o sistema de software entregue ao cliente.

Modelos de Processo de Software


42 UNIDADE II

5. Operao e manuteno: normalmente (embora no necessariamente),


esta a fase mais longa do ciclo de vida. O sistema instalado e colo-
cado em operao. A manuteno envolve corrigir erros que no foram
descobertos em estgios anteriores do ciclo de vida, melhorando a imple-
mentao das unidades de sistema e aumentando as funes desse sistema
medida que novos requisitos so descobertos.

Um estgio somente pode ser iniciado depois que o estgio anterior tenha sido
concludo. Porm, Sommerville (2011, p. 21) afirma que na prtica esses est-
gios acabam se sobrepondo, alimentando uns aos outros de informaes. Por

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
exemplo, durante o projeto, os problemas com os requisitos so identificados.
O que acontece que um processo de software no um modelo linear simples,
sequencial, mas envolve iteraes entre as fases. Os artefatos de software que so
produzidos em cada uma dessas fases podem ser modificados para refletirem
todas as alteraes realizadas em cada um deles.
Pressman (2011) aponta alguns problemas que podem ser encontrados
quando o modelo cascata aplicado:
1. Os projetos que acontecem nas empresas dificilmente seguem o fluxo
sequencial proposto pelo modelo. Alguma iterao sempre ocorre e traz
problemas na aplicao do paradigma.
2. Na maioria das vezes, o cliente no consegue definir claramente todas as
suas necessidades e o modelo cascata requer essa definio no incio das
atividades. Portanto, esse modelo tem dificuldade em acomodar a incer-
teza natural que existe no comeo de muitos projetos.
3. Uma verso operacional do sistema somente estar disponvel no final do
projeto, ou seja, o cliente no ter nenhum contato com o sistema durante
o seu desenvolvimento. Isso leva a crer que se algum erro grave no for
detectado durante o desenvolvimento, o sistema no atender de forma
plena as necessidades do cliente.
Segundo Sommerville (2011) e Pressman (2011), o modelo em cascata deve
ser utilizado somente quando os requisitos so fixos e tenham pouca probabi-
lidade de serem alterados durante o desenvolvimento do sistema e o trabalho
deve ser realizado at sua finalizao de forma linear. Sommerville (2011, p.21)

PROCESSOS DE SOFTWARE
43

ainda afirma que o modelo cascata reflete o tipo de processo usado em outros
projetos de engenharia. Como mais fcil usar um modelo de gerenciamento
comum para todo o projeto, processos de software baseados no modelo em cas-
cata ainda so comumente utilizados.

DESENVOLVIMENTO INCREMENTAL

O desenvolvimento incremental, segundo Sommerville (2011, p. 21), tem como


Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

base a ideia de desenvolver uma implementao inicial, baseada em uma reunio


com os envolvidos para definir os objetivos gerais do software, mostrar para o
usurio e fazer seu refinamento por meio de vrias verses, at que um sistema
adequado tenha sido desenvolvido.
Figura 1 Atividades concorrentes

Atividades concorrentes

Verso inicial
Especificaes

Descrio Verses
Desenvolvimento intermedirias
do esboo

Validao Verso final

Fonte: Sommerville (2011, p.22).

Assim, as atividades de especificao, desenvolvimento e validao so reali-


zadas concorrentemente com um rpido feedback entre todas as atividades. A
cada nova verso, o sistema incorpora novos requisitos definidos pelo cliente.

Modelos de Processo de Software


44 UNIDADE II

Para Pressman (2011, p. 63), inicialmente, necessrio desenvolver um pro-


jeto rpido que deve se concentrar em uma representao daqueles aspectos do
software que sero visveis aos usurios finais, como, o layout da interface com
o usurio.
O desenvolvimento incremental apresenta algumas vantagens importantes em
relao ao modelo em cascata. Sommerville (2011, p. 22) aponta trs vantagens:
(1) se o cliente mudar seus requisitos, o custo ser reduzido, pois a quantidade de
anlise e documentao a ser refeita menor do que no modelo em cascata; (2)
mais fcil obter um retorno dos clientes sobre o desenvolvimento que foi feito,

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
pois os clientes vo acompanhando o desenvolvimento do software medida
que novas verses so apresentadas a eles; (3) os clientes podem comear a uti-
lizar o software logo que as verses iniciais forem disponibilizadas, o que no
acontece com o modelo cascata.
Entretanto, a partir de uma perspectiva de engenharia e de gerenciamento,
existem alguns problemas:
1. O processo no visvel: os gerentes necessitam que o desenvolvimento
seja regular, para que possam medir o progresso. Se os sistemas so desen-
volvidos rapidamente, no vivel produzir documentos que reflitam
cada verso do sistema.
2. Os sistemas frequentemente so mal estruturados: a mudana constante
tende a corromper a estrutura do software. Incorporar modificaes no
software torna-se cada vez mais difcil e oneroso.
3. Podem ser exigidas ferramentas e tcnicas especiais: elas possibilitam
rpido desenvolvimento, mas podem ser incompatveis com outras ferra-
mentas ou tcnicas, e relativamente poucas pessoas podem ter a habilitao
necessria para utiliz-las.

Para sistemas pequenos (com menos de 100 mil linhas de cdigo) ou para sis-
temas de porte mdio (com at 500 mil linhas de cdigo), com tempo de vida
razoavelmente curto, a abordagem incremental de desenvolvimento talvez seja a
melhor opo. Contudo, para sistemas de grande porte, de longo tempo de vida,
nos quais vrias equipes desenvolvem diferentes partes do sistema, os problemas
de se utilizar o desenvolvimento incremental se tornam particularmente graves.

PROCESSOS DE SOFTWARE
45

Para esses sistemas, recomendado um processo misto, que incorpore as melho-


res caractersticas do modelo de desenvolvimento em cascata e do incremental,
ou ainda algum outro modelo disponvel na literatura.
Na literatura referente a modelos de processo de software pode-se encontrar
a prototipao como um exemplo de abordagem incremental.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Em todo processo h um cliente, pois, sem cliente, um processo deixa de


ter sentido.
(V. Daniel Hunt)

ENGENHARIA DE SOFTWARE ORIENTADA A REUSO

Na maioria dos projetos de software, ocorre algum reuso de software, pois,


normalmente, a equipe que trabalha no projeto conhece projetos ou cdigos
anlogos ao que est sendo desenvolvido. Ela busca esses cdigos, faz as modi-
ficaes conforme a necessidade do cliente e os incorporam em seus sistemas.
Independentemente do processo de software que est sendo utilizado, pode ocor-
rer esse reuso informal.
Porm, nos ltimos anos, uma abordagem para desenvolvimento de software,
com foco no reuso de software existente tem emergido e se tornado cada vez
mais utilizada. A abordagem orientada a reuso conta com um grande nmero
de componentes de software reutilizveis, que podem ser acessados, e com um
framework de integrao para esses componentes. s vezes, esses componen-
tes so sistemas propriamente ditos (sistemas COTS commercial off-the-shelf
- sistemas comerciais de prateleira), que podem ser utilizados para proporcionar
funcionalidade especfica, como formatao de textos, clculo numrico, entre
outros (SOMMERVILLE, 2011, p. 23).

Modelos de Processo de Software


46 UNIDADE II

O modelo genrico de processo baseado em reuso mostrado na figura 2


(SOMMERVILLE, 2007, p.46). Note que, embora as etapas de especificao de
requisitos e de validao sejam comparveis com outros processos, as etapas
intermedirias em um processo orientado a reuso so diferentes.
Figura 2: Modelo genrico de processo baseado em reuso

Especificao de Anlise de Modificao de


resquisitos componentes requisitos

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Projeto de sistema Desenvolvimento e Validao de
com reuso integrao sistema

Fonte: adaptado de Sommerville (2007).

Conforme Sommerville (2011, p.23), essas etapas so:


1. Anlise de componentes: considerando a especificao de requisitos, feita
uma busca de componentes para implementar essa especificao. Pode ser
que no sejam encontrados componentes que atendam a toda especificao de
requisitos, ou seja, pode fornecer somente parte da funcionalidade requerida.
2. Modificao de requisitos: no decorrer dessa etapa, os requisitos so
analisados, levando-se em considerao as informaes sobre os com-
ponentes que foram encontrados na etapa anterior. Se for possvel, os
requisitos so, ento, modificados para refletir os componentes dispon-
veis. Quando isso no for possvel, ou seja, quando as modificaes forem
impossveis, a etapa de anlise de componentes dever ser refeita, a fim
de procurar outras solues.

PROCESSOS DE SOFTWARE
47

3. Projeto do sistema com reuso: durante essa etapa, o framework do sis-


tema projetado ou ento alguma infraestrutura existente reutilizada.
Os projetistas levam em considerao os componentes que so reusados
e organizam o framework para tratar desse aspecto. Se os componentes
reusveis no estiverem disponveis, pode ser necessrio que um novo
software deva ser projetado.
4. Desenvolvimento e integrao: nessa etapa, o software que no puder ser
comprado dever ser desenvolvido, e os componentes e sistemas COTS
sero integrados, a fim de criar um novo sistema. A integrao de siste-
mas, nessa abordagem, pode ser parte do processo de desenvolvimento,
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

em vez de uma atividade separada.


Deve-se tomar muito cuidado ao utilizar essa abordagem, pois no se tem como
evitar as alteraes nos requisitos dos usurios e isso pode acabar levando ao
desenvolvimento de um sistema que no atenda as suas reais necessidades. H
tambm o fato de que o controle da evoluo do sistema fique comprometido,
pois as novas verses dos componentes reusveis no esto sob o controle da
organizao que as est utilizando.
De qualquer forma, a abordagem baseada em reuso tem a vantagem de pro-
piciar a entrega mais rpida do software, pois reduz sensivelmente a quantidade
de software que a empresa deve desenvolver, reduzindo, consequentemente, os
custos de desenvolvimento, bem como os seus riscos.

Modelos de Processo de Software


48 UNIDADE II

Modelos de Processos de Engenharia de Software


O artigo de Lessa e Lessa Jr. trata sobre a Engenharia de software e como
surgiram os problemas para corrigir com relao ao desenvolvimento de
projetos de software, a partir desse surgimento modelos de processos e
guia de desenvolvimentos foram criados para otimizao do processo de
desenvolvimento do software. O artigo tambm mostrar alguns modelos
de processos e um guia chamando de SWEBOK, que foi criado por membros
da comunidade cientfica devido ao vasto material que envolve a rea. Vale
a pena a leitura.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Fonte: Lessa e Lessa Jr. (online)2

ATIVIDADES BSICAS DO PROCESSO DE SOFTWARE

Caro(a) aluno(a), estudando os modelos de processo de software apresentados


anteriormente, possvel notar que algumas atividades esto presentes em todos
eles, somente, s vezes, essas atividades esto organizadas de forma diferente,
dependendo do processo de software que est sendo considerado. Sommerville
(2011, p. 24) afirma que no modelo cascata essas atividades so organizadas de
forma sequencial, ao passo que no desenvolvimento incremental so intercala-
das. A forma como essas atividades sero realizadas
depende do tipo de software, das pessoas e da orga-
nizao envolvida.
So quatro as atividades bsicas do processo de
software: a especificao, o projeto e a implemen-
tao, a validao e a evoluo. E a partir de agora,
iremos detalhar, de forma genrica, sem conside-
rar um processo de software em especfico, cada
uma dessas atividades.

shutterstock

PROCESSOS DE SOFTWARE
49

ESPECIFICAO DE SOFTWARE

A especificao de software, ou engenharia de requisitos, a primeira atividade


bsica de um processo de software e tem como objetivo definir quais funes
so requeridas pelo sistema e identificar as restries sobre a operao e o desen-
volvimento desse sistema. Essa atividade muito importante e crtica, pois se a
definio dos requisitos no for bem realizada, com certeza problemas posterio-
res no projeto e na implementao do sistema iro acontecer.
Segundo Sommerville (2011, p.24), o processo de engenharia de requisitos
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

tem como objetivo produzir um documento de requisitos acordados que espe-


cifica um sistema que satisfaz os requisitos dos stakeholders.
O processo de engenharia de requisitos composto por quatro fases, con-
forme descreve Sommerville (2007, p. 50). A unidade seguinte tratar com mais
detalhes sobre esse assunto.
1. Estudo de viabilidade: uma avaliao realizada para verificar se as
necessidades dos usurios, que foram identificadas, podem ser atendi-
das utilizando as atuais tecnologias de software e hardware, disponveis
na empresa. Esse estudo deve indicar se o sistema proposto ser vi-
vel, do ponto de vista comercial, e tambm, se poder ser desenvolvido
considerando restries oramentrias, caso existam. Um estudo de
viabilidade no deve ser caro e demorado, pois a partir do seu resul-
tado que a deciso de prosseguir com uma anlise mais detalhada deve
ser tomada.
2. Levantamento e anlise de requisitos: nesta fase necessrio levantar os
requisitos do sistema pela observao de sistemas j existentes, pela con-
versa com usurios e compradores em potencial, pela anlise de tarefas e
assim por diante. Essa fase pode envolver o desenvolvimento de um ou
mais diferentes modelos e prottipos de sistema. Isso pode ajudar a equipe
de desenvolvimento a compreender melhor o sistema a ser especificado.

Atividades Bsicas do Processo de Software


50 UNIDADE II

3. Especificao de requisitos: a atividade de traduzir as informaes cole-


tadas durante a fase anterior em um documento que defina um conjunto
de requisitos. Tanto os requisitos dos usurios quanto os requisitos de sis-
tema podem ser includos nesse documento. De acordo com Sommerville
(2011, p. 24), os requisitos dos usurios so declaraes abstratas dos
requisitos do sistema tanto para o cliente quanto para os usurios finais
do sistema; os requisitos do sistema so descries mais detalhadas das
funcionalidades a serem fornecidas. Na prxima unidade, trataremos com
mais detalhes sobre requisitos.
4. Validao de requisitos: essa atividade verifica os requisitos quanto sua

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
pertinncia, consistncia e integralidade. Durante o processo de valida-
o, os requisitos que apresentarem problemas devem ser corrigidos, para
que a documentao de requisitos fique correta.

As atividades de anlise, definio e especificao de requisitos so intercaladas,


ou seja, elas no so realizadas seguindo uma sequncia rigorosa, pois, com cer-
teza, novos requisitos surgem ao longo do processo.

PROJETO E IMPLEMENTAO DE SOFTWARE

Segundo Sommerville (2011, p. 25), O estgio de implementao do desenvol-


vimento de software o processo de converso de uma especificao do sistema
em um sistema executvel. Essa etapa sempre envolve processos de projeto e
programao de software, porm, se uma abordagem incremental de desenvolvi-
mento for utilizada, poder tambm envolver o aperfeioamento da especificao
de software, em que os requisitos foram definidos.
Para Pressman (2011, p. 206), o projeto de software cria uma representao
ou modelo do software, fornecendo detalhes sobre a arquitetura do software, as
estruturas de dados, interfaces e componentes fundamentais para implementar
o sistema. O projeto de software aplicado independentemente do modelo de
processo de software que est sendo utilizado, ou seja, se estiver sendo utilizado
o modelo em cascata ou a abordagem incremental.

PROCESSOS DE SOFTWARE
51

O incio do projeto ocorre assim que os requisitos tiverem sido analisados e


modelados, ou seja, assim que a modelagem do sistema tiver sido realizada. Com
base no documento de requisitos, o engenheiro de software, na fase de modelagem
do sistema, dever elaborar os diagramas da UML Unified Modeling Language
(por exemplo, o Diagrama de Caso de Uso e o Diagrama de Classes). Na fase
de projeto do sistema, o engenheiro de software dever: i) definir o Diagrama
Geral do Sistema; ii) elaborar as Interfaces com o Usurio (telas e relatrios) e
iii) desenvolver um conjunto de especificaes de casos de uso, sendo que, essas
especificaes devem conter detalhes suficientes para permitir a codificao.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Geralmente, durante o projeto, o analista de sistemas ter que definir cada com-
ponente do sistema ao nvel de detalhamento que se fizer necessrio para a sua
implementao em uma determinada linguagem de programao.
A programao, normalmente comea como era de se esperar, quando ter-
mina a atividade de projeto. A programao, ou fase de implementao de um
projeto tpico, envolve a escrita de instrues em Java, C++, C# ou em alguma
outra linguagem de programao para implementar o que o analista de sistemas
modelou na etapa de projeto. Sendo uma atividade pessoal, no existe um pro-
cesso geral que seja normalmente seguido durante a programao do sistema.
Alguns programadores comearo com os componentes que eles compreendem
melhor, passando, depois, para os mais complexos. Outros preferem deixar os
componentes mais fceis para o fim, porque sabem como desenvolv-los. Alguns
desenvolvedores gostam de definir os dados no incio do processo e, ento, uti-
lizam esses dados para dirigir o desenvolvimento do programa; outros deixam
os dados sem especificao enquanto for possvel.
De acordo com Sommerville (2011, p. 27), normalmente, os programadores
testam os cdigos fontes que eles mesmos desenvolveram, a fim de descobrir defei-
tos que devem ser removidos. Esse processo chamado de depurao. O teste e a
depurao dos defeitos so processos diferentes. O teste estabelece a existncia de
defeitos, enquanto que a depurao se ocupa em localizar e corrigir esses defeitos.
Em um processo de depurao, os defeitos no cdigo devem ser localizados e o
cdigo precisa ser corrigido, a fim de cumprir os requisitos. A fim de garantir que a
mudana foi realizada corretamente, os testes devero ser repetidos. Portanto, o pro-
cesso de depurao parte tanto do desenvolvimento quanto do teste do software.

Atividades Bsicas do Processo de Software


52 UNIDADE II

VALIDAO DE SOFTWARE

A validao de software dedica-se a


mostrar que um sistema atende tanto
s especificaes relacionadas no
documento de requisitos, quanto s
expectativas dos seus usurios. A prin-
cipal tcnica de validao, segundo
Sommerville (2011, p. 27), o teste de

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
programa, em que o sistema execu-
tado com dados de testes simulados.
shutterstock

Os testes somente podem ser


realizados como uma unidade isolada se o sistema for pequeno. Caso contrrio,
se o sistema for grande e constitudo a partir de subsistemas, que, por sua vez,
so construdos partindo-se de mdulos, o processo de testes deve evoluir em
estgios, ou seja, devem ser realizados de forma incremental, iterativa.
Sommerville (2011, p.27) prope um processo de teste em trs estgios. O pri-
meiro estgio o teste de componente, em seguida, o sistema integrado testado
e, por fim, o sistema testado com dados reais, ou seja, com dados do prprio
cliente. Idealmente, os defeitos de componentes so descobertos no incio do pro-
cesso, e os problemas de interface so encontrados quando o sistema integrado.
Os estgios do processo de testes, conforme Sommerville (2011, p. 27), so:
1. Testes de desenvolvimento: para garantir que os componentes individuais
esto operando corretamente, necessrio test-los, de forma indepen-
dente dos outros componentes do sistema.
2. Testes de sistema: os componentes so integrados para constiturem o
sistema. Esse processo se dedica a encontrar erros que resultem de intera-
es no previstas entre os componentes e de problemas com a interface
do componente. O teste de sistema tambm utilizado para validar que
o sistema atende aos requisitos funcionais e no funcionais definidos no
documento de requisitos.

PROCESSOS DE SOFTWARE
53

3. Teste de aceitao: nesse estgio, o sistema testado com dados reais


fornecidos pelo cliente, podendo mostrar falhas na definio de requi-
sitos, pois os dados reais podem exercitar o sistema de modo diferente
dos dados de teste.

EVOLUO DE SOFTWARE

Depois que um software colocado em funcionamento, ou seja, depois que o


Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

mesmo implantado, com certeza ocorrer mudanas que levaro alterao


desse software. Essas mudanas podem ser, de acordo com Pressman (2011, p.
662), para correo de erros no detectados durante a etapa de validao do sof-
tware, quando h adaptao a um novo ambiente, quando o cliente solicita novas
caractersticas ou funes ou, ainda, quando a aplicao passa por um processo
de reengenharia para proporcionar benefcio em um contexto moderno.
Sommerville (2011, p. 29) coloca que, historicamente, sempre houve uma
fronteira entre o processo de desenvolvimento de software e o processo de evo-
luo desse mesmo software (manuteno de software). O desenvolvimento de
software visto como uma atividade criativa, em que o software desenvolvido
a partir de um conceito inicial at chegar ao sistema em operao. Depois que
esse sistema entrou em operao, inicia-se a manuteno de software, no qual o
mesmo modificado. Normalmente, os custos de manuteno so maiores do
que os custos de desenvolvimento inicial, mas os processos de manuteno so
considerados menos desafiadores do que o desenvolvimento de software origi-
nal, ainda que tenha um custo mais elevado.
Porm, atualmente, os estgios de desenvolvimento e manuteno tm sido
considerados como integrados e contnuos, em vez de dois processos separados.
Tem sido mais realista pensar na engenharia de software como um processo evo-
lucionrio, em que o software sempre mudado ao longo de seu perodo de vida,
em resposta a requisitos em constante modificao e s necessidades do cliente.

Atividades Bsicas do Processo de Software


54 UNIDADE II

CONSIDERAES FINAIS

Chegamos ao final de mais uma unidade. Nesta segunda unidade, voc conheceu o
que um processo de software e tambm alguns modelos de processo de software.
Um processo de software um conjunto de atividades com resultados (arte-
fatos) associados a cada uma delas que leva produo de um software. Todo
software deve ser especificado, projetado, implementado e validado. E, aps o
seu uso pelo usurio, passa por evolues. Todas essas etapas so muito impor-
tantes, mas vimos que a especificao do software uma etapa imprescindvel

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
nesse conjunto, pois, se os requisitos no forem esclarecidos, bem especificados,
no incio do desenvolvimento, h uma grande chance do software no atender
s necessidades do cliente.
Mas, afinal, qual a diferena entre processo de software e modelo de processo
de software? Um processo de software o conjunto de atividades (menciona-
das anteriormente) e um modelo de processo de software uma representao
abstrata de um processo de software, ou seja, define a sequncia em que as ati-
vidades do processo sero realizadas.
Existem vrios modelos de processo de software descritos na literatura,
porm, nesta unidade, vimos somente alguns desses modelos. O primeiro foi
o Modelo em Cascata, que representa as atividades do processo (especificao,
desenvolvimento, validao e evoluo) como fases separadas, onde uma s pode
acontecer depois que a anterior tenha sido concluda. O segundo modelo foi o
Desenvolvimento Incremental, que tem como base a ideia de desenvolver uma
implementao inicial, expor ao comentrio do usurio/cliente e fazer seu apri-
moramento por meio de muitas verses, at que um sistema adequado tenha
sido desenvolvido.
Mas, afinal, qual o melhor modelo de processo de software para uma empresa?
Infelizmente, a resposta para essa pergunta no to simples. No existe um
processo ideal de software e os modelos no so mutuamente exclusivos e na
maioria das vezes, podem ser usados em conjuntos, em especial para o desen-
volvimento de sistemas de grande porte.
Na prxima unidade, vamos conhecer um pouco mais sobre requisitos de software
e entender por que os requisitos so to importantes em um processo de software.

PROCESSOS DE SOFTWARE
55

1. Sabemos que, um processo de software composto por um conjunto de etapas


necessrias para que um software seja produzido. Dentre elas:
I. Modelo Cascata: considera as atividades de especificao, desenvolvimento,
validao e evoluo, que so fundamentais ao processo.
II. Desenvolvimento Incremental: esse modelo intercala as atividades de especi-
ficao, desenvolvimento e validao.
III. Engenharia de software orientada a reuso: esse modelo parte do princpio de
que NO existem componentes que podem ser reutilizveis.
Assinale a alternativa correta:
a. Apenas a alternativa II est correta.
b. Apenas a alternativa III est correta.
c. Apenas as alternativas I e II esto corretas.
d. Apenas as alternativa I e III esto corretas.
e. Apenas as alternativas II e III esto corretas.
2. Para que um software seja produzido, necessrio concluir diversas etapas.
Essas etapas podem envolver o desenvolvimento de software a partir do zero.
Sendo assim, quais so as atividades fundamentais para a engenharia de softwa-
re, segundo Sommerville.
a. Especificao, projeto e implementao, validao e evoluo.
b. Projeto, implementao e validao.
c. Validao, evoluo e projeto.
d. Integrao, anlise, projeto, evoluo.
e. Anlise, implementao, validao e evoluo
56

3. Sabemos que o modelo cascata possui uma abordagem sequencial e sistemti-


ca para o desenvolvimento de software. Alguns estgios so fundamentais para
o desenvolvimento, sendo assim, assinale a alternativa incorreta:
a. Anlise e definio de requisitos: as funes, as restries e os objetivos do
sistema so estabelecidos por meio da consulta aos usurios do sistema.
b. Processo de sistemas e de software: o processo de projeto de sistemas no
agrupa os requisitos em sistemas de hardware ou de software.
c. Implementao e teste de unidades: o teste de unidades envolve verificar que
cada unidade atenda sua especificao.
d. Integrao e teste de sistema: so integrados e testados como um sistema
completo a fim de garantir que os requisitos de software foram atendidos.
e. Operao e manuteno: a manuteno envolve corrigir erros que no foram
descobertos em estgios anteriores do ciclo de vida.
57

PGDS - PROCESSO DE GERENCIAMENTO E DESENVOLVIMENTO DE SISTEMAS


DATASUS
Em busca de direcionamento e padronizao dos seus processos e da melhoria contnua
da qualidade dos produtos e servios de tecnologia da informao, o DATASUS elabo-
rou suas metodologias de desenvolvimento de software - PDS e de gerenciamento de
projetos - EGP. Essas metodologias evoluram, acompanhando o desenvolvimento tec-
nolgico e as prticas de sucesso dos projetos realizados. Em 2010, com a implantao
da Unidade de Apoio a Programas e Projetos (UAPP), o PDS e a EGP foram unificados em
uma metodologia, agora denominada Processo de Gerenciamento e Desenvolvimento
de Sistemas - PGDS.
Ela foi criada para auxiliar o DATASUS na elaborao, planejamento, execuo, controle,
monitoramento e encerramento de seus projetos, por meio das melhores prticas de
gerenciamento disponveis no mercado e as j adotadas pelo DATASUS.

Iniciao Planejamento Execuo Encerramento

Monitoramento e Controle
Fases do PGDS

O PGDS foi criado para auxiliar o DATASUS/SE no planejamento, execuo, controle, mo-
nitoramento e encerramento de seus projetos. Serve como um guia para Gestores, Co-
ordenadores, Lderes e equipes de projetos, equipe da UAPP e qualquer outro envolvido
nos projetos.
O PGDS estruturado com base em 4 elementos bsicos, que representam quem faz o
qu, como e quando:
Papis (quem) - Um papel define o comportamento e responsabilidades de um profis-
sional ou grupo de profissionais que participam do desenvolvimento do projeto. O com-
portamento representado por meio das atividades que cada papel deve desempenhar
ao longo do projeto. As responsabilidades normalmente esto associadas aos artefatos
que cada papel deve produzir e manter ao longo das atividades que realiza. Na prtica,
um mesmo papel pode ser desempenhado por mais de uma pessoa, assim como uma
mesma pessoa pode assumir vrios papis ao longo do projeto.
58

Artefatos (o qu) - Em sentido amplo, o termo artefato representa um produto con-


creto produzido, modificado ou utilizado pelas atividades de um processo. O PGDS
no inclui todos os artefatos de um projeto de desenvolvimento, mas todos os artefa-
tos obrigatrios descritos no PGDS devem ser elaborados ao longo do projeto. O PGDS
disponibiliza modelos (templates) para a maioria de seus artefatos, com o objetivo de
orientar e facilitar a sua elaborao.
Atividades (como) - Uma atividade no PGDS representa um conjunto de passos e ta-
refas que um profissional, que desempenha o papel responsvel por aquela atividade,
deve executar para gerar algum resultado. As atividades envolvem a produo e modi-
ficao de artefatos do projeto.
Fases (quando) - As fases do PGDS apresentam a sequncia e a dependncia entre as
atividades do projeto ao longo do tempo. As atividades no fluxo so divididas em fases
do ciclo de vida do projeto e nos papis responsveis pela execuo de cada uma.
Fonte: PGDS (online)3
MATERIAL COMPLEMENTAR

Nesta edio do Faz o Qu?, voc confere a graduao em Engenharia de Software. Adriana
Silveira engenheira de software. Ela explica a atuao do profissional. O tambm engenheiro de
software Thiago Oliveira fala um pouco sobre a atuao dele no mercado de trabalho.
<https://www.youtube.com/watch?v=BfzrAIHGbDU>.

Engenharia de Software - Anlise e Projeto de Sistemas


Srgio Luiz Tonsig
Editora: Moderna
Sinopse: indicado para quem deseja aprender sobre o planejamento,
anlise e projeto de software para sistemas de informao. Este livro
ensina passo a passo todas as etapas envolvidas no planejamento,
anlise e projeto de softwares, com demonstraes prticas dos
conceitos apresentados. O livro relata com clareza as circunstncias
atuais do desenvolvimento de software no ambiente empresarial, a
preocupao do alinhamento dos recursos da tecnologia da informao
com as necessidades do negcio da empresa e como esta relao pode
atrapalhar ou ajudar na construo de softwares.

Material Complementar
REFERNCIAS

LESSA, R. O; LESSA JR. E. O. Modelos de Processos de Engenharia de Software.


[artigo Online]. Disponvel em: <http://xps-project.googlecode.com/svnistory/r43/
trunk/outros/02_Artigo.pdf> Acesso em: 26 mar. de 2016.
PGDS. Processo de gerenciamento e desenvolvimento de sistemas (online). Dis-
ponvel em: <http://189.28.128.113/pgds/>. Acesso em: 05 mar. 2016
PRESSMAN, R. Engenharia de Software. 7.ed. Porto Alegre: AMGH, 2011.
SOMMERVILLE, I. Engenharia de Software. So Paulo: Pearson Addison-Wesley,
2007.
______. Engenharia de Software. So Paulo: Pearson Prentice Hall, 2011.
61
GABARITO

1. C
2. A
3. B
Professora Me. Mrcia Cristina Dadalto Pascutti

III
UNIDADE
REQUISITOS DE SOFTWARE

Objetivos de Aprendizagem
Entender os diversos tipos de requisitos relacionados ao
desenvolvimento de software.
Expor a importncia do documento de requisitos.
Compreender o processo de engenharia de requisitos.

Plano de Estudo
A seguir, apresentam-se os tpicos que voc estudar nesta unidade:
Tipos de Requisitos de Software
Documento de Requisitos
Engenharia de Requisitos
65

INTRODUO

Caro(a) aluno(a), na segunda unidade voc aprendeu os conceitos relacionados


a processo de software e viu que um processo composto de quatro atividades
fundamentais: especificao de software, projeto e implementao de software,
validao de software e, finalmente, evoluo de software.
Esta unidade vai tratar especificamente sobre requisitos de software e, no
final desta unidade voc vai compreender por que os requisitos so importan-
tes e devem ser muito bem definidos para que o software desenvolvido alcance
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

seus objetivos.
Uma das tarefas mais difceis que os desenvolvedores de software enfrentam
entender os requisitos de um problema. Os requisitos definiro o que o sistema
deve fazer, suas propriedades emergentes desejveis e essenciais e as restries
quanto operao do sistema. Essa definio de requisitos somente possvel com
a comunicao entre os clientes e os usurios e os desenvolvedores de software.
Nesta unidade, voc aprender a diferena entre os vrios tipos de requi-
sitos e trataremos, principalmente, dos requisitos funcionais e no funcionais.
Os requisitos funcionais representam as descries das diversas funes que
clientes e usurios querem ou precisam que o software oferea. Um exemplo
de requisito funcional o sistema deve possibilitar o cadastramento dos dados
pessoais dos pacientes. J, os requisitos no funcionais, declaram as restries
ou atributos de qualidade para um software, como, preciso, manutenibilidade,
usabilidade, entre outros.
Tambm estudaremos, nesta unidade, sobre os requisitos de qualidade que
so definidos pela Norma ISO/IEC 9126 e que tambm devem ser considerados
quando um software est sendo projetado.
E, por fim, veremos que a engenharia de requisitos um processo que envolve
quatro atividades genricas: avaliar se o sistema que est sendo projetado ser til
para a empresa (estudo de viabilidade), obter e analisar os requisitos (levanta-
mento e anlise), especificar esses requisitos, convertendo-os em um documento
de requisitos (especificao de requisitos) e, finalmente, verificar se os requisitos
realmente definem o sistema que o cliente deseja (validao).

Introduo
66 UNIDADE III

REQUISITOS DE SOFTWARE

Normalmente, os problemas que os desenvolvedores de software tm para solucio-


nar so, muitas vezes, imensamente complexos e se o sistema for novo, entender
a natureza desses problemas pode ser muito
mais difcil ainda. As descries das fun-
es e das restries so os requisitos para o
sistema; e o processo de descobrir, analisar,
documentar e verificar essas funes e restri-

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
es chamado de engenharia de requisitos.
De acordo com Sommerville (2011, p.
57), a indstria de software no utiliza o
termo requisito de modo consistente. Muitas
shutterstock
vezes, o requisito visto como uma declara-
o abstrata em alto nvel, de uma funo que
o sistema deve fornecer ou de uma restrio do sistema. Em outras vezes, ele
uma definio detalhada e formal, de uma funo do sistema.
Alguns dos problemas que surgem durante a especificao de requisitos so
as falhas em no fazer uma separao clara entre os diferentes nveis de descrio
dos requisitos. Por isso, Sommerville (2011, p. 57) prope uma distino entre
eles por meio do uso do termo requisitos de usurio, para expressar os requi-
sitos abstratos de alto nvel, e requisitos de sistema, para expressar a descrio
detalhada que o sistema deve fazer. Dessa forma, os requisitos de usurio devero
fornecer, em forma de declaraes, quais servios o sistema dever oferecer e as
restries com as quais o sistema deve operar. J os requisitos de sistema so des-
cries mais detalhadas das funes, servios e restries operacionais do sistema.
Caro(a) aluno(a), se sua empresa deseja estabelecer um contrato para o
desenvolvimento de um grande sistema, ela deve definir todas as necessidades/
requisitos de maneira suficientemente abstrata para que uma soluo no seja
pr-definida, ou seja, essas necessidades devem ser redigidas de modo que os
diversos fornecedores possam apresentar propostas, oferecendo, talvez, diferen-
tes maneiras de atender s necessidades organizacionais da sua empresa. Uma
vez estabelecido um contrato, o fornecedor precisa preparar uma definio de

REQUISITOS DE SOFTWARE
67

sistema para o cliente, com mais detalhes, de modo que o cliente compreenda e
possa validar o que o software far. Esses dois documentos podem ser chamados
de documentos de requisitos do sistema. Veremos mais adiante o documento de
requisitos com mais detalhes.
E o que pode acontecer se os requisitos no forem definidos corretamente,
se ficarem errados? Se isso acontecer, o sistema pode no ser entregue no prazo
combinado e com o custo acima do esperado no incio do projeto; o usurio final
e o cliente no ficaro satisfeitos com o sistema e isso pode at implicar em seu
descarte. Portanto, o ideal que essa etapa seja muito bem elaborada.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

A parte mais difcil ao construir um sistema de software decidir o que


construir. Nenhuma parte do trabalho afeta tanto o sistema resultante se for
feita a coisa errada. Nenhuma outra parte mais difcil de consertar depois.
(Fred Brooks, Engenheiro de Software.)

REQUISITOS FUNCIONAIS E NO FUNCIONAIS

Primeiramente, vamos definir o que requisito, independentemente da rea de


informtica. Um requisito a condio imprescindvel para a aquisio ou pre-
enchimento de determinado objetivo. Na abordagem da engenharia de software,
segundo Sommerville (2011, p. 57), os requisitos de um sistema so as descri-
es do que o sistema deve fazer, os servios que oferece e as restries a seu
funcionamento. Esses requisitos dizem respeito s necessidades dos usurios
para um sistema que deve atender um determinado objetivo, como, cadastrar
um pedido de venda ou emitir um relatrio. A engenharia de requisitos um
processo que engloba as atividades que so necessrias para criar e manter um
documento de requisitos de sistema. Essas atividades so: estudo de viabilidade,
levantamento e anlise de requisitos, especificao de requisitos e, finalmente, a
validao desses requisitos.

Requisitos de Software
68 UNIDADE III

De acordo com Sommerville (2011, p. 59), os requisitos de software so, nor-


malmente, classificados como funcionais ou no funcionais:
1. Requisitos funcionais: definem as funes que o sistema deve forne-
cer, de como o sistema deve reagir a entradas especficas e de como deve
se comportar em determinadas situaes. Em alguns casos, os requisitos
funcionais podem tambm explicitamente declarar o que o sistema no
deve fazer. Exemplos de requisitos funcionais: o software deve possibili-
tar o clculo das comisses dos vendedores de acordo com os produtos
vendidos; o software deve emitir relatrios de compras e vendas por per-
odo; o sistema deve mostrar, para cada aluno, as disciplinas em que foi

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
aprovado ou reprovado.
2. Requisitos no funcionais: so os requisitos relacionados utilizao do
software em termos de desempenho, confiabilidade, segurana, usabili-
dade e portabilidade entre outros. Exemplos de requisitos no funcionais:
o sistema deve ser protegido para acesso apenas de usurios autorizados; o
tempo de resposta do sistema no deve ultrapassar 20 segundos; o tempo
de desenvolvimento no deve ultrapassar doze meses.

Contudo, a diferenciao entre esses dois tipos de requisitos no to clara como


sugerem as definies acima. Um requisito referente proteo pode parecer ser
um requisito no funcional. Porm, quando desenvolvido com mais detalhes,
pode levar a outros requisitos que so cla-
ramente funcionais, como a necessidade de
incluir recursos de autorizao de usurios
no sistema (SOMMERVILLE, 2011, p. 59).
Portanto, embora seja interessante separar
os requisitos em funcionais e no funcionais,
devemos lembrar que essa , na verdade, uma
distino artificial. O que muito importante
que os requisitos, sejam eles funcionais ou
no funcionais, sejam claramente definidos.
shutterstock

REQUISITOS DE SOFTWARE
69

Requisitos funcionais

Os requisitos funcionais devem descrever detalhadamente os servios e a funcio-


nalidade que devem ser fornecidas pelo sistema, indicando suas entradas e sadas,
excees etc. Esses requisitos podem ser expressos de diversas maneiras, com dife-
rentes nveis de detalhes. A impreciso na especificao de requisitos uma das
causas de muitos problemas da engenharia de software (SOMMERVILLE, 2011,
p. 60). Pode acontecer que um desenvolvedor de sistemas interprete um requisito
ambguo para simplificar sua implementao, porm, nem sempre isso o que
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

o cliente quer. E quando isso acontece, pode ser que novos requisitos devam ser
estabelecidos, sendo necessrio realizar mudanas no sistema, podendo atrasar
a entrega final do sistema e, consequente, gerar aumento de custos.
De acordo com Sommerville (2011, p. 60), em princpio, a especificao de
requisitos funcionais de um sistema deve ser completa e consistente. A comple-
teza denota que todas as funes requeridas pelo usurio devem estar definidas
e a consistncia denota que os requisitos no devem ter definies contradit-
rias. Na prtica, para grandes sistemas, atingir a consistncia e a completeza dos
requisitos bastante difcil, por causa da complexidade inerente ao sistema e, em
parte, porque diferentes pontos de vista apresentam necessidades inconsistentes.

Requisitos no funcionais

Os requisitos no funcionais so aqueles que no dizem respeito diretamente


s funes especficas oferecidas pelo sistema. Eles podem estar relacionados a
propriedades, como confiabilidade, tempo de resposta e espao em disco. Como
alternativa, eles podem definir restries para o sistema, como a capacidade dos
dispositivos de E/S (entrada/sada) e as representaes de dados utilizadas nas
interfaces de sistema (SOMMERVILLE, 2011, p. 60).
Os requisitos no funcionais surgem conforme a necessidade dos usurios, em
razo de restries de oramento, de polticas organizacionais, pela necessidade de
interoperabilidade com outros sistemas de software ou hardware ou devido a fato-
res externos, por exemplo, regulamentos de segurana e legislao sobre privacidade.

Requisitos de Software
70 UNIDADE III

Sommerville (2011, p.61) faz uma classificao dos requisitos no funcio-


nais em requisitos de produto, requisitos organizacionais e requisitos externos.
Os requisitos de produto so aqueles que especificam o comportamento do pro-
duto, podendo ser subdivididos em requisitos de usabilidade, de eficincia, de
confiana e de proteo. Os requisitos organizacionais so aqueles derivados
das polticas e procedimentos da organizao do cliente e do desenvolvedor e
so subdivididos em requisitos ambientais, operacionais e de desenvolvimento.
Finalmente, os requisitos externos abrangem todos os requisitos que procedem
de fatores externos ao sistema e seu processo de desenvolvimento e so subdi-

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
vididos em requisitos reguladores, ticos e legais.
Os requisitos funcionais e no funcionais deveriam ser diferenciados em um
documento de requisitos, porm, na prtica, no fcil fazer essa distino. Em
nossos documentos de requisitos, nos preocuparemos mais com os requisitos fun-
cionais do sistema. Se os requisitos no funcionais forem definidos separadamente
dos requisitos funcionais, pode ser difcil enxergar a relao existente entre eles. Se
eles forem definidos com os requisitos funcionais, poder ser difcil separar conside-
raes funcionais e no funcionais e identificar os requisitos que correspondem ao
sistema como um todo. preciso encontrar um equilbrio adequado e isso depende
do tipo de sistema que est sendo modelado. Contudo, requisitos claramente relacio-
nados s propriedades emergentes do sistema devem ser explicitamente destacados.
Isso pode ser feito colocando-os em uma seo separada do documento de requi-
sitos ou diferenciando-os, de alguma maneira, dos outros requisitos de sistema.

REQUISITOS DE USURIO

De acordo com Sommerville (2011), os requisitos de usurios para um sistema


devem descrever os requisitos funcionais e no funcionais de forma que usu-
rios do sistema que no tenham conhecimentos tcnicos detalhados consigam
entender. Eles devem especificar somente o comportamento externo do sistema,
evitando sempre que possvel as caractersticas do projeto de sistema. Portanto,
no devem ser definidos utilizando um modelo de implementao, e sim, escri-
tos com o uso de linguagem natural, formulrios e diagramas intuitivos simples.

REQUISITOS DE SOFTWARE
71

REQUISITOS DE SISTEMA

Os requisitos de sistema so descries mais detalhadas dos requisitos do usu-


rio, servindo como base para um contrato destinado implementao do sistema
e, portanto, devem ser uma especificao completa e consistente de todo o sis-
tema (SOMMERVILLE, 2011, p. 87). Eles so utilizados pelos engenheiros de
software como ponto de partida para o projeto de sistema.
Antes de qualquer coisa, os requisitos de sistema deveriam definir o que
o sistema deveria fazer, e no como ele teria de ser implementado, porm, no
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

que se refere aos detalhes exigidos para especificar o sistema completamente,


quase impossvel excluir todas as informaes de projeto. H, pelo menos, duas
razes para isso:
1. Uma arquitetura inicial do sistema pode ser definida para ajudar a estru-
turar a especificao de requisitos.
2. Na maioria dos casos, os sistemas devem interoperar com outros sis-
temas existentes, restringindo assim o projeto em desenvolvimento,
sendo que, muitas vezes, essas restries geram requisitos para o novo
sistema.

De acordo com Sommerville (2011), os requisitos devem ser escritos em


nveis diferentes de detalhamento para que diferentes leitores possam us-los
de formas diferentes. Os possveis leitores para os requisitos de usurio so:
os gerentes clientes, os usurios finais do sistema, os engenheiros clientes,
os gerentes contratantes e os arquitetos de software. Esses leitores no tm
a preocupao com a forma como o sistema ser implementado. J para os
requisitos de sistema, podem haver os seguintes leitores: os usurios finais
do sistema, os engenheiros clientes, os arquitetos de sistema e os desenvol-
vedores de software. Esses leitores precisam saber com mais detalhes o que
o sistema far, principalmente os desenvolvedores que estaro envolvidos
no projeto e na implementao do sistema.

Requisitos de Software
72 UNIDADE III

As sementes das principais catstrofes de software so normalmente seme-


adas nos trs primeiros meses do projeto de software
(Caper Jones, Especialista em Engenharia de Software.)

O DOCUMENTO DE REQUISITOS DE SOFTWARE

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
O documento de requisitos de software ou especificao de requisitos de sof-
tware a declarao oficial do que exigido dos desenvolvedores de sistema.
Ele deve incluir os requisitos de usurios para um sistema e uma especificao
detalhada dos requisitos de sistema. Em alguns casos, os requisitos de usu-
rio e de sistema podem ser integrados em uma nica descrio. Em outros
casos, os requisitos de usurio so definidos em uma introduo especifi-
cao dos requisitos de sistema. Se houver um grande nmero de requisitos,
os requisitos detalhados de sistema podero ser apresentados como docu-
mentos separados.
O documento de requisitos serve como um termo de consenso entre a equipe
tcnica (desenvolvedores) e o cliente e constitui a base para as atividades sub-
sequentes do desenvolvimento do sistema, fornecendo um ponto de referncia
para qualquer validao futura do software construdo. Alm disso, o documento
de requisitos estabelece o escopo (o que faz parte e o que no faz parte) do sis-
tema, abrangendo um conjunto diversificado de usurios, que vai desde a alta
gerncia da organizao, que est pagando pelo sistema, at os engenheiros res-
ponsveis pelo desenvolvimento do software.
A tabela 1 mostra uma possvel organizao de um documento de
requisitos definido por Sommerville (2011, p. 64), baseada em uma norma
IEEE (Institute of Electrical and Electronics Engineers) para documentos de
requisitos.

REQUISITOS DE SOFTWARE
73

Tabela 1 A estrutura de um documento de requisitos

CAPTULO DESCRIO
Deve definir os possveis leitores do documento e descrever seu histrico
Prefcio de verses, incluindo uma justificativa para a criao de uma nova verso
e um resumo das mudanas feitas em cada verso.
Deve descrever a necessidade para o sistema. Deve descrever brevemen-
te as funes do sistema e explicar como ele vai funcionar com outros
Introduo sistemas. Tambm deve descrever como o sistema atende aos objetivos
globais de negcio ou estratgicos da organizao que encomendou o
software.
Deve definir os termos tcnicos usados no documento. Voc no deve
Glossrio
fazer suposies sobre a experincia ou o conhecimento do leitor.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Deve descrever os servios fornecidos ao usurio. Os requisitos no


Definio de funcionais de sistema tambm devem ser descritos nessa seo. Essa
requisitos de descrio pode usar a linguagem natural, diagramas ou outras notaes
usurio compreensveis para os clientes. Normas de produto e processos a serem
seguidos devem ser especificados.
Deve apresentar uma viso geral em alto nvel da arquitetura do sis-
Arquitetura tema previsto, mostrando a distribuio de funes entre os mdulos
do sistema do sistema. Componentes de arquitetura que so reusados devem ser
destacados.
Especificao Deve descrever em detalhes os requisitos funcionais e no funcionais. Se
de requisitos necessrio, tambm podem ser adicionados mais detalhes aos requisitos
do sistema no funcionais. Interfaces com outros sistemas podem ser definidas.
Pode incluir modelos grficos do sistema que mostram os relacionamen-
Modelos do tos entre os componentes do sistema, o sistema e seu ambiente. Exem-
sistema plos de possveis modelos so modelos de objetos, modelos de fluxo de
dados ou modelo semnticos de dados.
Deve descrever os pressupostos fundamentais em que o sistema se
baseia, bem como quaisquer mudanas previstas, em decorrncia da
Evoluo do
evoluo do hardware, de mudanas nas necessidades do usurio etc.
sistema
Essa seo til para projetistas de sistema, pois pode ajud-los a evitar
decises capazes de restringir possveis mudanas futuras no sistema.
Deve fornecer informaes detalhadas e especficas relacionadas apli-
cao em desenvolvimento, alm de descries de hardware e banco de
dados, por exemplo. Os requisitos de hardware definem as configuraes
Apndices
mnimas ideais para o sistema. Requisitos de banco de dados definem a
organizao lgica dos dados usados pelo sistema e os relacionamentos
entre esses dados.
Vrios ndices podem ser includos no documento. Pode haver, alm de
ndice um ndice alfabtico normal, um ndice de diagramas, de funes, entre
outros pertinentes.
Fonte: Sommerville (2011, p.64).
O Documento de Requisitos de Software
74 UNIDADE III

Para o desenvolvimento da nossa disciplina, usarei modelos de documento de


requisitos mais simplificados do que o apresentado na tabela acima. O documento
de requisitos trar detalhes de como o sistema funciona atualmente e quais fun-
cionalidades o usurio deseja para o novo sistema. Abaixo segue um modelo de
documento de requisitos para uma locadora de filmes. Lembre-se que deve ser
a partir do documento de requisitos que faremos a modelagem do sistema, que
ser detalhada na prxima unidade.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
EXEMPLO DE DOCUMENTO DE REQUISITOS LOCADORA DE
FILMES

Uma determinada locadora possui muitos ttulos em seu acervo e no conse-


gue controlar de maneira eficiente as locaes, devolues e reservas dos filmes.
Portanto, ela deseja ter um sistema informatizado que controle todas as locaes,
devolues e reservas de maneira eficiente, para aperfeioar o seu atendimento
com o cliente e seu controle interno.
Atualmente, a locadora possui uma ficha para o cadastro de clientes com os seguin-
tes dados: nome do cliente, fone residencial, fone celular, sexo, RG, CPF, endereo
completo, data de nascimento, estado civil e nomes de cinco dependentes e o grau de
parentesco de cada dependente (o dependente pode locar filmes em nome do cliente).
O sistema informatizado deve:
1. Manter o cadastro de filmes: neste cadastro dever conter os seguintes
dados: nome do filme, durao, sinopse, classificao, gnero, diretor,
elenco. Para cada cpia do filme, necessrio saber o fornecedor, a data
da compra, o valor pago e o tipo (VHS ou DVD).
2. Controlar locaes:
A locao feita mediante a verificao de cadastro do cliente. Se o cliente
for cadastrado ento se efetua a locao, se no, feito o cadastro do cliente.
Caso a locao seja efetuada pelo dependente do cliente, necessrio dei-
xar registrado qual o dependente e qual o cliente.

REQUISITOS DE SOFTWARE
75

verificado se o filme est disponvel e se o cliente possui pendncias


financeiras ou atraso de devoluo, caso uma das alternativas seja afir-
mativa bloqueia-se a operao, sendo liberada somente aps a devida
regularizao.
Emitir comprovante de locao com a data prevista para devoluo
de cada filme, discriminao dos filmes e se o pagamento foi ou no
efetuado.
A data prevista para devoluo deve ser calculada desconsiderando domin-
gos e feriados. Cada categoria pode ter um prazo diferente para que o
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

cliente possa ficar com o filme. Por exemplo: a categoria LANAMENTO


permite que o cliente fique com o filme por 2 dias.
3. Controlar devolues:
Verificar se a devoluo est no prazo correto e se o pagamento foi efe-
tuado; caso o prazo esteja vencido calcular a multa incidente. Efetuado o
pagamento, emite-se o recibo de devoluo.
No esquecer que no pode ser cobrada multa caso seja domingo ou
feriado.
4. Controlar reservas:
Verificar se o cliente j est cadastrado, caso contrrio o sistema permite
o cadastro do cliente no momento da reserva. Tambm verificado se o
filme desejado est disponvel para reserva.
Reservar somente para clientes sem pendncias financeiras e devolu-
es vencidas.
5. Consultar Filmes Locados por Cliente: o sistema deve ter uma con-
sulta em que seja informado um determinado cliente e sejam mostrados
todos os filmes j locados por esse cliente e mostre, tambm, a data em
que cada filme foi locado.
6. Consultar Reservas por Filme: o sistema deve ter uma consulta em que
seja informado um determinado filme e sejam mostradas todas as reser-
vas efetuadas para aquele filme, no perodo informado.

O Documento de Requisitos de Software


76 UNIDADE III

7. Emitir os seguintes relatrios:


Relatrio Geral de Clientes, em que conste o cdigo, nome, endereo,
telefone e dependentes do cliente.
Etiquetas com cdigos de barras para a identificao das cpias no pro-
cesso de locao e devoluo.
Relatrio de filmes por gnero, em que conste o cdigo do filme, o nome
do filme, o nome do diretor do filme, os nomes dos atores do filme, o
total de cpias, o total de cpias locadas e o total de cpias disponveis.
O relatrio deve ser agrupado por gnero, mostrando tambm o cdigo

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
e a descrio do gnero.
Relatrio de filmes locados por cliente por perodo. Para cada cliente,
devem ser emitidas todas as cpias que esto locadas para ele. Deve sair
no relatrio: o cdigo e o nome do cliente, o cdigo do filme, o nome do
filme, o cdigo da cpia (exemplar), a data de locao e o valor da loca-
o. O relatrio deve ser agrupado por cliente e devem sair somente as
cpias locadas e no devolvidas.
Relatrio de cpias no devolvidas, em que conste o cdigo do filme, o
nome do filme, o cdigo da fita, o nome do cliente, o telefone do cliente,
a data de locao, a data prevista para devoluo e o nmero de dias em
atraso.
Relatrio dos filmes mais locados, em que conste o cdigo do filme, o
nome do filme, a descrio do gnero e o nmero total de locaes. O
relatrio deve ser agrupado por ms/ano, ou seja, para um determinado
ms/ano, devem ser emitidos os 10 (dez) filmes mais locados.
Relatrio de Reservas por perodo, em que conste o cdigo do cliente,
o nome do cliente, o telefone do cliente, o cdigo do filme reservado, o
nome do filme, a data em que foi feita a reserva (data em que o cliente
telefonou para a locadora dizendo que queria fazer a reserva).

REQUISITOS DE SOFTWARE
77

Relatrio dos valores das locaes mensais. Dever mostrar os valores


das locaes de determinado ms, separado por data e somatria de valo-
res de cada dia, somando-se assim ao final, uma totalidade de locaes.
Nele deve-se conter a data e a soma das locaes desta data.

Todos os relatrios serviro para o processo de tomadas de decises nos


quais os Administradores podero obter informaes sobre o andamento
da locadora.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

REQUISITOS DE QUALIDADE

Quanto mais rgidos os requisitos de qualidade e mais complexo o software a ser


desenvolvido, aumenta-se a necessidade de se aplicar teorias e ferramentas que
garantam que esses requisitos sejam satisfeitos. A Norma ISO (The International
Organization for Standardization) / IEC (The International Electrotechnical
Commission ) 9126 define seis caractersticas de qualidade de software que
devem ser avaliadas:
Funcionalidade: a capacidade de um software fornecer funcionalidades
que atendam s necessidades explcitas e implcitas dos usurios, dentro
de um determinado contexto de uso.
Usabilidade: conjunto de atributos que evidenciam o esforo necessrio
para a utilizao do software.
Confiabilidade: indica a capacidade do software em manter seu nvel de
desempenho sob determinadas condies durante um perodo de tempo
estabelecido.
Eficincia: indica que o tempo de execuo e os recursos envolvidos so
compatveis com o nvel de desempenho do software.

O Documento de Requisitos de Software


78 UNIDADE III

Manutenibilidade: conjunto de atributos que evidenciam o esforo neces-


srio para fazer modificaes especificadas no software, incluindo tanto
as melhorias/ extenses de funcionalidades quanto correes de defei-
tos, falhas ou erros.
Portabilidade: indica a capacidade do software de ser transferido de um
ambiente para outro.

A ISO1 e a IEC2 formam o sistema especializado para padronizao mais conhe-


cido no mundo.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
ENGENHARIA DE REQUISITOS

Como foi dito na unidade anterior, a engenharia de requisitos um processo


que envolve todas as atividades necessrias para a criao e manuteno de um
documento de requisitos de software. Existem quatro atividades genricas de
processo de engenharia de requisitos que so de alto nvel: (i) o estudo de viabi-
lidade do sistema, (ii) o levantamento e anlise de requisitos, (iii) a especificao
de requisitos e sua documentao e, finalmente, (iv) a validao desses requisitos.
A seguir abordaremos todas as atividades, com exceo da especificao de requi-
sitos, que j foi discutida nesta unidade. A figura seguinte ilustra a relao entre
essas atividades e mostra tambm os documentos produzidos em cada estgio do
processo de engenharia de requisitos, de acordo com Sommerville (2011, p. 24).

1
Voc pode obter mais informaes por meio do endereo <http://www.iso.org/iso/iso_catalogue/
catalogue_tc/catalogue_detail.htm?csnumber=22749>.
2
Existe tambm adequao dessa norma para o Brasil a NBR ISO/IEC 9126-1. Verifique no endereo
<http://www.abnt.org.br/>.

REQUISITOS DE SOFTWARE
79

Figura 3 Processo de Engenharia de Requisitos

Estudo de Levantamento
Viabilidade e anlise de
requisitos Especificao de
requisitos
Validao de
Relatrio de requisitos
viabilidade
Modelos de
sistema
Requisitos de
usurio e de
sistema
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Documento de
requisitos

Fonte: Somerville (2011, p. 24).

As atividades de engenharia de requisitos, mostradas na figura 3, dizem res-


peito ao levantamento, documentao e verificao dos requisitos. Porm,
necessrio deixar claro que, em praticamente em todos os sistemas, os requisi-
tos se modificam; as pessoas interessadas desenvolvem melhor compreenso do
que elas querem que o software faa; a organizao compradora do sistema sofre
modificaes; e so feitas alteraes no hardware, no software e no ambiente
organizacional do sistema (SOMMERVILLE, 2011, p. 95).

Requisito no sinnimo de arquitetura. Requisito no sinnimo de pro-


jeto nem de interface do usurio. Requisito sinnimo de necessidade.
(Andrew Hunt e David Thomas)

Engenharia de Requisitos
80 UNIDADE III

ESTUDO DE VIABILIDADE

Segundo Sommerville (2011), para todos os sistemas novos, o processo de enge-


nharia de requisitos de sistemas deve se iniciar com um estudo de viabilidade ou
licitao de requisitos. Tal estudo principia com uma descrio geral do sistema
e de como ele ser utilizado dentro de uma organizao, sendo que o resultado
desse estudo deve ser um relatrio que recomenda a viabilidade, ou no, do pro-
cesso de realizao do processo de engenharia de requisitos e, consequentemente,
do processo de desenvolvimento de sistemas.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Um estudo de viabilidade um estudo rpido, direcionado, que se destina
a responder a algumas perguntas:
1. O sistema contribui para os objetivos gerais da organizao?
2. O sistema pode ser implementado com a utilizao de tecnologia atual
dentro das restries de custo e de prazo?
3. O sistema pode ser integrado com outros sistemas j em operao?
A questo sobre se o sistema contribui ou no para os objetivos da empresa fun-
damental, pois se um sistema no for compatvel com esses objetivos, ele no ter
nenhum valor real. Embora isso possa parecer bvio, muitas organizaes desen-
volvem sistemas que no contribuem para seus objetivos, seja porque no existe
uma declarao clara desses objetivos ou porque outros fatores polticos ou orga-
nizacionais influenciam na aquisio do sistema (SOMMERVILLE, 2007, p. 97).
Preparar um estudo de viabilidade envolve avaliar e coletar informaes e
redigir relatrios. A fase de avaliao identifica as informaes exigidas para res-
ponder s trs perguntas apresentadas anteriormente. Uma vez identificadas as
informaes, preciso questionar as fontes de informao, a fim de encontrar
as respostas para essas perguntas. Eis alguns exemplos das possveis perguntas
que devem ser feitas:

REQUISITOS DE SOFTWARE
81

1. Como a organizao se comportaria se esse sistema no fosse implementado?


2. Quais so os problemas com os processos atuais e como um novo sistema
ajudaria a diminuir esses problemas?
3. Que contribuio direta o sistema trar para os objetivos da empresa?
4. As informaes podem ser transferidas para outros sistemas organiza-
cionais e tambm podem ser recebidas a partir deles?
5. O sistema requer tecnologia que no tenha sido utilizada anteriormente
na organizao?
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

6. O que precisa e o que no precisa ser compatvel com o sistema?

Entre as fontes de informao, esto os gerentes de departamentos em que o sis-


tema ser utilizado, os engenheiros de software que esto familiarizados com o
tipo de sistema proposto, peritos em tecnologia, usurios finais de sistema entre
outros. Eles devem ser entrevistados durante o estudo de viabilidade, a fim de
coletar as informaes exigidas.
O relatrio do estudo de viabilidade dever ser elaborado com base nas
informaes mencionadas anteriormente, e deve recomendar se o desenvol-
vimento do sistema deve continuar ou no. Ele pode propor mudanas no
enfoque, no oramento e no cronograma, alm de sugerir outros requisitos
de alto nvel para o sistema.

LEVANTAMENTO E ANLISE DE REQUISITOS

De acordo com Sommerville (2011), aps os estudos iniciais de viabilidade, a


prxima atividade do processo de engenharia de requisitos o levantamento e a
anlise de requisitos. Nessa atividade, os membros da equipe tcnica de desen-
volvimento de software trabalham com o cliente e os usurios finais do sistema
para descobrir mais informaes sobre o domnio da aplicao, que servios o
sistema deve fornecer, o desempenho exigido do sistema, as restries de har-
dware e assim por diante.

Engenharia de Requisitos
82 UNIDADE III

O levantamento e a anlise de requisitos podem envolver diferentes tipos de pes-


soas em uma organizao. O termo stakeholder utilizado para se referir a qualquer
pessoa que ter alguma influncia direta ou indireta sobre os requisitos do sistema.
Dentre os stakeholders, destacam-se os usurios finais que interagiro com o sistema
e todo o pessoal, em uma organizao, que venha a ser por ele afetado. Os engenhei-
ros que esto desenvolvendo o sistema ou fazendo a manuteno de outros sistemas
relacionados, os gerentes de negcios, os especialistas nesse domnio, os represen-
tantes de sindicato entre outros, podem ser, tambm, os stakeholders do sistema.
O levantamento e a anlise de requisitos compem um processo difcil, por

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
diversas razes (SOMMERVILLE, 2011, p. 98):
1. Os stakeholders frequentemente no sabem na realidade o que querem
do sistema computacional, a no ser em termos muito gerais; eles podem
achar difcil articular o que desejam do sistema, muitas vezes, fazendo
pedidos no realistas, por no terem noo do custo de suas solicitaes.
2. Os stakeholders em um sistema expressam naturalmente os requisitos em
seus prprios termos e com o conhecimento implcito de sua rea de atu-
ao, dificultando a compreenso por parte dos engenheiros de software
que no tm experincia no domnio do cliente.
3. Diferentes stakeholders tm em mente diferentes requisitos e podem
express-los de maneiras distintas, obrigando os engenheiros de software
a descobrir todas as possveis fontes de requisitos e a encontrar os pon-
tos comuns e os conflitos.
4. Fatores polticos podem influenciar os requisitos do sistema.
5. O ambiente econmico e de negcios, no qual a anlise de requisitos
ocorre, dinmico, mudando durante o processo de anlise. Como con-
sequncia, a importncia dos requisitos especficos pode mudar, podendo
surgir novos requisitos por parte dos novos stakeholders, que no haviam
sido consultados inicialmente.

REQUISITOS DE SOFTWARE
83

INTRODUO ENGENHARIA DE REQUISITOS


O Artigo de autoria de vila e Spnola muito interessante, pois fala sobre
a engenharia de requisitos e como ela um dos um dos mais importantes
conjuntos de atividades a serem realizadas em projetos de desenvolvimen-
to de software. Embora no garanta a qualidade dos produtos gerados,
um pr-requisitos bsico para que obtenhamos sucesso no desenvolvimen-
to do projeto. tima leitura.
Fonte: vila e Spnola (2008). 4
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

ENTREVISTA

As entrevistas formais ou informais com os stakeholders do sistema faz parte da


maioria dos processos de engenharia de requisitos. a fonte mais importante para
o levantamento dos requisi-
tos desde que o entrevistado
confie no entrevistador.
A sumarizao durante
e no final da entrevista
necessria primeiro para
garantir que toda informa-
o apresentada foi anotada
e segundo que foi correta-
mente entendida.
shutterstock

Engenharia de Requisitos
84 UNIDADE III

Antes de tentar uma entrevista, o engenheiro de software deve prepar-la:


a. Comece por definir os objetivos. Verifique a documentao formal e desen-
volva um esquema do sistema existente ou proposto. Identifique questes,
partes omitidas e ambguas. Esses fatos ou componentes desconhecidos
representam um esboo inicial dos objetivos. Pode ser necessrio entre-
vistar vrias pessoas para atingir o objetivo.
b. Selecionar a pessoa ou grupo a ser entrevistado. claro que voc quer
encontrar a pessoa que melhor possa responder sobre o assunto. Pode
encontr-la utilizando o organograma, uma anlise do fluxo de trabalho

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
ou uma lista de distribuio de relatrios. Comece pelo organograma e
pelo gerente que parece ser o melhor para responder s questes. Alm
disso, as pessoas ficam menos hesitantes se souberem que a entrevista foi
autorizada pelo chefe.
c. Ler a documentao relevante, conhecer a posio e as responsabilidades
do entrevistado, ocupar-se com documentos ou procedimentos relevantes.
d. Preparar questes especficas. Selecione questes especficas que podem
ser respondidas. Desenvolva uma lista de questes a serem seguidas se a
entrevista comear a se desviar do ponto-chave.

A entrevista deve ser marcada com antecedncia, o horrio deve ser combinado
e as questes devem ser preparadas.
Uma entrevista composta de trs partes: a abertura, o corpo e o fechamento.
ABERTURA - o objetivo-chave estabelecer harmonia (concordncia).
Comece se identificando, apresentando o tpico que pretende discutir e o pro-
psito (objetivo) da entrevista. Se houver necessidade, quebre o gelo com
conversas informais, mas no caia na perda de tempo.
CORPO - pode-se comear com uma questo relativamente aberta (Quando eu
li a documentao para este sistema, tive algum trabalho com (anuncie a parte ou
seo) voc pode me explicar?) e gradualmente, caminhe para de questes especficas.
Nesta fase, o engenheiro de software deve:
a. Mostrar que conhece as responsabilidades e deveres do trabalho do
entrevistado.

REQUISITOS DE SOFTWARE
85

Exemplo: isto o que eu entendo do seu trabalho (uma breve descrio)


est correto?
b. Procurar saber as decises que o entrevistado toma (quais so e como ele
toma as decises; quais so as informaes necessrias, se da forma como
so apresentadas so satisfatrias, qual o tempo necessrio - antecedn-
cia - para que se possa tomar as decises).
c. Procurar respostas quantitativas. Exemplo: quantos telefones, funcion-
rio voc tem no departamento?
d. Evitar falar palavras sem sentido (falar baixo, fazer generalizaes, ter-
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

mos tcnicos).
e. Ouvir as respostas. D tempo para o entrevistado responder, no saia com
respostas antecipadas. No se concentre na prxima questo ( um erro
comum dos iniciantes). A lista de questes preparadas apenas um guia.
Tenha certeza de que as questes so relevantes; evite questes complexas
e desnecessrias.
f. Pedir explicaes para as questes que ficarem obscuras.
g. Pedir ideias e sugestes e descobrir se o entrevistado quer que sejam con-
sideradas. Exemplo: voc tem alguma sugesto ou recomendaes relativas
ao mtodo para calcular o oramento? Voc gostaria que os seus superio-
res ou os demais ficassem sabendo de suas sugestes?

ENCERRAMENTO - se a entrevista tiver consumido mais tempo do que o pre-


visto, pea para continuar e oferea uma reprogramao. Quando tiver toda a
informao necessria, agradea e faa um sumrio de todos os pontos prin-
cipais. Avise se for necessria outra sesso de entrevista com a mesma pessoa.
Muitas vezes, algumas expresses corporais podem substituir ou comunicar
mais informaes do que as prprias palavras. Esse tipo de comunicao pode
ajudar o engenheiro de software a:
a. Interpretar as palavras do entrevistado.
b. Determinar a atitude geral do entrevistado para as questes que esto
sendo discutidas.

Engenharia de Requisitos
86 UNIDADE III

c. Avaliar a confidncia de que o entrevistado demonstrou tanto ao seu redor


como no tratamento da rea de abrangncia do sistema.

Vrios pontos devem ser aprendidos e esclarecidos na entrevista:


a. Organizao da empresa (ambiente de trabalho). Como o administrador
organiza o seu pessoal? Como essa organizao se relaciona s funes
maiores que a empresa executa?
b. Os objetivos e exigncias do sistema (declarados nos manuais de proce-
dimentos) devem ser reafirmados e esclarecidos na entrevista - muitas
vezes os objetivos e exigncias declarados nos manuais no so os mes-

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
mos que os representantes veem. Quando existe uma discrepncia,
possvel que as metas representadas nos documentos possam ser irreais
com o atual potencial humano. O tempo e o crescimento podem ter alte-
rado a meta declarada.
c. Fluxo funcional: para cada funo importante, determinar as etapas exi-
gidas e descrever o significado delas.
d. Exigncia de recursos: determinar quais so os recursos aplicados pela
organizao para executar o trabalho. Quais so as exigncias com:
Recursos humanos (treinamento especializado, experincia exigida).
Equipamento e material necessrio para apoiar na execuo do trabalho.

e. Relao de tempo: como o trabalho executado, relaciona-se a perodos


especficos do ano ou outros ciclos comerciais. Existe pico? Qual o atual
volume de trabalho?
f. Formulrios, procedimentos e relatrios quais so utilizados? (inclua
exemplo de cada formulrio, relatrio e procedimento).
Verifique se o material tem origem no escritrio, se modificado pelo
escritrio e/ou transmitido para outro setor.
Faa comparaes que determinam se inutilizado, duplicado ou
incompleto.
Verifique a satisfao dos usurios com esses documentos.

REQUISITOS DE SOFTWARE
87

g. Funes desejveis e no existentes: registre a opinio das pessoas sobre


o sistema, como ele existe e como poderia ser. Ateno opinies mais
subjetivas que objetivas.
h. Flexibilidade dos procedimentos: o sistema atual to rgido e inflexvel
que a menor modificao requer o maior remendo?
i. Capacidade: o sistema atual consegue manipular volumes maiores do que
aqueles que resultam do crescimento normal?
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Coloque trs interessados em uma sala e pergunte a eles que tipo de siste-
ma desejam. Provavelmente voc obter quatro ou mais opinies diferen-
tes.
(Autor desconhecido.)

ESPECIFICAO DE REQUISITOS

Durante o levantamento de
requisitos (levantamento de
dados), a equipe de desenvolvi-
mento tenta entender o domnio
(contexto/problema) que deve
ser automatizado, sendo que
o produto do levantamento de
requisitos o Documento de
Requisitos ou Especificao
shutterstock

de Requisitos, que declara os


diversos tipos de requisitos do sistema (requisitos funcionais, requisitos no
funcionais, de usurio e de sistema). J tratamos desse tpico nesta unidade.

Engenharia de Requisitos
88 UNIDADE III

VALIDAO DE REQUISITOS

A validao de requisitos tem como objetivo mostrar que os requisitos realmente


definem o sistema que o cliente deseja. Ela tem muito em comum com a anlise
de requisitos, uma vez que se preocupa em descobrir problemas nos requisi-
tos. Contudo, esses so processos distintos, j que a validao deve se ocupar
da elaborao de um esboo completo do documento de requisitos, enquanto a
anlise envolve trabalhar com requisitos incompletos (SOMMERVILLE, 2011).
A validao de requisitos importante porque a ocorrncia de erros em um

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
documento de requisitos pode levar a grandes custos relacionados ao retrabalho,
quando esses erros so descobertos durante o desenvolvimento ou depois que o
sistema estiver em operao. O custo de fazer uma alterao no sistema, resultante
de um problema de requisito, muito maior do que reparar erros de projeto e de
codificao, pois, em geral, significa que o projeto do sistema e a implementao
tambm devem ser modificados e que o sistema tem de ser novamente testado.
Durante a etapa de validao de requisitos, Sommerville (2011, p. 106) pro-
pe que diferentes tipos de verificao devem ser realizados sobre os requisitos
no documento de requisitos. Dentre as verificaes, destacam-se:
1. Verificaes de validade: um usurio pode considerar que um sistema
necessrio para realizar certas funes. Contudo, mais estudos e anli-
ses podem identificar funes adicionais ou diferentes, que so exigidas.
Os sistemas tm diversos usurios com necessidades diferentes e qual-
quer conjunto de requisitos inevitavelmente uma soluo conciliatria
da comunidade de usurios.
2. Verificaes de consistncia: os requisitos em um documento no devem
ser conflitantes, ou seja, no devem existir restries contraditrias ou
descries diferentes para uma mesma funo do sistema.
3. Verificaes de completeza: o documento de requisitos deve incluir requisitos
que definam todas as funes e restries exigidas pelos usurios do sistema.
4. Verificaes de realismo: utilizando o conhecimento da tecnologia exis-
tente, os requisitos devem ser verificados, a fim de assegurar que eles
realmente podem ser implementados, levando-se tambm em conta o
oramento e os prazos para o desenvolvimento do sistema.

REQUISITOS DE SOFTWARE
89

5. Facilidade de verificao: para diminuir as possveis divergncias entre


cliente e fornecedor, os requisitos do sistema devem sempre ser escritos
de modo que possam ser verificados. Isso implica na definio de um
conjunto de verificaes para mostrar que o sistema entregue cumpre
com esses requisitos.

Algumas tcnicas de validao de requisitos podem ser utilizadas em conjunto


ou individualmente. A seguir, so mostradas algumas delas.
1. Revises de requisitos: os requisitos so analisados sistematicamente
por uma equipe de revisores, a fim de eliminar erros e inconsistncias.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

2. Prototipao: nessa abordagem de validao, um modelo executvel


do sistema mostrado aos usurios finais e clientes, possibilitando que
eles experimentem o modelo para verificar se atende s necessidades da
empresa.
3. Gerao de casos de teste: como modelo ideal, os requisitos deveriam ser
testveis. Se os testes para os requisitos so criados como parte do pro-
cesso de validao, isso, muitas vezes, revela problemas com os requisitos.
Se um teste difcil ou impossvel de ser projetado, isso frequentemente
significa que os requisitos sero de difcil implementao e devem ser
reconsiderados. O desenvolvimento de testes a partir dos requisitos de
usurio, antes da implementao do sistema, uma parte integrante da
Extreme Programming.

As dificuldades da validao de requisitos no devem ser subestimadas, pois


muito difcil demonstrar que, de fato, um conjunto de requisitos atende s
necessidades de um usurio. Os usurios devem pensar no sistema em ope-
rao e imaginar como esse sistema se adequaria ao seu trabalho. No fcil
para profissionais habilitados de computao conseguirem realizar esse tipo
de anlise abstrata, imagina s, como ser difcil para os usurios de sistema.
Sendo assim, a validao de requisitos no consegue descobrir todos os pro-
blemas com os requisitos, implicando em modificaes para corrigir essas
omisses e falhas de compreenso, depois que o documento de requisitos foi
aceito (SOMMERVILLE, 2011, p. 77).

Engenharia de Requisitos
90 UNIDADE III

Gastamos um bom tempo a maior parte do esforo de um projeto no


implementando ou testando, mas sim tentando decidir o que construir.
(Brian Lawrence, ex-jogador de beisebol da Major League.)

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
ARTIGO: USO DE PROTTIPOS DE INTERFACE COMO IDIOMA DURAN-
TE A VALIDAO DE REQUISITOS UMA ANLISE SEMITICA
Excelente trabalho que mostra o uso de prottipos de interface como idio-
ma durante a validao de requisito para estabelecer comunicao entre
tcnicos e usurios no-tcnicos durante a execuo do processo de Valida-
o (da Engenharia de Requisitos), como alternativa utilizao dos Diagra-
mas de Casos de Uso para executar este processo. O artigo utiliza a semiti-
ca (peirceana) como referencial terico principal para analisar o repertrio
requerido na leitura e compreenso desses dois tipos de artefato como jus-
tificativa para a sugesto apresentada.
Fonte: Marquioni (2008).4

REQUISITOS DE SOFTWARE
91

CONSIDERAES FINAIS

Caro(a) aluno(a), chegamos ao final da terceira unidade, na qual estudamos o


assunto Requisitos de Software. Nesta unidade, foi mostrado que os requisitos
para um software devem estabelecer o que o sistema deve fazer e definir tam-
bm as restries sobre o seu funcionamento e implementao.
Os requisitos de software podem ser classificados em requisitos funcionais
que so aqueles servios que o sistema deve fornecer e requisitos no fun-
cionais que esto, frequentemente, relacionados s propriedades emergentes
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

do sistema, aplicando-se ao sistema como um todo.


Todos os requisitos, sejam eles funcionais ou no funcionais, devem ser defini-
dos da forma mais clara possvel para que no haja problemas na sua interpretao,
pois, a partir da definio desses requisitos que o sistema ser modelado, pro-
jetado, implementado, testado e, por fim, colocado em funcionamento.
A primeira atividade servir para avaliar se o sistema ser til para a empresa.
Isso se d por meio do estudo de viabilidade, sendo que, ao final desta atividade,
um relatrio de viabilidade deve ser elaborado, no qual se recomenda se vale a
pena ou no realizar o processo de engenharia de requisitos.
A terceira atividade do processo de engenharia de requisitos a converso
dos requisitos levantados em uma forma-padro, ou seja, em um documento
de requisitos de software. E, finalmente, a ltima atividade, a verificao de
que os requisitos realmente definem o sistema que o cliente quer, ou seja, deve
ser realizada a validao dos requisitos anotados no documento de requisitos.
Na prxima unidade, vamos conhecer como se d o processo de modelagem
de um sistema e vamos usar os conceitos de orientao a objetos apresentados
na primeira unidade, pois a UML Unified Modeling Language (Linguagem de
Modelagem Unificada), que utilizaremos para realizar a modelagem, baseada
no paradigma da orientao a objetos.

Consideraes Finais
92

1. Descreva como os requisitos de software so classificados.


2. Quanto mais rgidos os requisitos de qualidade e mais complexo o software a ser
desenvolvido, aumenta-se a necessidade de se aplicar teorias e ferramentas que
garantam que esses requisitos sejam satisfatrios. Descreva as seis caractersti-
cas de qualidade de software que devem ser avaliadas.
3. Defina e explique os Requisitos de Usurio.
93

Artigo: Especificao de requisitos no desenvolvimento de software para tv digital


interativa no Brasil: reflexes e relato de experincia
O processo de implantao da TV Digital no Brasil iniciou uma nova fase em 2009, rela-
cionada definio de mecanismos para interao atravs do televisor. Contudo, alm
de viabilizar a infraestrutura tecnolgica para troca de informaes entre o telespecta-
dor e os difusores, parece relevante considerar a utilizao de processos de software
para que os produtos desenvolvidos que possibilitam a interao tenham qualidade.
Este trabalho apresenta conceitos do processo de Especificao da Engenharia de Re-
quisitos e relaciona boas prticas de escrita para gerar requisitos textuais que, integra-
das com a tcnica de Casos de Uso, levaram definio de um mtodo de especificao
de requisitos para a TV Digital Interativa que utiliza conceitos conhecidos pela comuni-
dade de software. O mtodo foi utilizado em um projeto real, e abordado no artigo
como relato de experincia. O trabalho completo pode ser encontrado no endereo
online citado.
Fonte: Marquioni (2011)5
MATERIAL COMPLEMENTAR

O vdeo mostra uma entrevista com Sergio Ayres, consultor com vasta experincia em Gesto e
Governana Corporativa, abordando a Engenharia de Requisitos.
<http://www.youtube.com/watch?v=P4ixBvRF4NY&feature=related>.
95
REFERNCIAS

VILA, A.L.; SPNOLA, R. O. Introduo Engenharia de Requisitos. Engenharia de


Software Magazine, v. 1, p. 46-53, 2008.
MARQUIONI, C. E. Especificao de requisitos no desenvolvimento de software para
TV Digital Interativa no Brasil: Reflexes e Relato de Experincia. Prisma.com, v. 15,
p. 784, 2011.
______. MARQUIONI, C. E. Uso de prottipos de interface como idioma durante a
validao de requisitos - uma anlise semitica. In: CONTECSI 5th International
Conference on Information Systems and Technology Management. So Paulo: 2008,
p. 1373-1384.
PRESSMAN, R. Engenharia de Software. 7.ed. Porto Alegre: AMGH, 2011.
SOMMERVILLE, I. Engenharia de Software. So Paulo: Pearson Prentice Hall, 2011.
______. Engenharia de Software. So Paulo: Pearson Addison-Wesley, 2007.
GABARITO

1. Requisitos funcionais: definem as funes que o sistema deve fornecer, de como


o sistema deve reagir a entradas especficas e de como deve se comportar em
determinadas situaes. Em alguns casos, os requisitos funcionais podem tam-
bm explicitamente declarar o que o sistema no deve fazer. Exemplos de requi-
sitos funcionais: o software deve possibilitar o clculo das comisses dos ven-
dedores de acordo com os produtos vendidos; o software deve emitir relatrios
de compras e vendas por perodo; o sistema deve mostrar, para cada aluno, as
disciplinas em que foi aprovado ou reprovado.
Requisitos no funcionais: so os requisitos relacionados utilizao do softwa-
re em termos de desempenho, confiabilidade, segurana, usabilidade e portabi-
lidade entre outros. Exemplos de requisitos no funcionais: o sistema deve ser
protegido para acesso apenas de usurios autorizados; o tempo de resposta do
sistema no deve ultrapassar 20 segundos; o tempo de desenvolvimento no
deve ultrapassar doze meses.
2. Funcionalidade, Usabilidade, Confiabilidade, Eficincia, Manutenibilidade, Por-
tabilidade.
3. Requisitos de Usurio: os requisitos de usurios para um sistema devem descre-
ver os requisitos funcionais e no funcionais de forma que usurios do sistema
que no tenham conhecimentos tcnicos detalhados consigam entender. Eles
devem especificar somente o comportamento externo do sistema, evitando
sempre que possvel as caractersticas do projeto de sistema. Portanto, no de-
vem ser definidos utilizando-se um modelo de implementao, e sim, escritos
com o uso de linguagem natural, formulrios e diagramas intuitivos simples.
Professora Me. Mrcia Cristina Dadalto Pascutti

IV
UNIDADE
MODELAGEM DE SISTEMAS

Objetivos de Aprendizagem
Expor a importncia da modelagem de sistemas.
Mostrar os conceitos relacionados a diagramas de casos de uso e
diagramas de classes.
Mostrar um estudo de caso no qual so construdos os diagramas de
casos de uso e de classes.

Plano de Estudo
A seguir, apresentam-se os tpicos que voc estudar nesta unidade:
Modelagem de Sistemas
Diagrama de Casos de Uso
Diagrama de Classes
Ferramentas CASE
Conceitos Bsicos de Orientao a Objetos
Introduo UML
99

INTRODUO

Caro(a) aluno(a), na terceira unidade estudamos sobre os requisitos de um sis-


tema e foi bastante destacada a importncia de um documento de requisitos.
Nesta unidade voc ver que, a partir do documento de requisitos, realizaremos
a modelagem de um sistema.
A modelagem de sistema o processo de elaborao de modelos abstratos
de um sistema, normalmente representado por meio de um diagrama, em que
cada um desses modelos apresenta uma viso ou perspectiva diferente do sistema
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

(SOMMERVILLE, 2011). Esses modelos, normalmente, so elaborados utilizan-


do-se uma notao grfica, que, em nosso caso, ser a UML.
Da mesma forma que os arquitetos elaboram plantas e projetos para serem
usados, para a construo de um edifcio, os engenheiros de software criam os
diagramas UML para auxiliarem os desenvolvedores de software a construir o
software.
A UML define, em sua verso 2.0, treze tipos de diferentes diagramas para
uso na modelagem de software. Nesta unidade, veremos somente os diagramas
de casos de uso e de classe. Se voc quiser conhecer os outros diagramas, con-
sulte alguns livros relacionados nas referncias. Como nosso objetivo aqui
mostrar a modelagem de um sistema, utilizaremos somente esses dois diagramas.
Primeiramente, ser apresentado a voc, caro(a) aluno(a), o diagrama de
casos de uso. Esse diagrama ajuda a determinar a funcionalidade e as caracters-
ticas do sistema sob o ponto de vista do usurio, sendo um dos diagramas mais
gerais e informais da UML. Para a elaborao do diagrama de casos de uso, deve
ser utilizada uma linguagem simples e de fcil compreenso para que os usurios
possam ter uma ideia geral de como o sistema ir se comportar (GUEDES, 2007).
Em seguida, ser mostrado o diagrama de classes. Esse o diagrama mais
importante e tambm o mais utilizado da UML, e serve de apoio para a maio-
ria de outros diagramas (que no sero abordados neste livro). O diagrama de
classes define a estrutura das classes identificadas para o sistema, mostrando os
atributos e mtodos possudos por cada uma das classes, alm de estabelecer
como as classes se relacionam e trocam informaes entre si.

Introduo
100 UNIDADE IV

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
shutterstock

MODELAGEM DE SISTEMAS

A necessidade de planejamento no desenvolvimento de sistemas de informa-


o leva ao conceito de modelagem de software, ou seja, antes do software ser
concebido deve-se criar um modelo para o mesmo. Um modelo pode ser visto
como uma representao idealizada de um sistema a ser construdo. Exemplos
de modelos: maquetes de edifcio, plantas de casa, fluxogramas etc.
A modelagem de sistemas de software consiste na utilizao de notaes gr-
ficas e textuais com o objetivo de construir modelos que representam as partes
essenciais de um sistema. So vrias as razes para se utilizar modelos na cons-
truo de sistemas, eis algumas:
No desenvolvimento de software usamos desenhos grficos denomina-
dos de diagramas para representar o comportamento do sistema. Esses
diagramas seguem um padro lgico e possuem uma srie de elementos
grficos que possuem um significado pr-definido.
Apesar de um diagrama conseguir expressar diversas informaes de forma
grfica, em diversos momentos, h a necessidade de adicionar informa-
es na forma de texto, com o objetivo de explicar ou definir certas partes
desse diagrama. A modelagem de um sistema em forma de diagrama, jun-
tamente com a informao textual associada, formam a documentao
de um sistema de software.

MODELAGEM DE SISTEMAS
101

O rpido crescimento da capacidade computacional das mquinas resul-


tou na demanda por sistemas de software cada vez mais complexos, que
tirassem proveito de tal capacidade. Por sua vez, o surgimento desses sis-
temas mais complexos resultou na necessidade de reavaliao da forma de
desenvolver sistemas. Desde o aparecimento do primeiro computador at
os dias de hoje, as tcnicas para construo de sistemas computacionais
tm evoludo para suprir as necessidades do desenvolvimento de software.
Dcada de 1950/60: os sistemas de software eram bastante simples e,
dessa forma, as tcnicas de modelagem tambm. Era a poca dos flu-
xogramas e diagramas de mdulos.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Dcada de 1970: nessa poca houve uma grande expanso do mer-


cado computacional. Sistemas complexos comeavam a surgir e, por
consequncia, modelos mais robustos foram propostos. Nesse per-
odo, surge a programao estruturada e, no final da dcada, a anlise
e o projeto estruturado.
Dcada de 1980: surge a necessidade por interfaces homem-mquina
mais sofisticadas, o que originou a produo de sistemas de software
mais complexos. A anlise estruturada se consolidou na primeira
metade dessa dcada e em 1989 Edward Yourdon lana o livro Anlise
Estruturada Moderna, tornando-o uma referncia no assunto.
Dcada de 1990: nesse perodo surge um novo paradigma de modelagem,
a Anlise Orientada a Objetos, como resposta a dificuldades encontra-
das na aplicao da Anlise Estruturada a certos domnios de aplicao.
Final da dcada de 90 e momento atual: o paradigma da orientao
a objetos atinge a sua maturidade. Os conceitos de padres de proje-
tos (design patterns), frameworks de desenvolvimento, componentes e
padres de qualidade comeam a ganhar espao. Nesse perodo, surge
a Linguagem de Modelagem Unificada (UML), que a ferramenta de
modelagem utilizada no desenvolvimento atual de sistemas.

O processo de desenvolvimento de software uma atividade bastante complexa.


Isso se reflete no alto nmero de projetos de software que no chegam ao fim
ou que extrapolam recursos de tempo e de dinheiro alocados. Em um estudo
clssico sobre projetos de desenvolvimento de software realizado em 1994, foi
constatado que:

Modelagem de Sistemas
102 UNIDADE IV

Porcentagem de projetos que terminam dentro do prazo estimado: 10%.


Porcentagem de projetos que so descontinuados antes de chegarem ao
fim: 25%.
Porcentagem de projetos acima do custo esperado: 60%.
Atraso mdio nos projetos: um ano.

Os modelos construdos na fase de anlise devem ser cuidadosamente validados e


verificados. O objetivo da validao assegurar que as necessidades do cliente esto
sendo atendidas. Nessa atividade, os analistas apresentam os modelos criados para

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
representar o sistema aos futuros usurios para que esses modelos sejam validados.
A verificao tem o objetivo de analisar se os modelos construdos esto em
conformidade com os requisitos definidos. Na verificao dos modelos, so ana-
lisadas a exatido de cada modelo em separado e a consistncia entre os modelos.
A verificao uma etapa tpica da fase de projeto que a prxima etapa do
desenvolvimento de software.
Caro(a) aluno(a), utilizaremos a UML para realizar a modelagem de sistemas,
e na primeira unidade estudamos alguns conceitos relacionados orientao de
objetos e tambm fizemos uma introduo linguagem UML. Lembre-se que
os artefatos de software produzidos durante a modelagem serviro de base para
a fase seguinte do ciclo de desenvolvimento de sistemas, ou seja, a fase projeto.

DIAGRAMA DE CASOS DE USO

O diagrama de casos de uso (Use Case Diagram) , dentre todos os diagramas da


UML, o mais abstrato, flexvel e informal, sendo utilizado principalmente no incio
da modelagem do sistema, a partir do documento de requisitos, podendo ser consul-
tado e possivelmente modificado durante todo o processo de engenharia e tambm
serve de base para a modelagem de outros diagramas (GUEDES, 2007, p. 38).

MODELAGEM DE SISTEMAS
103

O principal objetivo deste diagrama modelar as funcionalidades e servi-


os oferecidos pelo sistema, buscando, por meio de uma linguagem simples,
demonstrar o comportamento externo do sistema da perspectiva do usurio.
De acordo com Silva (2007, p. 101), o diagrama de caso de uso incorpora o
conjunto de requisitos funcionais estabelecidos para o software que est sendo
modelado. Esses requisitos devem estar descritos no documento de requisi-
tos, como j explicamos na unidade anterior. H uma correspondncia entre os
requisitos funcionais previstos para o software e os casos de uso. Os requisitos
no funcionais no aparecem no diagrama de casos de uso, pois no constituem
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

o foco da modelagem que estamos realizando.


O diagrama de casos de uso composto por atores, casos de uso e seus rela-
cionamentos. A seguir, descreveremos cada um desses elementos.

ATORES

Um ator representa um papel que um ser humano, um dispositivo de hardware


ou at outro sistema desempenha com o sistema (BOOCH, 2005, p. 231). Assim,
um ator pode ser qualquer elemento externo que interaja com o software, sendo
que o nome do ator identifica qual o papel assumido por ele dentro do dia-
grama (GUEDES, 2007, p. 38).
Um caso de uso sempre iniciado por um estmulo de um ator; ocasio-
nalmente, outros atores podem participar do caso de uso. A figura 4 apresenta
alguns exemplos de atores.

Figura 1 Exemplos de Atores

Cliente Departamento de Cobrana Sistema Financeiro Gerente


Fonte: os autores

Diagrama de Casos de Uso


104 UNIDADE IV

CASOS DE USO

De acordo com Booch (2005, p. 227), um caso de uso especifica o comporta-


mento de um sistema ou de parte de um sistema, referindo-se a servios, tarefas
ou funes apresentadas pelo sistema, como cadastrar funcionrio ou emitir
relatrio de produtos.
No diagrama de caso de uso no possvel documentar os casos de uso e
nem a UML oferece um recurso para que isso seja feito, porm, indicado que
cada caso de uso seja documentado, demonstrando qual o comportamento pre-

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
tendido para o caso de uso em questo e quais funes ele executar quando for
solicitado. Essa documentao dever, tambm, ser elaborada de acordo com o
documento de requisitos e poder auxiliar o desenvolvedor na elaborao dos
demais diagramas da UML. A figura 5 apresenta alguns exemplos de casos de uso.
Figura 2 Exemplos de Casos de Uso

Cadastrar Emitir
Funcionrios Efetuar venda Relatrio de
Produtos

Normalmente, os nomes de casos de uso so breves expresses verbais ativas,


nomeando algum comportamento encontrado no vocabulrio do sistema cuja
modelagem est sendo realizada, a partir do documento de requisitos (BOOCH,
2005). Alguns verbos que podem ser usados para nomear os casos de uso: efe-
tuar, cadastrar, consultar, emitir, registrar, realizar, manter, verificar, entre outros.

RELACIONAMENTO ENTRE CASOS DE USO E ATORES

Conforme Melo (2004), os casos de uso representam conjuntos bem definidos de


funcionalidades do sistema, precisando relacionar-se com outros casos de uso e
com atores que enviaro e recebero mensagens destes. Podemos ter os relacio-
namentos de associao, generalizao, extenso e incluso, da seguinte forma:

MODELAGEM DE SISTEMAS
105

Para relacionamentos entre atores e casos de uso: somente associao.


Para relacionamentos de atores, entre si: somente generalizao.
Para relacionamentos de casos de uso, entre si: generalizao, exten-
so e incluso.

ASSOCIAO
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

A associao o nico relacionamento possvel entre ator e caso de uso, sendo


sempre binria, ou seja, sempre envolvendo apenas dois elementos. Melo (2004,
p. 60) diz que representa a interao do ator com o caso de uso, ou seja, a comuni-
cao entre atores e casos de uso, por meio do envio e recebimento de mensagens.
Um relacionamento de associao demonstra que o ator utiliza a funcionali-
dade representada pelo caso de uso. Esse tipo de relacionamento representado
por uma reta ligando o ator ao caso de uso. Pode ser que essa reta possua em sua
extremidade uma seta, que indica a navegabilidade dessa associao, ou seja, se
as informaes so fornecidas pelo ator em caso de uso (nesse caso a seta aponta
para o caso de uso), se so transmitidas pelo caso de uso ao ator (nesse caso a
seta aponta para o ator) ou ambos (neste ltimo caso a reta no possui setas)
(GUEDES, 2007, p. 40). A figura seguinte representa uma associao entre um
ator e um caso de uso, em que o ator fornece uma informao para o caso de uso.
Figura 4 Associao entre um ator e um caso de uso

Calcular
emprstimo
pessoal
Correntista

Fonte: os autores.

Veja a figura seguinte. Ela mostra o ator Gerente Administrativo recebendo o


Relatrio de Vendas por Perodo (note que ele no solicita a emisso do relat-
rio, ele somente recebe o relatrio).

Diagrama de Casos de Uso


106 UNIDADE IV

Figura 5 Associao entre um ator e um caso de uso

Emitir relatrio
de vendas por
perodo
Gerente Administrativo

Fonte: os autores.

Na figura 8, outro exemplo, percebemos que o ator denominado Submissor


utiliza, de alguma forma, o servio de Realizar Submisso e que a informao
referente a esse processo trafega nas duas direes.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Figura 6 Associao entre um ator e um caso de uso

Realizar
submisso

Submissor
Fonte: os autores.

GENERALIZAO

J explicamos o conceito de generalizao/especializao quando falamos sobre


herana. Aqui, no diagrama de casos de uso, tambm aplicamos esse conceito, ou
seja, o relacionamento de generalizao entre casos de uso pode ocorrer quando
existirem dois ou mais casos de usos com caractersticas semelhantes, apresen-
tando pequenas diferenas entre si. Quando isso acontece, define-se um caso
de uso geral, que dever possuir as caractersticas compartilhadas por todos os
casos de uso em questo, e ento relacionamos esse caso de uso geral com os
casos de uso especficos, que devem conter somente a documentao das carac-
tersticas especficas de cada um deles. Dessa forma, evita-se reescrever toda a
documentao para todos os casos de uso envolvidos, porque toda a estrutura
de um caso de uso generalizado herdada pelos casos de uso especializados,
incluindo quaisquer possveis associaes que o caso de uso generalizado possua.
A associao representada por uma reta com uma seta mais grossa, partindo
dos casos de uso especializados e atingindo o caso de uso geral, como mostra a
figura 8 (GUEDES, 2007, p. 40).

MODELAGEM DE SISTEMAS
107

Figura 7 Exemplo de generalizao entre casos de uso

Abrir Conta
Comum

Abrir Conta Abrir Conta


Especial Poupana
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Fonte: os autores

Agora, vamos entender o que esse exemplo est representando. Em um banco,


existem trs opes de abertura de contas: abertura de conta comum, de conta
especial e de conta poupana, cada uma representada por um caso de uso diferente.
As aberturas de conta especial e de conta poupana possuem todas as caracte-
rsticas e requisitos da abertura de conta comum, porm, cada uma delas possui
tambm algumas caractersticas e requisitos prprios, o que justifica coloc-las
como especializaes do caso de uso Abertura de Conta Comum, detalhando-se
as particularidades de cada caso de uso especializado em sua prpria documen-
tao (GUEDES, 2007, p. 41).
O relacionamento de generalizao/especializao tambm pode ser aplicado entre
atores. A figura seguinte apresenta um exemplo, em que existe um ator geral cha-
mado Cliente e dois atores especializados chamados Pessoa Fsica e Pessoa Jurdica.
Figura 8: Generalizao entre Atores

Cliente

Pessoa Fsica Pessoa Jurdica

Fonte: os autores.

Diagrama de Casos de Uso


108 UNIDADE IV

INCLUSO

Esse tipo de relacionamento possvel somente entre casos de uso e utilizado


quando existem aes comuns a mais de um caso de uso. Quando isso ocorre,
a documentao dessas aes colocada em um caso de uso especfico, permi-
tindo que outros casos de uso se utilizem dessas aes, evitando-se descrever
uma mesma sequncia de passos em vrios casos de uso (GUEDES, 2007, p. 42).
Um relacionamento de incluso entre casos de uso significa que o caso de
uso base incorpora explicitamente o comportamento de outro caso de uso. O

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
caso de uso includo nunca permanece isolado, mas apenas instanciado como
parte de alguma base maior que o inclui (BOOCH, 2005, p. 235).
O relacionamento de incluso pode ser comparado chamada de uma sub-
-rotina, portanto, indicam uma obrigatoriedade, ou seja, quando um caso de
uso base possui um relacionamento de incluso com outro caso de uso, a execu-
o do primeiro obriga tambm a execuo do segundo (GUEDES, 2007, p. 42).
A representao do relacionamento de incluso feita por meio de uma reta
tracejada contendo uma seta em uma de suas extremidades, e rotulada com a pala-
vra-chave <<include>>. A seta deve sempre apontar para o caso de uso a ser includo.
Veja um exemplo na figura a seguir, que foi retirado de Guedes (2007, p. 43).
Figura 9 Exemplo de incluso de caso de uso

Realizar
depsito

<<Include>>

Registrar
movimento
Cliente Banco

<<Include>>

Realizar saque

Fonte: Guedes (2007, p. 43).

MODELAGEM DE SISTEMAS
109

Neste exemplo, sempre que um saque ou depsito ocorrer, ele deve ser regis-
trado para fins de histrico bancrio. Como as rotinas para registro de um saque
ou um depsito so extremamente semelhantes, colocou-se a rotina de registro
em um caso de uso parte, chamado Registrar Movimento, que ser executado
obrigatoriamente sempre que os casos de uso Realizar Depsito ou Realizar
Saque forem utilizados. Assim, s preciso descrever os passos para registrar
um movimento no caso de uso includo (GUEDES, 2007, p. 43). Nesse exemplo
temos dois casos de uso base e um caso de uso a ser includo.
Agora veja outro exemplo na figura 10. Aqui, est sendo apresentada a
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

seguinte situao: em algum ponto dos casos de uso Realizar matrcula do aluno
(caso de uso base), Cadastrar pagamento mensalidade aluno (caso de uso base)
e Emitir histrico escolar aluno (caso de uso base) necessrio Validar a matr-
cula (caso de uso a ser includo) do aluno. Assim, nesses pontos, o caso de uso
Validar matrcula ser internamente copiado.
Figura 10 Outro exemplo de incluso de caso de uso

Realizar
matrcula do
aluno
Emitir
Validar <<Include>> histrico
matrcula escolar do
aluno
Cadastrar
pagamento
mensalidade
aluno

EXTENSO

O relacionamento de extenso tambm possvel somente entre casos de uso e


utilizado para modelar rotinas opcionais de um sistema, que ocorrero somente
se uma determinada condio for satisfeita. A extenso separa um comporta-
mento obrigatrio de outro opcional.

Diagrama de Casos de Uso


110 UNIDADE IV

As associaes de extenso possuem uma representao muito semelhante


s associaes de incluso, sendo tambm representadas por uma reta tracejada,
diferenciando-se por possuir um esteretipo contendo o texto <<extend>> e
pela seta apontar para o caso de uso que estende, ou seja, neste caso a seta aponta
para o caso de uso base (GUEDES, 2007, p. 43). Veja na prxima figura um exem-
plo de relacionamento de extenso.
Figura 11 Exemplo de extenso de caso de uso

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Cliente Verificar
situao conta <<extend>> Emitir extrato
corrente do
cliente

Banco
Fonte: os autores.

No exemplo da figura 11 est sendo mostrado que tanto o Cliente quanto o Banco
podem Verificar a situao da conta corrente do cliente e, se for o caso, pode-
-se emitir um extrato. Mas, note que, o extrato somente ser emitido se alguma
condio do caso de uso base Verificar situao conta corrente do cliente - for
satisfeita, caso contrrio, o extrato nunca ser emitido.
Agora, vamos mostrar um exemplo bastante comum que acontece quando
utilizamos sistemas via Internet, em que, para utilizar os servios, o cliente deve se
logar no sistema e, caso seja a primeira vez, dever realizar o seu cadastro pessoal.
Figura 1 Outro exemplo de extenso de caso de uso

Realizar
Realizar login <<extend>> cadastro dados
no site
pessoais
Cliente
Fonte: os autores.

No exemplo da figura 14, o caso de base o Realizar login no site e Realizar


cadastro dados pessoais o caso de uso a ser estendido.

MODELAGEM DE SISTEMAS
111

Caro(a) aluno(a), para facilitar o entendimento do relacionamento de extenso,


vamos mostrar mais um exemplo de uso. Na figura a seguir est sendo apresen-
tada a seguinte situao: durante a execuo do caso de uso Efetuar venda, a
venda pode ser realizada para um cliente especial. Nesse caso, necessrio, num
ponto predefinido, incluir uma complementao da rotina que ser responsvel
por calcular o desconto para um cliente especial. Da mesma forma, durante o
pagamento, pode haver algum tipo de falha na autorizao do carto. Veja que
esse no um procedimento normal, pois possvel ter pagamentos em dinheiro,
cheque etc. Assim, havendo falha na autorizao, o caso de uso pertinente dever
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

dar um tratamento situao.


Figura 13 Representao de um Relacionamento Extend
Calcular
desconto para
cliente especial
tend>>
<<ex

Efetuar venda

Verificar falha
na autorizao
do carto

Fonte: os autores.

Quadro 1 Resumo de Relacionamentos entre Casos de Uso e Atores

Especializao/
Associao Incluso Extenso
Generalizao
Caso de Uso e Caso de Uso ----- OK OK OK
Ator e Ator ----- OK ----- -----
Ator e Caso de Uso OK ----- ----- -----
Fonte: os autores.

Vdeo que mostra a importncia da modelagem de sistemas, bem como trata da elaborao do
diagrama de casos de uso.
<http://www.youtube.com/watch?v=hfN6n5fJfLc&feature=relmfu>.

Diagrama de Casos de Uso


112 UNIDADE IV

DIAGRAMA DE CLASSES

O diagrama de classes tem como objetivo permitir a visualizao das classes uti-
lizadas pelo sistema e como essas se relacionam, apresentando uma viso esttica
de como essas classes esto organizadas, preocupando-se apenas em definir sua
estrutura lgica (GUEDES, 2007, p. 52).
Ainda, conforme Guedes (2007, p. 52), um diagrama de classes pode ser
utilizado para modelar o modelo lgico de um banco de dados, parecendo-se,
neste caso, com o Diagrama de Entidade-Relacionamento (Modelo Entidade-

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Relacionamento, que voc estudar na disciplina de Banco de Dados). No entanto,
deve ficar bem claro que o diagrama de classes no utilizado unicamente
para essa finalidade e mais importante, que
uma classe no, necessariamente, corres-
ponde a uma tabela.
Uma classe pode representar o repositrio
lgico dos atributos de uma tabela, porm, a
classe no a tabela, uma vez que os atributos
de seus objetos so armazenados em memria
enquanto uma tabela armazena seus registros
fisicamente em disco. Alm disso, uma classe
possui mtodos que no existem em uma tabela.
shutterstock

RELACIONAMENTOS

As classes no trabalham sozinhas, pelo contrrio, elas colaboram umas com as


outras por meio de relacionamentos (MELO, 2004, p. 108).
No diagrama de classes, temos os relacionamentos de associao (que pode
ser unria ou binria), generalizao e agregao. Existem alguns tipos especiais
de relacionamentos, porm no sero explicados aqui. Com os relacionamentos
citados, possvel elaborar um diagrama de classes.

MODELAGEM DE SISTEMAS
113

ASSOCIAO

De acordo com Melo (2004, p. 109), a associao um relacionamento que


conecta duas ou mais classes, demostrando a colaborao entre as instncias de
classe. Pode-se tambm ter um relacionamento de uma classe com ela mesma,
sendo que, neste caso, tem-se a associao unria ou reflexiva.

ASSOCIAO UNRIA OU REFLEXIVA


Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Segundo Guedes (2007, p. 54), a associao unria ocorre quando existe um rela-
cionamento de uma instncia de uma classe com instncias da mesma classe,
conforme mostra o exemplo abaixo.
Figura 14 Exemplo de Associao Unria

Funcionrios
-cdigo: int
-nome: char Chefia
-codChefe: int
0..*

Fonte: os autores.

Neste exemplo, temos a classe Funcionrio, cujos atributos so cdigo, nome e


o cdigo do possvel chefe do funcionrio. Como esse chefe tambm um fun-
cionrio, a associao chamada Chefia indica uma possvel relao entre uma
ou mais instncias da classe Funcionrio com outras instncias da mesma classe,
ou seja, tal associao determina que um funcionrio pode ou no chefiar outros
funcionrios. Essa associao faz com que a classe possua o atributo codChefe
para armazenar o cdigo do funcionrio, que responsvel pela instncia do
funcionrio em questo. Desse modo, aps consultar uma instncia da classe
funcionrio, pode-se utilizar o atributo codChefe da instncia consultada para
pesquisar por outra instncia da Classe (GUEDES, 2007, p. 54).

Diagrama de Classes
114 UNIDADE IV

ASSOCIAO BINRIA

A associao binria conecta duas classes por meio de uma reta que liga uma
classe a outra. A figura demonstra um exemplo de associao binria.
Figura 15 Exemplo de associao binria

Cliente
Cidade
-nome: String
-sexo: char -nome: String

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
-data_nascimento: Date -UF: String
-endereo: String 0..* -DDD: int
-CEP: int

Fonte: os autores.

No exemplo da figura 17, um objeto da classe Cidade pode se relacionar ou no com


instncias da classe Cliente, conforme demonstra a multiplicidade 0..*, ao passo
que, se existir um objeto da classe Cliente, ele ter que se relacionar com um objeto
da classe Cidade, pois como no foi definida a multiplicidade na extremidade da
classe Cidade, significa que ela 1..1. Logo, depois da explicao sobre os relacio-
namentos em um diagrama de classes, explicaremos o conceito de multiplicidade.

AGREGAO

Uma agregao somente pode ocorrer entre duas classes. Esse tipo de relacio-
namento ou associao conforme a UML identificvel a partir da notao de
uma linha slida entre duas classes, a classe denominada todo-agregado recebe
um diamante vazio, enquanto a outra ponta da linha ligada classe denomi-
nada parte-constituinte.
Ambas as classes podem viver de forma independente, ou seja, no existe
uma ligao forte entre as duas. Objetos da parte constituinte ou da parte agre-
gado so independentes em termos de vida, porm, ambas so partes de um
nico todo. Essa anlise depender do domnio do problema em estudo.

MODELAGEM DE SISTEMAS
115

Para sabermos se um relacionamento de agregao, basta perguntarmos


se, em primeiro lugar, cabe estrutura todo-parte. Em seguida, perguntamos se
o objeto constituinte-parte vive sem o objeto agregado. Se a resposta for sim a
ambas perguntas, teremos uma agregao.
A figura seguinte apresenta a notao para essa semntica. Para um deter-
minado domnio de problema que trata de apartamentos e condomnios, vemos
que um apartamento tem depsitos. Quando nos referimos a um depsito pode-
mos perguntar a qual apartamento aquele depsito pertence.
Por outro lado, um determinado proprietrio pode ter decidido sobre a
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

venda de um depsito para algum que sequer mora no prdio. Assim, teremos
os dois objetos, nesse exemplo, vivendo separadamente, sem incmodo algum.
Poderamos ter a situao em que um apartamento interditado ou passa por
uma grande reforma. Durante algum tempo, no teremos movimentao naquele
apartamento, porm, o depsito que faz parte daquele jogo apartamento-dep-
sito, continua sendo usado livremente.
O mesmo exemplo valeria para garagens de um apartamento.
Figura 16 Uma agregao entre duas classes

clsApartamento
-dMetragem: double
-iCountApartamento: int

+ObterMetragem ( )
+ObterNumAptsInstanciados ( ): int

clsDeposito

Diagrama de Classes
116 UNIDADE IV

COMPOSIO

Uma composio ocorre quando temos uma situao semelhante da agregao


entre duas classes, porm, os objetos da classe parte no podem viver quando
o todo destrudo.
Este tipo de relacionamento ou associao conforme a UML, identificvel
pela notao de uma linha slida entre duas classes, a classe denominada todo-
-composta recebe um diamante preenchido, enquanto a outra ponta da linha
ligada classe denominada parte-componente.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Ambas as classes vivem unidas de forma dependente, ou seja, existe uma
ligao forte entre as duas. Os objetos da classe parte so dependentes, em ter-
mos de vida, da classe-todo, ambas so partes de um nico todo. Essa anlise
depender do domnio do problema em estudo.
Para sabermos se um relacionamento de composio, basta perguntarmos
se, em primeiro lugar, cabe estrutura todo-parte; em seguida perguntamos se o
objeto parte vive sem o objeto todo. Se a resposta for sim primeira pergunta
e no segunda, teremos uma composio.
A figura 19 apresenta uma viso da notao para esse tipo de relacionamento.
Para esse domnio de problema, precisei pensar no prdio como um TODO. Isso
parece plausvel, pois nesse domnio de problema necessariamente um prdio,
deveria existir para que haja um apartamento. Caso no pudesse qualificar um
prdio, nada poderia ser feito com relao quele apartamento. No se pode fazer
nada com um apartamento, vender ou alugar, enquanto ele no possuir um ende-
reo. O endereo do prdio, o apartamento tem apenas complemento. Assim,
para os fins deste software, no se conseguiria instanciar um objeto clsAparta-
mento, caso no fosse designado um objeto clsPredio.

MODELAGEM DE SISTEMAS
117

Figura 18 - Composio entre duas classes


Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

GENERALIZAO/ESPECIALIZAO

Esta associao identifica classes-me (superclasse), chamadas gerais e classes-


-filhas (subclasses), chamadas especializadas, demonstrando a ocorrncia de
herana e, possivelmente, de mtodos polimrficos nas classes especializadas.

MULTIPLICIDADE

De acordo com Guedes (2007, p. 54), a multiplicidade determina o nmero mnimo


e mximo de instncias envolvidas em cada uma das extremidades da associao,
permitindo, tambm, especificar o nvel de dependncia de um objeto para com os
outros.
Quando no existe multiplicidade explcita, entende-se que a multiplicidade
1..1, significando que uma e somente uma instncia dessa extremidade da asso-
ciao relaciona-se com as instncias da outra extremidade. A tabela seguinte,
retirada de Guedes (2007, p. 55) demonstra alguns dos diversos valores de mul-
tiplicidade que podem ser utilizados em uma associao.

Diagrama de Classes
118 UNIDADE IV

Tabela 1 Exemplos de multiplicidade

MULTIPLICIDADE SIGNIFICADO
No mnimo zero (nenhum) e no mximo um. Indica que os
objetos das classes associadas no precisam obrigatoriamente
0..1 estar relacionadas, mas se houver relacionamento indica que
apenas uma instncia da classe se relaciona com as instncias
da outra classe.
Um e somente um. Indica que apenas um objeto da classe se
1..1
relaciona com os objetos da outra classe.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
No mnimo nenhum e no mximo muitos. Indica que pode ou
0..* no haver instncias da classe participando do relacionamen-
to.
Muitos. Indica que muitos objetos da classe esto envolvidos
*
no relacionamento.
No mnimo 1 e no mximo muitos. Indica que h pelo menos
1..* um objeto envolvido no relacionamento, podendo haver mui-
tos objetos envolvidos.
No mnimo 2 e no mximo 5. Indica que existem pelo menos 2
2..5 instncias envolvidas no relacionamento e que podem ser 3, 4
ou 5 as instncias envolvidas, mas no mais do que isso.

As associaes que possuem multiplicidade do tipo muitos (*), em qualquer de


suas extremidades, foram a transmisso do atributo-chave contido na classe da
outra extremidade da associao, porm esse atributo-chave no aparece dese-
nhado na classe.

CLASSE ASSOCIATIVA

Quando um relacionamento possui multiplicidade muitos (*) em suas duas


extremidades, necessrio criar uma classe associativa para guardar os objetos
envolvidos nessa associao. Na classe associativa so definidos o conjunto de
atributos que participam da associao e no s classes que participam do relacio-
namento. Nesse caso, pelo menos os atributos-chave devem fazer parte da classe
associativa, porm, a classe associativa tambm pode possuir atributos prprios.

MODELAGEM DE SISTEMAS
119

Uma classe associativa representada por uma reta tracejada partindo do


meio da associao e atingindo uma classe. A figura a seguir apresenta um exem-
plo de classe associativa que possui atributos prprios, alm dos atributos-chave
das classes que participam da associao (s que nesse caso esses atributos-chave
no so representados no diagrama).
Figura 19 Exemplo de classe associativa

Curso
Disciplina
-nome: String
Disciplina_Curso -nome: String
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

-area: String 1..* 1..*

Disciplina_Curso
-carga_horaria: int
-serie: int

Fonte: os autores.

Neste exemplo, uma instncia da classe Curso pode se relacionar com muitas ins-
tncias da classe Disciplina, e uma instncia da classe Disciplina pode se relacionar
com muitas instncias da classe Curso. Como existe a multiplicidade muitos nas
extremidades de ambas as classes da associao, no h como reservar atribu-
tos para armazenar as informaes decorrentes da associao, pois no h como
determinar um limite para a quantidade de disciplinas que um curso pode ter e
nem h como saber em quantos cursos uma disciplina pode pertencer. Assim,
preciso criar uma classe para guardar essa informao, alm das informaes
prprias da classe, que so a carga horria da disciplina no curso e tambm a qual
srie essa disciplina estar vinculada naquele curso. Os atributos-chave das clas-
ses Curso e Disciplina so transmitidos de forma transparente pela associao,
no sendo, portanto, necessrio escrev-los como atributos da classe associativa.
Segundo Guedes (2007, p. 61), as classes associativas podem ser substitu-
das por classes normais, que, neste caso, so chamadas de classes intermedirias,
mas que desempenham exatamente a mesma funo das classes associativas. A
figura seguinte mostra o mesmo exemplo da figura 19, porm com a classe inter-
mediria ao invs da classe associativa.

Diagrama de Classes
120 UNIDADE IV

Figura 20 Exemplo de classe intermediria

Curso Disciplina_Curso
Disciplina
-nome: String -carga_horaria: int
-nome: String
-area: String 1..* -serie: int 1..*

Fonte: os autores.

ESTUDO DE CASO

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Neste estudo de caso, vou mostrar um novo documento de requisitos, agora de
um Laboratrio de Anlises Clnicas. Com base nesse documento de requisitos,
vamos elaborar o diagrama de casos de uso e, tambm, o diagrama de classes,
mas dessa vez faremos isso passo a passo.
Antes de comearmos a ler o documento de requisitos, gostaria que voc imagi-
nasse que foi a um mdico, por exemplo, um clnico geral. Para te dar um diagnstico
preciso e correto, esse mdico pediu que voc fizesse uma srie de exames, por
exemplo: hemograma, glicemia, creatinina, triglicerdeos e urocultura. Ele anotou
essa lista de exames em um Pedido de Exames e voc, de posse desse pedido, vai at
um laboratrio de anlises clnicas para fazer os exames (nesse caso, voc vai at o
Laboratrio So Joo). a que comea o nosso documento de requisitos.

DOCUMENTO DE REQUISITOS LABORATRIO DE ANLISES


CLNICAS

O Laboratrio de Anlises Clnicas So Joo deseja informatizar suas atividades,


pois hoje no h controle sobre o histrico de cada paciente (dos exames que ele
j realizou) e se gasta muito tempo com atividades que poderiam ser feitas por
um sistema informatizado.
Hoje, o laboratrio funciona da seguinte forma:
O paciente (voc) chega ao laboratrio com o pedido dos exames (pre-
enchido pelo seu mdico aquele que o clnico geral que voc acabou de
consultar, preencheu).

MODELAGEM DE SISTEMAS
121

Se for a primeira vez que o paciente vai fazer exames, preenchida uma
ficha de cadastro com os seguintes dados: nome, endereo, cidade, UF,
CEP, telefone, data de nascimento, RG e CPF.
A recepcionista (a moa que te atendeu quando voc chegou ao labora-
trio So Joo) preenche uma ficha com o nome do paciente, nome do
convnio do paciente, os nomes dos exames que o paciente ir fazer e a
data e horrio da realizao de cada exame. No final da ficha, anotada
a data em que os exames estaro prontos. A primeira via dessa ficha
entregue ao paciente (a voc).
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

O resultado do exame colocado no envelope para posterior retirada


pelo paciente.

O Laboratrio deseja que o novo sistema possa fornecer informaes rpidas,


precisas e seguras, para assim melhorar suas atividades administrativas e o atendi-
mento a seus pacientes (e nesse caso, voc vai demorar bem menos no laboratrio,
pois os processos estaro automatizados). Para tanto, o novo sistema deve:
Permitir o cadastro dos pacientes do laboratrio, com todos os dados
preenchidos hoje na ficha de cadastro. Esse cadastro ser realizado pelas
recepcionistas.
Permitir o cadastro dos exames que o laboratrio pode realizar. Cada exame
pertence a um Grupo de Exames. Por exemplo, o exame HEMOGRAMA,
pertence ao grupo SANGUE. Para cada exame preciso saber o seu cdigo,
descrio, valor e procedimentos para a sua realizao. Por exemplo, hemo-
grama: deve estar em jejum. Esse cadastro ser realizado pelos Bioqumicos.
Permitir o cadastro dos pedidos de exames dos pacientes. necessrio
saber qual o nome do paciente, o nome do mdico que est solicitando os
exames, o nome do convnio que o paciente ir utilizar para este pedido,
data e horrio dos exames (ateno: cada exame pode ser realizado em
datas e horrios diferentes), os nomes dos exames a serem feitos, data
e horrio em que cada exame ficar pronto (ateno: cada exame pode
ficar pronto em uma data e horrio diferente) e o valor de cada um
deles. Lembrando que o mdico pode solicitar mais de um exame em
cada pedido (no seu caso, o mdico solicitou 5 exames. Est lembrado
do comeo do nosso estudo de caso?). Esse cadastro ser realizado pelas
recepcionistas.

Diagrama de Classes
122 UNIDADE IV

Emitir a ficha do paciente, contendo todos os dados cadastrados. Este


relatrio ser solicitado e recebido tanto pelas recepcionistas quanto pelo
departamento administrativo do laboratrio.
Emitir relatrio com todos os exames que o laboratrio realiza com o
cdigo, a descrio, os procedimentos e valor de cada exame, agrupados
por grupo de exame, devendo ser impresso neste relatrio o cdigo e a des-
crio do grupo. O relatrio ser solicitado e recebido pelas recepcionistas.
Emitir o pedido do exame em 3 vias, com todos os dados do pedido do
exame. O relatrio ser emitido pela recepcionista, sendo que a 1 via

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
ser entregue ao paciente (comprovante da entrega do exame), a 2 via
ser entregue para o departamento de faturamento (para a cobrana dos
exames dos convnios) e a 3 via para os bioqumicos (para a realizao
dos exames).
Emitir relatrio com os resultados dos exames por pedido de exame,
contendo o nome do paciente, data e horrio do exame (da realizao do
exame), nome do mdico que solicitou o exame, nome do convnio, o
nome e o resultado de cada exame realizado, no caso de ter sido mais de
um. O relatrio ser solicitado pela recepcionista e entregue ao paciente
(no necessrio que a recepcionista fique com esse relatrio).

PASSO A PASSO PARA A ELABORAO DO DIAGRAMA DE


CASOS DE USO

1. Leia novamente o Documento de Requisitos citado anteriormente e veri-


fique quais so os usurios do sistema. Essas pessoas sero os atores. Faa
uma lista com os atores.
a. Recepcionista.
b. Bioqumicos.
c. Departamento Administrativo.
d. Departamento de Faturamento.
e. Paciente.

MODELAGEM DE SISTEMAS
123

2. Agora faa uma lista com as funcionalidades do sistema. Algumas apare-


cem descritas claramente no documento de requisitos. Cada relatrio que
mencionado no documento ser uma funcionalidade. Ento j sabemos
que teremos as seguintes funcionalidades:
a. Emitir ficha do paciente.
b. Emitir relatrio de exames.
c. Emitir pedido de exame.
d. Emitir resultados dos exames.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

3. importante observar que, alm dos relatrios, um sistema precisa ter


os cadastros para que o usurio consiga inserir os dados no sistema, para
da ser possvel emitir os relatrios. Ento, com base nos relatrios men-
cionados anteriormente, teremos os seguintes cadastros:
a. Cadastrar pacientes.
b. Cadastrar exames.
c. Cadastrar pedidos de exame.
d. Cadastrar resultados dos exames.
4. Cada uma das funcionalidades relacionadas anteriormente ser um caso
de uso em nosso diagrama. Ento, agora voc precisa verificar qual (is)
ator (es) estar(o) envolvido(s) em cada caso de uso. Isso voc descobre
fazendo uma nova leitura do documento de requisitos.
5. Alm das funcionalidades j relacionadas, importante pensar que algu-
mas informaes podem ser transformadas em classes, facilitando o uso e
manuteno do sistema. Por exemplo: o sistema pode ter, alm dos cadas-
tros relacionados, um cadastro de mdico, evitando que a recepcionista
precisasse digitar o nome completo do mdico toda vez que um pedido
de exame daquele mdico fosse lanado no sistema. Seguindo esse mesmo
raciocnio, alguns cadastros seriam importantes para o sistema:
a. Cadastro de mdicos.
b. Cadastro de convnios.
c. Cadastro de cidades.

Diagrama de Classes
124 UNIDADE IV

d. Cadastro de UFs.
e. Cadastro de grupos de exames (nesse caso esse cadastro de suma
importncia, pois o relatrio de exames deve ser agrupado por Grupo
de Exames. Com a criao de um cadastro, evita-se de o usurio cadas-
trar o mesmo grupo vrias vezes).
6. Agora s voc utilizar a ferramenta Astah e desenhar o seu diagrama.
Depois que voc tiver terminado de desenhar o seu, veja se ficou pare-
cido com o meu. Note que o nome do caso de uso sempre comea com
um verbo.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Figura 21 Diagrama de Casos de Uso para o Laboratrio de Anlises Clnicas

Cadastrar
pedidos de
Emitir ficha do
Cadastrar exames
paciente
mdicos Depto
Administrativo
Cadastrar Emitir relatrio
pacientes de exames
Cadastrar
Recepcionista convnios
Cadastrar
cidades
Emitir resultados
dos exames
Cadastrar UFs
Cadastrar
Cadastrar resultados dos
Cadastrar
exames exames Emitir pedido
grupos de
de exames Paciente
exames

Bioqumico
Depto Faturamento
Fonte: os autores.

MODELAGEM DE SISTEMAS
125

PASSO A PASSO PARA A ELABORAO DO DIAGRAMA DE


CLASSES

1. Como voc j fez o diagrama de casos de uso vai ficar mais fcil elabo-
rar o diagrama de classes. Com base nos casos de uso que voc definiu,
voc vai fazer uma lista das possveis classes do sistema. Lembre-se que
os relatrios no sero classe por si s, mas, para emitir cada relatrio
utilizaremos diversas classes. Uma dica: se o diagrama possui um caso
de uso de cadastro, certeza de que precisar de uma classe para arma-
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

zenar os dados que sero cadastrados nesse caso de uso. Seguindo esse
raciocnio, teramos as seguintes classes:
a. Paciente.
b. Exame.
c. Pedido de Exame.
d. Resultado de Exame.
e. Mdicos.
f. Convnios.
g. Cidades.
h. UFs.
i. Grupos de Exames.
2. Agora, para cada uma das classes listadas, relacione os possveis atribu-
tos de cada uma delas. A maioria desses atributos j aparece descrita no
documento de requisitos. Nunca se esquea de voltar ao documento de
requisitos sempre que tiver dvidas.
a. Paciente: cdigo, nome, endereo, CEP, cidade, UF, telefone, data de nas-
cimento, RG e CPF.

Diagrama de Classes
126 UNIDADE IV

b. Exame: cdigo, descrio, valor, procedimentos, grupo ao qual pertence


o exame.
c. Pedido de Exame: cdigo, nome do paciente, nome do mdico, nome do con-
vnio, nomes dos exames que sero realizados, data e hora da realizao de
cada exame, data e hora em que cada exame ficar pronto, valor de cada exame.
d. Resultado de Exame: descrio do resultado (para cada exame do pedido
de exame, o resultado dever ser cadastrado).
e. Mdicos: CRM, nome (como o documento de requisitos no menciona
nada sobre os dados dos mdicos, coloquei somente os atributos que inte-

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
ressam para o pedido de exame).
f. Convnios: cdigo, nome (como o documento de requisitos no men-
ciona nada sobre os dados dos convnios, coloquei somente os atributos
que interessam para o pedido de exame).
g. Cidades: cdigo, nome, DDD (mesmo o documento de requisitos no
mencionando nada, esses atributos devem constar em qualquer classe
de cidades).
h. UFs: sigla, nome.
i. Grupos de Exames: cdigo, descrio.
j. Desenhar as classes relacionadas anteriormente, com seus respectivos atri-
butos, no Diagrama de Classes. Faremos o desenho do diagrama tambm
utilizando a ferramenta Astah e no mesmo arquivo em que j desenha-
mos o diagrama de casos de uso. Assim, ficaremos com os dois diagramas
em um nico arquivo.
3. Para cada classe desenhada no diagrama, estabelecer o seu relaciona-
mento com as demais classes. Lembre-se dos tipos de relacionamentos
que estudamos: associao (unria e binria), generalizao/especializa-
o, agregao. Releia, tambm, a explicao sobre classes associativas.
4. Depois disso, estabelecer a multiplicidade de cada relacionamento, lem-
brando-se de eliminar atributos que podem ser obtidos por meio do
relacionamento.
5. Primeiro, desenhe o seu diagrama de classes e depois compare com o
meu. Veja s como ficou o meu diagrama.

MODELAGEM DE SISTEMAS
127

Figura 22 Diagrama de Classes do Laboratrio de Anlises Clincas

Paciente Mdico Convnio


-codigo: int -CRM: int -codigo: int
-nome: String -nome: String -nome: String
-endereco: String
-CEP: String
-telefone: String
-data_nascimento: Date
-RG: String 1..* 0..* 0..*
-CPF: String
Pedido Exame Exame-Pedido Exame
1..* -codigo: int -data_realizacao_exame: Date
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

-hora_realizacao_exame: String
Cidade 0..* -data_pronto: Date
-codigo: int -hora_pronto: String
-nome: String -resultado: String
Exame-Pedido Exame
-DDD: int -valor: float
1..*
0..* Exame
-codigo: int
UF -descricao: String Grupo Exame
-sigla: String -valor: float -codigo: int
-nome: String -procedimentos: String 1..* -descricao: String

Seguem alguns esclarecimentos sobre o diagrama representado na figura 22:


1. Um pedido de exame pode estar relacionado somente um paciente, um
mdico e um convnio (no diagrama no aparece a multiplicidade 1, por
ser o valor default de um relacionamento).
2. Um pedido de exame pode estar relacionado a um ou a vrios exames
(no caso desse documento de requisitos, a 5 exames).
3. Note que os atributos: data_realizacao_exame, hora_realizao_exame,
data_pronto, hora_pronto, resultado e valor esto armazenados na classe
associativa que foi originada do relacionamento muitos para muitos entre
Pedido de Exame e Exame. Isso se deve ao fato de que, para cada exame,
esses atributos podem ser diferentes. Por exemplo: se o atributo DATA_
PRONTO tivesse sido armazenado na classe PEDIDO_EXAME, seria
possvel cadastrar somente uma data em que os exames ficariam pron-
tos. Mas, na realidade, no isso o que acontece, ou seja, em uma lista
de exames que o paciente precisa realizar pode-se ter exames que ficam
prontos em 2 dias e outros que ficam prontos em 5 dias.

Diagrama de Classes
128 UNIDADE IV

4. Veja que no foi criada uma classe RESULTADO_EXAME, pois como


somente uma descrio, decidiu-se armazen-la na classe associativa
Exame-Pedido Exame.
5. Note tambm que na classe Pedido Exame no aparece o nome do paciente
como relacionamos no item 2 desse Passo a Passo. Isto porque o nome ser
obtido por meio do relacionamento de Pedido Exame com Paciente. No
desenhamos o atributo-chave de paciente na classe Pedido Exame, mas
ele est l, ou seja, por meio dele que buscaremos o nome do paciente
na classe paciente quando precisarmos.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
6. Ao invs de termos utilizado o recurso da classe associativa, poderamos
ter utilizado o relacionamento de agregao. Veja como ficaria (sero
mostradas somente algumas classes, as demais no foram mostradas, pois
ficariam iguais ao diagrama j mostrado anteriormente).
Figura 23 Diagrama de Classes Associativas

1..* 0..*
Pedido Exame 0..*
-codigo: int

1..*
Exame-Pedido Exame
Exame
-data_realizacao_exame: Date
-codigo: int
-hora_realizacao_exame: Date
-descricao: String
-data_pronto: Date
0..* -valor: float
-hora_pronto: String
-procedimentos: String
-resultado: String
-valor: float 1..*
1..*

Grupo Exame
-codigo: int
-descricao: String

MODELAGEM DE SISTEMAS
129

FERRAMENTAS CASE (COMPUTER-AIDED


SOFTWARE ENGINEERING)

Uma ferramenta CASE um sof-


tware que pode ser utilizado para
apoiar as atividades do processo
de software, como a engenharia de
requisitos, o projeto, o desenvolvi-
mento de programa e os testes. As
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

ferramentas CASE podem incluir

shutterstock
editores de projeto, dicionrios de
dados, compiladores, depuradores,
ferramentas de construo de siste-
mas entre outros (SOMMERVILLE, 2011, p. 56).
Sommerville (2011, p. 56) mostra alguns exemplos de atividades que podem
ser automatizadas utilizando-se CASE, entre elas:
1. O desenvolvimento de modelos grficos de sistemas, como parte das espe-
cificaes de requisitos ou do projeto de software.
2. A compreenso de um projeto utilizando um dicionrio de dados que
contm informaes sobre as entidades e sua relao em um projeto.
3. A gerao de interfaces com usurios, a partir de uma descrio grfica
da interface, que criada interativamente pelo usurio.
4. A depurao de programas, pelo fornecimento de informaes sobre um
programa em execuo.
5. A traduo automatizada de programas, a partir de uma antiga verso de
uma linguagem de programao, como Cobol, para uma verso mais recente.

A tecnologia CASE est atualmente disponvel para a maioria das atividades de


rotina no processo de software, proporcionando assim algumas melhorias na
qualidade e na produtividade de software.

Ferramentas Case (Computer-Aided Software Engineering)


130 UNIDADE IV

Existem, basicamente, duas formas de classificao geral para as Ferramentas


CASE. A primeira delas divide-se em: Upper CASE, Lower CASE, Integrated-
CASE e Best in Class:
Upper CASE ou U-CASE ou Front-End: so aquelas ferramentas que esto vol-
tadas para as primeiras fases do processo de desenvolvimento de sistemas, como
anlise de requisitos, projeto lgico e documentao. So utilizadas por analistas
e pessoas mais interessadas na soluo do problema do que na implementao.
Lower CASE ou L-CASE ou Back-End: praticamente o oposto das anterior-
mente citadas, oferecem suporte nas ltimas fases do desenvolvimento, como a

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
codificao, os testes e a manuteno.
Integrated CASE ou I-CASE: este tipo de ferramenta, alm de englobar carac-
tersticas das Upper e Lower CASEs, ainda oferecem outras caractersticas, como
por exemplo, controle de verso. Entretanto, esse tipo de ferramenta somente
utilizado em projetos de desenvolvimento muito grandes, por serem bastante
caras e difceis de operar.
Best in Class ou Kit de Ferramenta: semelhante as I-CASE, os Kits de Ferramenta
tambm acompanham todo o ciclo de desenvolvimento, entretanto, possuem a
propriedade de conjugar sua capacidade a outras ferramentas externas comple-
mentares, que variam de acordo com as necessidades do usurio. Para um melhor
entendimento, podemos compar-las a um computador sem o kit multimdia, as
Best in Class seriam o computador que funciona normalmente, e as outras fer-
ramentas fariam o papel do kit multimdia, promovendo um maior potencial de
trabalho mquina. So mais usadas para desenvolvimento corporativo, apresen-
tando controle de acesso, verso, repositrios de dados entre outras caractersticas.
A segunda forma divide as Ferramentas CASE em orientadas funo e
orientadas atividade:
Orientadas funo: seriam as Upper CASE e Lower CASE. Baseiam-se
na funcionalidade das ferramentas, ou seja, so aquelas que tm funes dife-
rentes no ciclo de vida de um projeto, como representar apenas o Diagrama de
Entidades e Relacionamentos (DER) ou o Diagrama de Fluxo de Dados (DFD).

MODELAGEM DE SISTEMAS
131

Orientadas a atividade: seriam as Best In Class e as I-CASE, que processam


a atividades como especificaes, modelagem e implementao.

As diferenas no so insignificantes so bem semelhantes s diferenas


Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

entre Salieri e Mozart. Estudos aps estudos demonstram que os melhores


projetistas produzem estruturas mais rpidas, menores, mais simples, mais
claras e com menos esforo.
(Frederick P. Brooks)

O que UML e Diagramas de Caso de Uso: Introduo Prtica UML


Veja no artigo escrito por Ribeiro um estudo prtico sobre UML e uma intro-
duo a um de seus principais diagramas, o diagrama de Casos de Uso. So
explicados os fundamentos de uma linguagem muito importante no s
para desenvolvedores, mas para todos os profissionais que se envolvem em
projetos de desenvolvimento de sistemas e clientes.
Leia o artigo na ntegra acessando o link disponvel em:
Fonte: Ribeiro (online).6

<http://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-intro-
ducao-pratica-a-uml/23408#ixzz3zyz3sLwB>

Ferramentas Case (Computer-Aided Software Engineering)


132 UNIDADE IV

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
shutterstock

CONCEITOS BSICOS DE ORIENTAO A OBJETOS

A UML totalmente baseada no paradigma de orientao a objetos (OO). Sendo


assim, para compreend-la corretamente, precisamos, antes, estudar alguns dos
conceitos relacionados orientao a objetos.

OBJETOS

Segundo Melo (2004, p.15), um objeto qualquer coisa, em forma concreta ou


abstrata, que exista fsica ou apenas conceitualmente no mundo real. So exem-
plos de objetos: cliente, professor, carteira, caneta, carro, disciplina, curso, caixa
de dilogo. Os objetos possuem caractersticas e comportamentos.

CLASSES

Uma classe uma abstrao de um conjunto de objetos que possuem os mesmos


tipos de caractersticas e comportamentos, sendo representada por um retn-
gulo que pode possuir at trs divises. A primeira diviso armazena o nome da
classe; a segunda, os atributos (caractersticas) da classe; e a terceira, os mtodos.

MODELAGEM DE SISTEMAS
133

Geralmente, uma classe possui atributos e mtodos, porm, possvel encontrar


classes que contenham apenas uma dessas caractersticas ou mesmo nenhuma
quando se tratar de classes abstratas. A figura 24 apresenta um exemplo de classe.
Figura 24 Exemplo de Classe

Cliente
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

De acordo com Melo (2004, p. 18), o ponto inicial para identificao de classes num
documento de requisitos assinalar os substantivos. Note que esses substantivos
podem levar a objetos fsicos (como cliente, livro, computador) ou objetos conceitu-
ais (como reserva, cronograma, norma). Em seguida, preciso identificar somente os
objetos que possuem importncia para o sistema, verificando o que realmente con-
siste em objeto e o que consiste em atributo. Ainda, preciso fazer uma nova anlise
dos requisitos para identificar classes implcitas no contexto trabalhado, excluir clas-
ses parecidas ou juntar duas classes em uma nica classe. Vale a pena ressaltar que
esse processo ser iterativo e no ser possvel definir todas as classes de uma s vez.

ATRIBUTOS

Uma classe, normalmente, possui atributos que representam as caractersticas


de uma classe, que costumam variar de objeto para objeto, como o nome em um
objeto da classe Cliente ou a cor em um objeto da classe Carro, e que permitem
diferenciar um objeto de outro da mesma classe.
De acordo com Guedes (2007, p. 32), na segunda diviso da classe, aparecem
os atributos, sendo que cada atributo deve possuir um nome e, eventualmente, o
tipo de dado que o atributo armazena, por exemplo, integer, float ou char. Assim,
a classe especifica a estrutura de um objeto sem informar quais sero os seus
valores, sendo que um objeto corresponde a uma instncia de uma classe em um
determinado momento. Vou mostrar um exemplo para facilitar o entendimento:

Conceitos Bsicos de Orientao a Objetos


134 UNIDADE IV

Uma classe pessoa possui os atributos nome, sexo e data de nascimento.


Essa classe pode ter um objeto ou instncia com os seguintes valores para cada
atributo, respectivamente, Mrcia, feminino e 22/03/1969. Dessa forma, em um
sistema, devemos trabalhar com as instncias (objetos) de uma classe, pois os
valores de cada atributo so carregados nas instncias (MELO, 2004, p. 17). A
figura seguinte mostra um exemplo de classe com atributos.
Figura 23 Exemplo de Classe com Atributos

Cidade

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
-nome: String
-sexo: char
-data_nascimento: Date

Fonte: os autores.

MTODOS

Mtodos so processos ou servios realizados por uma classe e disponibilizados


para uso de outras classes em um sistema e devem ficar armazenados na terceira
diviso da classe. Os mtodos so as atividades que uma instncia de uma classe
pode executar (GUEDES, 2007, p. 33).
Um mtodo pode receber ou no parmetros (valores que so utilizados
durante a execuo do mtodo) e pode, tambm, retornar valores, que podem
representar o resultado da operao executada ou somente indicar se o processo
foi concludo com sucesso ou no. Assim, um mtodo representa um conjunto
de instrues que so executadas quando o mtodo chamado. Um objeto da
classe Cliente, por exemplo, pode executar a atividade de incluir novo cliente. A
figura seguinte apresenta um exemplo de uma classe com mtodos.

MODELAGEM DE SISTEMAS
135

Figura 26 Exemplo de Classe com Mtodos

Cliente
-nome: String
-sexo: char
-data_nascimento: Date

+IncluirNovoCliente(): void
+AtualizarCliente(): void
Fonte: os autores.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

VISIBILIDADE

De acordo com Guedes (2007, p. 34), a visibilidade um smbolo que antecede


um atributo ou mtodo e utilizada para indicar seu nvel de acessibilidade.
Existem basicamente trs modos de visibilidade: o pblico, o protegido e o privado.
O smbolo de mais (+) indica visibilidade pblica, ou seja, significa que
o atributo ou mtodo pode ser utilizado por objetos de qualquer classe.
O smbolo de sustenido (#) indica que a visibilidade protegida, ou seja,
determina que apenas objetos da classe possuidora do atributo ou mtodo
ou de suas subclasses podem acess-lo.
O smbolo de menos (-) indica que a visibilidade privada, ou seja, somente
os objetos da classe possuidora do atributo ou mtodo podero utiliz-lo.

Note que no exemplo da classe Cliente, tanto os atributos quanto os mtodos


apresentam sua visibilidade representada esquerda de seus nomes, em que
os atributos nome, sexo e data_nascimento possuem visibilidade privada, pois
apresentam o smbolo de menos (-) esquerda da sua descrio. J os mtodos
IncluirNovoCliente() e AtualizarCliente(), possuem visibilidade pblica, como
indica o smbolo + acrescentado esquerda da sua descrio.

Conceitos Bsicos de Orientao a Objetos


136 UNIDADE IV

HERANA (GENERALIZAO/ESPECIALIZAO)

A herana permite que as classes de um sistema compartilhem atributos e mto-


dos, otimizando assim o tempo de desenvolvimento, com a diminuio de linhas
de cdigo, facilitando futuras manutenes (GUEDES, 2007, p. 35). A herana
(ou generalizao/especializao) acontece entre classes gerais (chamadas de
superclasses ou classes-me) e classes especficas (chamadas de subclasses ou
classes-filha) (BOOCH, 2005, p. 66).
A herana significa que os objetos da subclasse podem ser utilizados em qual-

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
quer local em que a superclasse ocorra, mas no vice-versa. A subclasse herda
as propriedades da me, ou seja, seus atributos e mtodos, e tambm podem
possuir atributos e mtodos prprios, alm daqueles herdados da classe-me.
De acordo com Guedes (2007, p.35), a vantagem do uso da herana que,
quando uma classe declarada com seus atributos e mtodos especficos e aps
isso uma subclasse derivada, no necessrio redeclarar os atributos e mtodos
j definidos, ou seja, por meio da herana, a subclasse os herda automaticamente,
permitindo a reutilizao do cdigo j pronto. Assim, preciso somente declarar
os atributos ou mtodos restritos da subclasse, tornando o processo de desen-
volvimento mais gil, alm de facilitar as manutenes futuras, pois, em caso
de uma alterao, ser necessrio somente alterar o mtodo da superclasse para
que todas as subclasses estejam tambm atualizadas. A figura 26 apresenta um
exemplo de herana, explicitando os papis de superclasse e subclasse e apre-
sentando tambm o smbolo de herana da UML, uma linha que liga as classes
com um tringulo tocando a superclasse.

MODELAGEM DE SISTEMAS
137

Figura 26 Exemplo de Herana

Cliente
-nome: String
-endereo: String
-cidade: String
-UF: String
-CEP: int
+IncluirNovoCliente(): void
+AtualizarCliente(): void
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Pessoa_Fsica
-CPF: int Pessoa_Jurdica
-RG: int -CNPJ: int
-sexo: char -inscrio_estadual: String
-data_nascimento: Date -razo_social: String
+ValidarCPF(): void +ValidadeCNPJ(): void

Fonte: os autores

A figura anterior mostra a superclasse Cliente com os atributos nome, endereo,


cidade, UF e CEP e os mtodos IncluirNovoCliente() e AtualizarCliente(). A sub-
classe Pessoa_Fisica herda esses atributos e mtodos, alm de possuir os atributos
CPF, RG, sexo e data_nascimento e o mtodo ValidarCPF(). A seta que aponta
para a superclasse Cliente indica a herana. A subclasse Pessoa_Juridica tam-
bm herda todos os atributos e mtodos da superclasse Cliente, alm de possuir
os atributos CNPJ, inscrio_estadual e razo_social e o mtodo ValidarCNPF().

Conceitos Bsicos de Orientao a Objetos


138 UNIDADE IV

Quando olhamos a figura 28, notamos que a classe Cliente a mais genrica e as
classes Pessoa_Fisica e Pessoa_Juridica so as mais especializadas. Ento, pode-
mos dizer que generalizamos quando partimos das subclasses para a superclasse,
e especializamos quando fazemos o contrrio, ou seja, quando partimos super-
classe para as subclasses.

POLIMORFISMO

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
O conceito de polimorfismo est associado herana, pois trabalha com a redecla-
rao de mtodos previamente herdados por uma classe. Esses mtodos, embora
parecidos, diferem de alguma forma da implementao utilizada na superclasse,
sendo preciso implement-los novamente na subclasse. Mas, a fim de no ter
que alterar o cdigo-fonte, acrescentando uma chamada a um mtodo com um
nome diferente, redeclara-se o mtodo com o mesmo nome declarado na super-
classe (GUEDES, 2007, p. 36).

De acordo com Lima (2009, p. 26), polimorfismo o princpio em que classes


derivadas (as subclasses) e uma mesma superclasse podem chamar mtodos
que tm o mesmo nome (ou a mesma assinatura), mas possuem comportamen-
tos diferentes em cada subclasse, produzindo resultados diferentes, dependen-
do de como cada objeto implementa o mtodo.

Ou seja, podem existir dois ou mais mtodos com a mesma nomenclatura, di-
ferenciando-se na maneira como foram implementados, sendo o sistema res-
ponsvel por verificar se a classe da instncia em questo possui o mtodo de-
clarado nela prpria ou se o herda de uma superclasse (GUEDES, 2007, p. 36).

MODELAGEM DE SISTEMAS
139

Por ser um exemplo bastante claro, para ilustrar o polimorfismo, utilizare-


mos o mesmo exemplo de Guedes (2007, p. 37), que est mostrado na figura
seguinte.
Figura 27 Exemplo de Polimorfismo

Conta_Coumum
-saldo: double

+Saque(): void
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Conta_Especial Conta_Poupana
-limite: double -aniversrio: Date
+Saque(): void

Fonte: Guedes (2007, p. 37).

No exemplo apresentado, na figura 27, aparece uma classe geral chamada Conta_
Comum (que, nesse caso, a superclasse), que possui um atributo chamado
Saldo, contendo o valor total depositado em uma determinada instncia da
classe e um mtodo chamado Saque. Esse mtodo somente diminui o valor a
ser debitado do saldo da conta se esse possuir o valor suficiente. Caso contrrio,
a operao no poder ser realizada, ou seja, o saque deve ser recusado pelo sis-
tema (GUEDES, 2007, p. 37).

Conceitos Bsicos de Orientao a Objetos


140 UNIDADE IV

UML UNIFIED MODELING LANGUAGE

Segundo Booch (2005, p. 13), a UML (Unified Modeling


Language ou Linguagem de Modelagem
Unificada) uma linguagem-padro para a ela-
borao da estrutura de projetos de software,
podendo ser utilizada para a visualizao,
especificao, construo e documenta-
o de artefatos de software, por meio

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
do paradigma de Orientao a Objetos.
A UML tem sido a linguagem-padro de
modelagem de software adotada interna-
cionalmente pela indstria de Engenharia
de Software (GUEDES, 2007, p. 13).
A UML no uma linguagem de progra- shutterstock

mao, mas uma linguagem de modelagem, que tem como meta auxiliar os
engenheiros de software a definir as caractersticas do software, tais como seus
requisitos, seu comportamento, sua estrutura lgica, a dinmica de seus processos
e at mesmo suas necessidades fsicas em relao ao equipamento sobre o qual o
sistema dever ser implantado. Todas essas caractersticas so definidas por meio
da UML antes do incio do desenvolvimento do software (GUEDES, 2007, p. 13).
De acordo com Booch (2005, p. 13), a UML apenas uma linguagem de
modelagem e independente de processo de software, podendo ser utilizada em
modelo cascata, desenvolvimento evolucionrio, ou qualquer outro processo que
esteja sendo utilizado para o desenvolvimento do software.
A notao UML utiliza diversos smbolos grficos, existindo uma semn-
tica bem definida para cada um deles, sendo possvel elaborar diversos modelos.
A UML tem sido empregada de maneira efetiva em sistemas cujos domnios
abrangem: os sistemas de informaes corporativos, os servios bancrios e os
financeiros, os transportes, os servios distribudos baseados na Web entre outros.
Porm, a UML no se limita modelagem de software, podendo modelar siste-
mas como o fluxo de trabalho no sistema legal, a estrutura e o comportamento
de sistemas de sade e o projeto de hardware (BOOCH, 2005, p. 17).

MODELAGEM DE SISTEMAS
141

FERRAMENTAS CASE BASEADAS NA LINGUAGEM UML

Nesta unidade, j vimos que uma ferramentas CASE (Computer-Aided Software


Engineering Engenharia de Software Auxiliada por Computador) um sof-
tware que, de alguma forma, colabora na realizao de uma ou mais atividades
realizadas durante o processo de desenvolvimento de software. Agora, vamos
ver alguns exemplos de ferramentas CASE que suportam a UML, sendo esta,
em geral, sua principal caracterstica. Existem diversas ferramentas no mercado,
dentre as quais, podemos destacar:
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Rational Rose: a ferramenta Rational Rose foi desenvolvida pela Rational


Software Corporation, empresa que estimulou a criao da UML, sendo a primeira
ferramenta CASE baseada na linguagem UML. Atualmente, essa ferramenta
bastante usada pelas empresas desenvolvedoras de software. Ela permite a mode-
lagem dos diversos diagramas da UML e tambm a construo de modelos de
dados com possibilidade de exportao para construo da base de dados ou rea-
lizao de engenharia reversa de uma base de dados existente. Em 20 de fevereiro
de 2003, a empresa Rational foi adquirida pela IBM e a ferramenta foi renome-
ada como IBM Rational Architect. Maiores informaes sobre esta ferramenta
podem ser consultadas no endereo <www.rational.com>.
Astah Professional: uma ferramenta para criao de diagramas UML,
possuindo uma verso gratuita, o Astah Community, e outras verses pagas. A
verso gratuita, que pode ser obtida no endereo <http://astah.net/download>,
possui algumas restries de funes, porm para as que precisaremos nesta
unidade ser suficiente, portanto, ser essa a ferramenta que utilizaremos para
modelar os diagramas da UML que aprenderemos. Anteriormente, essa ferra-
menta era conhecida por Jude.
Visual Paradigm for UML ou VP-UML: essa ferramenta oferece uma verso
que pode ser baixada gratuitamente, a Community Edition, porm essa verso
no suporta todos os servios e opes disponveis nas verses Standard ou
Professional da ferramenta. Para quem deseja praticar a UML, a verso gratuita
uma boa alternativa, apresentando um ambiente amigvel e de fcil compreen-
so. O download das diferentes verses da ferramenta pode ser feito em: <http://
www.visual-paradigm.com>.

Uml Unified Modeling Language


142 UNIDADE IV

Enterprise Architect: essa ferramenta no possui uma edio gratuita como


as anteriores, porm uma das ferramentas que mais oferecem recursos com-
patveis com a UML 2. Uma verso Trial para avaliao dessa ferramenta pode
ser obtida no site <www.sparxsystems.com.au>.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
CONSIDERAES FINAIS

No decorrer desta unidade estudamos sobre a importncia da modelagem de


um sistema, a partir do documento de requisitos. A modelagem a parte fun-
damental de todas as atividades, dentro de um processo de software, que levam
implantao de um bom software. Esses modelos, normalmente, so represen-
tados por meio de diagramas, em que utilizada uma notao grfica, que, em
nosso caso, foi a UML.
A UML tem muitos tipos de diagramas, apoiando a criao de diferentes
modelos de sistema, no entanto, conhecemos, nesta unidade, somente o Diagrama
de Casos de Uso e o Diagrama de Classes.
A UML no estabelece uma ordem pr-definida para a elaborao dos seus
diversos diagramas, porm, como o diagrama de casos de uso um dos diagra-
mas mais gerais e informais da UML, normalmente, a modelagem do sistema
inicia com a elaborao desse diagrama.
O diagrama de casos de uso mostra as interaes entre um sistema e seu
ambiente externo, determinando as funcionalidades e as caractersticas do sis-
tema sob o ponto de vista do usurio. Conhecemos, nesta unidade, os conceitos
necessrios para a elaborao desse diagrama: atores, casos de uso e os possveis
relacionamentos entre estes elementos.

MODELAGEM DE SISTEMAS
143

Depois que o diagrama de casos de uso elaborado fica bem mais fcil ela-
borar o diagrama de classes, que o mais importante e tambm o mais utilizado
da UML, e que define a estrutura das classes identificadas para o sistema, mos-
trando os atributos e mtodos possudos por cada uma das classes, e tambm
os seus relacionamentos.
E, para auxiliar o entendimento desses dois diagramas, foi apresentada a ela-
borao passo a passo de cada um deles. Para verificar se voc realmente entendeu
todos os conceitos, estou propondo mais um documento de requisitos nas ativi-
dades de autoestudo. Ento, mos obra!
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Consideraes Finais
144

1. Sobre relacionamento entre Casos de Uso e Atores


a. Explique o relacionamento de Associao (association).
b. Explique o relacionamento de Generalizao entre casos de uso (generaliza-
tion).
2. Com base no documento de requisitos abaixo elaborar o Diagrama de Casos de
Uso:

Sistema Controle de Cinema


Um cinema pode ter muitas salas, sendo necessrio, portanto, registrar informaes
a respeito de cada uma, como sua capacidade, ou seja, o nmero de assentos dispo-
nveis. O cinema apresenta muitos filmes. Um filme tem informaes como titulo e
durao. Assim, sempre que um filme for apresentado, deve ser registrado tambm.
Um mesmo filme pode ser apresentado em diferentes salas e em horrios diferen-
tes. Cada apresentao em uma determinada sala e horrio chamado sesso. Um
filme sendo apresentado em uma sesso tem um conjunto mximo de ingressos,
determinado pela capacidade da sala. Os clientes do cinema podem comprar ou
no ingressos para assistir a sesso. O funcionrio deve intermediar a compra do
ingresso. Um ingresso deve conter informaes como o tipo de ingresso (meio in-
gresso ou ingresso inteiro). Alm disso, um cliente s pode comprar ingressos para
sesses ainda no encerradas.
145

O que UML
UML > Unified Modeling Language (Linguagem modelada unificada) um padro para
desenvolvimento de software que rene melhores prticas de metodologia de sistemas.
Nesse modelo, diversos diagramas auxiliam na visualizao do problema e a concepo
da soluo, permitindo uma viso macro dos objetos e seus relacionamentos; ela pro-
pe uma linguagem visual para especificao (modelagem) de sistemas orientados a
objetos, fornece representao grfica para os elementos essenciais do paradigma de
objetos como classes, atributos, objetos, troca de mensagens, etc. Grandes sistemas ne-
cessitam de uma srie de especificaes e geralmente tais documentos so longos e
muito detalhados.
A modelagem proporcionada pela UML permite simplificar o entendimento de um sis-
tema, ao transformar suas complexidades em objetos grficos simples, onde a lgica
interna de seu funcionamento abstrada. Por meio da modelagem tambm consegui-
mos estruturar um sistema. A manuteno que ocorrer nos posteriores ciclos de de-
senvolvimento fica mais fcil de ser efetuada j que a ela ocorre inicialmente num nvel
lgico, e no no cdigo (programa), de forma que se pode evoluir os diagramas que
sero alterados e verificar suas consequncias, antes de se preocupar com a fase de de-
senvolvimento.
Utilizao da UML
Visualizao Facilita a comunicao entre as pessoas interessadas Especificao
Permite uma definio mais precisa dos modelos
Construo Ferramentas facilitam o mapeamento do modelo UML para linguagens
de programao.
Documentao Permite a documentao de vrios aspectos do sistema.
Melhorias & Motivao: abstrai a complexidade do negcio
Facilita melhorias .
Auxilia na identificao de novas oportunidades de negcio Melhorias no negcio
Inovaes.
Estabelece entendimento comum aos interessados no negcio: Responsveis Ge-
rentes Empregados Clientes Consumidores.
146

Estrutura Bsica da UML


Descrio de Casos de Uso.
Diagrama de Casos de Uso.
Diagrama de Classes.
Diagrama de Sequncia.
Diagrama de Atividades..
Descrio de Casos de Uso
uma descrio textual completa de um determinado processo, identificando seu ce-
nrio principal, isto , o fluxo normal que ocorreria normalmente.
Este documento estruturado descrevendo-se seus passos / instrues sem se ater a
detalhes de tecnologia, porm identificando o limite/restrio/faixa de dados.
Alm disso, aqui identificamos o(s) ator (es) que interage(m) com o sistema.
As excees (fluxos / cenrios alternativos) tambm so explicadas, porm a nfase
dada no fluxo principal.
Por meio da documentao do sistema, identificamos os atores, eventos e seus pro-
cessos, de forma a eleger os possveis Casos de Uso. O Ator pode ser entendido como
um elemento externo que interage com o sistema. Geralmente simboliza um usurio
de algum departamento, mas tambm pode simbolizar outros elementos tais como um
temporizador (relgio) que aciona o sistema de tempos em tempos para realizar alguma
ao ou sistemas externos que interagem com um determinado sistema.
Diagrama de caso de uso
Modelo grfico que agrupa determinados casos de usos e atores de um determinado
sistema, de forma a visualizar-se de maneira rpida e fcil o relacionamento entre eles,
servindo de documento para comunicao entre os participantes do projeto.
Tem o objetivo de auxiliar a comunicao entre os analistas e o cliente e descreve um
cenrio que mostra as funcionalidades do sistema do ponto de vista do usurio. O clien-
te deve ver no Diagrama de Casos de Uso as principais funcionalidades de seu sistema.
147

Notao
O diagrama de Caso de Uso representado por: atores; casos de uso; relacionamentos
entre estes elementos.
Estes relacionamentos podem ser: associaes entre atores e casos de uso; genera-
lizaes entre os atores; generalizaes, extends e includes entre os casos de uso.
Casos de uso podem opcionalmente estar envolvidos por um retngulo que represen-
ta os limites do sistema.
Atores: um ator representado por um boneco e um rtulo com o nome do ator. Um
ator um usurio do sistema, que pode ser um usurio humano ou um outro sistema.
Caso de Uso: um caso de uso representado por uma elipse e um rtulo com o nome
do caso de uso. Um caso de uso define uma grande funo do sistema. A implicao
que Diagrama de Casos de Uso uma funo pode ser estruturada em outras funes e,
portanto, um caso de uso pode ser estruturado.
Relacionamentos: entre um Ator e um caso de uso: Associao.
Leia o artigo completo no link:< http://www.purainfo.com.br/artigos/o-que-e-uml/>

Fonte: Duarte (online).7


MATERIAL COMPLEMENTAR

Vdeo que mostra uma introduo aos conceitos de orientao a objetos.


<http://www.youtube.com/watch?v=MnJLeYAno4o&feature=relmfu>.
149
REFERNCIAS

BOOCH, G. UML: guia do usurio. 2. ed. So Paulo: Campus, 2005.


DUARTE, D. O que UML. PuraInfo. (online). Disponvel em: <http://www.purainfo.
com.br/artigos/o-que-e-uml/>. Acesso em: 25 mar. 2016.
GUEDES, G. T. A. UML 2: guia prtico. So Paulo: Novatec Editora, 2007.
LIMA, A. S. UML 2.0: do requisito soluo. So Paulo: rica, 2009.
MELO, A. C. Desenvolvendo Aplicaes com UML 2.0: do conceitual implemen-
tao. Rio de Janeiro: Brasport, 2004.
RIBEIRO L. O que UML e Diagramas de Caso de Uso: Introduo Prtica UML. Dev-
media (online). Disponvel em:<http://www.devmedia.com.br/o-que-e-uml-e-dia-
gramas-de-caso-de-uso-introducao-pratica-a-uml/23408#ixzz3zyz3sLwB> Acesso
em: 26 mar. 2016
SILVA, R. P. UML 2: modelagem orientada a objetos . Florianpolis: Visual Books,
2007.
SOMMERVILLE, I. Engenharia de Software. So Paulo: Pearson Prentice Hall, 2011.
_______. I. Engenharia de Software. So Paulo: Pearson Addison-Wesley, 2007.
YOURDON, E. Anlise Estruturada Moderna. Rio de Janeiro: Elsevier, 1990.
MEDEIROS, Ernani S. de. Desenvolvendo software com UML 2.0: definitivo. So
Paulo, Pearson Makron Books, 2004, 264p.
GABARITO

1. a) Associao (association): um relacionamento que conecta duas ou mais clas-


ses, demostrando a colaborao entre as instncias de classe. Pode-se tambm
ter um relacionamento de uma classe com ela mesma, sendo que, neste caso,
tem-se a associao unria ou reflexiva.
b. Relacionamento que ocorre quando dois ou mais casos de uso tem caracters-
ticas semelhantes.
2. Sistema de Controle de Cinema:
uc Sistema de Controle de Cinema

Sistema de Controle de Cinema

Manter Salas

Manter Filmes

Manter Sesso
de Filme
Funcionrio
Vender Ingresso

Cliente
Professora Esp. Janana Aparecida de Freitas.

V
PROJETO, IMPLEMENTAO,

UNIDADE
TESTES E MANUTENO DE
SOFTWARE

Objetivos de Aprendizagem
Expor a importncia do projeto, da implementao, do teste e da
manuteno de software.
Entender o processo de teste de software, ou seja, quais os tipos de
testes que devem ser realizados no sistema.
Compreender a importncia da manuteno de software, para que
este continue til aos seus usurios.

Plano de Estudo
A seguir, apresentam-se os tpicos que voc estudar nesta unidade:
Projeto de Software
Implementao de Software
Testes de Software
Manuteno de Software
153

INTRODUO

Ol, aluno (a)! Na quarta unidade, estudamos sobre a modelagem do sistema e


aprendemos sobre Diagrama de Casos de Uso, Diagrama de Classes e Ferramentas
Case. Agora, vamos para as prximas etapas que so: o Projeto de Software, a
Implementao, o Teste e a Manuteno do software com o objetivo de compreen-
der a importncia desses conceitos como partes do processo de desenvolvimento
do software.
Nesta unidade apresentada a etapa de Projeto e vamos estudar o seu fun-
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

cionamento, as estruturas, a interface e todos os componentes necessrios para


desenvolver um sistema. Etapa em que deve ser comparado e verificado se os
requisitos do cliente podero ser atendidos e onde geramos uma descrio deta-
lhada informando tudo o que o software dever fazer e como este ir se comportar,
sempre levando em conta o que foi levantado na anlise inicial junto ao cliente.
Aps a etapa de Projeto, passamos a etapa de implementao, ou seja, onde
ocorre a programao, a codificao do cdigo e onde verificamos a linguagem
que ser usada para o desenvolvimento do software. Etapa em que construmos
o software baseado nas definies tcnicas da fase de projeto e entramos na pr-
tica do desenvolvimento do sistema.
Seguindo, temos a etapa de Testes, onde passamos a validar o sistema que foi
implementado. nessa etapa onde so testados os cdigos a procura de defeitos,
problemas que podem ocorrer na interface e outros que possam surgir quando
o sistema integrado.
E por fim, a etapa de Manuteno, onde independentemente do domnio
de aplicao, tamanho ou complexidade, o software continuar a evoluir com
o tempo. Ou seja, podem ocorrer alteraes quando so corrigidos os erros,
quando h adaptao de um novo componente, ou quando o cliente pede novas
funcionalidades.
Assim, nosso objetivo nesta unidade entender os conceitos das etapas que
envolvem o processo de software e como elas se englobam.
Vamos, portanto, aos conceitos! Boa leitura!

Introduo
154 UNIDADE V

PROJETO DE SOFTWARE

A etapa de projeto de software, segundo Pressman (2011), deve ser aplicada


em qualquer modelo de processo de software que esteja sendo utilizado para o
desenvolvimento do software e deve ser iniciada assim que os requisitos tiverem
sido analisados e modelados, constituindo a ltima ao da modelagem e pre-
parando a cena para a construo (gerao de cdigo e validao) do software.
Como disse Pressman sobre o Projeto de Software:
O Projeto o que quase todo engenheiro quer fazer. o lugar onde a

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
criatividade impera onde os requisitos dos interessados, as necessi-
dades da aplicao e consideraes tcnicas se juntam na formulao
de um produto ou sistema. O projeto cria uma representao ou mo-
delo do software, mas diferentemente do modelo de requisitos (que se
concentra na descrio do O que para ser feito: dos dados, funo
e comportamento necessrios), o modelo de projeto indica O Como
fazer, fornecendo detalhes sobre a arquitetura de software, estruturas
de dados, interfaces e componentes. (PRESSMAN, 2011, p. 2011).

De acordo com Sommerville (2011), um projeto de software a descrio da


estrutura de software a ser implementada, dos dados, das interfaces do sistema
e, algumas vezes, dos algoritmos utilizados. Um projeto deve ser desenvolvido
de forma iterativa, por meio de diferentes verses que devem ser mostradas
ao usurio para que ele ajude a decidir se o projeto realmente atende as suas
necessidades.
Segundo Pressman (2011), o pro-
jeto de software usado para criar
uma representao com detalhes sobre
a arquitetura do software, as estruturas
de dados, interfaces e componentes fun-
damentais para implementar um sistema.
Assim, ao pensarmos em projeto, deve-
mos sempre ter em mente que quanto mais
detalhado e refinado ele for, mas fcil e tranquila
ser a prxima etapa de implementao. shutterstock

PROJETO, IMPLEMENTAO, TESTES E MANUTENO DE SOFTWARE


155

Portanto, importante conhecer todas as tecnologias envolvidas na imple-


mentao do software e suas solues, caso ocorram imprevistos. A qualidade
do software pode ser avaliada nessa etapa, pois o projeto serve de base para as
etapas de implementao e teste de software.
Na etapa de projeto, deve ser considerado como o sistema funcionar inter-
namente, para que os requisitos do cliente possam ser atendidos e, para isso,
essa etapa tambm dividida em fases, ou melhor, caracterizada por um con-
junto de projetos, que ocorrem paralelamente. Conforme Sommerville (2011),
a fase de projeto deve ter:
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Projeto da Arquitetura do Software: a parte em que definimos os com-


ponentes estruturais e seus relacionamentos.
Projeto de Dados: projeto que tem como objetivo definir a estrutura de
dados para implementar o software.
Projeto de Interfaces: nessa parte descrito como ser a comunicao den-
tro do sistema, com outros sistemas e com os usurios que iro utiliz-los.
Projeto de Componentes: detalhamos os procedimentos dos componen-
tes estruturais da arquitetura do software.
Figura 1 Modelo Geral do Projeto de Software.

Especificao
de requisitos

Atividades de projeto
Projeto de
Projeto de Especificao Projeto de Projeto de Projeto de
estrutura de
arquitetura abstrata interface componente algoritmo
dados

Especificao
Arquitetura Especificao Especificao Especificao Especificao
de estrutura
de sistema de software de interface de componente de algoritmo
de dados

Produtos de projeto
Fonte: (SOMMERVILLE, 2011).

Projeto de Software
156 UNIDADE V

Geralmente, durante o projeto, o engenheiro de software ter que definir cada


componente do sistema ao nvel de detalhamento que se fizer necessrio para a
sua implementao em uma determinada linguagem de programao.
Segundo Pressman (2011), o modelo de requisitos usado para preencher
a lacuna entre uma representao sistmica que descreve o sistema (como o
usurio imagina) como um todo ou a funcionalidade de negcio, e o modelo
de projeto de software usado para descrever a arquitetura da aplicao de sof-
tware, a interface do usurio e a estrutura no nvel de componentes.
Segundo Pressman (2011, p. 207), O projeto permite que se modele o sis-

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
tema ou produto a ser construdo. O modelo pode ser avaliado em termos de
qualidade e aperfeioado ANTES de o cdigo ser gerado, ou de os testes serem
realizados, ou de os usurios finais se envolverem com grandes nmeros. Projeto
o lugar onde a qualidade do software estabelecida.

O MODELO DE PROJETO

Conforme Pressman (2011), o modelo de projeto pode ser visto em duas


dimenses diferentes: a dimenso do processo que mostra como est a evo-
luo do projeto conforme as atividades so executadas; e a dimenso da
abstrao que representa o nvel de detalhe medida que cada elemento do
modelo de anlise transformado. Em alguns casos, possvel ter uma clara
distino entre os modelos de anlise e de projeto. Na maioria dos casos, um
projeto de arquitetura preliminar prepara o terreno e seguido pelos projetos
de interfaces e projeto de componentes, que normalmente ocorrem em para-
lelo. O modelo de implantao em geral retardado at que o projeto tenha
sido completamente desenvolvido.

PROJETO, IMPLEMENTAO, TESTES E MANUTENO DE SOFTWARE


157

Figura 2 Dimenses do Modelo do Projeto

Alto
Modelo de anlise

Diagramas de classes Casos de uso - texto Diagramas de classes Requisitos:


Pacotes de anlise Diagramas de casos de uso Pacotes de anlise Restries
Modelos CRC Diagramas de atividade Modelos CRC Interoperabilidade
Diagramas de colaborao Diagramas de raia Diagramas de colaborao Metas e configuraes
Diagramas de fluxo de dados Diagramas de colaborao Diagramas de fluxo de dados
Diagramas de fluxo de controle Diagramas de estados Diagramas de fluxo de controle
Narrativas de processamento Diagramas de sequncia Narrativas de processamento
Diagramas de estados
Diagramas de sequncia
Realizao das classes de
projeto
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Subsistemas Projeto tcnico da interface


Diagramas de componentes Realizaes das classes de
Diagrama de colaborao Projeto de navegao
Classes de projeto projeto
Projeto da interface grfica do
Diagramas de atividade Subsistemas
Modelo de projeto usurio
Diagramas de sequncia Diagramas de colaborao
Refinamentos para: Diagramas de componentes
Realizaes das classes de Refinamentos para: Classes de projeto
projetos Diagramas de componentes Diagramas de atividade
Subsistemas Classes de projetos Diagramas de sequncia
Baixo Diagramas de colaborao Diagramas de atividades
Elementos da arquitetura Diagramas de sequncia Diagramas de implantao
Elementros da Elementros da Elementros de Elementros de
arquitetura interface componentes implantao

Fonte: Pressman (2011).

ELEMENTOS DE PROJETO DE DADOS

Para Pressman (2011), como ocorre em outras atividades do processo de desen-


volvimento de software, o projeto de dados cria um modelo de dados e/ou
informaes que representado em um nvel de abstrao elevado (a viso do
cliente/usurio dos dados).
Esse modelo ento refinado em representaes cada vez mais espec-
ficas da implementao que podem ser processadas pelo sistema base-
ado em computador. Em muitas aplicaes de software, a arquitetura
dos dados ter uma profunda influncia na arquitetura do software que
deve process-los. A estrutura de dados sempre foi uma importante
parte do projeto de software (PRESSMAN, 2011, p. 222).

Projeto de Software
158 UNIDADE V

ELEMENTOS DE PROJETO DE ARQUITETURA

Conforme Pressman (2011, pg. 222), o projeto de arquitetura para software o


equivalente planta baixa para uma casa. A planta baixa representa a distribui-
o dos cmodos; seus tamanhos, formas e relacionamentos entre si e as portas
e janelas que possibilitam o deslocamento para dentro e fora dos cmodos. A
planta baixa nos d uma viso geral da casa. Os elementos de projeto de arqui-
tetura nos do uma viso geral do software. Para ele, o modelo de arquitetura
obtido a partir de trs fontes:

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Informaes sobre o domnio de aplicao do software a ser construdo.
Elementos especficos de modelo de requisitos como os diagramas de
fluxo de dados ou as classes de anlise, seus relacionamentos e colabora-
es para o problema em questo.
A disponibilidade de estilos de arquitetura e padres.

ELEMENTOS DE PROJETO DE INTERFACES

Segundo Pressman (2011), o projeto de interfaces para software um conjunto


de desenhos detalhados (e especificaes) que representam os fluxos de informa-
es que entram e saem do sistema e que so transmitidos entre os componentes
definidos como parte da arquitetura.
Conforme Pressman (2011), h trs importantes elementos de projeto de
interfaces:
A interface do usurio.
Interfaces externas para outros sistemas, dispositivos, redes ou outros
produtores ou consumidores de informao.
Interfaces internas entre vrios componentes de projeto.
Os elementos citados proporcionam que o software se comunique com elemen-
tos externos e que a comunicao interna e a colaborao entre os componentes
preencham a arquitetura de software.

PROJETO, IMPLEMENTAO, TESTES E MANUTENO DE SOFTWARE


159

ELEMENTOS DE PROJETO DE COMPONENTES

Conforme Pressman (2011, pg. 224), o projeto de componentes para o software


equivale a um conjunto de desenhos detalhados (e especificaes) para cada
cmodo de uma casa. Esses desenhos representam a fiao e o encanamento den-
tro de cada cmodo, a localizao das tomadas e interruptores, torneiras, pias,
chuveiros, banheiras, ralos, armrios e banheiros. Eles tambm descrevem o piso
a ser usado, as molduras a ser aplicadas e qualquer outro detalhe associado a um
cmodo. Para ele, o projeto de componentes para software descreve completa-
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

mente os detalhes internos de cada componente de software.

O milagre mais comum da engenharia de software a transio da anlise


para o projeto e do projeto para o cdigo.
(Richard Due)

O que Projeto de Software?


Artigo que fala sobre o Projeto de software, seus conceitos de acordo com
Pressman, como o Projeto a representao significativa de alguma coisa
que ser construda. Em engenharia de software, o Projeto de Software a
fase de desenvolvimento, na qual so feitos modelos com todas as entida-
des que sero construdas posteriormente a partir dos requisitos do sistema.
Leitura muito interessante. Aproveite!
Para ler o artigo completo, acesse o site:
Disponvel em: <http://projeto-de-software.blogspot.com.br/2008/06/o-que-proje-
to-de-software.html>. Acesso em :13 jun. 2016

Fonte: Blog Projeto de Software (online)8

Projeto de Software
160 UNIDADE V

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
shutterstock

IMPLEMENTAO DE SOFTWARE

Conforme Sommerville (2011), a implementao de software o processo de


converso de uma especificao do sistema em um sistema executvel. A fase de
implementao sempre comea quando a fase de projeto tiver sido encerrada.
Na Implementao de Software onde iro ser detalhados os componentes que
foram descritos na fase de projeto, como os cdigos fonte que sero usados na
linguagem de programao e lembrando que devem ser conforme as tecnolo-
gias que foram informadas.
Na implementao, definida a linguagem de programao que pode ser
Java, C#, PHP, C++ ou qualquer outra que possa desenvolver o que foi mode-
lado na fase de projeto. O cdigo escrito por programadores e importante
que haja uma organizao na escrita das instrues. Essa organizao pode ser
definida com a criao de padres a serem seguidos pela equipe de programao.
Exemplo de padres que podem ser definidos: declarao de nomes de variveis,
formato de cabealhos, comentrios dos cdigos e como documentar o cdigo.
Nesta fase construmos os programas e eles so codificados e, tambm os
mdulos que envolvem o software so integrados.

PROJETO, IMPLEMENTAO, TESTES E MANUTENO DE SOFTWARE


161

Para Pressman (2011), os problemas de confiabilidade de software podem


quase sempre ser associados a defeitos de projeto ou de implementao. Ele
afirma que todas as falhas que um software possui esto associadas aos proble-
mas na fase de projeto e de implementao. Segundo o autor, as falhas so de
ambos, tanto do cliente, quanto de quem desenvolve o software.
A etapa de implementao uma maneira de formalizar ou mostrar, utili-
zando uma linguagem de programao, as anlises e os modelos levantados nas
fases de requisito e de projeto, gerando, assim, um sistema que possa executar
as tarefas que foram descritas pelo usurio. Para Pressman, podemos definir a
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

implementao como sendo a fase de programao que transformar o projeto


em um sistema com forma computacional mais palpvel pelo usurio.
Conforme Sommerville (2011), na etapa da implementao, o programa-
dor procura mapear corretamente as representaes (ou modelos) obtidos no
projeto nas construes suportadas por uma dada linguagem de programao.
A etapa de implementao inclui algumas atividade que devem ser desen-
volvidas, por exemplo:
Planejamento detalhado da implementao das unidades de cada iterao.
Implementao das classes e outros elementos do modelo de projeto,
geralmente arquivos de cdigo fonte.
Verificao das unidades, por meio de revises, inspees e testes de
unidade.
Compilao, ligao das unidades e integrao das unidades entre si.
Integrao das unidades com componentes reutilizados.

Ao falarmos de integrao, estamos nos referimos ligao de um componente


desenvolvido com outro que necessite de suas funcionalidades.
Conforme Tsui (2013) sempre bom saber que, para uma boa implementa-
o, so necessrias algumas caractersticas:
Legibilidade: o cdigo deve ser facilmente entendido e compreendido.
Mantenabilidade: o cdigo deve ser facilmente modificado.

Implementao de Software
162 UNIDADE V

Desempenho: o cdigo deve auxiliar para que a execuo seja rpida.


Rastreabilidade: todos os elementos do cdigo devem se relacionar a um
elemento do projeto.
Exatido: a implementao deve fazer aquilo que foi definido.
Integridade: todos os requisitos levantados devem ser atendidos.

Para obter todas essas caractersticas, necessrio um esforo, alm de ser necessrio
ter em vista que elas devem estar sempre relacionadas, pois uma influencia a outra.
Algumas empresas adotam estilos ou padres de codificao para suas imple-

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
mentaes e isso importante quando se trabalha em equipe e quando outros
programadores estiverem realizando a depurao ou a manuteno de seu cdigo
posteriormente. Tais estilos fornecem e especificam algumas regras de: atribui-
o de nomes de variveis, endentaes e estilos de comentrios, entre outros.
A seguir, vamos ver algumas questes importantes que devem ser utiliza-
das e que podem afetar o estilo das codificaes, conforme Tsui (2013, pg. 136):
Atribuio de nomes: essa questo refere-se escolha de nomes que sero
usados em variveis, classes, mtodos e outros elementos de programao.
Separao de palavras e utilizao de maisculas/minsculas: nomes podem
ser compostos por mais de uma palavra ou possuem diferentes convenes para
combinar as palavras com um identificador.
Endentao e espaamento: se referem ao acrscimo de espaos horizon-
tais antes de algumas linhas para melhorar a estrutura do cdigo.
Tamanho da funo/mtodo: cdigos com grandes funes ou mtodos so
mais propensos a erros do que os menores at certo ponto, pois, s vezes, mto-
dos muitos pequenos podem gerar muitos erros tambm.
Questes de atribuio de nomes de arquivo: um padro especificar
como devem ser atribudos os nomes de arquivos, assim facilita a localizao.
Elementos particulares de programao: temos vrias linguagens de progra-
mao diferentes e que suportam recursos diferentes, entretanto, muitos desses
recursos so considerados perigosos.

PROJETO, IMPLEMENTAO, TESTES E MANUTENO DE SOFTWARE


163

As organizaes de software apresentaram falhas significativas quanto


habilidade em capitalizar as experincias adquiridas nos projetos finaliza-
dos.
(Nasa)
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

Fbrica de Software: vantagens da Implementao do conceito em Ins-


tituio de Ensino Superior
Esse trabalho aborda os aspectos relacionados implantao de uma fbri-
ca de software em um ambiente acadmico de nvel superior, como meca-
nismo para promover a interdisciplinaridade e a criao de um ambiente
empresarial composto pelo corpo acadmico durante o perodo da gradua-
o. O trabalho utiliza como mtodo de pesquisa o Estudo de Caso, e inclui
avaliaes de projetos semelhantes em instituies de ensino superior no
Brasil. Boa leitura!
Leia na ntegra o artigo acessando o site disponvel em: <http://www.aedb.br/
seget/arquivos/artigos15/36722414.pdf

Fonte: Romanha (2015)9.

Teste de Software
164 UNIDADE V

TESTE DE SOFTWARE

Segundo Weber (2001), a qualidade de software determinada pela qualidade


dos processos que so usados durante a fase de desenvolvimento do software.
Quando se fala em qualidade de software, necessrio lembrar que o projeto
do software, o processo de desenvolvimento e o produto final tm que ter qua-
lidade tambm (Rezende, 2005).
De acordo com Molinari (2003), todo software que se destina ao pblico
e/ou ao mercado deve sofrer um nvel mnimo de teste. Assim, quanto maior

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
o nvel de complexidade do software, mais testes e tcnicas de testes se tornam
necessrios para a obteno da sua qualidade.
Sem os testes, no se consegue garantir que o software ir se comportar con-
forme o esperado ou conforme a solicitao do cliente, e isso pode ser negativo
para a empresa que o desenvolveu. Entretanto, caso a empresa no possua uma
anlise de requisitos ou uma documentao do software detalhada, a equipe de
desenvolvimento e a equipe de teste no sabero se o que est sendo constru-
do o que o cliente espera.
Conforme Molinari (2003), h alguns axiomas e conceitos que podem ser
usados no processo de teste e, em muitos casos so considerados como verda-
des no mundo dos testes. Conforme listado a seguir:
No possvel testar um programa completamente.
Teste de software um exerccio baseado em risco.
Teste no mostra que bugs no existem, mas sim, o contrrio.
Quanto mais bugs so encontrados, mais bugs podero aparecer.

O teste de software tem como objetivo mostrar que um sistema est de acordo
com as especificaes descritas no documento de requisitos e que ele atende s
expectativas do cliente comprador do sistema. Esse processo envolve verificar pro-
cessos em cada estgio do processo de software, desde a definio dos requisitos
dos usurios at o desenvolvimento de cada um dos programas que compem

PROJETO, IMPLEMENTAO, TESTES E MANUTENO DE SOFTWARE


165

o sistema. Porm, a maior parte dos custos de validao observada depois da


implementao, quando o sistema operacional testado.
Para Tsui (2013), exceto os programas mais simples, os testes de software
no podem provar que um produto funciona e, sim, que ele pode apenas encon-
trar defeitos e que ele funciona para as situaes em que foi testado, mas sem
garantir outras situaes que no foram testadas.
O processo de testes pode ocupar grande parte do cronograma de desenvol-
vimento de sistema, dependendo do cuidado com que tenham sido executadas
as atividades iniciais de especificao, projeto e implementao.
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

O que voc precisa saber sobre testes como analista de sistemas? Em muitos
casos, o analista de sistemas trabalha em estreita associao com o usurio para
desenvolver um conjunto completo e abrangente de casos de testes.
Esse processo de desenvolvimento de casos de testes de aceitao pode ser
executado em paralelo com as atividades de implementao de projeto e programa-
o, de modo que, quando os programadores tiverem terminado seus programas
e executado seus prprios testes locais, a equipe usurio/analista estar pronta
para seus prprios casos de testes (YOURDON, 1990, p.539).

TIPOS DE TESTES

Para Yourdon (1990), existem diferentes estratgias de testes, porm as duas


mais conhecidas so os testes bottom-up e os top-down. A abordagem bottom-up
comea por testar os mdulos pequenos de forma individual; essa modalidade
muitas vezes chamada de teste de unidade, teste de mdulo ou teste de programa.
Em seguida, os mdulos individuais so agrupados com outros mdulos para
serem testados em conjunto; isso costuma ser chamado de teste de subsistemas.
Conforme Sommerville (2011), todos os mdulos do sistema so combina-
dos para um teste final, que conhecido como teste do sistema, e muitas vezes
seguido pelo teste de aceitao, quando o usurio pode submeter dados reais
para verificar se o sistema est funcionando corretamente.

Teste de Software
166 UNIDADE V

A abordagem de testes top-down principia com um esqueleto do sistema, ou


seja, a estratgia de testes presume que os mdulos de execuo de alto nvel do
sistema foram desenvolvidos, mas que os mdulos de baixo nvel existem ape-
nas como simulaes, somente como prottipos. Como a maioria das funes
detalhadas do sistema no foi desenvolvida, os testes iniciais se tornam limita-
dos, sendo possvel apenas testar as interfaces entre os principais subsistemas.
Os testes seguintes tornam-se, em seguida, cada vez mais abrangentes, testando
aspectos cada vez mais detalhados do sistema.
Alm desses conceitos bsicos, voc deve conhecer os seguintes tipos de testes:

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Testes funcionais. Nesse tipo de teste o objetivo verificar se o sistema
executa corretamente as funes para os quais ele foi projetado. Portanto,
os casos de testes sero desenvolvidos e lanados no sistema; as sadas
(e os resultados da atualizao da base de dados) sero examinadas para
testar sua correo (YOURDON, 1990).
Testes de desempenho. O objetivo deste tipo de teste verificar se o sis-
tema pode manipular o volume de dados e transaes recebidas, bem como
verificar se ele apresenta o tempo de resposta necessrio (YOURDON,
1990). Isso pode exigir que a equipe de desenvolvimento execute uma srie
de testes em que a carga do sistema aumentada at que o seu desempe-
nho se torne inaceitvel (SOMMERVILLE, 2011)
Teste de Unidade. Tem por objetivo verificar um elemento que possa ser
logicamente tratado como uma unidade de implementao, por exemplo,
uma sub-rotina ou um mdulo.
Figura 3 Teste de Unidade

Mdulo
Interface
Estrutura de dados locais
Condies de limite
Caminhos independentes
Caminho de tratamento de erros

Casos de Teste
Fonte: Sommerville, (2011).

PROJETO, IMPLEMENTAO, TESTES E MANUTENO DE SOFTWARE


167

O teste de unidade ou unitrio tem como objetivo testar o funcionamento de


um determinado componente. Esse componente deve ser um item funcional
(o menor possvel), para que se possa verificar o seu correto funcionamento.
Vamos usar como exemplo uma classe determinada CLIENTE, ela pertencer a
um sistema maior que trata da comercializao de produtos alimentcios. Para
testarmos a classe CLIENTE, poderamos inserir um cliente na base e verificar
o que acontece. Validar o CPF de um determinado cliente e verificar qual o
comportamento do sistema.
Teste de Aceitao: Tem por objetivo validar o produto, ou seja, verifi-
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

car se esse atende aos requisitos especificados. Eles so executados em


ambiente o mais semelhante possvel ao ambiente real de execuo. Ele
verifica junto ao cliente se os requisitos iniciais estabelecidos para o sis-
tema realmente esto sendo entregues.

Para fazermos essa comparao, necessrio que o sistema j possua uma


verso executvel e que o cliente tenha acesso documentao produzida no
incio do projeto com suas requisies. A partir da o teste de aceitao poder
ser executado. Por exemplo, no sistema de comercializao de produtos alimen-
tcios, poderamos testar a venda de um produto, caso esse fosse um requisito
inicial do usurio/cliente.
Teste de Integrao: Tem por objetivo verificar o funcionamento de um
ou mais componentes testados unitariamente. Assim, a partir da juno
de duas classes (por exemplo) podemos trabalhar com os testes de inte-
grao dessas duas classes. Como exemplo, considerando que as classes
CLIENTE e VENDAS j tivessem sido testadas, ao testarmos a integra-
o dessas duas classes, poderamos verificar se uma determinada venda
um cliente especfico est sendo inserida ou se este cliente possui cadas-
tro ou um cliente inexistente no sistema.

Se os casos de teste forem desenvolvidos no final da etapa de projeto, com uti-


lizao do diagrama de casos de uso, diagrama de classes e da especificao de
casos de uso, no h meio de se saber como o programa funcionar quando o
desenvolvedor escrever o cdigo fonte e, desse modo, pode-se, ento, executar
o teste da caixa preta. Este tipo de teste focaliza os requisitos funcionais do sof-
tware, determinando se eles foram total ou parcialmente satisfeitos pelo produto.

Teste de Software
168 UNIDADE V

Os testes de caixa preta no verificam como ocorre o processamento, mas ape-


nas os resultados produzidos. Pressman (2011) afirma que o teste de caixa preta
pode encontrar funes incorretas ou que estejam faltando, erros de interface,
erros em estruturas de dados ou acesso a bases de dados externas, erros de com-
portamento ou de desempenho e, por ltimo, erros de inicializao e trmino.
Quando a lgica e a estrutura interna do programa so conhecidas, isto ,
depois de o programador ter escrito o programa, pode-se fundamentar os casos
de testes na lgica do programa e executar o que muitas vezes chamado de
testes de caixa de vidro ou de caixa branca. Portanto, os testes de caixa branca

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
podem, segundo Pressman (2011), garantir que todos os caminhos indepen-
dentes de um mdulo, sejam executados pelo menos uma vez, exercitar todas
as decises lgicas nos seus estados verdadeiro e falso, executar todos os ciclos
em seus limites e dentro de suas fronteiras operacionais e, por ltimo, exercitar
estruturas de dados internas para assegurar a sua validade.
Para Pressman (2011), o teste dificilmente chega ao fim, o que acontece
uma transferncia do desenvolvedor para o seu cliente, ou seja, toda vez que um
cliente usa o sistema, um teste est sendo realizado.

A melhor preparao para fazer um bom trabalho amanh fazer um bom


trabalho hoje.
(Elbert Hubbard)

PROJETO, IMPLEMENTAO, TESTES E MANUTENO DE SOFTWARE


169

Teste de Software
Artigo que mostra o que o teste do software, como ele um processo
realizado pelo testador de software que permeia outros processos da Enge-
nharia de Software, e envolve aes que vo do levantamento de requisitos
(necessidades) at a execuo do teste propriamente dito. O objetivo, por
paradoxal que parea, encontrar defeitos nos produtos, para que estes
possam ser corrigidos pela equipe de programadores, antes da entrega fi-
nal. A maioria das pessoas pensa que o teste de software serve para de-
monstrar o correto funcionamento de um programa, quando na verdade
ele utilizado como um processo da engenharia de software para encontrar
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

defeitos. Boa leitura!


Para ler na ntegra, acesse o site disponvel em: < http://imasters.com.br/arti-
go/9572/software/teste-de-software/>.

Fonte: Tozelli (online)10.

MANUTENO DE SOFTWARE

Aps a implantao de um sistema, inevitvel que ocorram mudanas, sejam


elas para pequenos ajustes ps-implantao, para melhorias substanciais, por fora
da legislao, para atender novos requisitos dos usurios e, finalmente, por estar
gerando erros.
De acordo com Sommerville (2011), cerca de dois teros de custos de sof-
tware esto relacionados evoluo do software, requerendo grande parte do
oramento de Tecnologia da Informao para todas as empresas.
O desafio da manuteno comea to logo o software colocado em funciona-
mento. Normalmente, depois que os usurios comeam a utilizar o software, eles
percebem que outras funcionalidades (ainda inexistentes) podem ser acrescenta-
das, ou seja, acabam aparecendo requisitos que o usurio no havia mencionado,
pois foi com o uso do sistema que ele passou a perceber que o software pode ofe-
recer mais do que est oferecendo.

Manuteno de Software
170 UNIDADE V

Como o sistema j est em funcionamento, essas novas funcionalidades so


consideradas como manuteno. Ou ento a manuteno se d para correo de
erros no sistema, pois descobrir todos os erros enquanto o software est na etapa
de validao bastante complexo, pois todos os caminhos possveis dentro dos
programas teriam que ser testados e nem sempre isso possvel.
O fato que a manuteno sempre vai existir e vai consumir bastante tempo
da equipe de desenvolvimento. Pressman (2011) coloca que de fato, no raro
uma organizao de software despender de 60% a 70% de todos os recursos com
manuteno de software.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Uma das razes para o problema da manuteno de software a troca das
pessoas que compem as equipes de desenvolvimento, podendo acontecer que
a equipe que desenvolveu o software inicialmente, j no se encontra mais por
perto. Ou ainda, que ningum que esteja trabalhando, atualmente, na empresa,
tenha participado da concepo do sistema. Nesse caso, se o sistema desen-
volvido estiver bem documentado, se ele tiver sido desenvolvido seguindo os
preceitos da engenharia de software, com certeza, sua alterao se tornar mais
fcil e pode-se dizer que o sistema apresenta alta manutenibilidade.
De acordo com Pressman (2011), um software manutenvel (de fcil manu-
teno) apresenta uma modularidade eficaz, utiliza padres de projeto que
permitem entend-lo com facilidade, foi construdo utilizando padres e con-
venes de codificao bem definidos. Dessa forma, tanto o projeto quanto a
implementao do software ajudaro a pessoa ou equipe que far a alterao.
Para Pressman (2011, p. 662), no nvel organizacional, a manuteno exe-
cutada por pessoal de suporte que faz parte
da organizao de engenharia de software.
Mas voc pode estar se perguntando:
por que importante a Manuteno do
Software? Pense em como o mundo muda
rapidamente. As demandas por tecnologia
de informao que suportem estas mudan-
as e exigncias no mercado, impem um
ritmo que de enorme presso competi-
tiva em todas as organizaes comerciais. shutterstock

PROJETO, IMPLEMENTAO, TESTES E MANUTENO DE SOFTWARE


171

por essa razo que o software deve ser mantido continuamente, ou seja, pas-
sar por manutenes sempre.
A manuteno e o suporte de software so atividades contnuas que ocorrem
por todo o ciclo de vida de um aplicativo. Durante essas atividades, defeitos so
corrigidos, aplicativos so adaptados a um ambiente operacional ou de negcio
em mutao, melhorias so implementadas por solicitao dos interessados e
fornecido suporte (PRESSMAN 2001, p. 677).
Segundo Garcia (2013, p. 67), softwares so produtos mutveis, isto , sofrem
diversas mudanas e correes ao longo de sua vida til. A evoluo do software
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

necessria tambm para manter sua utilidade/aplicabilidade, pois caso o cen-


rio de utilizao/contexto mude, ele precisa acompanhar/ser atualizado, caso
contrrio se tornar intil e at mesmo perigoso para a organizao.
Conforme Sommerville (2011), existem trs tipos diferentes de manuten-
o de software:
1. Manuteno para reparo de defeitos de software.
2. Manuteno para adaptar o software a um ambiente operacional diferente.
3. Manuteno para adicionar funcionalidade ao sistema ou modific-la.

A manuteno de software considerada um processo de mudanas de um sistema


depois que est em uso do cliente e geralmente aplicado em softwares que so desen-
volvidos sob encomenda. As mudanas, segundo Sommerville (2011), so mudanas
simples para corrigir erros de codificao, ou podem ser mudanas mais extensas
para corrigir erros que ocorreram no projeto ou ainda, apenas melhorias para corrigir
erros de especificaes ou para adaptar novos requisitos que o cliente tenha solicitado.

Manutenibilidade e clareza de programa so conceitos paralelos: quanto


mais difcil for entender um programa, mais difcil ser mant-lo.
(Gerald Berns)

Manuteno de Software
172 UNIDADE V

Manutenibilidade de Software
Artigo muito interessante sobre a Manuteno de software e como ela
definida como o processo de modificao de um produto de software, com-
ponente ou sistema aps a sua instalao, de forma a corrigi-lo, melhor-
-lo ou adapt-lo para uma mudana no ambiente operacional. Pensar em
manutenibilidade durante o desenvolvimento de um software, pensar em
atributos que iro facilitar a implementao de modificaes e, provavel-
mente, permitiro minimizar um panorama constante da nossa profisso.
Aproveite a leitura.

Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.
Para saber mais, leia na ntegra o artigo no site disponvel em: <http://www.
batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=132>.

Fonte: Cordeiro, M. A. (online).11

CONSIDERAES FINAIS

Nesta ltima unidade, conseguimos fechar todas as etapas do processo de software,


ou seja, j tnhamos estudado a importncia de definirmos bem os requisitos
do sistema e deixar isso devidamente anotado em um documento de requisi-
tos. E finalmente, estudamos sobre as etapas de projeto, implementao, testes
e manuteno de software.
A etapa de projeto de software se caracteriza por ser a definio fsica do sis-
tema, ou seja, onde podemos definir as interfaces do nosso sistema. Na etapa
de projeto tambm importante especificar cada caso de uso definido no dia-
grama de casos de uso. Voc deve ter notado que essa especificao vai ajudar,
e muito, o programador a escrever o cdigo fonte de cada programa, pois esta
especificao deve conter detalhes sobre as restries que cada programa deve
considerar para que o sistema, como um todo, atinja o seu objetivo.

PROJETO, IMPLEMENTAO, TESTES E MANUTENO DE SOFTWARE


173

Depois que o software foi implementado, hora dos testes, ou seja, hora
de verificar se ele realmente est funcionando. Enquanto o sistema est sendo
desenvolvido ele j est sendo testado pelas pessoas que o esto desenvolvendo,
mas isso s no basta.
Aps a implantao e efetiva utilizao do sistema pelo usurio, qualquer
alterao que seja necessria ser considerada como uma manuteno do sof-
tware. Se um software tiver uma vida longa, passar por manutenes durante
esse perodo e, para que o mesmo continue manutenvel, vimos que necess-
rio manter a aplicao das tcnicas de engenharia de software, pois nem sempre
Reproduo proibida. Art. 184 do Cdigo Penal e Lei 9.610 de 19 de fevereiro de 1998.

quem desenvolve quem vai dar manuteno no software.


Com isso, chegamos ao final das atividades bsicas do processo de software.
Espero que voc tenha conseguido entender os conceitos relacionados a essas
atividades, pois se voc entendeu, conseguir entender qualquer processo de
software que possa vir a ser adotado pela empresa que voc trabalha (ou traba-
lhar) como desenvolvedor (a).

Consideraes Finais
174

1. Na etapa de projeto, deve ser considerado, como o sistema funcionar interna-


mente, para que os requisitos do cliente possam ser atendidos e para isso, esta
etapa tambm dividida em fases, ou melhor, caracterizada por um conjunto de
projetos, que ocorrem paralelamente.
I. Projeto da Arquitetura do Software e Projeto de Dados.
II. Projeto de Interfaces e Projeto de Componentes.
III. Projeto de Espao do Software e Projeto de Dados.
IV. Projeto da Arquitetura do Software e Projeto de cones e janelas.
V. Projeto de Interfaces e Projeto de Espao do software.
Assinale a opo com a sequncia CORRETA.
a. Somente as questes I e II esto corretas.
b. Somente as questes I e III esto corretas.
c. Somente a questo I est correta.
d. Somente as questes III e V esto corretas.
e. Todas esto corretas.
2. A etapa de __________________ uma maneira de formalizar ou mostrar, uti-
lizando uma ____________________________, as ________________ e os
__________________ levantados nas fases de requisito e de projeto, e gerando
assim um sistema que possa executar as tarefas que foram descritas pelo usurio.
3. Axiomas e conceitos que podem ser usados no processo de teste em muitos ca-
sos so considerados como verdades no mundo dos testes. Marque com V (Ver-
dadeiro) e F (Falso) quais so os axiomas e conceitos utilizados:
( ) No possvel testar um programa completamente.
( ) Teste de software um exerccio baseado em risco.
( ) Teste no mostra que bugs no existem, mas sim, o contrrio.
( ) Quanto menos bugs so encontrados, mais bugs podero aparecer.
( ) Teste de software no encontra erros e nem bugs.
4. Vimos na etapa de Manuteno de Software, que, segundo Sommerville (2011)
existem trs tipos de diferentes de manuteno de software. Cite esses trs tipos.
175

Questes importantes na implementao de software


Artigo dos autores Valentim, Dias, e Pacheco (2008).
Introduo
A implementao demanda grande parte do tempo no processo de desenvolvimento de
um software, por ser uma das atividades mais trabalhosas e exigir grandes habilidades do
profissional da rea de informtica. Assim, antes de se iniciar a etapa de implementao de
um software, necessrio escolher o ambiente de programao e tratar outras questes
que possam influenciar direta ou indiretamente no bom desempenho desta atividade.
Alm da escolha do ambiente de programao, existem boas prticas a serem seguidas
para facilitar, principalmente, a manuteno do software e, ainda, alguns problemas a
serem solucionados relativos documentao, s rotinas de teste, integrao da equi-
pe de desenvolvimento e composio de arquivos de configurao da aplicao. No
caso de um ambiente orientado a objetos, outros problemas surgem, como, por exem-
plo, controle de instncias e relacionamentos entre objetos e persistncia de objetos.
Assim, o objetivo deste artigo apresentar questes importantes que precisam ser con-
sideradas durante o projeto de um software para facilitar a realizao da etapa de im-
plementao.
Questes no desenvolvimento de software
A primeira questo tratada diz respeito linguagem que seria utilizada para a imple-
mentao. Considerando o caso do software ser integrado em ambientes corporativos,
a primeira deciso escolher uma tecnologia que oferea suporte ao desenvolvimento
de sistemas corporativos. Foram analisadas as plataformas: Net2 da Microsoft e a J2EE
da Sun. A segunda pode ser definida como sendo a mais indicada por ser um software
gratuito e manter um bom relacionamento com a comunidade de software livre, alm
de contar com inmeras ferramentas gratuitas.
Melhores prticas em desenvolvimento de software
Broemmer (2003) apresenta prticas de desenvolvimento que durante anos tm sido
comprovadamente as melhores. Seu foco na plataforma J2EE, no entanto, as questes
abordadas so perfeitamente praticadas em qualquer plataforma ou metodologia de
desenvolvimento de software. Aqui so consideradas trs prticas que desempenham
um importante papel na especificao de um framework.
Problema de persistncia de objetos
A persistncia refere-se ao armazenamento no voltil dos dados, ou seja, uma vez acei-
tos pelo gerenciador de banco de dados, os dados so mantidos em um dispositivo fsi-
co de armazenamento e s podem ser removidos por alguma requisio explcita a esse
gerenciador. Na orientao a objetos, a persistncia de objetos diz respeito existncia
dos objetos mesmo aps o trmino da execuo do programa.
176

O paradigma da orientao a objetos no apresenta uma soluo simples para a persis-


tncia, raramente existe disponvel um banco de dados orientado a objetos e, geralmen-
te, um banco de dados relacional utilizado para armazenar as caractersticas do objeto.
Assim, surgem problemas na persistncia de objetos.
O problema de armazenamento de objetos em estruturas relacionais j foi bastante
pesquisado e apresenta algumas solues satisfatrias. Uma delas o framework Hiber-
nate. O Hibernate um framework de persistncia de objetos sobre bancos de dados
relacionais que realiza esta atividade de maneira transparente. considerado um dos
maiores projetos de cdigo aberto desenvolvido em Java.
Problema de documentao
A questo aqui tratada a documentao das interfaces e cdigos desenvolvidos. Fa-
zendo a pergunta: quem que gosta de documentar o que implementa, em uma sala
de aula de bacharelandos em informtica ou cincia da computao possvel notar
que a documentao do software pode se tornar um problema se no abordada logo
no incio do projeto.
Durante o desenvolvimento de uma rotina, a ateno do programador est voltada
resoluo do problema. A documentao geralmente deixada para um segundo
momento, que s vezes no chega nunca. Para auxiliar nesta questo, a integrao da
documentao com o prprio cdigo uma proposta que evita que o programador
tenha que acessar outra ferramenta para documentar o que est sendo implementado.
Segundo Pamplona (2006), a linguagem Java inventou o conceito de comentrio de
documentao. Este comentrio especfico para quem precisa saber o que o cdigo
fonte faz sem ver o cdigo, ou seja, um comentrio para documentos. Este padro de
documentao chamado de JavaDoc.
Problema de testes
Murphy (2005) destaca a importncia de estar definindo testes logo no incio do pro-
cesso de desenvolvimento de um software. Ele mostra que indispensvel que cada
funcionalidade do sistema seja testada antes de sua integrao com os demais elemen-
tos da aplicao. As questes de teste abordadas contribuem para a implementao
de classes que auxiliam na realizao de testes em funcionalidades que se integraro
arquitetura.
Para a implementao das classes bsicas para teste pode ser utilizado o framework de
teste unitrio JUnit. Com este framework, possvel construir classes de testes que so
instanciadas e executadas para automatizar as atividades de teste.
177

Problema de integrao
O desenvolvimento de um sistema de grande porte pode envolver diferentes equipes
trabalhando em paralelo. Assim, para a sua integrao, necessrio o uso de uma ferra-
menta de controle de verso concorrente (CVS, do ingls Concurrent Version System). O
Eclipse pode ser o ambiente escolhido pelo fato de possuir uma interface gil, inmeros
recursos que facilitam a produo de software (assistentes e modelos) e consumir me-
nos recurso computacional do equipamento ( mais leve). Nesse ambiente, o sistema de
controle de verso j integrado, sendo necessrio somente configurar um servidor do
repositrio central.
O artigo pode ser lido na ntegra no link: disponvel em: <http://periodicos.uem.br/ojs/index.php/
RevTecnol/article/download/7985/5161>.

Fonte: Valentim, Dias, e Pacheco (2008, online).12


MATERIAL COMPLEMENTAR

Vdeo que mostra a importncia dos testes e da manuteno de um software.


<http://www.youtube.com/watch?v=G6yk7fLK3JY&feature=relmfu>.

Engenharia de Software - Conceitos e Prticas


Raul Sidnei Wazlawick
Editora:LCampus
Sinopse: O SWEBOK (Software Engineering Book of Knowledge),
organizado pela IEE Computer Society, foi um avano da rea de
engenharia de software. Adotado como padro internacional desde
2006 (ISSO/IEC TR 19759), sistematiza os conhecimentos necessrios
para todo engenheiro de software. Em Engenharia de Software,
so abordadas sete das dez reas de conhecimento relacionadas
ao SWEBOK: Teste, Manuteno, Gerenciamento de Configurao,
Gerenciamento de Engenharia, Processo de Engenharia,
Ferramentas e Mtodos e Qualidade. As demais Requisitos, Design
e Construo so abordadas no livro Anlise e Projeto de Sistemas
de Informao Orientados a Objetos (Elsevier Editora, 2011). Juntos,
eles formam a bibliografia mais completa sobre engenharia de
software editada no Brasil. A profundidade com que os tpicos
so tratados adequada a estudantes de graduao dos cursos
Sistemas de Informao e Cincia da Computao. Dessa forma,
espera-se contribuir para que esses alunos possam desempenhar adequadamente a funo de
engenheiro de software no mercado de trabalho. Alm disso, o livro tambm pode ser de grande
valia para profissionais que tenham interesse em atualizar seus conhecimentos ou dar o primeiro
passo para a implantao de processos produtivos mais organizados em suas empresas.
MATERIAL COMPLEMENTAR

Introduo ao Teste de Software


Jose Carlos Maldonado
Editora: Campus
Sinopse: O primeiro objetivo deste livro servir como livro-texto
para disciplinas de cursos relacionados ao desenvolvimento
de software como Cincia ou Engenharia da Computao e
Sistemas de Informao. Acreditamos servir, tambm, como um
texto introdutrio para profissionais da rea que necessitam
de uma fonte de consulta e aprendizado. Neste livro, tal
profissional poder encontrar as informaes bsicas relativas
s tcnicas de teste, bem como formas de aplic-las nos mais
variados domnios e tipos de software. Em 2006, a Sociedade
Brasileira de Computao (SBC) organizou o seminrio Grandes
Desafios da Computao, onde foram identificados os mais
importantes temas relacionados rea para a prxima dcada.
Dentre eles, est o desenvolvimento tecnolgico de qualidade
e, consequentemente, a disponibilizao de sistemas corretos,
confiveis e seguros.
Nota-se tambm que, nos ltimos anos, a indstria de software, no Brasil e no resto do mundo,
tem empregado cada vez mais recursos na busca pela qualidade de seus produtos e na reduo
de seus custos de desenvolvimento e manuteno.
Alm da demanda criada pelas principais companhias de desenvolvimento de software,
nota-se uma acentuada carncia de profissionais aptos a atuar na rea de qualidade e, mais
especificamente, de teste de software.

Material Complementar
REFERNCIAS

O QUE PROJETO de Software? Projeto de Software (online) Disponvel em:


<http://projeto-de-software.blogspot.com.br/2008/06/o-que-projeto-de-software.
html> Acesso em: 14 abr. 2016.
GARCIA, L. F. F. Engenharia de software I. Canoas: Editora. ULBRA, 2013.
MOLINARI, L. Testes de Software: Produzindo Sistemas Melhores e Mais Confiveis.
So Paulo, SP, rica, 2003.
PRESSMAN, R. Engenharia de Software. 7.ed. Porto Alegre: AMGH, 2011.
ROMANHA, S. D.. Fbrica de Software: Vantagens da Implementao do Conceito
em Instituio de Ensino Superior. In: Anais do VIII Simpsio de Excelncia em
Gesto e Tecnologia SEGeT: Resende, RJ, 2015.
REZENDE, D. A. Engenharia de Software e Sistemas de Informao. Rio de Janei-
ro: Editora Brasport, 2005, 3 Edio.
SOMMERVILLE, I. Engenharia de Software. So Paulo: Pearson Prentice Hall, 2011.
_____. Engenharia de Software. So Paulo: Pearson Addison-Wesley, 2007.
TOZELLI, P. Teste de Software. Imasters (online). Disponvel em: < http://imasters.
com.br/artigo/9572/software/teste-de-software/> Acesso em: 27 mar. 2016.
TSUI, F.; KARAN, O. Fundamentos de Engenharia de Software. 2 ed. Rio de Janeiro:
LTC, 2013.
VALENTIN, L. G.; DIAS, M. M. ; PACHECO, R. C. S. Questes importantes na implemen-
tao de software. Revista Tecnolgica (UEM). v. 17, 2008, p. 73-80.
YOURDON, E. Anlise Estruturada Moderna. Rio de Janeiro: Elsevier, 1990.
WEBER, K. C.; ROCHA, A. R. C.; MALDONADO, J. C. Qualidade de Software Teoria e
Prtica. So Paulo: Prentice Hall, 2001.
181
GABARITO

1. a. Somente as questes I e II esto corretas.


2. A etapa de implementao uma maneira de formalizar ou mostrar, utilizando
uma linguagem de programao, as anlises e os modelos levantados nas
fases de requisito e de projeto, e gerando assim um sistema que possa executar
as tarefas que foram descritas pelo usurio.
3. ( V ) No possvel testar um programa completamente.
( V ) Teste de software um exerccio baseado em risco.
( V ) Teste no mostra que bugs no existem, mas sim, o contrrio.
4. Os trs tipos diferentes de manuteno de software so:
1. Manuteno para reparo de defeitos de software.
2. Manuteno para adaptar o software a um ambiente operacional diferente.
3. Manuteno para adicionar funcionalidade ao sistema ou modific-la.
CONCLUSO

Neste livro, procuramos mostrar a voc a importncia da disciplina de Engenharia


de Software e como ela pode ser aplicada durante o desenvolvimento de um siste-
ma. A fim de possibilitar o seu entendimento, na unidade I, foram estudados os con-
ceitos de software e de engenharia de software. Mostramos tambm que podemos
ter vrias aplicaes para o software, desde o software embutido que pode estar
na sua mquina de lavar roupas at o software que controla um foguete espacial.
Porm, neste material procuramos utilizar exemplos que fazem parte do nosso dia a
dia, pensando em facilitar o entendimento para problema e da sua possvel soluo.
Na unidade II, trabalhamos especificamente com processos de software. Mostramos
que podem existir diversos modelos de processos de software, mas que algumas
atividades bsicas esto presentes em todos eles (s vezes com nomes diferentes,
mas esto presentes). Voc est lembrado de quais so essas atividades? As ativida-
des so: especificao de software, projeto e implementao de software, validao
de software e, por ltimo, evoluo de software.
A unidade III foi dedicada exclusivamente a explicar o que so requisitos de softwa-
re. Mostramos quais as diferenas entre os requisitos funcionais e no funcionais e a
importncia do documento de requisitos, inclusive mostrando um exemplo.
Na unidade IV, mostramos como, a partir do documento de requisitos, realizar a
modelagem do sistema, utilizando a UML. Nesta unidade, expliquei com detalhes
os Diagramas de Casos de Uso e Diagrama de Classes, dois dos mais importantes
diagramas da UML.
E, para finalizar, vimos na unidade V, as etapas de projeto, implementao, testes e
manuteno do software, permitindo que voc pudesse entender todas as etapas
envolvidas nos modelos de processos de software.
Esperamos ter alcanado o objetivo inicial, que era mostrar a importncia da Enge-
nharia de Software. Desejamos que voc seja muito feliz profissionalmente utilizan-
do os conceitos apresentados aqui e se pudermos ajudar de alguma forma, estamos
sua disposio. Desejamos muito sucesso e paz.
Prof. Mrcia.
Prof. Janana.
Prof. Talita.