Engenharia de Software

Professora Me.
Mrcia Cristina Dadalto Pascutti
ENGENHARIA DE SOFTWARE
GRADUAO
CURSO
MARING-PR
2012
Reitor: Wilson de Matos Silva

Vice-Reitor: Wilson de Matos Silva Filho
Pr-Reitor de Administrao: Wilson de Matos Silva Filho
Presidente da Mantenedora: Cludio Ferdinandi
NEAD - Ncleo de Educao a Distncia

Diretoria do NEAD: Willian Victor Kendrick de Matos Silva
Coordenao Pedaggica: Gislene Miotto Catolino Raymundo
Coordenao de Marketing: Bruno Jorge
Coordenao Comercial: Helder Machado
Coordenao de Tecnologia: Fabrcio Ricardo Lazilha
Coordenao de Curso:
Supervisora do Ncleo de Produo de Materiais: Nalva Aparecida da Rosa Moura
Capa e Editorao: Daniel Fuverki Hey, Fernando Henrique Mendes, Jaime de Marchi Junior, Jos Jhonny Coelho, Luiz
Fernando Rokubuiti e Thayla Daiany Guimares Cripaldi
Superviso de Materiais: Ndila de Almeida Toledo
Reviso Textual e Normas: Cristiane de Oliveira Alves, Gabriela Fonseca Tofanelo, Janana Bicudo Kikuchi, Jaquelina
Kutsunugi, Karla Regina dos Santos Morelli e Maria Fernanda Canova Vasconcelos.
Ficha catalogrfica elaborada pela Biblioteca Central - CESUMAR
As imagens utilizadas neste livro foram obtidas a partir dos sites PHOTOS.COM e SHUTTERSTOCK.COM.
Av. Guedner, 1610 - Jd. Aclimao - (44) 3027-6360 - CEP 87050-390 - Maring - Paran - www.cesumar.br
NEAD - Ncleo de Educao a Distncia - bl. 4 sl. 1 e 2 - (44) 3027-6363 - ead@cesumar.br - www.ead.cesumar.br
Professora Me. Mrcia Cristina Dadalto Pascutti
APRESENTAO DO REITOR
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 soluo de problemas com eficincia tornou-se uma questo de sobrevivncia no
mundo do trabalho.
Cada um de ns tem uma grande responsabilidade: as escolhas que fizermos por ns e pelos
nossos far grande diferena no futuro.
Com essa viso, o Cesumar Centro Universitrio de Maring assume o compromisso
de democratizar o conhecimento 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 Cesumar busca a integrao do ensino-pesquisa-extenso com as demandas institucionais e sociais; a realizao de uma prtica acadmica que
contribua para o desenvolvimento da conscincia social e poltica e, por fim, a democratizao
do conhecimento acadmico com a articulao e a integrao com a sociedade.
Diante disso, o Cesumar almeja ser reconhecido como uma instituio universitria de referncia regional e nacional pela qualidade e compromisso do corpo docente; aquisio de competncias institucionais para o desenvolvimento de linhas de pesquisa; consolidao da extenso
universitria; qualidade da oferta dos ensinos presencial e a distncia; bem-estar e satisfao
da comunidade interna; qualidade da gesto acadmica e administrativa; compromisso social
de incluso; processos de cooperao e parceria com o mundo do trabalho, como tambm
pelo compromisso e relacionamento permanente com os egressos, incentivando a educao
continuada.
Professor Wilson de Matos Silva
Reitor
ENGENHARIA DE SOFTWARE | Educao a Distncia
Caro aluno, ensinar no transferir conhecimento, mas criar as possibilidades para a sua
produo ou a sua construo (FREIRE, 1996, p. 25). Tenho a certeza de que no Ncleo de
Educao a Distncia do Cesumar, voc ter sua disposio todas as condies para se
fazer um competente profissional e, assim, colaborar efetivamente para o desenvolvimento da
realidade social em que est inserido.
Todas as atividades de estudo presentes neste material foram desenvolvidas para atender o
seu processo de formao e contemplam as diretrizes curriculares dos cursos de graduao,
determinadas pelo Ministrio da Educao (MEC). Desta forma, buscando atender essas
necessidades, dispomos de uma equipe de profissionais multidisciplinares para que,
independente da distncia geogrfica que voc esteja, possamos interagir e, assim, fazer-se
presentes no seu processo de ensino-aprendizagem-conhecimento.
Neste sentido, por meio de um modelo pedaggico interativo, possibilitamos que, efetivamente,
voc construa e amplie a sua rede de conhecimentos. Essa interatividade ser vivenciada
especialmente no ambiente virtual de aprendizagem AVA no qual disponibilizamos, alm do
material produzido em linguagem dialgica, aulas sobre os contedos abordados, atividades de
estudo, enfim, um mundo de linguagens diferenciadas e ricas de possibilidades efetivas para
a sua aprendizagem. Assim sendo, todas as atividades de ensino, disponibilizadas para o seu
processo de formao, tm por intuito possibilitar o desenvolvimento de novas competncias
necessrias para que voc se aproprie do conhecimento de forma colaborativa.
Portanto, recomendo que durante a realizao de seu curso, voc procure interagir com os
textos, fazer anotaes, responder s atividades de autoestudo, participar ativamente dos
fruns, ver as indicaes de leitura e realizar novas pesquisas sobre os assuntos tratados,
pois tais atividades lhe possibilitaro organizar o seu processo educativo e, assim, superar os
desafios na construo de conhecimentos. Para finalizar essa mensagem de boas-vindas, lhe
estendo o convite para que caminhe conosco na Comunidade do Conhecimento e vivencie
a oportunidade de constituir-se sujeito do seu processo de aprendizagem e membro de uma
comunidade mais universal e igualitria.
Um grande abrao e timos momentos de construo de aprendizagem!
Professora Gislene Miotto Catolino Raymundo
Coordenadora Pedaggica do NEAD- CESUMAR
APRESENTAO
Livro: ENGENHARIA DE SOFTWARE
Prezado(a) acadmico(a), com muito prazer que apresento a voc o livro de Engenharia de
Software I. Sou a professora Mrcia Cristina Dadalto Pascutti, autora deste material e, pode
ter certeza, que o mesmo foi preparado com carinho especial para que voc possa entender
o que esta disciplina pode te trazer de benefcio ao longo de sua vida como desenvolvedor de
sistemas.
Ministro esta disciplina em cursos de graduao h, praticamente, dezesseis anos. Inicialmente,
a disciplina era chamada de Anlise de Sistemas e nos ltimos anos, de Engenharia de Software,
mas sempre com o mesmo objetivo, ou seja, mostrar ao aluno o processo de desenvolvimento
de um software. Escrever este material foi um desafio, pois preciso escrever de forma clara
para que voc, querido(a) aluno(a), possa entender o meu raciocnio. Mas foi uma experincia
tima e espero que voc goste do que foi colocado aqui.
A engenharia de software possui uma gama imensa de tpicos, que no seria possvel abordar
em cinco unidades (como este livro est organizado), ento coloquei 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 que cito durante as unidades. Neles, com
certeza, voc aprender muitos outros assuntos e poder ter certeza de que a engenharia de
software realmente muito importante quando tratamos de software, como um todo.
muito importante que voc no deixe de realizar as atividades de autoestudo para fixar os
conceitos estudados durante a unidade. Lembre-se de que a unidade seguinte sempre est
vinculada com a unidade anterior, portanto, saudvel que voc entenda todo o contedo
de uma unidade para passar para a prxima. Se ainda ficar com dvida, procure realizar
pesquisas na internet e fazer as leituras complementares indicadas. Pode ter certeza que isso
o ajudar.
Este livro est organizado em cinco unidades, sendo que todas esto estreitamente
relacionadas. 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 software

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 acontecia. A proposta
da engenharia de software, portanto, tornar o desenvolvimento de software um processo
sistematizado, no qual podem ser aplicados tcnicas e mtodos necessrios para controlar a
complexidade inerente aos grandes sistemas (SOMMERVILLE, 2007, p. 4).
Gostaria de ressaltar que software compreende, alm dos programas, toda a documentao
referente aos mesmos, sendo que a engenharia de software a disciplina que trata dessa
documentao. Sendo assim, apresentarei a voc uma pequena parte dessa documentao,
pois seria necessrio mais do que um livro para tratar da documentao completa que pode
ser elaborada no desenvolvimento de um software. 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. Uma ferramenta CASE
tambm um software, s que neste caso, auxilia o desenvolvedor e no o usurio final do
sistema que est sendo desenvolvido.
Depois, na segunda unidade, comearemos a aplicar os conceitos j estudados e mostrarei
a voc que um processo de software genrico composto de algumas etapas bsicas 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 implementao do
software; iii) a validao do software e, finalmente iv) a evoluo do software. Nesta unidade,
abordarei trs modelos de processo de software, mas a literatura traz outros modelos, como,
por exemplo, o Rational Unified Proccess. 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 requisitos
de software, j que, para o desenvolvimento de um software da forma esperada pelo cliente,
fundamental que todos os requisitos tenham sido claramente definidos. Nesta unidade,
mostrarei a voc o que um documento de requisitos e porque ele to importante.
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,
como, por exemplo, o cadastro dos pacientes de uma clnica odontolgica, a emisso de
um relatrio de vendas. J os requisitos no funcionais normalmente esto relacionados s
propriedades emergentes do sistema, podendo ser aplicados ao sistema como um todo. Um
exemplo de requisito no funcional: o sistema deve ser desenvolvido em seis meses.
Todos esses requisitos, tanto os funcionais quanto os no funcionais, devem ser claramente
definidos no documento de requisitos, pois a partir desse documento que o sistema ser
modelado, projetado, implementado, ou seja, todo o desenvolvimento do sistema ser baseado
neste documento. Em alguns casos, o documento de requisitos pode servir como um contrato
entre o cliente e a empresa desenvolvedora do software.
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 que trata da modelagem do sistema. Nesta unidade, utilizaremos os
conceitos de orientao a objetos e de UML estudados na primeira unidade. A modelagem
a parte fundamental de todas as atividades relacionadas ao processo de software, sendo
que, os modelos que so construdos nesta 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.
Representaremos estes modelos por meio de diagramas, utilizando a UML como notao
grfica. Na primeira unidade j explicamos 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 elaborao dos mesmos passo
a passo. Isso foi feito para facilitar o seu entendimento, pois esses diagramas so os mais
importantes e os mais utilizados da UML, servindo de base para os demais diagramas.
E, finalmente, chegamos ltima unidade do nosso material. Essa unidade o fechamento das
etapas do processo de software, ou seja, tratar das etapas de projeto, validao e evoluo
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. Voc pode fazer isso j
utilizando uma linguagem de programao (de preferncia aquela em que voc vai implementar
o sistema) ou ento alguma ferramenta CASE para prototipao de sistema. importante que
o usurio participe ativamente deste processo, afinal, ser ele quem vai passar a maior parte
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 validado 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 continuar
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 e profissional.
Prof. Mrcia.
10
SUMRIO
UNIDADE I
INTRODUO ENGENHARIA DE SOFTWARE
SOFTWARE.............................................................................................................................19
ENGENHARIA DE SOFTWARE..............................................................................................20
TIPOS DE APLICAES DE SOFTWARE.............................................................................21
FERRAMENTAS CASE (COMPUTER-AIDED SOFTWARE ENGINEERING)........................22
CONCEITOS BSICOS DE ORIENTAO A OBJETOS........................................................24
UML UNIFIED MODELING LANGUAGE..............................................................................32
HISTRICO DA UML...............................................................................................................34
FERRAMENTAS CASE BASEADAS NA LINGUAGEM UML..................................................35
UNIDADE II
PROCESSOS DE SOFTWARE
PROCESSOS DE SOFTWARE...............................................................................................42
MODELOS DE PROCESSO DE SOFTWARE.........................................................................44
ATIVIDADES BSICAS DO PROCESSO DE SOFTWARE.....................................................54
ESPECIFICAO DE SOFTWARE.........................................................................................55
PROJETO E IMPLEMENTAO DE SOFTWARE..................................................................57
VALIDAO DE SOFTWARE..................................................................................................58
EVOLUO DE SOFTWARE..................................................................................................60
UNIDADE III
REQUISITOS DE SOFTWARE
REQUISITOS DE SOFTWARE................................................................................................67
REQUISITOS FUNCIONAIS E NO FUNCIONAIS.................................................................69
REQUISITOS DE USURIO....................................................................................................72
REQUISITOS DE SISTEMA.....................................................................................................72
O DOCUMENTO DE REQUISITOS DE SOFTWARE..............................................................73
REQUISITOS DE QUALIDADE................................................................................................78
ENGENHARIA DE REQUISITOS.............................................................................................80
ESTUDO DE VIABILIDADE.....................................................................................................81
LEVANTAMENTO E ANLISE DE REQUISITOS....................................................................83
ESPECIFICAO DE REQUISITOS........................................................................................89
VALIDAO DE REQUISITOS................................................................................................90
UNIDADE IV
MODELAGEM DE SISTEMAS
INTRODUO.........................................................................................................................97
MODELAGEM DE SISTEMAS.................................................................................................99
DIAGRAMA DE CASOS DE USO..........................................................................................101
ESTUDO DE CASO............................................................................................................... 112
DOCUMENTO DE REQUISITOS FBRICA DE COLCHES............................................ 112
DIAGRAMA DE CLASSES.................................................................................................... 115
RELACIONAMENTOS........................................................................................................... 116
MULTIPLICIDADE.................................................................................................................. 119
CLASSE ASSOCIATIVA.........................................................................................................120
ESTUDO DE CASO...............................................................................................................122
ESTUDO DE CASO 2............................................................................................................123
PASSO A PASSO PARA A ELABORAO DO DIAGRAMA DE CASOS DE USO.............125
PASSO A PASSO PARA A ELABORAO DO DIAGRAMA DE CLASSES........................127
DOCUMENTO DE REQUISITOS CONTROLE DE ESTOQUE..........................................133
UNIDADE V
PROJETO, TESTES E EVOLUO DE SOFTWARE
PROJETO DE SOFTWARE...................................................................................................140
FORMATOS DE ENTRADAS/SADAS...................................................................................155
VALIDAO DE SOFTWARE................................................................................................158
TIPOS DE TESTES................................................................................................................159
EVOLUO DE SOFTWARE................................................................................................162
CONCLUSO.........................................................................................................................166
REFERNCIAS......................................................................................................................168
UNIDADE I
INTRODUO ENGENHARIA DE SOFTWARE

Objetivos de Aprendizagem
Entender o que engenharia de software e qual a sua importncia.
Estudar os conceitos bsicos de orientao a objetos necessrios para o entendimento da UML.
Abordar a importncia da utilizao da UML para a modelagem de sistemas.
Plano de Estudo
A seguir, apresentam-se os tpicos que voc estudar nesta unidade:
Conceitos bsicos sobre Software e Engenharia de Software
Tipos de Aplicaes de Software
Ferramentas CASE
Conceitos Bsicos de Orientao a Objetos
Introduo UML
INTRODUO
Caro(a) aluno(a), nesta primeira unidade trataremos alguns conceitos relacionados 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 software. Essa crise foi originada
em funo do hardware, que nessa poca tinha seu poder de processamento e memria
aumentados, sendo que o software deveria 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-definidas, no era suficiente.
O software desenvolvido at ento, no era confivel, no era desenvolvido dentro do tempo e
custos previstos inicialmente, seu desempenho era insatisfatrio e era difcil de dar manuteno
ao mesmo. 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 mtodos necessrios para controlar a
complexidade inerente aos grandes sistemas (SOMMERVILLE, 2007, p. 4).
17
Apresentarei a voc o conceito de software e voc ver que software muito abrangente,
englobando desde os programas escritos at a documentao associada a esse software.
Cabe aqui ressaltar que essa documentao deve estar sempre atualizada, pois, caso
contrrio, ela perde o seu sentido. Para ajudar nessa tarefa de manter a documentao em
dia, podem ser utilizadas as ferramentas CASE, que tambm veremos nessa unidade. Um
detalhe interessante que uma ferramenta CASE tambm um software.
Depois, trataremos sobre a engenharia de software como um todo. Neste livro, abordarei
somente alguns tpicos da engenharia, mas, 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.
Os exemplos que sero mostrados neste livro so simples para que seja mais fcil entendermos
os conceitos apresentados, mas a engenharia de software pode ser aplicada a um conjunto
imenso de tipos diferentes de solues que requerem software. Voc, com certeza, j deve
ter utilizado um micro-ondas. Ento ... quando voc pressiona a tecla pipoca, um software
embutido que est sendo executado. Portanto, com a tecnologia que temos hoje nossa
disposio, possvel encontrar o software em muitos lugares.
Voc vai perceber que grande parte da documentao do sistema produzido a partir da
aplicao das tcnicas e mtodos da engenharia de software, grfica, ou seja, acontece
atravs de diagramas. Como a UML (Unified Modeling Language Linguagem de Modelagem
Unificada) a linguagem para modelagem mais utilizada atualmente, vamos tambm utiliz-la
neste livro.
Porm, para entender qualquer diagrama da UML necessrio conhecer alguns conceitos
relacionados orientao a objetos, como, por exemplo, classe, objeto, herana. Aps esses
conceitos serem apresentados que iniciaremos o estudo da UML.
Nesta unidade, veremos somente uma introduo sobre a UML. Voc ver como ela surgiu
18
e ver tambm que uma forma de representao orientada a objetos bastante recente. Na
unidade III que estudaremos dois dos diagramas da UML, por isso importante entender,
nesta unidade, os conceitos relacionados UML.
SOFTWARE
De acordo com Sommerville (2007, p. 4), o software composto no somente pelos programas,
mas tambm pela documentao associada a esses programas.
Para Pressman (2011, p. 32), 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 projetos de fabricao.
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 decrescida, 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 iniciais, com o software tambm acontece assim, pois alguns
defeitos ainda podem passar pela etapa de validao do software.
Quando um componente de hardware se desgasta, ele normalmente trocado por um
novo componente e o hardware volta a funcionar. Com o software isso no acontece, no
tem como simplesmente trocar o componente, pois quando um erro acontece no hardware, pode ser de projeto, de requisito mal definido, levando o software a sofrer manuteno,
que pode ser considerada mais complexa que a do hardware.
Embora a indstria caminhe para a construo com base em componentes, a maioria
19
dos softwares continua a ser construda de forma personalizada (sob encomenda).

