Beruflich Dokumente
Kultur Dokumente
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
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
ENGENHARIA DE SOFTWARE
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.
Diante disso, o Cesumar almeja ser reconhecido como uma instituio universitria de refern-
cia regional e nacional pela qualidade e compromisso do corpo docente; aquisio de compe-
tncias 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.
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.
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.
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.
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.
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,
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.
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.
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.
UNIDADE I
SOFTWARE.............................................................................................................................19
ENGENHARIA DE SOFTWARE..............................................................................................20
HISTRICO DA UML...............................................................................................................34
UNIDADE II
PROCESSOS DE SOFTWARE
PROCESSOS DE SOFTWARE...............................................................................................42
ESPECIFICAO DE SOFTWARE.........................................................................................55
VALIDAO DE SOFTWARE..................................................................................................58
EVOLUO DE SOFTWARE..................................................................................................60
UNIDADE III
REQUISITOS DE SOFTWARE
REQUISITOS DE SOFTWARE................................................................................................67
REQUISITOS DE USURIO....................................................................................................72
REQUISITOS DE SISTEMA.....................................................................................................72
REQUISITOS DE QUALIDADE................................................................................................78
ENGENHARIA DE REQUISITOS.............................................................................................80
ESTUDO DE VIABILIDADE.....................................................................................................81
ESPECIFICAO DE REQUISITOS........................................................................................89
VALIDAO DE REQUISITOS................................................................................................90
UNIDADE IV
MODELAGEM DE SISTEMAS
INTRODUO.........................................................................................................................97
MODELAGEM DE SISTEMAS.................................................................................................99
MULTIPLICIDADE.................................................................................................................. 119
CLASSE ASSOCIATIVA.........................................................................................................120
ESTUDO DE CASO...............................................................................................................122
UNIDADE V
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
Objetivos de Aprendizagem
Plano de Estudo
Ferramentas CASE
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.
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
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 fabri-
cado 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 concen-
tram-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 dife-
rente, 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 hardwa-
re, 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
ENGENHARIA DE SOFTWARE
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 con-
fiveis 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 fos-
sem 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.
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.
2. A compreenso de um projeto utilizando-se um dicionrio de dados que contm in-
formaes sobre as entidades e sua relao em um projeto.
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 caracters-
ticas 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 Ferramen-
ta tambm acompanham todo o ciclo de desenvolvimento, entretanto, possuem a
propriedade de conjugar sua capacidade a outras ferramentas externas comple-
mentares, que variam de acordo com as necessidades do usurio. Para um melhor
entendimento, podemos compar-las a um computador sem o kit multimdia, as Best
in Class seriam o computador que funciona normalmente, e as outras ferramentas
fariam o papel do kit multimdia, promovendo um maior potencial de trabalho m-
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
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.
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.
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.
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).
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.
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 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
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.
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
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, diferenciando-
se 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.
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
<http://www.youtube.com/watch?v=MnJLeYAno4o&feature=relmfu>.
Vdeo que mostra uma introduo aos conceitos de orientao a objetos.
Fonte: <http://onlywhatmatters.wordpress.com/2011/02/20/uml-unified-modeling-language/>
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).
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).
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
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
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 ENGENHARIA DE SOFTWARE | Educao a Distncia
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.
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
ATIVIDADE DE AUTOESTUDO
1. Uma classe um conjunto de objetos que compartilham os mesmos atributos, mto-
dos 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.
PROCESSOS DE SOFTWARE
Professora Me. Mrcia Cristina Dadalto Pascutti
Objetivos de Aprendizagem
Plano de Estudo
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
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.
PROCESSOS DE SOFTWARE
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 desen-
volvimento do software podem mudar e o software precisa evoluir para atender a essas
mudanas.
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.
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.
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, desen-
volvimento, validao e evoluo, que so fundamentais ao processo, e as representa
como fases separadas, como a especificao de requisitos, o projeto de software, a im-
plementao, os testes e assim por diante (SOMMERVILLE, 2011).
2. Desenvolvimento Incremental. Esse modelo intercala as atividades de especifica-
o, 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 desenvolvimen-
to 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
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
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 pro-
posto 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 ne-
cessidades 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
Atividades concorrentes
Verso inicial
Especificao
Descrio do Verses
Desenvolvimento intermedirias
esboo
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.
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 maioria dos projetos de software, ocorre algum reuso de software, pois, normalmente,
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
(SOMMERVILLE, 2011, p. 23).
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.
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 ati-
vidades 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.
ESPECIFICAO DE SOFTWARE
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.
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.
VALIDAO DE SOFTWARE
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.
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.
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.
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
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.
ATIVIDADE DE AUTOESTUDO
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, de-
fina um modelo de processo de software que poderia ser utilizado por uma pequena
empresa de desenvolvimento de sistemas.
REQUISITOS DE SOFTWARE
Professora Me. Mrcia Cristina Dadalto Pascutti
Objetivos de Aprendizagem
Plano de Estudo
Documento de Requisitos
Engenharia de Requisitos
INTRODUO
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.
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).
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.
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.
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
Requisitos funcionais
Requisitos no funcionais
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.
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
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 espe-
cificao de requisitos.
2. Na maioria dos casos, os sistemas devem interoperar com outros sistemas exis-
tentes, 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
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.
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.
Captulo Descrio
Deve definir os possveis leitores do documento e descrever seu histrico
Prefcio de verses, incluindo uma justificativa para a criao de uma nova verso
e um resumo das mudanas feitas em cada verso.
Deve descrever a necessidade para o sistema. Deve descrever bre-
vemente as funes do sistema e explicar como ele vai funcionar com
Introduo outros sistemas. Tambm deve descrever como o sistema atende aos
objetivos globais de negcio ou estratgicos da organizao que enco-
mendou o software.
Deve definir os termos tcnicos usados no documento. Voc no deve
Glossrio
fazer suposies sobre a experincia ou o conhecimento do leitor.
Deve descrever os servios fornecidos ao usurio. Os requisitos no
funcionais de sistema tambm devem ser descritos nessa seo. Essa
Definio de requisitos
descrio pode usar a linguagem natural, diagramas ou outras notaes
de usurio
compreensveis para os clientes. Normas de produto e processos a se-
rem seguidos devem ser especificados.
Deve apresentar uma viso geral em alto nvel da arquitetura do siste-
ma previsto, mostrando a distribuio de funes entre os mdulos do
Arquitetura do sistema
sistema. Componentes de arquitetura que so reusados devem ser des-
tacados.
Uma determinada locadora possui muitos ttulos em seu acervo e no consegue controlar
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).
3. Controlar devolues
Verificar se a devoluo est no prazo correto e se o pagamento foi efetuado, caso
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 utiliza-
o do software.
Confiabilidade indica a capacidade do software em manter seu nvel de desempenho
sob determinadas condies durante um perodo de tempo estabelecido.
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 Go-
vernana Corporativa, abordando a Engenharia de Requisitos.
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.
Quais so os problemas com os processos atuais e como um novo sistema ajudaria a diminuir
esses problemas?
As informaes podem ser transferidas para outros sistemas organizacionais e tambm podem
ser recebidas a partir deles?
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.
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.
Entrevista
As entrevistas formais ou informais com os stakeholders do sistema faz parte da maioria dos
A sumarizao durante e no final da entrevista necessria primeiro para garantir que toda
informao apresentada foi anotada e segundo que foi corretamente entendida.
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).
d) Evitar falar palavras sem sentido (falar baixo, fazer generalizaes, termos tcnicos).
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:
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.
c) Fluxo funcional: para cada funo importante, determinar as etapas exigidas e descreva o
significado delas.
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.
Coloque trs interessados em uma sala e pergunte a eles que tipo de sistema desejam. Provavelmen-
te voc obter quatro ou mais opinies diferentes.
Autor desconhecido.
ESPECIFICAO 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
(SOMMERVILLE, 2007, p. 105).
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 necess-
rio para realizar certas funes. Contudo, mais estudos e anlises podem identificar
funes adicionais ou diferentes, que so exigidas. Os sistemas tm diversos usu-
rios 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 con-
flitantes, 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.
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
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
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.
MODELAGEM DE SISTEMAS
Professora Me. Mrcia Cristina Dadalto Pascutti
Objetivos de Aprendizagem
Plano de Estudo
Diagrama de Classes
INTRODUO
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.
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.
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.
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).
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.
Atores
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
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
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).
Generalizao
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).
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).
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).
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,
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.
Extenso
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.
Especializao/
Associao Incluso Extenso
Generalizao
Caso de Uso e Caso
----- OK OK OK
de Uso
Ator e Ator ----- OK ----- -----
Ator e Caso de Uso OK ----- ----- -----
ESTUDO DE CASO
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).
A figura abaixo mostra uma possvel soluo para o problema que acabamos de descrever.
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.
As classes no trabalham sozinhas, pelo contrrio, elas colaboram umas com as outras por
meio de relacionamentos (MELO, 2004, p. 108).
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.
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.
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 agregao
Generalizao/Especializao
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.
Multiplicidade Significado
No mnimo zero (nenhum) e no mximo um. Indica que os objetos das classes
associadas no precisam obrigatoriamente estar relacionados, mas se houver
0..1
relacionamento indica que apenas uma instncia da classe se relaciona com as
instncias da outra classe.
Um e somente um. Indica que apenas um objeto da classe se relaciona com os
1..1
objetos da outra classe.
No mnimo nenhum e no mximo muitos. Indica que pode ou no haver instn-
0..*
cias da classe participando do relacionamento.
* Muitos. Indica que muitos objetos da classe esto envolvidos no relacionamento.
No mnimo 1 e no mximo muitos. Indica que h pelo menos um objeto envolvi-
1..*
do no relacionamento, podendo haver muitos objetos envolvidos.
No mnimo 2 e no mximo 5. Indica que existem pelo menos 2 instncias envol-
2..5 vidas no relacionamento e que podem ser 3, 4 ou 5 as instncias envolvidas,
mas no mais do que isso.
CLASSE ASSOCIATIVA
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
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 escrev-
los 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
ESTUDO DE CASO
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.
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.
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 per-
tence 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
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,
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!
ATIVIDADE DE AUTOESTUDO
1. Sobre relacionamento entre Casos de Uso e Atores
a. Explique o relacionamento de Associao (association).
b. Explique o relacionamento de Generalizao entre casos de uso (generaliza-
tion).
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 Diagrama B
Gnero 1..* Filme Gnero 0..* Filme
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.
DATA: 99/99/9999
N PEDIDO NOME FORNECEDOR TOTAL COM-
PRADO
999999 XXXXXXXXXXXXXXXXXXXXXXXX 99.999.999,99
999999 XXXXXXXXXXXXXXXXXXXXXXXX 999.999.999,99
Vendas dirias por cliente sinttico. Este relatrio ser solicitado e recebido
pelo Departamento de Vendas.
DATA: 99/99/9999
TOTAL VEN-
N NF NOME CLIENTE VENDEDOR
DIDO
999999 XXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXX 99.999.999,99
999999 XXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXX 99.999.999,99
Objetivos de Aprendizagem
Plano de Estudo
Testes de Software
Evoluo de Software
INTRODUO
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.
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
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
Sistema
Biblioteca
Autores Geral
Livros em
Exemplares
Atraso
Fonte: a autora
O Diagrama de Caso de Uso referente a esse sistema deveria conter, pelo menos, os seguintes
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 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.
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.
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.
NOME DA EMPRESA
DATA: 99/99/9999 Relatrio de Clientes PAG.: 99
CDIGO NOME ENDERECO 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
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.
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,
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
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.
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
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
Alm desses conceitos bsicos, voc deve conhecer os seguintes tipos de testes:
Testes de Unidade. Tm por objetivo verificar um elemento que possa ser logicamente
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.
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.
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
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
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
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).
ATIVIDADE DE AUTOESTUDO
1. Baseando-se no Documento de Requisitos Laboratrio de Anlises Clnicas, mos-
trado na unidade IV estudo de caso 2:
a. Elabore o Diagrama Geral do Sistema.
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.
Espero ter alcanado o objetivo inicial, que era mostrar a importncia da Engenharia de Software.
Prof. Mrcia.
LIMA, Adilson da Silva. UML 2.0: do requisito soluo. So Paulo: rica, 2009.
SILVA, Ricardo Pereira. UML 2: modelagem orientada a objetos . Florianpolis: Visual Books,
2007.