A reutilizao de componentes de hardware parte natural do seu processo 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 encapsulam dados e o processamento aplicado a eles, possibilitando criar novas
aplicaes a partir de partes reutilizveis. Na unidade II trataremos sobre Engenharia de
Software Orientada a Reuso.
De acordo com Sommerville (2011, p. 5), a engenharia de software uma disciplina de
engenharia cujo foco est em todos os aspectos da produo de software, desde os estgios
iniciais da especificao do sistema at sua manuteno.
Como dissemos na introduo desta unidade, o termo engenharia de software relativamente
novo e foi proposto para tornar o desenvolvimento de software sistemtico, podendo
ser realizado com padres de qualidade, dentro do cronograma e do oramento previstos
inicialmente.
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 produzir 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 sistemas, o maior custo est na sua
manuteno, ou seja, nas alteraes que so realizadas depois que o sistema
implantado.
20
Alguns Fundamentos da Engenharia de Software

Por Wilson de Pdua Paula Filho
O que Engenharia de Software?
a mesma coisa que Cincia da Computao? Ou uma entre muitas especialidades da Cincia da
Computao? Ou dos Sistemas de Informao, ou do Processamento de Dados, ou da Informtica, ou
da Tecnologia da Informao? Ou uma especialidade diferente de todas as anteriores?
Na maioria das instituies brasileiras de ensino superior, o conjunto de conhecimentos e tcnicas
conhecido como Engenharia de Software ensinado em uma ou duas disciplinas dos cursos que tm
os nomes de Cincia da Computao, Informtica ou Sistemas de Informao. Raramente, em mais
disciplinas, muitas vezes opcionais, e muitas vezes oferecidas apenas em nvel de ps-graduao.
Algumas instituies oferecem cursos de ps-graduao em Engenharia de Software, geralmente no
nvel de especializao.
Neste artigo voc vai entender os fundamentos da engenharia de software. O artigo completo pode
ser acessado no endereo abaixo.
Fonte: <http://www.devmedia.com.br/artigo-engenharia-de-software-alguns-fundamentos-da-engenharia-de-software/8029>. Acesso em: 02 jun. 2012.
TIPOS DE APLICAES DE SOFTWARE

Atualmente, com o software sendo utilizado em praticamente todas as atividades exercidas
pelas pessoas, existe uma grande variedade de aplicaes de software. Vamos ver algumas
delas:

Software de sistema de acordo com Pressman (2011, p. 34), so aqueles programas desenvolvidos para atender a outros programas, como por exemplo, editores de
texto, compiladores e sistemas operacionais.
Software de aplicao so programas desenvolvidos para solucionar uma neces-
21
sidade 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 aplicaes que vo da astronomia vulcanologia, da biologia molecular fabricao automatizada, normalmente utilizando
algoritmos para processamento numrico pesado.
Software embutido controla ou gerencia dispositivos de hardware, como por

exemplo, 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, como por exemplo, sistemas especialistas, robtica, redes neurais
artificiais.
No existe computador que tenha bom senso.

Marvin Minsky, cofundador do laboratrio de inteligncia artifi cial do Instituto de Tecnologia de Massachusetts.
FERRAMENTAS CASE (COMPUTER-AIDED SOFTWARE ENGINEERING)

Uma ferramenta CASE um software que pode ser utilizado para apoiar as atividades do
processo de software, como a engenharia de requisitos, o projeto, o desenvolvimento de
programa e os testes. As ferramentas CASE podem incluir editores de projeto, dicionrios
de dados, compiladores, depuradores, ferramentas de construo de sistemas entre outros
(SOMMERVILLE, 2007, p. 56).
Sommerville (2007, 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 especificaes
de requisitos ou do projeto de software.
22
2. A compreenso de um projeto utilizando-se 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.
Existe, basicamente, duas formas de classificao geral para as Ferramentas CASE. A primeira
delas as divide em Upper CASE, Lower CASE, Integrated-CASE e Best in Class:

Upper CASE ou U-CASE ou Front-End: so aquelas ferramentas que esto voltadas

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 anteriormente

citadas, oferecem suporte nas ltimas fases do desenvolvimento, como codificao,
testes e manuteno.
Integrated CASE ou I-CASE: este tipo de ferramenta, alm de englobar caractersticas 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 complementares, 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 ferramentas
fariam o papel do kit multimdia, promovendo um maior potencial de trabalho m-
23
quina. So mais usadas para desenvolvimento corporativo, apresentando 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 diferentes 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).
Orientadas a atividade: Seriam as Best In Class e as I-CASE, que processam a atividades como especificaes, modelagem e implementao.
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
24
exista fsica ou apenas conceitualmente no mundo real. So exemplos 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 retngulo 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. 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 abaixo
apresenta um exemplo de classe.
Exemplo de uma Classe

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 conceituais (como reserva, cronograma,
norma). Em seguida, preciso identificar somente os objetos que possuem importncia para
o sistema, verificando o que realmente consiste em objeto e o que consiste em atributo. Ainda
preciso fazer uma nova anlise dos requisitos para identificar classes implcitas no contexto
trabalhado, excluir classes 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.
25
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, como, 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:
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 abaixo mostra um exemplo de classe com atributos.
Exemplo de Classe com Atributos
26
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 a seguir apresenta um exemplo de uma classe com mtodos.
Exemplo de Classe com Atributos e Mtodos

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: pblico, protegido e privado.

O smbolo de mais (+) indica visibilidade pblica, ou seja, significa que o atributo ou
mtodo pode ser utilizado por objetos de qualquer classe.
27
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.
Herana (Generalizao/Especializao)
A herana permite que as classes de um sistema compartilhem atributos e mtodos, 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 qualquer 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 desenvolvimento mais gil, alm de facilitar as manutenes futuras, pois, em caso de
28
uma alterao, ser necessrio somente alterar o mtodo da superclasse para que todas as
subclasses estejam tambm atualizadas. A figura abaixo apresenta um exemplo de herana,
explicitando os papis de superclasse e subclasse e apresentando tambm o smbolo de
herana da UML, uma linha que liga as classes com um tringulo tocando a superclasse.
Exemplo de Herana (generalizao/especializao)

Fonte: a autora
A figura acima mostra a superclasse Cliente com os atributos nome, endereo, cidade, UF e
CEP e os mtodos IncluirNovoCliente() e AtualizarCliente(). A subclasse 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.
29
A subclasse Pessoa_Juridica tambm herda todos os atributos e mtodos da superclasse

Cliente, alm de possuir os atributos CNPJ, inscrio_estadual e razo_social e o mtodo
ValidarCNPF().
Quando olhamos a figura acima, notamos que a classe Cliente a mais genrica e as classes
Pessoa_Fisica e Pessoa_Juridica so as mais especializadas. Ento, podemos dizer que
generalizamos quando partimos das subclasses para a superclasse, e especializamos quando
fazemos o contrrio, ou seja, quando partimos superclasse para as subclasses.
Polimorfismo
O conceito de polimorfismo est associado herana, pois o mesmo trabalha com a
redeclarao 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 superclasse (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 comportamentos diferentes em cada subclasse, produzindo
resultados diferentes, dependendo de como cada objeto implementa o mtodo.
Ou seja, podem existir dois ou mais mtodos com a mesma nomenclatura, diferenciandose na maneira como foram implementados, sendo o sistema responsvel por verificar se a
classe da instncia em questo possui o mtodo declarado nela prpria ou se o herda de uma
superclasse (GUEDES, 2007, p. 36).
Por ser um exemplo bastante claro, para ilustrar o polimorfismo, utilizaremos o mesmo exemplo
de Gedues (2007, p. 37), que est mostrado na figura abaixo.
30
Exemplo de Polimorfismo
Fonte: Guedes (2007, p. 37)
No exemplo apresentado acima, 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 este possuir o valor
suficiente. Caso contrrio, a operao no poder ser realizada, ou seja, o saque deve ser
recusado pelo sistema (GUEDES, 2007, p. 37).
A partir da superclasse Conta_Comum, uma nova classe foi derivada, a subclasse Conta_
Especial, que possui um atributo prprio chamado limite e possui tambm os atributos
herdados da superclasse. O atributo limite define o valor extra que pode ser sacado alm do
valor contido no saldo da conta. Por esse motivo, a classe Conta_Especial apresenta uma
31
redefinio do mtodo Saque, porque a rotina do mtodo Saque da classe Conta_Especial

diferente a do mtodo Saque declarado na classe Conta_Comum, pois preciso incluir o limite
da conta no teste para determinar se o cliente pode ou no retirar o valor solicitado. No entanto,
o nome do mtodo permanece o mesmo; apenas no momento de executar o mtodo, o sistema
dever verificar se a instncia que o chamou pertence classe Conta_Comum ou classe
Conta_Especial, executando o mtodo definido na classe em questo (GUEDES, 2007, p. 37).
<http://www.youtube.com/watch?v=MnJLeYAno4o&feature=relmfu>.
Vdeo que mostra uma introduo aos conceitos de orientao a objetos.
UML UNIFIED MODELING LANGUAGE
Fonte: <http://onlywhatmatters.wordpress.com/2011/02/20/uml-unified-modeling-language/>
32
Segundo Booch (2005, p. 13), a UML (Unified Modeling Language ou Linguagem de Modelagem
Unificada) uma linguagem-padro para a elaborao da estrutura de projetos de software,
podendo ser utilizada para a visualizao, especificao, construo e documentao de
artefatos de software, por meio do paradigma de Orientao a Objetos. A UML tem sido a
linguagem-padro de modelagem de software adotada internacionalmente pela indstria de
Engenharia de Software (GUEDES, 2007, p. 13).
A UML no uma linguagem de programao, 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 semntica bem definida para
cada um deles, sendo possvel elaborar diversos modelos. A UML tem sido empregada de
maneira efetiva em sistemas cujos domnios abrangem: sistemas de informaes corporativos,
servios bancrios e financeiros, transportes, servios distribudos baseados na Web entre
outros. Porm, a UML no se limita modelagem de software, podendo modelar sistemas
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).
33
HISTRICO DA UML
A UML originou-se da juno dos Mtodo Booch de Grady Booch, Mtodo OMT (Object Modeling
Technique) de Rumbaugh e do mtodo OOSE (Object-Oriented Software Engineering) de
Jacobson. Esses eram, at meados da dcada de 1990, as trs metodologias de modelagem
orientadas a objetos mais populares entre os profissionais da rea de engenharia de software
(GUEDES, 2007, p. 13).
Em outubro de 1994, Rumbaugh se juntou a Booch na Rational Software Corporation, iniciando
assim, oficialmente, os esforos para a criao da UML. O foco inicial do projeto era a unificao
dos mtodos Booch e OMT, o que resultou no lanamento do Mtodo Unificado no final de
1995. Logo em seguida, Jacobson juntou-se a Booch e Rumbaugh na Rational Software e seu
mtodo OOSE comeou tambm a ser incorporado nova metodologia (BOOCH, 2005). O
trabalho de Booch, Jacobson e Rumbaugh, conhecidos popularmente como Os Trs Amigos,
resultou no lanamento, em 1996, da primeira verso da UML propriamente dita, que foi
chamada de verso 0.9.
To logo a primeira verso foi lanada, diversas empresas de software passaram a contribuir
com o projeto, estabelecendo um consrcio de UML com vrias empresas que desejavam
dedicar recursos com o objetivo de trabalhar para uma definio mais forte e completa da
UML, criando-se assim a verso 1.0 da UML. Essa verso foi oferecida para padronizao
ao OMG (Object Management Group ou Grupo de Gerenciamento de Objetos) em janeiro de
1997.
De acordo com Booch (2005), entre janeiro e julho de 1997, o grupo original de parceiros
cresceu e passou a incluir praticamente todos os participantes e colaboradores da resposta
inicial ao OMG, criando uma verso revisada da UML (verso 1.1), que foi novamente oferecida
para padronizao ao OMG.
Finalmente, a UML foi adotada pela OMG em novembro de 1997, como uma linguagem padro
34
de modelagem, sendo que sua manuteno ficou sob responsabilidade da RTF (Revision
Task Force), pertencente OMG. O objetivo da RTF realizar revises nas especificaes,
referentes a erros, inconsistncias, ambiguidades e pequenas omisses, de acordo com os
comentrios da comunidade em geral (MELO, 2004, p. 31). Porm, essas revises no devem
provocar uma grande mudana no escopo original da proposta de padronizao. Nestes
ltimos anos aconteceram as seguintes revises: em julho de 1998, a UML 1.2; no final de
1998, a UML 1.3; em maio de 2001, a UML 1.4. Em agosto de 2001, a RTF submeteu ao
OMG um relatrio provisrio da UML 1.5, publicada em maro de 2003. No incio de 2005,
a verso oficial da UML 2.0, foi adotado pelo OMG. Hoje, a UML est em sua verso 2.4.1 e
sua documentao oficial pode ser consultada atravs do endereo <www.uml.org>. A grande
mudana aconteceu na verso 2.0, sendo que a maioria da bibliografia disponvel atualmente,
inclusive a que est sendo utilizada na consulta para produo deste livro, trata dessa verso.
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 software 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:
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 modelagem dos diversos diagramas da UML e
tambm a construo de modelos de dados com possibilidade de exportao para construo
da base de dados ou realizao de engenharia reversa de uma base de dados existente. Em
35
20 de fevereiro de 2003, a empresa Rational foi adquirida pela IBM e agora a ferramenta
chama-se sucedido pelo 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
ferramenta era conhecida por Jude.
Visual Paradigm for UML ou VP-UML: esta 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. Mas, para quem
deseja praticar a UML, a verso gratuita uma boa alternativa, apresentando um ambiente
amigvel e de fcil compreenso. O download das diferentes verses da ferramenta pode ser
feito em: <http://www.visual-paradigm.com>.
Enterprise Architect: esta ferramenta no possui uma edio gratuita como as anteriores,
porm uma das ferramentas que mais oferecem recursos compatveis com a UML 2.
Uma verso Trial para avaliao dessa ferramenta pode ser obtida atravs do site <www.
sparxsystems.com.au>.
CONSIDERAES FINAIS
Nesta primeira unidade foram apresentados alguns conceitos bsicos sobre engenharia 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 engenharia 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 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
36
propuseram 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 conceito 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 documentao, as pessoas, os procedimentos envolvidos. A
engenharia de software trata de todos esses aspectos, mas em nosso livro trataremos mais
especificamente da modelagem de um software, desde o levantamento dos requisitos at a
elaborao de vrios diagramas. No trataremos da implementao propriamente dita, pois
isso voc ver em outras disciplinas do curso. A implementao muito importante, por isso
voc ter disciplinas dedicadas a essa tarefa.
Todas as etapas da engenharia de software podem ser desenvolvidas com o auxlio de
ferramentas CASE, que, conforme vimos, nada mais do que um software desenvolvido
por alguma empresa, e que tem por objetivo auxiliar o desenvolvedor nas tarefas executadas
durante o desenvolvimento (desde o seu incio at a implantao do software para o usurio).
Em nossa disciplina de engenharia de software vamos utilizar a ferramenta Astah, que voc
pode baixar gratuitamente no endereo mencionado nesta unidade. Sua instalao bastante
simples e voc j pode deixar a ferramenta instalada para uso nas prximas unidades.
Estudamos tambm vrios conceitos de orientao a objetos que utilizaremos em nossa
disciplina e, com certeza, voc tambm vai utilizar quando for estudar, por exemplo, alguma
linguagem orientada ao objeto, como Java. Portanto, o entendimento desses conceitos ser de
suma importncia para todo o curso.
E, finalmente, apresentei a voc um breve histrico do que a UML e como ela foi concebida.
Utilizaremos a linguagem UML para a elaborao de diversos diagramas. Note que essa
uma linguagem padro, universal, ou seja, um diagrama produzido em nossa disciplina pode
ser lido por algum que conhea UML e que esteja do outro lado do mundo.
Essa primeira unidade foi somente um aperitivo. Agora vamos passar a estudar assuntos
especficos da disciplina e voc vai perceber que a engenharia de software muito importante
37
para o desenvolvimento de um software.
ATIVIDADE DE AUTOESTUDO
1. Uma classe um conjunto de objetos que compartilham os mesmos atributos, mtodos e relacionamentos. Sendo assim:
a) Explique o que significa instanciar uma classe.
b) Descreva o que so atributos.
2. Um dos principais recursos da orientao a objetos a Herana entre classes, uma
vez que esse recurso pode reduzir substancialmente as repeties nos projetos e
programas orientados a objetos. Dentro deste contexto:
a) Explique o que Herana.
b) Crie um exemplo de Herana com no mnimo trs classes. Neste exemplo devem
aparecer atributos tanto na superclasse quanto nas subclasses.
38
UNIDADE II
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
Processos de Software
Modelos de Processo de Software
Atividades Bsicas do Processo de Software
INTRODUO
Caro(a) aluno(a), na primeira unidade voc aprendeu alguns conceitos bsicos 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 tecnologia que
mais cresceu, e com esse crescimento vieram tambm problemas que vo desde o no
cumprimento dos prazos estabelecidos para o seu desenvolvimento at a falta de qualidade
do software desenvolvido.
Um software no pode ser desenvolvido de qualquer jeito, sem seguir critrios, sem que se
saiba qual o prximo passo a ser dado. Por isso que 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 conhecer alguns modelos
de processo que j existem em nossa literatura e que so utilizados por muitas empresas.
Esses modelos so: modelo em cascata, desenvolvimento incremental e engenharia de
software baseada em componentes. Mas, importante ressaltar que no preciso seguir um
41
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 software. 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.
Para que um software seja produzido so necessrias diversas etapas, compostas de 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 diferentes, 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 confeccionado seguindo
as especificaes definidas anteriormente.
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 evoluir para atender a essas
mudanas.
42
Vamos estudar detalhadamente cada uma das atividades mencionadas acima durante a nossa
disciplina, inclusive utilizando ferramentas automatizadas (ferramentas CASE, j estudadas
em nossa unidade I) para nos auxiliar na elaborao dos diversos documentos que sero
necessrios.
Para Sommerville (2011, p. 19), os processos de software so complexos 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.
Mas o que acontece que nem sempre as empresas aproveitam as boas tcnicas da
engenharia de software em seu desenvolvimento de software. E, normalmente, 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 adotado pela empresa no deve deixar de
considerar nenhuma das etapas.
O processo de desenvolvimento de software e a utilizao de ferramentas CASE

Por Maria Clara dos Santos Pinto Silveira
A presente dissertao situa-se na rea das ferramentas CASE. apresentado um estudo dos conceitos fundamentais da Engenharia de Software e so abordados diversos problemas relacionados com
o desenvolvimento de software.
So tambm apresentados os paradigmas mais conhecidos e algumas metodologias para o desenvolvimento de software. Registra ainda as caractersticas, vantagens e desvantagens das ferramentas
43
CASE.
Nesta Dissertao efetuado um estudo sobre a sistematizao do caminho a percorrer na escolha
de um ambiente CASE. Para tal so analisadas questes como: metodologia a utilizar, deciso a
tomar quanto ao produto ou produtos que correspondem s necessidades e capacidades da organizao, seleo do fornecedor, nvel de formao exigida e custos envolvidos.
Para ilustrar este estudo foi desenvolvida uma aplicao que permite ao departamento de qualidade
de uma indstria de lacticnios gerir todas as amostras e anlises efetuadas ao nvel do produtor e do
processo de fabrico. Nesta aplicao foram usadas ferramentas CASE, EasyCASE Professional 4.22
e EasyCASE Database Engineer 1.10, assim como uma base de dados, Microsoft Access 2.0.
Fonte: <http://repositorio-aberto.up.pt/handle/10216/12914>. Acesso em: 02 jun. 2012.
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 prprio, que atenda as suas necessidades.
MODELOS DE PROCESSO DE SOFTWARE

Como foi discutido anteriormente, um processo de software composto por um conjunto de
etapas que so necessrias para que um software seja produzido. Sommerville (2007) diz
que um modelo de processo de software uma representao abstrata, 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 pessoas envolvidas na engenharia de software. Alm disso, cada
modelo de processo representa um processo a partir de uma perspectiva particular, de uma
maneira que proporciona apenas informaes parciais sobre o processo.
44
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 especificao, 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 rapidamente desenvolvido a partir
de especificaes abstratas, que so ento refinadas com informaes do cliente, para
produzir um sistema que satisfaa a suas necessidades, produzindo vrias verses do
software (SOMMERVILLE, 2011).
3. Engenharia de Software Orientada a Reuso. Esse modelo parte do princpio de que
existem muitos componentes que podem ser reutilizveis. O processo de desenvolvimento do sistema se concentra em combinar 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).
O modelo em cascata
45
O modelo cascata ou ciclo de vida clssico, considerado o paradigma mais antigo da engenharia
de software, sugere uma abordagem sequencial e sistemtica para o desenvolvimento de
software, comeando com a definio dos requisitos por parte do cliente, avanando pelas
atividades de projeto e implementao de software, testes, implantao, culminando no
suporte contnuo do software concludo.
Segundo Sommerville (2007, p. 44), os principais estgios do modelo em cascata demonstram
as atividades fundamentais do desenvolvimento:
1. Anlise e definio de requisitos As funes, as restries e os objetivos do sistema so estabelecidos por meio da consulta aos usurios do sistema. Em seguida, so
definidos em detalhes e servem como uma especificao 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 estabelece 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 unidades 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 testes, o sistema de software entregue ao
cliente.
5. Operao e manuteno Normalmente (embora no necessariamente), esta a
fase mais longa do ciclo de vida. O sistema instalado e colocado em operao. A manuteno envolve corrigir erros que no foram descobertos em estgios anteriores do
ciclo de vida, melhorando a implementao 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 estgios acabam se sobrepondo,
alimentando uns aos outros de informaes. Por exemplo, durante o projeto, os problemas
com os requisitos so identificados. O que acontece que um processo de software no
46
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 incerteza 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, p. 21) e Pressman (2011, p. 61), o modelo em cascata deve ser
utilizado somente quando os requisitos so fixos e tenham pouca probabilidade de serem
alterados durante o desenvolvimento do sistema e o trabalho deve ser realizado at sua
finalizao de forma linear. Sommerville (2011, p.21) 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 cascata ainda so comumente utilizados.
<http://www.youtube.com/watch?v=vaavIT2Bqz8>.
Vdeo de demonstrao do modelo de desenvolvimento cascata simulado pelo jogo SERPG.
Desenvolvimento incremental
O desenvolvimento incremental, segundo Sommerville (2011, p. 21) tem como base a ideia
47
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.
Atividades concorrentes
Especificao
Descrio do
esboo
Verso inicial
Desenvolvimento
Verses
intermedirias
Validao
Verso final
Fonte: Sommerville (2011, p.22)
Assim, as atividades de especificao, desenvolvimento e validao so realizadas

concorrentemente com um rpido feedback entre todas as atividades. A cada nova verso, o
sistema incorpora novos requisitos definidos pelo cliente.
Para Pressman (2011, p. 63), inicialmente, necessrio desenvolver um projeto rpido que
deve se concentrar em uma representao daqueles aspectos do software que sero visveis
aos usurios finais, como, por exemplo, o layout da interface com o usurio.
O desenvolvimento incremental apresenta algumas vantagens importantes em relao ao
modelo em cascata. Sommerville (2011, p. 22) coloca 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, pois os clientes vo acompanhando o desenvolvimento
48
do software medida que novas verses so apresentadas a eles; (3) os clientes podem
comear a utilizar 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 desenvolvidos 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 ferramentas 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 sistemas 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. Para esses sistemas, recomendado um processo misto, que incorpore as melhores
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.
Engenharia de software orientada a reuso
Na maioria dos projetos de software, ocorre algum reuso de software, pois, normalmente,
49
a equipe que trabalha no projeto conhece projetos ou cdigos anlogos ao que est sendo
desenvolvido. Ela busca esses cdigos, faz as modificaes conforme a necessidade do
cliente e os incorporam em seus sistemas. Independentemente do processo de software que
est sendo utilizado, pode ocorrer 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 componentes 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
O modelo genrico de processo baseado em reuso mostrado na figura abaixo (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.
50
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 a 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 componentes que foram encontrados na etapa anterior. Se for possvel, os requisitos so ento modificados para refletir os
componentes disponveis. 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.
3. Projeto do sistema com reuso durante essa etapa, o framework do sistema 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 sistemas, nessa abordagem, pode ser parte do
processo de desenvolvimento, 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 propiciar 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.
51
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 elaborou suas metodologias
de desenvolvimento de software - PDS e de gerenciamento de projetos - EGP. Essas metodologias
evoluram, acompanhando o desenvolvimento tecnolgico 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 unifi cados 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.
Fases do PGDS
O PGDS foi criado para auxiliar o DATASUS/SE no planejamento, execuo, controle, monitoramento
e encerramento de seus projetos. Serve como um guia para Gestores, Coordenadores, 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 defi ne o comportamento e responsabilidades de um profi ssional ou grupo
de profi ssionais que participam do desenvolvimento do projeto. O comportamento representado
atravs 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.
52
Artefatos (o qu) - Em sentido amplo, o termo artefato representa um produto concreto produzido,
modifi cado ou utilizado pelas atividades de um processo. O PGDS no inclui todos os artefatos de
um projeto de desenvolvimento, mas todos os artefatos 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 tarefas que um
profi ssional, que desempenha o papel responsvel por aquela atividade, deve executar para gerar
algum resultado. As atividades envolvem a produo e modifi cao de artefatos do projeto.
Fases (quando) - As fases do PGDS apresentam a seqncia e a dependncia entre as atividades do
projeto ao longo do tempo. As atividades no fl uxo so divididas em fases do ciclo de vida do projeto e
nos papis responsveis pela execuo de cada uma.
Disponvel em: <http://189.28.128.113/pgds/>. Acesso em: 05 jun. 2012.
Caro(a) aluno(a), o DATASUS o Departamento de Informtica do Sistema nico de Sade

do Ministrio da Sade e voc pde perceber, pelo texto acima, que ele criou um processo de
software prprio. muito interessante conhecer todo o material que eles disponibilizam. Se
voc quiser conhecer, acesse o endereo <http://189.28.128.113/pgds/>. Ou ento acesse o
endereo <http://www2.datasus.gov.br/DATASUS/index.php?area=01> para ler mais sobre o
DATASUS como um todo. uma leitura bastante esclarecedora.
Disponvel em: <http://189.28.128.113/pgds/>. Acesso em 05 jun. 2012.
Modelos de Processos de Engenharia de Software

<http://xps-project.googlecode.com/svn-history/r43/trunk/outros/02_Artigo.pdf>.
53
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
as mesmas so intercaladas. A forma como essas atividades sero realizadas depende do tipo
de software, das pessoas e da organizao envolvida.
So quatro as atividades bsicas do processo de software: especificao, projeto e
implementao, validao e evoluo. E a partir de agora, iremos detalhar, de forma genrica,
sem considerar um processo de software em especfico, cada uma dessas atividades.
54
ESTUDO DO CICLO DE VIDA DO SOFTWARE EM UMA EMPRESA DE DESENVOLVIMENTO DE

SISTEMAS
Por Fabrcio Luis Marinheiro Loureno e Mrcio Alan Benine
Um estudo do ciclo de vida do software desenvolvido em uma empresa de desenvolvimento de sistemas importante, pois construir um software com qualidade demanda a utilizao e implantao de
processos e tcnicas de engenharia de software. Este processo indispensvel para que o produto
seja entregue ao cliente dentro do prazo e oramento planejado, alcanando a qualidade esperada.
Considerando-se esse procedimento, realizou-se um estudo utilizando-se uma pesquisa bibliogrfi ca,
visando encontrar referencial terico para dar sustentao questo proposta e um estudo de caso
na empresa Nippon Informtica Ltda ME. Esta empresa localizada na cidade de Batatais/SP, atua
com desenvolvimento de software para as reas Contbil, Fiscal e Recursos Humanos. No estudo
de caso buscou-se elaborar o mapeamento dos processos existentes e aps anlise dos mesmos,
propor um cenrio de soluo adequado realidade da empresa. Como resultado fi nal deste estudo,
foi apresentada uma proposta de implantao do modelo de ciclo de vida do software, proporcionando
a construo do software com qualidade; fornecendo um modelo que atenda aos padres da engenharia de software e que tenha aspectos de qualidade importantes. Concluiu-se que, cada vez mais,
empresas de desenvolvimento de sistemas necessitam adotar processos de software adequados. A
defi nio do ciclo de vida de um software importante para se ter a viso completa do desenvolvimento do software. Com isto, foi possvel defi nir etapas que abrangem desde a anlise dos requisitos at
a entrega do software para o cliente.
Fonte: <http://revistas.claretiano.edu.br/index.php/linguagemacademica/article/view/40>. Acesso em:
07 jun. 2012.
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
55
identificar as restries sobre a operao e o desenvolvimento desse sistema. Essa atividade

muito importante e crtica, pois se a definio dos requisitos no for bem realizada, com
certeza problemas posteriores no projeto e na implementao do sistema iro acontecer.
Segundo Sommerville (2011, p.24), o processo de engenharia de requisitos tem como objetivo
produzir um documento de requisitos acordados que especifica um sistema que satisfaz os
requisitos dos stakeholders.
O processo de engenharia de requisitos composto por quatro fases, conforme 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 atendidas utilizando-se as atuais tecnologias de software e hardware, disponveis na empresa. Esse estudo deve indicar se
o sistema proposto ser vivel, do ponto de vista comercial, e tambm, se poder ser
desenvolvido considerando restries oramentrias, caso as mesmas existam. Um estudo de viabilidade no deve ser caro e demorado, pois a partir do seu resultado 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 conversa 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.
3. Especificao de requisitos a atividade de traduzir as informaes coletadas
durante a fase anterior em um documento que defina um conjunto de requisitos. Tanto
os requisitos dos usurios quanto os requisitos de sistema 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 a sua pertinncia, consistncia e integralidade. Durante o processo de validao, os requisitos que
56
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 certeza, novos requisitos
surgem ao longo do processo.
PROJETO E IMPLEMENTAO DE SOFTWARE

O estgio de implementao do desenvolvimento de software o processo de converso
de uma especificao do sistema em um sistema executvel para Sommerville (2011, p.
25). Esta etapa sempre envolve processos de projeto e programao de software, porm,
se uma abordagem incremental de desenvolvimento 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.
O incio do projeto se d 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 (como, 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. Geralmente,
57
durante o projeto, o analista de sistemas 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.
A programao, normalmente comea como era de se esperar, quando termina 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 processo 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, utilizam 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 defeitos 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 processo de depurao
parte tanto do desenvolvimento quanto do teste do software.
VALIDAO DE SOFTWARE
A validao de software dedica-se a mostrar que um sistema atende tanto as especificaes
58
relacionadas no documento de requisitos, quanto s expectativas dos seus usurios. A principal

tcnica de validao, de acordo com Sommerville (2011, p. 27), o teste de programa, em que
o sistema executado com dados de testes simulados.
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 primeiro 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 processo, 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 independente 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 interaes 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 os requisitos funcionais e no funcionais definidos no documento de requisitos.
3. Teste de aceitao Nesse estgio, o sistema testado com dados reais fornecidos
pelo cliente, podendo mostrar falhas na definio de requisitos, pois os dados reais
podem exercitar o sistema de modo diferente dos dados de teste.
59
EVOLUO DE SOFTWARE
Depois que um software colocado em funcionamento, ou seja, depois que o 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 software, 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 evoluo 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 original, 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 evolucionrio, 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.
60
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 (artefatos) 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 importantes, mas vimos que a especificao do software
uma etapa imprescindvel 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. No tempo que trabalhei com desenvolvimento de sistemas vi
isso acontecer algumas vezes. E sabem o que acontece? O usurio acaba no utilizando o
sistema e assim o sistema acaba no atingindo o seu objetivo. Na prxima unidade vamos
tratar o assunto Requisitos de Software mais detalhadamente, justamente pela importncia
que mencionei acima.
Aps os requisitos estarem declarados e validados, vimos que o projeto do sistema deve ser
realizado. Nessa etapa, o sistema modelado de forma bem detalhada, pois a prxima etapa
a implementao do software. Na unidade quatro trataremos com mais detalhes sobre a
modelagem do sistema, em especial sobre a linguagem de modelagem unificada (UML
Unified Modeling Language). A implementao a escrita do sistema em uma linguagem de
programao. Nesta disciplina veremos somente a parte terica relacionada implementao,
pois a parte prtica faz parte de outras disciplinas do seu curso.
Mas, afinal, qual a diferena entre processo de software e modelo de processo de software?
Um processo de software o conjunto de atividades (mencionadas acima) e um modelo de
processo de software uma representao abstrata de um processo de software, ou seja,
define a sequncia em que as atividades 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
61
implementao inicial, expor ao comentrio do usurio/cliente e fazer seu aprimoramento por

meio de muitas verses, at que um sistema adequado tenha sido desenvolvido. Nesse modelo,
em vez de ter as atividades de especificao, desenvolvimento e validao em separado, todo
esse trabalho realizado concorrentemente. O ltimo modelo que estudamos foi a Engenharia
de Software Baseada em Reuso, que baseia-se na existncia de um nmero significativo de
componentes reusveis, sendo que o processo de desenvolvimento de sistemas se concentra
na integrao desses componentes em um sistema, em vez de partir do zero.
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 desenvolvimento de sistemas de grande porte.
O aumento na demanda por software de qualidade vem causando grande presso sobre
as empresas que trabalham com desenvolvimento de software. As entregas de software
obedecendo ao cronograma e custos previstos vm se tornando, a cada dia, um diferencial
importante nesse ramo de atividade. Por isso, as empresas procuram por processos de
software que propiciem o desenvolvimento de produtos com qualidade, e que respeitem o
custo e cronograma previstos.
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.
1. Faa um comparativo entre os Modelos de Processo de Software Modelo Cascata
e Desenvolvimento Incremental.
2. Explique cada uma das atividades bsicas que compem um processo de software.
Essas atividades devem ser realizadas sempre na ordem descrita nesta unidade?
Justifique sua resposta.
3. Considerando os modelos de processo de software apresentados nesta unidade, defina um modelo de processo de software que poderia ser utilizado por uma pequena
empresa de desenvolvimento de sistemas.
62
UNIDADE III
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
Tipos de Requisitos de Software
Documento de Requisitos
Engenharia de Requisitos
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 importantes e devem ser muito bem definidos
para que o software desenvolvido alcance 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 de software e os desenvolvedores de software.
As preferncias, preconceitos e recusas dos usurios, alm das questes polticas e
organizacionais influenciam diretamente nos requisitos do sistema, portanto, a engenharia de
software no simplesmente um processo tcnico (SOMMERVILLE, 2007, p. 78).
65
Nesta unidade, voc aprender a diferena entre os vrios tipos de requisitos 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, por exemplo, preciso, manutenibilidade,
usabilidade entre outros. O tempo de desenvolvimento no deve ultrapassar seis meses um
exemplo de requisito no funcional.
Todos os requisitos definidos, sejam eles funcionais ou no funcionais, devem estar escritos
em um documento de requisitos, que servir como base para todas as atividades subsequentes
do desenvolvimento e tambm fornecer um ponto de referncia para qualquer validao do
software construdo.
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 (levantamento 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).
66
Normalmente, os problemas que os desenvolvedores de software tm para solucionar 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 funes e das restries so
os requisitos para o sistema; e o processo de descobrir, analisar, documentar e verificar essas
funes e restries 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 vezes, o requisito visto como uma declarao 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 requisitos abstratos de alto nvel, e requisitos de sistema, para
expressar a descrio detalhada que o sistema deve fazer. Dessa forma, os requisitos de
67
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 descries
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 predefinida, ou seja, essas necessidades devem ser
redigidas de modo que os diversos fornecedores possam apresentar propostas, oferecendo,
talvez, diferentes maneiras de atender s necessidades organizacionais da sua empresa. Uma
vez estabelecido um contrato, o fornecedor precisa preparar uma definio de 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.
Mas, 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 no descarte do sistema. Portanto, o ideal que essa
etapa seja muito bem elaborada.
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.
68
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 preenchimento de determinado
objetivo. Na abordagem da engenharia de software, segundo Sommerville (2011, p. 57), os
requisitos de um sistema so as descries 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, por exemplo,
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.
De acordo com Sommerville (2011, p. 59), os requisitos de software so, normalmente,
classificados como funcionais ou no funcionais:
1. Requisitos funcionais define 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 tambm explicitamente declarar o que o sistema no deve fazer. Exemplos de requisitos funcionais: o software deve possibilitar o clculo das comisses dos vendedores 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 o mesmo foi
aprovado ou reprovado.
2. Requisitos no funcionais so os requisitos relacionados utilizao do software
em termos de desempenho, confiabilidade, segurana, usabilidade 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
69
funcional. Porm, quando desenvolvido com mais detalhes, pode levar a outros requisitos
que so claramente 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.
Requisitos funcionais
Os requisitos funcionais devem descrever detalhadamente os servios e a funcionalidade que
devem ser fornecidas pelo sistema, indicando suas entradas e sadas, excees etc. Esses
requisitos podem ser expressos de diversas maneiras, com diferentes 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 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, 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 completeza denota que todas as funes
requeridas pelo usurio devem estar definidas e a consistncia denota que os requisitos no
devem ter definies contraditrias. 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
70
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 fatores externos, como por exemplo,
regulamentos de segurana e legislao sobre privacidade.
Sommerville (2011, p.61) faz uma classificao dos requisitos no funcionais em requisitos de
produto, requisitos organizacionais e requisitos externos. Os requisitos de produto so aqueles
que especificam o comportamento do produto, 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 subdivididos 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 funcionais 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 consideraes 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
relacionados s propriedades emergentes do sistema devem ser explicitamente destacados.
Isso pode ser feito colocando-os em uma seo separada do documento de requisitos ou
diferenciando-os, de alguma maneira, dos outros requisitos de sistema.
71
REQUISITOS DE USURIO
De acordo com Sommerville (2007, p. 85), os requisitos de usurios para um sistema devem
descrever 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 devem ser definidos utilizando-se um modelo de
implementao, e sim, escritos com o uso de linguagem natural, formulrios e diagramas
intuitivos simples.
REQUISITOS DE SISTEMA
Os requisitos de sistema so descries mais detalhadas dos requisitos do usurio, servindo
como base para um contrato destinado implementao do sistema e, portanto, devem ser
uma especificao completa e consistente de todo o sistema (SOMMERVILLE, 2007, 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 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 estruturar a especificao de requisitos.
2. Na maioria dos casos, os sistemas devem interoperar com outros sistemas existentes, restringindo assim o projeto em desenvolvimento, sendo que, muitas vezes,
essas restries geram requisitos para o novo sistema.
De acordo com Sommerville (2011, p. 58), os requisitos devem ser escritos em nveis
72
diferentes de detalhamento para que diferentes leitores possam us-los de formas diferentes.
Os possveis leitores para os requisitos de usurio so: gerentes clientes, usurios finais do
sistema, engenheiros clientes, gerentes contratantes e arquitetos de software. Esses leitores
no tem a preocupao com a forma como o sistema ser implementado. J para os requisitos
de sistema podem-se ter os seguintes leitores: usurios finais do sistema, engenheiros clientes,
arquitetos de sistema e desenvolvedores 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.
As sementes das principais catstrofes de software so normalmente semeadas nos trs primeiros
meses do projeto de software
Caper Jones, Especialista em Engenharia de Software.
O DOCUMENTO DE REQUISITOS DE SOFTWARE

O documento de requisitos de software ou especificao de requisitos de software 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 usurio e de sistema podem ser integrados em uma
nica descrio. Em outros casos, os requisitos de usurio so definidos em uma introduo
especificao dos requisitos de sistema. Se houver um grande nmero de requisitos, os
requisitos detalhados de sistema podero ser apresentados como documentos separados.
O documento de requisitos serve como um termo de consenso entre a equipe tcnica
73
(desenvolvedores) e o cliente e constitui a base para as atividades subsequentes 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 sistema, abrangendo um conjunto diversificado de
usurios, que vai desde a alta gerncia da organizao, que est pagando pelo sistema, at
os engenheiros responsveis pelo desenvolvimento do software.
A tabela abaixo 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.
Tabela A estrutura de um documento de requisitos
Captulo
Descrio
Prefcio
Deve definir os possveis leitores do documento e descrever seu histrico

de verses, incluindo uma justificativa para a criao de uma nova verso
e um resumo das mudanas feitas em cada verso.
Introduo
Deve descrever a necessidade para o sistema. Deve descrever brevemente as funes do sistema e explicar como ele vai funcionar com
outros sistemas. Tambm deve descrever como o sistema atende aos
objetivos globais de negcio ou estratgicos da organizao que encomendou o software.
Glossrio
Deve definir os termos tcnicos usados no documento. Voc no deve

fazer suposies sobre a experincia ou o conhecimento do leitor.
Definio de requisitos
de usurio
Deve descrever os servios fornecidos ao usurio. Os requisitos no

funcionais de sistema tambm devem ser descritos nessa seo. Essa
descrio pode usar a linguagem natural, diagramas ou outras notaes
compreensveis para os clientes. Normas de produto e processos a serem seguidos devem ser especificados.
Arquitetura do sistema
Deve apresentar uma viso geral em alto nvel da arquitetura do sistema previsto, mostrando a distribuio de funes entre os mdulos do
sistema. Componentes de arquitetura que so reusados devem ser destacados.
74
Captulo
Descrio
Especificao de requisitos do sistema
Deve descrever em detalhes os requisitos funcionais e no funcionais. Se

necessrio, tambm podem ser adicionados mais detalhes aos requisitos
no funcionais. Interfaces com outros sistemas podem ser definidas.
Modelos do sistema
Pode incluir modelos grficos do sistema que mostram os relacionamentos entre os componentes do sistema, o sistema e seu ambiente. Exemplos de possveis modelos so modelos de objetos, modelos de fluxo de
dados ou modelo semnticos de dados.
Evoluo do sistema
Deve descrever os pressupostos fundamentais em que o sistema se

baseia, bem como quaisquer mudanas previstas, em decorrncia da
evoluo do hardware, de mudanas nas necessidades do usurio, etc.
Essa seo til para projetistas de sistema, pois pode ajud-los a evitar
decises capazes de restringir possveis mudanas futuras no sistema.
Apndices
Deve fornecer informaes detalhadas e especficas relacionadas aplicao em desenvolvimento, alm de descries de hardware e banco de
dados, por exemplo. Os requisitos de hardware definem as configuraes
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.
ndice
Vrios ndices podem ser includos no documento. Pode haver, alm de

um ndice alfabtico normal, um ndice de diagramas, de funes, entre
outros pertinentes.
Fonte: (SOMMERVILLE, 2011, p.64)
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 funcionalidades 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.
Exemplo de Documento de Requisitos Locadora de Filmes
Uma determinada locadora possui muitos ttulos em seu acervo e no consegue controlar
75
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 seguintes 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 da mesma, 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 se cadastra o cliente.
Caso a locao seja efetuada pelo dependente do cliente, necessrio deixar registrado qual o dependente e qual o cliente.
verificado se o filme est disponvel e se o cliente possui pendncias financeiras

ou atraso de devoluo, caso uma das alternativas seja afirmativa 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 domingos e

feriados. Cada categoria pode ter um prazo diferente para que o 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

76
Verificar se a devoluo est no prazo correto e se o pagamento foi efetuado, 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 devolues vencidas.
5. Consultar Filmes Locados por Cliente: o sistema deve ter uma consulta 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 reservas efetuadas para
aquele filme, no perodo informado.
7. Emitir os seguintes relatrios

Relatrio Geral de Clientes, onde conste o cdigo, nome, endereo, telefone e

dependentes do cliente.
Etiquetas com cdigos de barras para a identificao das cpias no processo de

locao e devoluo.
Relatrio de filmes por gnero, onde 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 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 locao. O relatrio deve ser agrupado
por cliente e devem sair somente as cpias locadas e no devolvidas.
Relatrio de cpias no devolvidas, onde 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.
77
Relatrio dos filmes mais locados, onde 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, onde 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).
Relatrio dos valores das locaes mensais. Dever mostrar os valores das
locaes de determinado ms, separado por data e somatria de valores 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.
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
as 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.
78
Eficincia indica que o tempo de execuo e os recursos envolvidos so compatveis

com o nvel de desempenho do software.
Manutenibilidade conjunto de atributos que evidenciam o esforo necessrio para fazer modificaes especificadas no software, incluindo tanto as melhorias/ extenses de
funcionalidades quanto as correes de defeitos, falhas ou erros.
Portabilidade indica a capacidade do software de ser transferido de um ambiente para
outro.
A ISO/IEC formam o sistema especializado para padronizao mais conhecido no mundo.
Voc pode obter mais informaes atravs do endereo <http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22749>. Existe tambm adequao
dessa norma para o Brasil a NBR ISO/IEC 9126-1. Verifique no endereo <http://www.
abnt.org.br/>.
Especifi cao de requisitos no desenvolvimento de software para TV Digital Interativa no Brasil: Re exes e Relato de Experincia
Por Carlos Eduardo Marquioni
O processo de implantao da TV Digital no Brasil iniciou uma nova fase em 2009, relacionada
defi nio de mecanismos para interao atravs do televisor. Contudo, alm de viabilizar a infraestrutura tecnolgica para troca de informaes entre o telespectador 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 Especifi cao da
Engenharia de Requisitos e relaciona boas prticas de escrita para gerar requisitos textuais que,
integradas com a tcnica de Casos de Uso levaram defi nio de um mtodo de especifi cao de
requisitos para a TV Digital Interativa que utiliza conceitos conhecidos pela comunidade 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 abaixo.
Fonte: <http://revistas.ua.pt/index.php/prismacom/article/view/784>. Acesso em: 07 jun. 2012.
79
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 viabilidade 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 requisitos, que j foi discutida nesta unidade. A figura abaixo 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).
<http://www.youtube.com/watch?v=P4ixBvRF4NY&feature=related>.
O vdeo mostra uma entrevista com Sergio Ayres, consultor com vasta experincia em Gesto e Governana Corporativa, abordando a Engenharia de Requisitos.
80
Estudo de
Viabilidade
Levantamento e
anlise de
requisitos
Especificao de
requisitos
Relatrio de
Viabilidade
Modelos de
sistema
Validao de
requisitos
Requisitos de
usurio e de
sistema
Documento de
requisitos
Fonte: Somerville (2011, p. 24).
As atividades de engenharia de requisitos, mostradas nessa figura, dizem respeito ao

levantamento, documentao e verificao dos requisitos. Porm, necessrio deixar
claro que, em praticamente em todos os sistemas, os requisitos 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, 2007, p. 95).
ESTUDO DE VIABILIDADE
Segundo Sommerville (2007, p. 97), para todos os sistemas novos, o processo de engenharia
de requisitos de sistemas deve se iniciar com um estudo de viabilidade ou elicitao de
requisitos. O estudo de viabilidade inicia-se 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 se vale a pena ou no realizar o processo de engenharia de requisitos
e, consequentemente, o processo de desenvolvimento de sistemas.
Um estudo de viabilidade um estudo rpido, direcionado, que se destina a responder a
81
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 fundamental,
pois se um sistema no for compatvel com esses objetivos, ele no ter nenhum valor real
para a mesma. Embora isso possa parecer bvio, muitas organizaes desenvolvem sistemas
que no contribuem para seus objetivos, seja porque no existe uma declarao clara desses
objetivos ou porque outros fatores polticos ou organizacionais 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 responder 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:
Como a organizao se comportaria, se esse sistema no fosse implementado?
Quais so os problemas com os processos atuais e como um novo sistema ajudaria a diminuir
esses problemas?
Que contribuio direta o sistema trar para os objetivos da empresa?
As informaes podem ser transferidas para outros sistemas organizacionais e tambm podem
ser recebidas a partir deles?
O sistema requer tecnologia que no tenha sido utilizada anteriormente na organizao?
82
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 sistema 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 acima, e deve recomendar se o desenvolvimento 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 (2007, p. 97), 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 desenvolvimento 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 hardware e assim por diante.
O levantamento e a anlise de requisitos podem envolver diferentes tipos de pessoas 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 destacamse os usurios finais que interagiro com o sistema e todo o pessoal, em uma organizao, que
venha a ser por ele afetado. Os engenheiros que esto desenvolvendo o sistema ou fazendo a
manuteno de outros sistemas relacionados, os gerentes de negcios, os especialistas nesse
domnio, os representantes de sindicato entre outros, podem ser tambm os stakeholders do
sistema.
83
O levantamento e a anlise de requisitos compem um processo difcil, por diversas razes

(SOMMERVILLE, 2007, 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 atuao, 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 pontos 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 consequncia, a importncia
dos requisitos especficos pode mudar, podendo surgir novos requisitos por parte dos
novos stakeholders, que no haviam sido consultados inicialmente.
Introduo Engenharia de Requisitos

Por Rodrigo Oliveira Spnola, Doutor e Mestre em Engenharia de Sistemas e Computao.
Fonte: <http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-engenharia-de-requisitos/8034>. Acesso em: 13 jun. 2012.
Entrevista
As entrevistas formais ou informais com os stakeholders do sistema faz parte da maioria dos
84
processos de engenharia de requisitos. a fonte mais importante para o levantamento dos

requisitos desde que o entrevistado confie no entrevistador.
A sumarizao durante e no final da entrevista necessria primeiro para garantir que toda
informao apresentada foi anotada e segundo que foi corretamente entendida.
Antes de tentar uma entrevista, o engenheiro de software deve prepar-la:
a) Comece por definir os objetivos. Verifique a documentao formal e desenvolva um
esquema do sistema existente ou proposto. Identifique questes, partes omitidas e ambguas. Estes fatos ou componentes desconhecidos representam um esboo inicial dos
objetivos. Pode ser necessrio entrevistar 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-se encontr-la utilizando o
organograma, uma anlise do fluxo de trabalho 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.
85
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 propsito (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 atravs de questes especficas.
Nesta fase, o engenheiro de software deve:
a) Mostrar que conhece as responsabilidades e deveres do trabalho do entrevistado.
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 - antecedncia - para que se possa tomar as decises).
c) Procurar respostas quantitativas. Exemplo: quantos telefones, funcionrio voc tem no
departamento?
d) Evitar falar palavras sem sentido (falar baixo, fazer generalizaes, termos tcnicos).
e) Ouvir as respostas. D tempo para o entrevistado responder, no saia com respostas
antecipadas. No se concentre na prxima questo (isto um erro comum dos iniciantes).
A lista de questes preparada apenas um guia. Tenha certeza de que as questes so
86
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 consideradas.
Exemplo: voc tem alguma sugesto ou recomendaes relativas ao mtodo para calcular o
oramento? Voc gostaria que os seus superiores ou os demais ficassem sabendo de suas
sugestes?
ENCERRAMENTO - se a entrevista tiver consumido mais tempo do que o previsto pea
para continuar e oferea uma reprogramao. Quando tiver toda a informao necessria,
agradea e faa um sumrio de todos os pontos principais. 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. Este 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;
c) avaliar a confidncia 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 esta organizao se relaciona s funes maiores que a empresa executa?
b) Os objetivos e exigncias do sistema (declarados nos manuais de procedimentos) devem
ser reafirmados e esclarecidos na entrevista - muitas vezes os objetivos e exigncias
87
declarados nos manuais no so os mesmos 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 alterado a meta declarada.
c) Fluxo funcional: para cada funo importante, determinar as etapas exigidas e descreva 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 se relaciona 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 escritrio.

Faa comparaes que determinam se inutilizado, duplicado ou incompleto.
Verifique a satisfao dos usurios com esses documentos.
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?
88
i) Capacidade: o sistema atual consegue manipular volumes maiores do que aqueles que
resultam do crescimento normal?
Coloque trs interessados em uma sala e pergunte a eles que tipo de sistema desejam. Provavelmente voc obter quatro ou mais opinies diferentes.
Autor desconhecido.
ESPECIFICAO DE REQUISITOS
Durante o levantamento de requisitos (levantamento de dados), a equipe de desenvolvimento
tenta entender o domnio (contexto/problema) que deve ser automatizado, sendo que o produto
do levantamento de requisitos o DOCUMENTO DE REQUISITOS ou ESPECIFICAO 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.
89
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 requisitos. 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
A validao de requisitos importante porque a ocorrncia de erros em um 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 (2007, p. 106) prope 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 anlises podem identificar
funes adicionais ou diferentes, que so exigidas. Os sistemas tm diversos usurios com necessidades diferentes e qualquer 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.
90
4. Verificaes de realismo. Utilizando o conhecimento da tecnologia existente, 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.
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.
2. Prototipao. Nessa abordagem de validao, um modelo executvel do sistema
mostrado aos usurios finais e clientes, possibilitando que os mesmos 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 processo 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 operao e imaginar como esse sistema se adequaria
ao seu trabalho. No fcil para profissionais habilitados de computao conseguir 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 problemas 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).
91
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.
Uso de prottipos de interface como idioma durante a Validao de requisitos Uma anlise
semitica
Por Carlos Eduardo Marquioni, M.Sc., PMP
Fonte: <http://www.marquioni.com.br/artigos.php?id_artigo=14&titulo=Uso de prottipos de interface
como idioma durante a Validao de requisitos Uma anlise semitica>. Acesso em: 12 jun. 2012.
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 tambm 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 funcionais que esto, frequentemente,
relacionados s propriedades emergentes do sistema, aplicando-se ao sistema como um todo.
Todos os requisitos, sejam eles funcionais ou no funcionais, devem ser definidos 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, projetado, implementado, testado e,
por fim, colocado em funcionamento. Um erro na definio de requisitos pode levar a alteraes
92
em todas essas etapas, por isso essa etapa to importante.

Para auxiliar todo esse processo, vimos que Sommerville (2011) prope que a engenharia
de requisitos seja um processo que deve incluir quatro atividades de alto nvel. A primeira
atividade servir para avaliar se o sistema ser til para a empresa. Isto 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 e, consequentemente, o processo de desenvolvimento de sistemas. Aps
o estudo de viabilidade, parte-se para a descoberta dos requisitos, ou seja, realizado o
levantamento e a anlise dos requisitos, envolvendo diferentes tipos de pessoas (stakeholders)
na organizao. Existem diversas formas para que esse levantamento seja realizado, alm
da entrevista, que foi mostrada nesta unidade. A entrevista a forma mais utilizada, por isso,
optamos em descrev-la.
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.
Por meio do exemplo mostrado, que foi um documento de requisitos para uma locadora de
filmes, pode-se perceber que ele deve trazer detalhes suficientes para dar continuidade ao
processo de desenvolvimento do sistema. 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. Note que, nem sempre fcil
validar os requisitos, pois, s vezes, o prprio cliente no sabe definir com preciso o que ele
deseja, o que acaba dificultando essa etapa.
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. Nesta prxima
unidade trabalharemos com uma ferramenta CASE para nos auxiliar na elaborao de alguns
diagramas e voc ver que o documento de requisitos realmente muito importante. Vamos
l?
93
1. Identifique e descreva os quatro tipos de requisitos que podem ser definidos para
um sistema.
2. Descreve trs tipos de requisitos no funcionais que podem ser definidos para um
sistema, fornecendo exemplos para cada um deles.
3. Baseando-se no Documento de Requisitos da Locadora de Filmes, mostrado como
exemplo nesta unidade, relacione os requisitos funcionais encontrados no mesmo.
4. Descreva detalhadamente as quatro atividades que fazem parte do processo de engenharia de requisitos.
94
UNIDADE IV
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
Modelagem de Sistemas
Diagrama de Casos de Uso
Diagrama de Classes
INTRODUO
Caro(a) aluno(a), na terceira unidade estudamos sobre os requisitos de um sistema 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 (SOMMERVILLE, 2011 p. 82). Esses
modelos, normalmente, so elaborados utilizando-se uma notao grfica, que, em nosso
caso, ser a UML.
De acordo com BOOCH (2005, p. 13), a UML uma linguagem-padro para a elaborao
da estrutura de projetos de software. Ela poder ser empregada para a visualizao, a
especificao, a construo e a documentao de artefatos que faam uso de sistemas
complexos de software.
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 auxiliar
os desenvolvedores de software a construir o software.
97
A UML foi desenvolvida, inicialmente, por meio da combinao de um grupo de notaes

de modelagem usadas pela indstria de software: o mtodo de Booch, o mtodo OMT
(Object Modeling Technique) de Jacobson e o mtodo OOSE (Object-Oriented Software
Engineering) de Rumbaugh. Em 1997, a UML 1.0 foi oferecida para padronizao ao OMG
(Object Management Group). A UML 1.0 foi revisada com a ajuda de vrios segmentos da
comunidade de desenvolvedores de software, tornando-se UML 1.1, sendo adotada pelo OML
em novembro de 1997. O padro atual a UML 2.0, sendo um padro ISO.
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, consulte 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 caractersticas 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, 20007, p. 15).
Depois, ser mostrado o diagrama de classes. Esse o diagrama mais importante e tambm
o mais utilizado da UML, e serve de apoio para a maioria dos 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.
98
A necessidade de planejamento no desenvolvimento de sistemas de informao 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 grficas 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 construo de sistemas, eis algumas:

No desenvolvimento de software usamos desenhos grficos denominados 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 informaes na forma de
texto, com o objetivo de explicar ou definir certas partes desse diagrama. A modelagem de um sistema em forma de diagrama, juntamente com a informao textual
associada, formam a documentao de um sistema de software.
O rpido crescimento da capacidade computacional das mquinas resultou na demanda por sistemas de software cada vez mais complexos, que tirassem proveito de
tal capacidade. Por sua vez, o surgimento desses sistemas 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 fluxogramas e diagramas de
mdulos.
Dcada de 1970: nessa poca houve uma grande expanso do mercado computacional. Sistemas complexos comeavam a surgir e, por consequncia, modelos
99
mais robustos foram propostos. Nesse perodo, 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 encontradas 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 projetos (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:

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 representar o sistema aos
futuros usurios para que esses modelos sejam validados.
100 ENGENHARIA DE SOFTWARE | Educao a Distncia
A verificao tem o objetivo de analisar se os modelos construdos esto em conformidade

com os requisitos definidos. Na verificao dos modelos, so analisadas 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 a 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 consultado e possivelmente modificado
durante todo o processo de engenharia e tambm serve de base para a modelagem de outros
diagramas (GUEDES, 2007, p. 38).
O principal objetivo deste diagrama modelar as funcionalidades e servios 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 requisitos, 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 o foco da modelagem que estamos realizando.
101
O diagrama de casos de uso composto por atores, casos de uso e seus relacionamentos. 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 diagrama (GUEDES, 2007, p. 38).
Um caso de uso sempre iniciado por um estmulo de um ator; ocasionalmente, outros atores
podem participar do caso de uso. A figura abaixo apresenta alguns exemplos de atores.
Exemplos de Atores
Casos de Uso
De acordo com Booch (2005, p. 227), um caso de uso especifica o comportamento 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 pretendido 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 abaixo apresenta alguns exemplos de
casos de uso.
Exemplos de Casos de Uso

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, p. 231). Alguns verbos que
podem ser usados para nomear os casos de uso: efetuar, cadastrar, consultar, emitir, registrar,
realizar, manter, verificar entre outros.
Relacionamento entre Casos de Uso e Atores
Conforme Melo (2004, p. 60), 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 relacionamentos de associao,
generalizao, extenso e incluso, da seguinte forma:

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, extenso e

incluso.
Associao
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
103
interao do ator com o caso de uso, ou seja, a comunicao entre atores e casos de uso, por
meio do envio e recebimento de mensagens.
Um relacionamento de associao demonstra que o ator utiliza-se da funcionalidade
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 ao 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 abaixo representa uma associao entre um
ator e um caso de uso, em que o ator fornece uma informao para o caso de uso.
Associao entre um ator e um caso de uso

Veja o exemplo abaixo. Nele est sendo mostrado que o ator Gerente Administrativo recebe o
Relatrio de Vendas por Perodo (note que ele no solicita a emisso do relatrio, ele somente
recebe o relatrio).
Neste 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.

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, apresentando 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 caractersticas 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 abaixo (GUEDES, 2007, p. 40).
105
Exemplo de generalizao entre casos de uso

Agora vamos entender o que este 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 caractersticas 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
documentao (GUEDES, 2007, p. 41).
O relacionamento de generalizao/especializao tambm pode ser aplicado entre atores.
A figura abaixo apresenta um exemplo, em que existe um ator geral chamado Cliente e dois
atores especializados chamados Pessoa Fsica e Pessoa Jurdica.
Generalizao entre Atores

Incluso
Este 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, permitindo 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 caso de uso includo nunca
permanece isolado, mas apenas instanciado como parte de alguma base maior que o inclui
(BOOCH, 2005, p. 235).
107
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 execuo 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 palavra-chave <<include>>. A seta
deve sempre apontar para o caso de uso a ser includo. Veja um exemplo na figura abaixo, que
foi retirado de Guedes (2007, p. 43).
Exemplo de incluso de caso de uso

Neste exemplo sempre que um saque ou depsito ocorrer, ele deve ser registrado 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).
Neste exemplo temos dois casos de uso base e um caso de a ser includo.
Agora veja outro exemplo na figura abaixo. Aqui, est sendo apresentada a 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 matrcula (caso de uso a ser includo) do aluno. Assim, nestes
pontos o caso de uso Validar matrcula ser internamente copiado.
Outro exemplo de incluso de caso de uso

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 comportamento obrigatrio de outro opcional.
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
109
que estende, ou seja, neste caso a seta aponta para o caso de uso base (GUEDES, 2007, p.
43). Veja abaixo um exemplo de relacionamento de extenso.
Exemplo de extenso de caso de uso

Neste exemplo, 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.
Outro exemplo de extenso de caso de uso
No exemplo acima, o caso de base o Realizar login no site e Realizar cadastro dados
pessoais o caso de uso a ser estendido.
Caro(a) aluno(a), para facilitar o entendimento do relacionamento de extenso, vamos
mostrar mais um exemplo de uso do mesmo. Na figura abaixo est sendo apresentada a
seguinte situao: durante a execuo do caso de uso Efetuar venda, a venda pode estar
sendo realizada para um cliente especial. Neste 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 dar um tratamento situao.
Representao de um Relacionamento Extend

QUADRO RESUMO DE RELACIONAMENTOS ENTRE CASOS DE USO E ATORES
Associao
Especializao/
Generalizao
Incluso
Extenso
Caso de Uso e Caso

de Uso
-----
OK
OK
OK
Ator e Ator
-----
OK
-----
-----
Ator e Caso de Uso
OK
-----
-----
-----
111
<http://www.youtube.com/watch?v=hfN6n5fJfLc&feature=relmfu>.
Vdeo que mostra a importncia da modelagem de sistemas, bem como trata da elaborao do diagrama de casos de uso.
ESTUDO DE CASO
Vamos mostrar um documento de requisitos de uma fbrica de colches e depois o diagrama
de casos de uso que foi elaborado com base neste documento. A ferramenta que utilizaremos
para modelar o diagrama ser o Astah, como j foi dito anteriormente. Outra observao
importante que esse documento de requisitos est bastante simplificado, seu principal
objetivo mostrar como os conceitos mostrados podem ser aplicados em um diagrama de
casos de uso.
DOCUMENTO DE REQUISITOS FBRICA DE COLCHES

A fbrica de colches Mimindo Ltda compra matria-prima, fabrica os colches (casal ou
solteiro) e vende para seus clientes de vrias partes do pas. Ela deseja gerenciar todos os
processos com a utilizao de um sistema que voc vai desenvolver.
Mas, o sistema ser desenvolvido em partes sendo o que a empresa precisa de imediato
lanar no sistema as compras de matrias-primas (MP) e cadastrar os produtos acabados
(PA).
Algumas informaes importantes que ajudar o entendimento do sistema

Quando a Mimindo Ltda comprar MP (matria-prima) de um fornecedor receber

uma nota de compra que deve ser lanada no sistema. Nesta nota constam as seguintes informaes: o nmero da nota, data emisso, nome do fornecedor, CFOP
(cdigo fiscal de operao) e as MPs com as quantidades compradas de cada uma
delas, bem como o seu valor unitrio. Uma nota de compra pode conter N matrias-primas. No lanamento da nota de compra o sistema deve atualizar o estoque de
MPs automaticamente.
Essas MPs devem ser cadastradas separadas por grupos, sendo que uma MP poder pertencer a um nico grupo (Ex.: tecidos, espumas etc.).
Os PAs (produtos acabados) so os colches fabricados que a Mimindo Ltda ir vender (esse sistema que voc est desenvolvendo agora no tratar da venda).
Para fabricar um PA necessrio saber quais as matrias-primas que compem
esse PA, bem como a quantidade de cada matria-prima que utilizada na fabricao do PA. O sistema deve permitir o cadastro dos PAs e tambm as matrias-primas e as quantidades de cada MP usadas em cada um deles.
Os cadastros e a movimentao do sistema devero ser realizadas pelo departamento de compras.
O sistema deve emitir os relatrios que esto definidos abaixo. A informao de

quem solicita cada relatrio bem como de quem recebe cada relatrio est junto com
a definio do relatrio.
O sistema deve emitir os seguintes relatrios:

A) Lista de Fornecedores contendo o cdigo, nome, cidade e fone. Este relatrio ser
solicitado e recebido pelo Departamento de Compras.
B) Lista de MPs por grupo contendo o nome do grupo e para cada grupo os dados da
matria-prima: cdigo, descrio, quantidade em estoque e valor unitrio. Este relatrio ser solicitado pelo Departamento de Compras e recebido pelo Departamento
de Compras e pelo Gerente de Compras.
C) Relao de Compras por Fornecedor, contendo Nmero da Nota, Nome do fornecedor, Data da emisso e Total da nota. Este relatrio ser solicitado e recebido pelo
Departamento de Compras.
D) Lista de Produtos Acabados contendo o cdigo, descrio, valor de venda e o tipo
113
do colcho (se solteiro, casal, bero, queen size ou king size). Para cada produto
acabado, emitir a lista de matrias-primas utilizadas para fabricao do mesmo. Para
cada matria-prima, emitir o seu cdigo, sua descrio e a quantidade utilizada na
fabricao do PA. Este relatrio ser solicitado e recebido pelo Departamento de
Compras e tambm ser solicitado e recebido pelo Gerente de Compras.
A figura abaixo mostra uma possvel soluo para o problema que acabamos de descrever.
Diagrama de Casos de Uso para o Sistema Fbrica de Colches
DIAGRAMA DE CLASSES
O diagrama de classes tem como objetivo permitir a visualizao das classes utilizadas 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-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,
corresponde 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.
115
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.
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
Segundo Gedes (2007, p. 54), a associao unria ocorre quando existe um relacionamento
de uma instncia de uma classe com instncias da mesma classe, conforme mostra o exemplo
abaixo.
Exemplo de Associao Unria
Neste exemplo, temos a classe Funcionrio, cujos atributos so cdigo, nome e o cdigo
do possvel chefe do funcionrio. Como esse chefe tambm um funcionrio, 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).
Associao Binria
A associao binria conecta duas classes por meio de uma reta que liga uma classe a outra.
A figura abaixo demonstra um exemplo de associao binria.
Exemplo de associao binria

Neste exemplo, 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 relacionamentos em um diagrama de classes, explicaremos o conceito
de multiplicidade.
117
Agregao
A agregao corresponde a um tipo especial de associao utilizada para expressar
um relacionamento todo-parte. Ou seja, as informaes do objeto-todo precisam ser
complementadas pelas informaes contidas em um ou mais objetos de outra classe,
chamados objeto-parte, sendo que, os objetos-parte no podem ser destrudos por um objeto
diferente do objeto-todo (GUEDES, 2007, p. 57).
O smbolo de agregao difere do de associao por conter um losango na extremidade da
classe que contm os objetos-todo. A figura abaixo demonstra um exemplo de agregao, em
que existe uma classe Pedido, que armazena os objetos-todo e uma classe Item_Pedido, em
que so armazenados os objetos-parte.
Exemplo de agregao
Neste exemplo, um pedido pode possuir apenas um item como vrios, no sendo possvel
determinar o nmero mximo de itens que um pedido pode ter. Por isso, as informaes
da classe Pedido esto incompletas, possuindo apenas atributos que no se repetem. Os
atributos que podem se repetir devem ser armazenados em uma classe dependente da classe
Pedido. Dessa forma, sempre que uma instncia da classe Pedido for pesquisada, todas
as instncias da classe Item_Pedido relacionadas instncia da classe Pedido pesquisada
devero tambm ser apresentadas. Da mesma forma, sempre que um objeto da classe Pedido
for destrudo, todos os objetos da classe Item_Pedido a ele relacionados devem tambm ser
destrudos (GUEDES, 2007, p. 58).
Note que o relacionamento entre a classe Item_Pedido e Produto de associao, portanto,
quando o objeto da classe Item_pedido for excludo, por exemplo, o objeto relacionado a ele,
na classe Produto, no dever ser excludo.
Generalizao/Especializao
Esta associao identifica classes-me (superclasse), chamadas gerais e classesfilhas (subclasses), chamadas especializadas, demonstrando a ocorrncia de herana e
possivelmente de mtodos polimrficos nas classes especializadas. Anteriormente, nesta
mesma unidade, j foi explicado o conceito de herana e polimorfismo.
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 associao relaciona-se com as
119
instncias da outra extremidade. A tabela abaixo, retirada de Guedes (2007, p. 55) demonstra
alguns dos diversos valores de multiplicidade que podem ser utilizados em uma associao.
Tabela Exemplos de multiplicidade
Multiplicidade
Significado
0..1
No mnimo zero (nenhum) e no mximo um. Indica que os objetos das classes
associadas no precisam obrigatoriamente estar relacionados, mas se houver
relacionamento indica que apenas uma instncia da classe se relaciona com as
instncias da outra classe.
1..1
Um e somente um. Indica que apenas um objeto da classe se relaciona com os

objetos da outra classe.
0..*
No mnimo nenhum e no mximo muitos. Indica que pode ou no haver instncias da classe participando do relacionamento.
Muitos. Indica que muitos objetos da classe esto envolvidos no relacionamento.
1..*
No mnimo 1 e no mximo muitos. Indica que h pelo menos um objeto envolvido no relacionamento, podendo haver muitos objetos envolvidos.
2..5
No mnimo 2 e no mximo 5. Indica que existem pelo menos 2 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 desenhado 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 relacionamento. Neste caso, pelo menos os atributos-chave
devem fazer parte da classe associativa, porm, a classe associativa tambm pode possuir
atributos prprios.
Uma classe associativa representada por uma reta tracejada partindo do meio da associao
e atingindo uma classe. A figura abaixo apresenta um exemplo 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).
Exemplo de classe associativa

Neste exemplo, uma instncia da classe Curso pode se relacionar com muitas instncias 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 atributos 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 classes Curso e Disciplina so
transmitidos de forma transparente pela associao, no sendo, portanto, necessrio escrevlos como atributos da classe associativa.
Segundo Guedes (2007, p. 61), as classes associativas podem ser substitudas por classes
normais, que, neste caso, so chamadas de classes intermedirias, mas que desempenham
121
exatamente a mesma funo das classes associativas. A figura abaixo mostra o mesmo
exemplo da figura anterior, porm com a classe intermediria ao invs da classe associativa.
Exemplo de classe intermediria
ESTUDO DE CASO
Para mostrar um diagrama de classes, vamos utilizar o mesmo documento de requisitos
utilizado para demonstrar o diagrama de casos de uso, ou seja, o documento de requisitos da
Fbrica de Colches. No vou colocar novamente o documento aqui, mas seria interessante
que voc fizesse a leitura novamente do documento antes de analisar o diagrama de classes
abaixo.
ESTUDO DE CASO 2
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.
Mas antes de comearmos a ler o documento de requisitos, gostaria que voc imaginasse 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, como, 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.
123
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 (preenchido pelo
seu mdico aquele que o clnico geral que voc acabou de consultar, preencheu).
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 laboratrio 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 desta ficha entregue ao paciente (a voc).
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 atendimento a seus
pacientes (e neste 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 realizao do mesmo. Por exemplo, hemograma: 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.

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, descrio, procedimentos e valor de cada exame, agrupados por grupo de exame, devendo
ser impresso neste relatrio o cdigo e a descrio do grupo. Este 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 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. Esse 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 acima e verifique quais so os usurios
do sistema. Essas pessoas sero os atores. Faa uma lista com os atores.
a. Recepcionista
125
a. Bioqumicos
b. Departamento Administrativo
c. Departamento de Faturamento
d. Paciente
2. Agora faa uma lista com as funcionalidades do sistema. Algumas aparecem 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
3. Porm, 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 mencionados acima, 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 acima 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 algumas informaes podem ser transformadas em classes, facilitando o uso e manuteno do
sistema. Por exemplo: o sistema pode ter, alm dos cadastros relacionados acima,
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
d. Cadastro de UFs
e. Cadastro de grupos de exames (neste 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 cadastrar 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 parecido com o meu. Note que
o nome do caso de uso sempre comea com um verbo.
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 elaborar 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 armazenar os dados que sero cadastrados nesse caso de uso. Seguindo esse raciocnio teramos as seguintes classes:
127
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 atributos 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 nascimento, RG e CPF.
b. Exame: cdigo, descrio, valor, procedimentos, grup,o ao qual pertence o exame.
c. Pedido de Exame: cdigo, nome do paciente, nome do mdico, nome do convnio, 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 interessam
para o pedido de exame).
f. Convnios: cdigo, nome (como o documento de requisitos no menciona nada
sobre os dados dos convnios, coloquei somente os atributos que interessam
para o pedido de exame).
g. Cidades: cdigo, nome, DDD (neste caso, 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.
3. Desenhar as classes relacionadas acima, com seus respectivos atributos, no Diagrama de Classes. Faremos o desenho do diagrama tambm utilizando a ferramenta
Astah e no mesmo arquivo em que j desenhamos o diagrama de casos de uso.

Assim, ficaremos com os dois diagramas em um nico arquivo.
4. Para cada classe desenhada no diagrama, estabelecer o seu relacionamento com
as demais classes. Lembre-se dos tipos de relacionamentos que estudamos: associao (unria e binria), generalizao/especializao, agregao. Releia tambm a
explicao sobre classes associativas.
5. Depois disso, estabelecer a multiplicidade de cada relacionamento, lembrando-se de
eliminar atributos que podem ser obtidos por meio do relacionamento.
6. Primeiro desenhe o seu diagrama de classes e depois compare com o meu. Veja s
como ficou o meu diagrama.
Seguem alguns esclarecimentos sobre o diagrama acima:
129
1. Um pedido de exame pode estar relacionado a 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 prontos. 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.
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.
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).
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 fundamental de todas as atividades,
dentro de um processo de software, que levam implantao de um bom software.
necessrio construirmos modelos para comunicar a estrutura e o comportamento desejados
do sistema, para melhor compreender o sistema que estamos elaborando (BOOCH, 2005,
p. 3). Esses modelos, normalmente, so representados 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, que so considerados por muitos autores, como os principais diagramas da UML.
A UML no estabelece uma ordem pr-definida para a elaborao dos seus diversos diagramas,
131
porm, como o diagrama de casos de uso, um dos diagramas mais gerais e informais da
UML, normalmente a modelagem do sistema inicia-se 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 sistema 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. Alm
disso, foi apresentado um diagrama pronto, que foi elaborado a partir do documento de
requisitos para uma fbrica de colches, mostrando como os conceitos acima podem ser
aplicados em um diagrama.
Depois que o diagrama de casos de uso elaborado fica bem mais fcil elaborar 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, mostrando os atributos e mtodos possudos por
cada uma das classes, e tambm os seus relacionamentos. Com base no mesmo documento
de requisitos, o da fbrica de colches, foi mostrado como fica o diagrama de classes referente
ao mesmo.
E, para auxiliar o entendimento desses dois diagramas, foi apresentado a elaborao passo a
passo de cada um deles. Para verificar se voc realmente entendeu todos os conceitos, estou
propondo mais um documento de requisitos nas atividades de autoestudo. Ento mos a obra!
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 (generalization).
c. Explique o relacionamento de Extenso (extend).
d. Explique o relacionamento de Incluso (include).
2. Explique qual a diferena entre os diagramas de classe abaixo:
Diagrama A
Gnero
1..*
Diagrama B
Filme
Gnero
0..*
Filme
3. Com base no documento de requisitos abaixo elaborar o Diagrama de Casos de Uso e o

Diagrama de Classes.
DOCUMENTO DE REQUISITOS CONTROLE DE ESTOQUE

A empresa Auto Peas XYZ Ltda atua no ramo de compra e venda de peas para veculos
automotores. Atualmente, a empresa no possui sistema automatizado, mas pretende
informatizar-se totalmente, para isso est contratando os servios de um analista de sistemas.
A empresa pretende comear pelo controle de estoque, pois o aumento do seu faturamento
depende de um controle de estoque rgido.
O sistema atualmente funciona da seguinte maneira:
1. Os produtos so separados e controlados por grupos de produtos.
2. A empresa compra peas de diversos fornecedores. preenchido um formulrio
denominado pedido de compra, no qual constam os seguintes dados: nmero do
pedido, data do pedido, nome do fornecedor, telefone do fornecedor, nome do produto, quantidade do produto e preo unitrio do produto. E, no final do pedido, uma
totalizao (quantidade * preo). Em cada pedido de compra tem-se somente um
fornecedor, podendo ter-se vrios produtos comprados.
3. Vende as peas vista ou a prazo para os clientes. Nas vendas vista so preenchidos os seguintes dados do cliente: nome, endereo completo, telefone e e-mail, para
envio de correspondncias (jornais de propaganda, ofertas). Nas vendas a prazo,
so preenchidos os seguintes dados: nome, endereo completo, telefone, e-mail,
RG, CPF, renda mensal, local de trabalho. Para cada venda preenchida uma nota
fiscal de venda, contendo os seguintes dados: nmero da nota fiscal, data da venda, nome do cliente, nome do vendedor, condio de pagamento, nome do produto,
quantidade do produto e preo unitrio do produto. Sendo que, no final da nota fiscal,
feito uma totalizao da mesma (quantidade * preo unitrio). Em cada nota fiscal
de venda tem-se somente um cliente, podendo ter-se vrios produtos vendidos.
4. Os vendedores so comissionados. Cada vendedor pode ter um % diferente de comisso sobre as vendas efetuadas. No final de cada ms, as vendas so somadas e
a comisso do vendedor calculada.
A empresa deseja que o sistema:

Efetue o cadastro dos pedidos de compra que so preenchidos no item 2, atualizando automaticamente o estoque dos produtos que esto sendo comprados (somando
no estoque). Este cadastro ser realizado pelo Departamento de Compras.
133
Efetue o cadastro das notas fiscais de vendas que so preenchidas no item 3, atualizando automaticamente o estoque do produto que est sendo vendido (diminuindo
do estoque). Este cadastro ser realizado pelo Departamento de Vendas.
Calcule automaticamente as comisses dos vendedores de acordo com o % de cada

um deles.
Os demais cadastros sero efetuados pelo Departamento de Vendas.
O sistema deve emitir os seguintes relatrios:

Lista de preo de produtos por grupo de produtos. Este relatrio ser solicitado
e recebido pelo Departamento de Compras e pelo Departamento de Vendas.
Grupo: 99 - XXXXXXXXXXXXXXXXXXXX
Cdigo Produto
Nome do Produto
Preo Unitrio
999999
XXXXXXXXXXXXXXXXXXXXXXXX
999.999,99
999999
999.999,99
Quantidade disponvel em estoque por produto e grupo de produto. Este relatrio ser solicitado e recebido pelo Departamento de Compras e pelo Departamento
de Vendas.
Grupo: 99 - XXXXXXXXXXXXXXXXXXXX
Cdigo Produto
Nome do Produto
Estoque Atual
999999
999999
9.999,99
9.999,99
Compras dirias sinttico. Este relatrio ser solicitado e recebido pelo Departamento de Compras.
DATA: 99/99/9999
N PEDIDO
NOME FORNECEDOR
999999
999999
TOTAL COMPRADO
99.999.999,99
999.999.999,99
Vendas dirias por cliente sinttico. Este relatrio ser solicitado e recebido
pelo Departamento de Vendas.
DATA: 99/99/9999
N NF
NOME CLIENTE
VENDEDOR
999999
XXXXXXXXXXXXXXXXXXXXX
999999
TOTAL VENDIDO
99.999.999,99
99.999.999,99
Vendas por vendedor num determinado intervalo de data. Este relatrio ser
solicitado e recebido pelo Departamento de Vendas.
PERODO: 99/99/9999 A 99/99/9999
VENDEDOR: XXXXXXXXXXXXXXXXXXXXXXXXXX
DATA
N NF
NOME CLIENTE
TOTAL
VENDIDO
VLR COMISSAO
99/99/9999
999999
XXXXXXXXXXXXXX
9.999.999,99
999.999,99
99/99/9999
999999
XXXXXXXXXXXXXX
9.999.999,99
999.999,99
99/99/9999
999999
XXXXXXXXXXXXXX
9.999.999,99
999.999,99
135
UNIDADE V
PROJETO, TESTES E EVOLUO DE

SOFTWARE
Expor a importncia do projeto de software, mostrando os artefatos que sero criados durante o projeto.
Estudar os formatos de entradas e sadas de informaes atravs da interface do
sistema.
Entender o processo de validao de software, ou seja, quais os tipos de testes que
devem ser realizados no sistema.
Compreender a importncia da evoluo de software, para que o mesmo continue
til aos seus usurios.
Plano de Estudo
Projeto de Software
Diagrama Geral do Sistema, Interfaces e Especificao de Casos de Uso
Testes de Software
Evoluo de Software
INTRODUO
Na quarta unidade estudamos sobre a modelagem do sistema e aprendemos sobre Diagrama
de Casos de Uso e Diagrama de Classes. Agora, para a prxima etapa do processo de
software, ou seja, a etapa do projeto de software, precisaremos desses dois diagramas e
tambm do documento de requisitos, para definir uma srie de artefatos necessrios para que,
posteriormente, o software possa ser implementado.
A etapa de projeto de software, segundo Pressman (2011, p. 207), 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 preparando a cena para a construo (gerao de
cdigo e validao) do software.
O primeiro artefato de software que ser explicado nesta unidade ser o Diagrama Geral do
Sistema (DGS). Neste diagrama devem aparecer todos os mdulos e submdulos do sistema,
assim como os itens que compem cada um deles. O principal objetivo do DGS mostrar
como esses mdulos e seus itens esto relacionados. Cada item que aparece no diagrama
deve aparecer como um caso de uso no Diagrama de Casos de Uso.
139
Depois que o DGS est definido, pode-se partir para a definio das interfaces com o usurio,
tanto as de vdeo quanto as impressas. Para cada item que aparece no DGS, voc deve
pensar em como o usurio ir interagir com o sistema. Cada dado que dever ser informado ao
sistema, ser por meio de uma interface que isso ir acontecer, portanto, quando a interface for
definida, dever ser verificado se os dados colocados na mesma esto definidos no Diagrama
de Classes.
A interface do usurio um dos elementos mais importantes de um sistema, e quando essa
interface mal projetada, a capacidade de o usurio aproveitar todo o potencial do sistema
pode ser seriamente afetada, portanto, uma interface fraca pode fazer com que toda uma
aplicao falhe (PRESSMAN, 2011, p. 313).
Nesta unidade, na seo Formatos de Entradas/Sadas, so mostradas algumas diretrizes
importantes que o ajudaro a definir uma interface humana que seja de mais fcil compreenso
para o usurio.
Depois que a interface foi definida e que o software foi implementado em alguma linguagem
de programao, chegou a hora de executar a validao do software. A etapa de validao
vai garantir que o software realmente executa as funcionalidades solicitadas pelos usurios.
E, finalmente, depois que o software foi validado e colocado em funcionamento, vir a etapa
de evoluo do software, pois, com certeza, os usurios tero requisitos que podero ser
alterados, implicando em alteraes no software. Portanto, para que o software continue sendo
til para o usurio necessrio que ele evolua, atendendo as necessidades desse usurio.
PROJETO DE SOFTWARE
De acordo com Sommerville (2007, p. 50), 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 (que, em nosso caso, ser realizada por meio da Especificao dos casos
de Uso). 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.
Na etapa de modelagem do sistema, o engenheiro de software, com base no documento de
requisitos, j elaborou o Diagrama de Caso de Uso e o Diagrama de Classes. Agora, na etapa
de projeto, ele 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.
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.
Diagrama Geral do Sistema
Tambm conhecido por Diagrama de Mdulos, apresenta os mdulos do sistema, as ligaes
entre eles, os seus submdulos e/ou itens. O Diagrama Geral do Sistema deve ser condizente
com o Diagrama de Caso de Uso, ou seja, as opes representadas no Diagrama Geral do
Sistema devem aparecer como Casos de Uso no Diagrama de Casos de Uso. Seguem abaixo
alguns exemplos de Diagrama Geral do Sistema.
141
Exemplo 1 Diagrama Geral do Sistema para um sistema de Controle de Estoque
Fonte: a autora
O Diagrama de Caso de Uso referente a esse sistema deveria conter, pelo menos, os seguintes
casos de uso: Cadastrar Grupos de Produtos, Cadastrar Produtos, Cadastrar Clientes, Cadastrar
Vendedores, Cadastrar Condies de Pagamento, Cadastrar Fornecedores, Cadastrar Pedido
de Compra, Efetuar Cancelamento de Pedido de Compra, Emitir Pedido de Compra, Cadastrar

Nota Fiscal de Venda, Efetuar Cancelamento de Nota Fiscal de Venda, Emitir Nota Fiscal
de Venda, Emitir Relatrio de Clientes, Emitir Relatrio de Fornecedores, Emitir Relatrio de
Vendedores, Emitir Lista de Preos de Produtos, Emitir Relatrio de Estoque Atual de Produtos,
Emitir Relatrio de Produtos Mais Vendidos.
Exemplo 2 Diagrama Geral do Sistema para um sistema de Controle de Biblioteca
Sistema
Biblioteca
Cadastros
Categoria
Leitor
Assuntos
Editoras
Movimentaes
Emprstimos
Comprovante
Emprstimos
Devolues
Relatrios
Consultas
Leitores por
Categoria
Leitor por
Exemplar
Emprstimos
Exemplares por
Leitor
Devolues
Catlogo Livros
Autores
Geral
Livros
por Assunto
Exemplares
Livros em
Atraso
Fonte: a autora
O Diagrama de Caso de Uso referente a esse sistema deveria conter, pelo menos, os seguintes
143
casos de uso: Cadastrar Categorias, Cadastrar Leitores, Cadastrar Assuntos, Cadastrar

Editoras, Cadastrar Autores, Cadastrar Livros, Cadastrar Exemplares, Registrar Emprstimos,
Emitir Comprovante de Emprstimos, Registrar Devolues, Emitir Relatrio de Leitores por
Categoria, Emitir Relatrio de Emprstimos, Emitir Relatrio de Devolues, Emitir Catlogo
Geral de Livros, Emitir Catlogo de Livros por Assunto, Emitir Relatrio de Livros em Atraso,
Efetuar Consulta de Leitor por Exemplar, Efetuar Consulta de Exemplares por Leitor.
Interfaces com o Usurio
Sommerville (2007, p. 241) comenta que o projeto de interface com o usurio deve ser feito
cautelosamente, pois uma parte fundamental de todo o processo de projeto de software.
A interface com o usurio deve ser projetada para combinar as habilidades, experincias e
expectativas dos usurios do sistema. A confiabilidade do sistema aumenta se um bom projeto
de interface com o usurio for executado, se forem consideradas as capacidades dos usurios
reais bem como o seu ambiente de trabalho. O engenheiro de software dever definir todas as
interfaces de vdeo e as interfaces impressas do sistema que est sendo projetado.
Interface de Vdeo
Para cada funcionalidade do sistema (caso de uso), definir o layout da tela. O layout o
desenho da tela e onde devem constar as informaes que o usurio dever fornecer ao
sistema. Sugesto: criar uma padronizao para todas as telas do sistema, para facilitar a
utilizao do mesmo pelo usurio. Seguem alguns exemplos de interfaces de vdeo.

Tela de Cadastro de Pacientes: esta interface contm as informaes pessoais de

um paciente. Note que as informaes encontram-se distribudas de maneira lgica e
o espao foi otimizado para que em uma mesma tela vrias informaes pudessem ser
colocadas.
Outro Exemplo de Tela de Cadastro de Pacientes: j nesta tela as informaes no

esto distribudas de maneira lgica. Note que o nome do paciente somente solicitado
depois da data de nascimento, RG e telefone.
Tela de Cadastro de Produtos: nesta tela, alm de cadastrar os dados do produto,

tambm possvel cadastrar os fornecedores que fornecem o produto.
145
Este boto um BOTO DE ATALHO, que chamar o cadastro de marcas, caso a marca
de determinado produto no esteja cadastrada. Desta forma, o usurio no ter que sair do
cadastro de produto, chamar o cadastro de marcas e depois chamar novamente a tela de
cadastro de produtos.

Tela de Cadastro de Filmes: nesta tela o usurio poder informar os dados do filme, com
seu gnero e categoria e todos os atores que fazem parte do elenco do filme. Note que os
atores esto em uma grade, em que possvel cadastrar vrios atores.
Tela de Venda: nesta tela possvel lanar vrios produtos em uma mesma venda, pois
medida que o lanamento do produto efetuado e o usurio pressiona a tecla TAB, uma
nova linha acrescentada na grade de Produtos. O valor total de cada produto bem como
o total geral da venda devem ser calculados automaticamente pelo sistema.
147
Tela de Pedido de Exame: nesta tela possvel lanar vrios exames em um mesmo
pedido de exame. Nesta mesma tela possvel, no caso do pedido de exame ser pago em
parcelas, lanar o valor de cada parcela, o nmero do cheque deixado pelo paciente e a
data de vencimento de cada parcela.
Tela de Compras: nesta tela sero lanados os dados da compra, ou seja, a data da compra,
o fornecedor, a condio de pagamento e os vrios produtos que esto sendo comprados.
Nesta tela tambm aparecem os botes de atalho. Note que o desenho do boto o mesmo,
assim o sistema fica padronizado e o usurio, quando se depara com esse boto em qualquer
lugar do sistema, saber que ao clic-lo o sistema o levar para o cadastro referente ao dado
em que o boto estava se referindo.
Outro exemplo de Tela de Compras: nesta tela, alm de lanar os produtos comprados,
possvel j efetuar o lanamento do Contas a Pagar, ou seja, como na Nota Fiscal de Compra,
normalmente j vem as informaes da data de vencimento e do valor de cada parcela,
quando uma compra parcelada, o usurio j pode efetuar o lanamento dessas informaes
no momento em que est cadastrando as compras.
149
Tela de Filtro do Relatrio de Consultas Mdicas Efetuadas por Dia: a tela de filtro de
relatrio tem por objetivo oferecer ao usurio mecanismos para a seleo dos dados que
ele deseja imprimir no relatrio, pois, caso contrrio, seriam impressos todos os dados
cadastrados na base de dados referentes quele relatrio. Na tela abaixo o usurio ir
informar uma data e o relatrio emitir somente as consultas efetuadas na data informada.
Tela de Filtro do Relatrio de Pagamento de Consultas por Perodo: note que neste
filtro de relatrio o usurio poder informar um intervalo de datas, dessa forma ele poder
emitir o relatrio de um nico dia, de uma semana, de um ms, ou seja, do perodo que ele
desejar. Este tipo de filtro torna o relatrio mais flexvel. No exemplo abaixo sero emitidos
os pagamentos das consultas efetuadas a partir da data inicial at a data final informadas
na tela de filtro.
Tela de Filtro do Relatrio de Pedido de Exame: na tela abaixo so oferecidos dois

filtros: primeiro o usurio dever escolher se ele que selecionar por nome do paciente
ou pelo seu cdigo. Depois ele poder escolher de qual data ele quer emitir o pedido
de exame. As opes que devero aparecer na tela de filtro dos relatrios devero ser
discutidas com o usurio, pois o objetivo facilitar o andamento do seu trabalho quando o
mesmo estiver utilizando o sistema.
151
Tela de Filtro do Relatrio de Contas a Pagar por Fornecedor: no exemplo abaixo o

usurio poder escolher, alm do perodo, tambm o fornecedor que ele deseja emitir o
relatrio de contas a pagar.
B) Interface Impressa
Para cada relatrio do sistema (definidos no Diagrama de Caso de Uso), necessrio definir o
seu layout. Sugesto: criar uma padronizao para todos os relatrios do sistema, para facilitar
a utilizao dos mesmos pelo usurio. Seguem alguns exemplos de interfaces impressas.
Note nos exemplos que eles possuem no cabealho o nome da empresa, o nmero da pgina
do relatrio, a data (e em alguns o horrio) da emisso do relatrio, o ttulo do relatrio e, em
alguns, o valor dos parmetros informados na tela de filtro do relatrio para que o usurio
possa saber depois do relatrio impresso, quais foram os dados informados no filtro para a
emisso do mesmo.

Relatrio de Clientes por Cidade

NOME DA EMPRESA
DATA: 99/99/9999
CDIGO
NOME
Relatrio de Clientes
ENDERECO
PAG.: 99
CEP
TELEFONE
CIDADE: 9999 XXXXXXXXXXXXXXXXXXX

9999
XXXXXXXXXXXXX
XXXXXXXXXXXXXXX
XXXXXXX
XXXXXXXXXXXX
9999
XXXXXXXXXXXXX
XXXXXXXXXXXXXXX
XXXXXXX
XXXXXXXXXXXX
9999
XXXXXXXXXXXXX
XXXXXXXXXXXXXXX
XXXXXXX
XXXXXXXXXXXX
9999
XXXXXXXXXXXXX
XXXXXXXXXXXXXXX
XXXXXXX
XXXXXXXXXXXX
Relatrio de Consultas Efetuadas por Dia

NOME DA EMPRESA
DATA:99/99/9999
Relatrio de Consultas Efetuadas em 99/99/9999
PAG.: 99
PACIENTE
MDICO
CONVNIO
XXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXX
XXXXXXXXXXXXXXX
XXXXXXXXXXXXXXX
Relatrio de Pagamento de Consultas por Perodo
NOME DA EMPRESA
99/99/9999 99:99
Relatrio de Pagamentos de Consultas de 99/99/9999 a 99/99/9999 PAG.: 99
VALOR
DATA PAGAMENTO PACIENTE
MDICO
CONSULTA
99/99/9999
XXXXXXXXXXXXXXXXXX XXXXXXXXXXXX 999.999,99
99/99/9999
99/99/9999
99/99/9999
VALOR TOTAL 99.999.999,99
Especificao de Casos de Uso
A especificao de casos de uso descreve, por meio de uma linguagem bastante simples,
as restries que devero ser consideradas no momento da implementao do caso de uso.
Essas especificaes devem conter detalhes suficientes para permitir a codificao em uma
linguagem de programao qualquer. Seguem alguns exemplos de especificaes de casos
de uso.

Especificao de Caso de Uso Cadastrar Paciente

Os dados digitados pelo usurio devero estar em caixa alta.
O cdigo do paciente dever ser gerado automaticamente pelo sistema, mas o usu-
153
rio poder alterar. Nesse caso, no pode ser menor ou igual a zero.
O nome do paciente no pode ser branco.
Se CPF for digitado, aceitar somente CPF vlido.
No permitir a excluso de um paciente que tenha pelo menos um horrio cadastrado
na agenda.

Especificao de Caso de Uso Cadastrar Agenda

Os dados digitados pelo usurio devero estar em caixa alta.
O cdigo do paciente no pode ser menor ou igual a zero.
No permitir que seja marcada mais de uma consulta para o mesmo mdico na
mesma data e no mesmo horrio.
Quando for includo um novo horrio, mover N para o atributo CONS_REALIZADA.
Quando a consulta for efetivada, mover S para CONS_REALIZADA.
Se for consulta particular, pedir o valor da consulta.
Data da consulta no pode ser menor que a data atual.
Especificao de Caso de Uso Emitir Relatrio de Pagamentos de Consultas por

Perodo
Selecionar somente as instncias da classe AGENDAS que tenham o atributo DATA
maior ou igual data inicial informada na tela de filtro do relatrio e menor ou igual
data final e CONS_REALIZADA igual a S e VLR_CONSULTA diferente de zero.
No permitir data final menor que data inicial.
Validar datas.
Caso no exista nenhuma instncia selecionada, mostrar mensagem de alerta NO
H PAGAMENTO DE CONSULTAS NO PERODO INFORMADO e no mostrar relatrio em branco.
FORMATOS DE ENTRADAS/SADAS
Um dos problemas comuns de entrada/sada inclui a organizao fsica de elementos de
dados de entrada em uma tela de vdeo, a natureza das mensagens de erro quando se comete
em erro de entrada e a organizao fsica de elementos de dados de sada nas telas e em
relatrios. Com o imenso conjunto atual de linguagens de quarta gerao e ferramentas de
prototipao, interessante dar ao usurio diversas variaes de telas de entrada, imagens de
sada e coisas desse tipo. Uma vez obtido o consentimento do usurio, deve ser vinculada uma
cpia das imagens de tela e formatos de relatrios documentao do sistema.
claro que em muitos casos o usurio no ter grandes sugestes para fazer porque no tem
experincia anterior em trabalhar com um sistema informatizado. No caso dos sistemas de
informaes computadorizadas, as seguintes diretrizes ajudaro a desenvolver uma interface
humana amistosa ao usurio na maioria dos casos.
1. Seu sistema deve requisitar entradas e produzir sadas em uma forma consistente.
Isso particularmente verdadeiro nos sistemas on-line em que o usurio pode introduzir uma
entre diversas transaes diferentes e/ou receber uma de diversas imagens diferentes. Por
exemplo, se o sistema solicitar a data ao usurio sempre que uma transao for introduzida,
seria desastroso se um tipo de transao exigisse a data na forma 12/23/87, enquanto outra
transao exigisse a data na forma 87/12/23. E tambm seria desastroso se uma parte do
sistema exigisse que o usurio especificasse o estado como um cdigo de dois caracteres
(p.ex., RJ para Rio de Janeiro), enquanto outra parte do sistema exigisse que o nome de
estado fosse escrito por extenso. De forma anloga, se uma parte do sistema exigir que o
usurio fornea um cdigo de rea quando introduzir um nmero de telefone, todas as partes
do sistema devem exigir um cdigo de rea quando for introduzido um nmero de telefone.
2. Pea informaes em uma sequncia lgica. Em muitos casos, isso depende da natureza
da aplicao e exigir minuciosos entendimentos com o usurio. Por exemplo, se estiver sendo
desenvolvido um sistema de controle de pedidos onde o usurio especifique o nome do cliente,
155
ser necessrio especificar a sequncia na qual os componentes de nome de cliente seriam

introduzidos. Uma sequncia lgica seria solicitar ao usurio que introduzisse a informao na
seguinte sequncia:
ttulo (Sr./Sra. etc.)
primeiro nome
inicial do nome intermedirio
ltimo nome
Porm, o usurio pode achar isso muito desajeitado; suponha que o usurio tenha obtido o
nome do cliente de alguma fonte externa como um catlogo de telefones. Nesse caso, seria
muito mais prtico que o usurio introduzisse.
ltimo nome
inicial do nome intermedirio
ttulo
3. Evidencie ao usurio o tipo de erro que cometeu e onde est. Em muitos sistemas, o
usurio fornece uma quantidade substancial de informaes ao sistema para cada evento ou
transao. Em um sistema de controle de pedidos, por exemplo, o usurio pode especificar o
nome do cliente, endereo e nmero de telefone, bem como informaes sobre itens que esto
sendo pedidos, desconto aplicvel, instrues de embarque e impostos de vendas. Todas
essas informaes podem ser introduzidas em uma nica tela antes de serem gravadas; e,
certamente, o sistema poder determinar em seguida que parte da entrada est errada ou
toda ela. O importante ter certeza de que o usurio compreenda a espcie de erro que foi
cometido e onde o erro est localizado; no aceitvel que o sistema simplesmente emita um
sinal sonoro e exiba a mensagem M ENTRADA. Cada erro (presumindo-se que haja mais
de um) deve ser identificado, ou com uma mensagem descritiva ou (no caso de um sistema
on-line) ressaltando ou codificando em cores os dados errados. Dependendo da natureza
do sistema e do nvel de sofisticao do usurio, pode ser tambm importante exibir uma
mensagem explicativa.
4. Oferea ao usurio um modo de (a) cancelar parte de uma transao e (b) cancelar
toda uma transao. ingnuo pressupor que o usurio sempre terminar a introduo de
uma transao inteira sem ter interrompido. O usurio pode ter introduzido um nome e endereo
de cliente antes de descobrir que estava trabalhando com o cliente errado; ele desejar ser
capaz de anular o que foi digitado e comear de novo. Ou o usurio pode haver terminado a
introduo da maior parte das informaes do cliente e, ento, perceber que escreveu mal o
primeiro nome do cliente; ele vai querer poder retornar quele elemento de dados e corrigi-lo
sem perder todas as outras informaes j digitadas.
5. Providencie um mecanismo prtico de socorro. Nos sistemas on-line cada vez mais
importante oferecer ao usurio um mecanismo prtico para a obteno de informaes sobre
como usar o sistema. Em alguns casos, a facilidade do socorro simplesmente fornecer uma
explicao se o usurio cometer um erro; em outros casos, o socorro poderia ser usado para
explicar os detalhes de vrios comandos ou transaes disponveis ao usurio. Existem muitos
meios de implementar essa facilidade, e o analista e os usurios devem examinar diversos
exemplos tpicos antes de tomar uma deciso.
6. Se o seu sistema estiver empenhado em um processamento muito prolongado, exiba
uma mensagem para que o usurio no pense que o sistema caiu. Se o seu sistema tiver
de executar clculos extensos ou se ele provavelmente apresentar demoras peridicas por
causa de entradas volumosas, importante exibir uma adequada mensagem para o usurio;
caso contrrio possvel que ele imagine que o seu computador congelou ou ficou preso,
ou que o sistema caiu, ou que ocorreu uma falta de energia. O sistema deve, no mnimo,
emitir uma mensagem (por exemplo, SISTEMA OPERANDO - POR FAVOR, ESPERE) em
intervalos regulares. Melhor ainda seria uma srie de mensagens informando o usurio quanto
do trabalho j foi executado e aproximadamente quanto tempo falta para complet-lo, como
acontece na maioria dos processos de instalao de aplicativos, como, por exemplo, Microsoft
Word, Visio, Visual Studio.
157
7. Fornea defaults para entradas padronizadas. Em muitos casos, o sistema pode fazer
uma boa suposio sobre o provvel valor de uma entrada fornecida pelo usurio; tornando-o
um default, poder ser economizado um considervel tempo do usurio. Essa abordagem
vlida para todos os tipos de sistemas. Um exemplo de valor default a data: em muitas
aplicaes a data mais provvel que o usurio introduzir a data atual. Ou, suponha que voc
esteja construindo um sistema de controle de pedidos, e o usurio diz que 95% dos clientes
vivem nas redondezas; em seguida, quando for solicitado que o usurio informe o nmero do
telefone do cliente, o sistema deve presumir que o cdigo de rea default o seu cdigo de
rea local.
8. Beneficie-se das cores e do som, mas no exagere. Os efeitos de cores e som podem
ser bastante teis para a enfatizao de tipos diferentes de entrada ou atrair a ateno do
usurio para aspectos importantes da interface humana. Dessa forma, poder ser utilizada
a cor verde para tudo o que for exibido pelo sistema, azul para todos os dados de entrada
fornecidos pelo usurio, e vermelho para todas as mensagens de erro. Entretanto, o analista
no deve exagerar: a maioria dos usurios poder no gostar se as telas ficarem parecendo
rvores de Natal. Isso tambm vale para efeitos sonoros; uma ocasional campainha ou bip
til, mas o usurio no deseja que o terminal produza todos os efeitos sonoros do filme Guerra
nas Estrelas.
VALIDAO DE SOFTWARE
A validao 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 processos em cada estgio do
processo de software, desde a definio dos requisitos dos usurios at o desenvolvimento
de cada um dos programas que compem o sistema. Porm, a maior parte dos custos de
validao observada depois da implementao, quando o sistema operacional testado.
A atividade de testes uma etapa muito importante para o desenvolvimento de software,
normalmente inserindo tantos erros em um produto quanto a prpria implementao. Por outro
lado, caso um erro seja descoberto durante o desenvolvimento, o custo para sua correo
ser muito menor do que se esse mesmo erro tivesse sido descoberto somente na fase de
manuteno.
O processo de testes pode ocupar grande parte do cronograma de desenvolvimento de
sistema, dependendo do cuidado com que tenham sido executadas as atividades iniciais de
especificao, projeto e implementao.
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 programao, 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, p. 540), 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
159
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. Finalmente, todos os mdulos do sistema so combinados
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.
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 apenas como simulaes, somente como
prottipos. Como a maioria das funes detalhadas do sistema no foi desenvolvida, os testes
iniciais se tornam limitados, 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:

Testes funcionais. Neste tipo de teste o objetivo verificar se o sistema executa

corretamente suas 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, p. 540).
Testes de desempenho. O objetivo deste tipo de teste verificar se o sistema pode

manipular o volume de dados e transaes recebidas, bem como verificar se ele apresenta
o tempo de resposta necessrio (YOURDON, 1990, p. 541). Isso pode exigir que a equipe
de desenvolvimento execute uma srie de testes em que a carga do sistema aumentada
at que o seu desempenho se torne inaceitvel (SOMMERVILLE, 2011, p. 153).
Testes de Unidade. Tm por objetivo verificar um elemento que possa ser logicamente
tratado como uma unidade de implementao, por exemplo, uma sub-rotina ou um mdulo.

Testes de Aceitao. Tm por objetivo validar o produto, ou seja, verificar se esse atende
aos requisitos especificados. Eles so executados em ambiente o mais semelhante
possvel ao ambiente real de execuo.
Se os casos de teste forem desenvolvidos no final da etapa de projeto, com utilizao 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 de caixa preta. Este tipo de teste focaliza
os requisitos funcionais do software, determinando se os mesmos foram total ou parcialmente
satisfeitos pelo produto. Os testes de caixa preta no verificam como ocorre o processamento,
mas apenas os resultados produzidos. Pressman (2011, p. 439) coloca 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 comportamento 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 pode, segundo Pressman (2011, p. 431), garantir
que todos os caminhos independentes de um mdulo foram exercidos 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, p. 451), 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.
161
EVOLUO 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, p. 164), cerca de dois teros de custos de software esto
relacionados evoluo do software, requerendo grande parte do oramento de Tecnologia da
Informao para todas as empresas.
Manuteno de Software
O desafio da manuteno comea to logo o software colocado em funcionamento.
Normalmente, depois que os usurios comeam a utilizar o software, eles percebem que
outras funcionalidades (ainda inexistentes) podem ser acrescentadas ao mesmo, 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 oferecer mais do que est oferecendo.
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, p. 663) coloca que de fato, no raro uma organizao
de software despender de 60% a 70% de todos os recursos com manuteno de software.
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. Neste caso,

se o sistema desenvolvido 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, p. 664), um software manutenvel (de fcil manuteno)
apresenta uma modularidade eficaz, utiliza padres de projeto que permitem entend-lo com
facilidade, foi construdo utilizando padres e convenes de codificao bem definidos. Dessa
forma, tanto o projeto quanto a implementao do software ajudaro a pessoa ou equipe que
precisar realizar a alterao.
<http://www.youtube.com/watch?v=G6yk7fLK3JY&feature=relmfu>.
Vdeo que mostra a importncia dos testes e da manuteno de um software.
CONSIDERAES FINAIS
Nesta ltima unidade, pudemos 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 requisitos. Depois, estudamos sobre a modelagem
do sistema e aprendemos a elaborar o diagrama de casos de uso e o diagrama de classes. E
finalmente, estudamos sobre as etapas de projeto, validao e evoluo de software.
A etapa de projeto de software se caracteriza por ser a definio fsica do sistema, ou seja,
onde podemos definir as interfaces do nosso sistema. No entrei em muitos detalhes de como
elaborar essa interface, pois este no o nosso principal objetivo, mas se voc tiver interesse
pode estudar mais sobre o assunto Interao Humano-Computador (IHC) que uma matria
interdisciplinar que relaciona a cincia da computao, artes, design, ergonomia, semitica e
outras reas afins (veja s como esse assunto abrangente!). Na etapa de projeto tambm
importante especificar cada caso de uso definido no diagrama de casos de uso. Voc deve ter
163
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.
Depois que todos os artefatos descritos na modelagem e no projeto estiverem prontos, hora
da equipe de desenvolvimento codificar o sistema na linguagem de programao escolhida.
Tambm no falamos nada sobre esse assunto, pois com certeza, voc aprender (ou j
aprendeu) as tcnicas de programao em outras disciplinas do seu curso, e saber que
essa etapa bastante trabalhosa e deve ser muito bem realizada para que todo o esforo
despendido at aqui no seja em vo.
Depois que o software foi implementado, hora da sua validao, 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 isto s no basta. necessrio
desenvolver vrios tipos de testes, como mostramos nesta unidade, para assegurar que o
sistema funcionar corretamente. A real validao do software, normalmente, feita quando
o mesmo est em uso, pois muito difcil testar todas as possibilidades de um sistema inteiro.
Aps a implantao e efetiva utilizao do sistema pelo usurio, qualquer alterao que seja
necessria ser considerada como uma evoluo do software. Essa evoluo necessria
para que o software continue sendo til ao usurio, para que ele continue atendendo as
suas necessidades. Se um software tiver uma vida longa, passar por manutenes durante
esse perodo e, para que o mesmo continue manutenvel, vimos que necessrio manter a
aplicao das tcnicas de engenharia de software, pois nem sempre 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 trabalhar) como desenvolvedor(a).
1. Baseando-se no Documento de Requisitos Laboratrio de Anlises Clnicas, mostrado na unidade IV estudo de caso 2:
a. Elabore o Diagrama Geral do Sistema.
b. Elabore as Interfaces de Vdeo dos seguintes casos de uso: Cadastrar exames,

cadastrar mdicos e cadastrar resultados de exame.
c. Elabore as telas de filtros dos relatrios de Ficha de Paciente e Relatrio de
Exame.
d. Elabore o layout dos relatrios de Ficha de Paciente e Exame.
2. Explique quatro diretrizes que devem ser levadas em considerao no desenvolvimento da interface do sistema.
3. Para que um sistema funcione corretamente necessrio que sejam efetuados vrios testes. Explique como o analista deve conduzir esta etapa de testes, para que,
no final, o sistema possa ser considerado apto a ser implantado.
165
CONCLUSO
Neste livro procurei mostrar a voc a importncia da disciplina de Engenharia de Software e
como ela pode ser aplicada durante o desenvolvimento de um sistema. A fim de possibilitar o
seu entendimento, na unidade I, foram estudados os conceitos de software e de engenharia
de software. Mostrei 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 procurei utilizar exemplos que fazem parte do
nosso dia a dia, pensando em facilitar o entendimento para problema e da sua possvel soluo.
Ainda na unidade I tratamos sobre ferramentas CASE, que so softwares que auxiliam o
trabalho do desenvolvedor, automatizando tarefas que so realizadas durante o processo de
software. Outro assunto que estudamos nesta unidade foram alguns conceitos de orientao
a objetos e uma rpida introduo linguagem de modelagem UML.
Na unidade II, trabalhamos especificamente com processos de software. Mostrei 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 atividades 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 software. Mostrei
qual a diferena entre os requisitos funcionais e no funcionais e a importncia do documento
de requisitos, inclusive mostrando um exemplo.
Na unidade IV mostrei 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. Apresentei
tambm um exemplo de diagrama, partindo do documento de requisitos, explicando passo a
passo a elaborao de cada um deles.
E para finalizar, vimos na unidade V, as etapas de projeto, validao e evoluo de software,
permitindo que voc pudesse entender todas as etapas envolvidas nos modelos de processos
de software.
Espero ter alcanado o objetivo inicial, que era mostrar a importncia da Engenharia de Software.
Desejo que voc seja muito feliz profissionalmente utilizando os conceitos apresentados aqui e
se puder ajudar de alguma forma, estou a sua disposio. Desejo muito sucesso e paz.
Prof. Mrcia.
167
REFERNCIAS
BOOCH, Grady. UML: guia do usurio. 2. ed. So Paulo: Campus, 2005.
GUEDES, Gilleanes T. A. UML 2: guia prtico. So Paulo: Novatec Editora, 2007.
LIMA, Adilson da Silva. UML 2.0: do requisito soluo. So Paulo: rica, 2009.
MELO, Ana Cristina. Desenvolvendo Aplicaes com UML 2.0: do conceitual
implementao. Rio de Janeiro: Brasport, 2004.
PRESSMAN, Roger. Engenharia de Software. 7.ed. Porto Alegre: AMGH, 2011.
SILVA, Ricardo Pereira. UML 2: modelagem orientada a objetos . Florianpolis: Visual Books,
2007.
SOMMERVILLE, Ian. Engenharia de Software. So Paulo: Pearson Addison-Wesley, 2007.
SOMMERVILLE, Ian. Engenharia de Software. So Paulo: Pearson Prentice Hall, 2011.
YOURDON, Edward. Anlise Estruturada Moderna. Rio de Janeiro: Elsevier, 1990.

Engenharia de Software

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Engenharia de Software

Încărcat de

Drepturi de autor:

Formate disponibile

Professora Me.

Mrcia Cristina Dadalto Pascutti

Reitor: Wilson de Matos Silva

NEAD - Ncleo de Educao a Distncia

Ficha catalogrfica elaborada pela Biblioteca Central - CESUMAR

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

A engenharia de software surgiu da necessidade de tornar o desenvolvimento de software

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

INTRODUO ENGENHARIA DE SOFTWARE

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

dos softwares continua a ser construda de forma personalizada (sob encomenda).

ENGENHARIA DE SOFTWARE | Educao a Distncia

Alguns Fundamentos da Engenharia de Software

TIPOS DE APLICAES DE SOFTWARE

Software de aplicao so programas desenvolvidos para solucionar uma neces-

ENGENHARIA DE SOFTWARE | Educao a Distncia

sidade especfica de negcio, processando dados comerciais ou tcnicos de forma

Software embutido controla ou gerencia dispositivos de hardware, como por

No existe computador que tenha bom senso.

FERRAMENTAS CASE (COMPUTER-AIDED SOFTWARE ENGINEERING)

3. A gerao de interfaces com usurios, a partir de uma descrio grfica da interface,

Upper CASE ou U-CASE ou Front-End: so aquelas ferramentas que esto voltadas

Lower CASE ou L-CASE ou Back-End: praticamente o oposto das anteriormente

ENGENHARIA DE SOFTWARE | Educao a Distncia

quina. So mais usadas para desenvolvimento corporativo, apresentando controle de

CONCEITOS BSICOS DE ORIENTAO A OBJETOS

ENGENHARIA DE SOFTWARE | Educao a Distncia

exista fsica ou apenas conceitualmente no mundo real. So exemplos de objetos: cliente,

Exemplo de uma Classe

ENGENHARIA DE SOFTWARE | Educao a Distncia

Exemplo de Classe com Atributos

ENGENHARIA DE SOFTWARE | Educao a Distncia

Exemplo de Classe com Atributos e Mtodos

ENGENHARIA DE SOFTWARE | Educao a Distncia

O smbolo de sustenido (#) indica que a visibilidade protegida, ou seja, determina

ENGENHARIA DE SOFTWARE | Educao a Distncia

Exemplo de Herana (generalizao/especializao)

ENGENHARIA DE SOFTWARE | Educao a Distncia

A subclasse Pessoa_Juridica tambm herda todos os atributos e mtodos da superclasse

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

redefinio do mtodo Saque, porque a rotina do mtodo Saque da classe Conta_Especial

UML UNIFIED MODELING LANGUAGE

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

FERRAMENTAS CASE BASEADAS NA LINGUAGEM UML

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

para o desenvolvimento de um software.

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

O processo de desenvolvimento de software e a utilizao de ferramentas CASE

ENGENHARIA DE SOFTWARE | Educao a Distncia

MODELOS DE PROCESSO DE SOFTWARE

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

ENGENHARIA DE SOFTWARE | Educao a Distncia

Fonte: Sommerville (2011, p.22)