7/28/2019 _pontos de Casos de Uso
1/182
UNIVERSIDADE FEDERAL DE SO CARLOS
CENTRO DE CINCIAS EXATAS E DE TECNOLOGIA
PROGRAMA DE PS-GRADUAO EM CINCIAS DA COMPUTAO
DISSERTAO DE MESTRADO
GERAO DE PONTOS DE CASOS DE USO NOAMBIENTE COCAR
MARCOS DANILO CHIODI MARTINS
So CarlosJaneiro/2007
7/28/2019 _pontos de Casos de Uso
2/182
Ficha catalogrfica elaborada pelo DePT daBiblioteca Comunitria da UFSCar
M386gpMartins, Marcos Danilo Chiodi.
Gerao de pontos de casos de uso no ambiente Cocar /Marcos Danilo Chiodi Martins. -- So Carlos : UFSCar, 2008.
169f.
Dissertao (Mestrado) -- Universidade Federal de So
Carlos, 2007.
1. Mtricas de software. 2. Pontos de casos de uso. 3.Modelo de casos de uso. 4. Software desenvolvimento. I.Ttulo.
CDD: 005.1 (20a)
7/28/2019 _pontos de Casos de Uso
3/182
Universidade Federal de So CarlosCentro de Cincias Exatas e de TecnologiaPrograma de Ps-Graduao em Cincia da Computao
"Gerao de Pontos de Casos de Uso no AmbienteCOCAR"
MARCOS DANILO CHIODI MARTINS
Dissertao de Mestrado apresentada aoPrograma de Ps-Graduao em Cincia daComputao da. Universidade Federal de SoCarlos, como parte dos requisitos para aobteno do ttulo de Mestre em Cincia daComputao.Membros da Banca:
~!~clProfa. Dra. Sandra Camargo P. Ferraz Fabbri(Orientadora - DCIUFSCar)
P~~Wel~(ICMCIUSP)
~"" ~ 0~~ JtJc);A)i,Prof. Dr. Auri Marcelo Rizzo Vincenzi(UNlSANTOS)
So CarlosJaneiro/2007
7/28/2019 _pontos de Casos de Uso
4/182
DEDICATRIA
A minha me Marli, irm Mariele, querida noiva Carole padrasto Paulo pelo carinho, incentivo
e pacincia em todos os momentos.Amo muito todos vocs.
7/28/2019 _pontos de Casos de Uso
5/182
AGRADECIMENTOS
Acima de tudo a Deus por me proporcionar a sabedoria, a sade e a coragem necessrios para
me permitir realizar este trabalho.
A minha orientadora, Prof. Dr. Sandra C.P.F. Fabbri, pela confiana, ensinamentos,
motivao e excelente orientao, alm da grande pacincia e dedicao.
A Prof. Dr Maria da Graa Brasil Rocha pela colaborao com a parte de implementao da
ferramenta.
Em especial minha me Marli e irm Mariele pelo apoio e incentivo, nunca me permitindo
o desnimo e sempre me mostrando o melhor caminho.
minha sempre amorosa e solcita noiva Carol pela colaborao nas revises, pelo apoio,
incentivo, carinho, pacincia e compreenso nos meus momentos de ausncia ocasionados
por este trabalho.
Ao diretor Lcio da empresa AGX Tecnologia LTDA e diretora Magda, da empresa
VoxAge Teleinformtica LTDA, pela compreenso, apoio, incentivo e fornecimento de
informaes fundamentais para a realizao deste trabalho.
Aos companheiros de mestrado e amigos Andr e Bruno e ao amigo de cruz Pedro, pelos
conhecimentos compartilhados e pela enorme amizade que cultivamos. Ao amigo Maurcio
agradeo as contribuies tcnicas para a implementao da ferramenta, sem as quais
certamente este trabalho no teria sido concludo.
secretria da Ps-Graduao, Cristina e Miriam, pelos seus servios sempre bem
prestados e a toda comisso da PPGCC pela compreenso dos contratempos acontecidos
durante este trabalho.
Aos professores membros da banca examinadora por prestigiarem este trabalho com sua
presena, crticas e sugestes de melhoria.
7/28/2019 _pontos de Casos de Uso
6/182
SUMRIOSUMRIO......................................................................................................................................................4
LISTA DE FIGURAS ............................................................... ............................................................... .....7
LISTA DE TABELAS...................................................................................................................................8
LISTA DE QUADROS ............................................................. ............................................................... .....9
ABSTRACT ............................................................... ........................................................... .......................11
CAPTULO 1 INTRODUO...................................................................................1
1.1 Contexto...........................................................................................................................................4
1.2 Motivao e Objetivos.....................................................................................................................6
1.3 Organizao do Trabalho...............................................................................................................6
CAPTULO 2 - ENGENHARIA DE REQUISITOS....................................................8
2.1 Consideraes Iniciais.....................................................................................................................8
2.2 Engenharia de Requisitos Principais Conceitos ...................................................... ..................9
2.3 Consideraes Finais.....................................................................................................................28
CAPTULO 3 - MODELAGEM DE REQUISITOS COM CASOS DE USO.............30
3.1 Consideraes Iniciais...................................................................................................................30
3.2 Diagramas de Casos de Uso..........................................................................................................31
3.3 Especificao de Casos de Uso ............................................................ .........................................35
3.4 Consideraes Finais.....................................................................................................................37
CAPTULO 4 - MTRICAS DE TAMANHO DE SOFTWARE................................39
4.1 Consideraes Iniciais...................................................................................................................39
4.2 Pontos de Casos de Uso.................................................................................................................40
4.3 Pontos por Funo.........................................................................................................................45
4.4 Consideraes Finais.....................................................................................................................51
CAPTULO 5 - TRABALHOS RELACIONADOS...................................................535.1 Consideraes Iniciais...................................................................................................................53
7/28/2019 _pontos de Casos de Uso
7/182
v
5.2 Trabalhos Tericos........................................................................................................................54
5.3 Ferramentas para Automatizao de Mtricas de Software.....................................................89
5.4 Consideraes Finais.....................................................................................................................94
CAPTULO 6 - O AMBIENTE COCAR.....................................................................956.1 Consideraes Iniciais...................................................................................................................95
6.2 Funcionalidades do Ambiente COCAR .........................................................................................96 6.3 Aspectos de Implementao do Ambiente COCAR....................................................................100
6.3.1 Processo de Desenvolvimento............... ........................................................... ................................ 1006.3.2 Projeto ....................................................... ................................................................ ....................... 1036.3.3 Implementao ......................................................... ................................................................ ........ 107
6.4 Requisitos Funcionais do Ambiente COCAR Pontos de Caso de Uso....................................1086.4.1 Classificao Automtica da Complexidade dos Casos de Uso ....................................................... 1096.4.2 Clculo da Medida dos Pontos de Caso de Uso ........................................................... .................... 1096.4.3 Transformao da mtrica de PCU em PF ........................................................... ............................ 111
6.5 Consideraes Finais...................................................................................................................111
CAPTULO 7 - EXEMPLO DE USO DO AMBIENTE COCAR ...............................1137.1 Consideraes Iniciais.................................................................................................................113
7.2 Apresentao do Ambiente COCAR............................................................................................115 7.3 Criao de Sistema......................................................................................................................116
7.4 Cadastramento de Requisitos.....................................................................................................117
7.5 Criao do Modelo de Casos de Uso..........................................................................................1217.5.1 - Actor-Goal Reading Technique ...................................................................... ............................... 1217.5.2 - Use Case Reading Technique (UCRT) ............................................................. ............................. 125
7.6 Automatizao da Tcnica PCU e Gerao da mtrica de PF ................................................130
7.7 Avaliao do Ambiente COCAR ..................................................................................................133 7.7.1 Planejamento do Estudo de Caso ............................................................ ......................................... 1337.7.2 Execuo do Estudo de Caso............................................................................... ........................... 1347.7.3 Coleta e Anlise de Dados.................................................................................. ............................ 135
7.8 Consideraes Finais...................................................................................................................138
CAPTULO 8 - CONCLUSO..............................................................................139
8.1 Contribuies e Limitaes deste Trabalho..............................................................................141
8.2 Lies Aprendidas.......................................................................................................................143
8.3 Trabalhos Futuros.......................................................................................................................144
REFERNCIAS BIBLIOGRFICAS.......................................................................146
7/28/2019 _pontos de Casos de Uso
8/182
vi
APNDICE I............................................................................................................157
APNDICE II...........................................................................................................163
7/28/2019 _pontos de Casos de Uso
9/182
vii
LISTA DEFIGURAS
Figura 1 Subreas da engenharia de requisitos [SWEBOK, 2004] ........................................10
Figura 2 Representao grfica de um Caso de Uso .............................................................31Figura 3 Atores com relacionamento de generalizao (adaptado de Boock et al., 2000)....33Figura 4 Casos de Uso e seus relacionamentos (adaptado de Boock et al., 2000)...............35Figura 5 Principais caractersticas e diferenas entre APF e PCU........................................51Figura 6 Processo de estimativa de esforo [Carrol, 2005]...................................................64Figura 7 Formulrio de Casos de Uso Preliminares [Belgamo, 2004]. .................................68Figura 8 - Formulrio de Especificao de Casos de Uso........................................................68Figura 9 - Arquitetura da ferramenta U-EST............................................................................84Figura 10 Formato de um Requisitos Funcional [Kawai, 2005]. ..........................................86Figura 11 Diagrama de Classe UML do Padro DAO[Java, 2006] ....................................105Figura 12 - Diagrama de Classe UML do Padro DAO[Java, 2006] .....................................105Figura 13 - Diagrama de Classes UML do Padro Transfer Object [Java, 2006]..................106Figura 14 - Diagrama de Classes e Seqncia UML do Padro Transfer Object [Java, 2006].................................................................................................................................................106Figura 15 - Diagrama de Classes UML da funcionalidade Cadastrar Sistema..............107Figura 16 - Prototipao Evolucionria [Sommerville, 2003] ...............................................107Figura 17 Interface de help do sistema COCAR...................................................................115Figura 18 Escolha de um sistema ou a criao de um novo sistema...................................116Figura 19 Selecionar um sistema j cadastrado como ativo................................................116Figura 20 Cadastramento de um sistema no ambiente COCAR ..........................................117Figura 21 Cadastramento de Requisitos no ambiente COCAR. ...........................................119
Figura 22 Cadastramento de Entradas no ambiente COCAR ...............................................120Figura 23 Cadastramento de Atores (primrio e secundrio)..............................................120Figura 24 Cadastramento de Solicitante de Requisitos .......................................................120Figura 25 Cadastramento de Gerente de Requisito .............................................................121Figura 26 - Processo de marcao de atores, funes e restries. ........................................123Figura 27 Determinao dos atores e objetivos...................................................................124Figura 28 - Exemplo da interface de resoluo de redundncia intra-atores e inter-atores....125Figura 29 - Exemplo do FAO gerado pela aplicao da AGRT no ambiente COCAR..........125Figura 30 Primeira Etapa: Formulrio de Casos de Uso Preliminares................................127Figura 31 Interface para a especificao dos Casos de Uso e Janela com a janela dosrequisitos relacionados e janela de especificao de curso alternativo ..................................129
Figura 32 Classificao de complexidade dos atores..........................................................130Figura 33 Resultado do Clculo do PCU no ajustado .......................................................131Figura 34 Itens de complexidade ambiental e complexidade tcnica julgados pelo usurio................................................................................................................................................132Figura 35 Relatrio de Pontos de Caso de Uso Ajustado....................................................132
7/28/2019 _pontos de Casos de Uso
10/182
viii
LISTA DETABELAS
Tabela 1 Forma de classificao dos atores com seus respectivos pesos [Karner, 1993]. .....41
Tabela 2 Forma de classificao dos Casos de Uso com seus respectivos pesos [Karner,1993].........................................................................................................................................41Tabela 3 Fatores que contribuem para a complexidade do sistema [Medeiros, 2004; Karner,1993].........................................................................................................................................42Tabela 4 Fatores que contribuem para a eficincia [Medeiros, 2004; Karner, 1993] ............43Tabela 5 Estimativas de especialistas, estimativa por Pontos de Casos de Uso, e Esforo (emhoras) [Anda et al., 2001]. ........................................................................................................55Tabela 6 Resumo dos Pontos de Casos de Usopara projetos incrementais [Mohagheghi etal., 2005]. ..................................................................................................................................59Tabela 7 - Esforo estimado por projetos................................................................................66Tabela 8 - Esforo de desenvolvimento por Caso de Uso........................................................74Tabela 9 - Horas Estimadas X Horas Gastas dos projetos das quatro empresas......................74Tabela 10 Regras para o clculo da Profundidade das Alteraes de um Caso de Uso........76Tabela 11 Principais funcionalidades da ferramenta Construx Estimate [Construx, 2005]..90Tabela 12 Principais funcionalidades da ferramenta Cost Xpert [Costxpert, 2005]. ............91Tabela 13 Principais funcionalidades da ferramenta COSMOS [Cosmos, 2005]. ................91Tabela 14 Principais funcionalidades da ferramenta EEUC [EEUC, 2005]. ........................92Tabela 15 Resumo das funcionalidades das ferramentas analisadas.....................................92Tabela 16 Dados coletados do Estudo de Caso ....................................................................136
7/28/2019 _pontos de Casos de Uso
11/182
ix
LISTA DEQUADROS
Quadro 1 Formulrio de Especificao de Casos de Uso [Belgamo, 2004]..........................37
Quadro 2 Complexidade funcional [IFPUG, 1999]. .............................................................46Quadro 3 Complexidade de EE (IFPUG, 1999). ...................................................................48Quadro 4 Complexidade de SE [IFPUG, 1999]. ...................................................................48Quadro 5 Exemplo de clculo dos Pontos por Funo No Ajustados [IFPUG, 1999]........49Quadro 6 - Caractersticas gerais do sistema [Andrade, 2004]. ...............................................49Quadro 7 -Passos para a determinao do VFA [IFPUG, 1999]. ..........................................50
7/28/2019 _pontos de Casos de Uso
12/182
7/28/2019 _pontos de Casos de Uso
13/182
ABSTRACT
The objective of this paper was to implement an initial version of a development supportenvironment named COCAR based on the Use Case Model. Even though the conception and
some features of this environment are the outcome of several other master papers, this work
emphasises the relevance of the Use Case Point metric (PCU). This metric strengthens the
usage of estimates which are of fundamental importance for the calculation of a system
development time. Furthermore, such a metric is associated to one of the main drivers of a
software product quality, which is the ability to meet delivery time. With the advent of the
object oriented development paradigm, the Use Case Point metric based on the Use Case
Model has been highlighted. However, given the lack of formality and standardization,
specifying and building these models a PCU metric may be jeopardized. In the scope of this
work, there have been relevant contributions to building such an environment implementing
a technique called TUCCA which helps with the model standardization, a functionality that
supports the insertion of system requirements in the environment and the generation of PCU
as in the model generated by TUCCA application. In the assessment process of the COCAR
environment an informal case study, in which a specification of actual software from a
development company, has been carried out, producing Use Case Models, PCUs and effort
estimates, both compared against the industry benchmarks. The results of this research
showed that for this particular situation the output from the COCAR environment were very
close to those defined by the industry.
7/28/2019 _pontos de Casos de Uso
14/182
Captulo 1 Introduo 1___________________________________________________________________________
Captulo 1 IntroduoIntroduo
Segundo MCT (2003), o setor de produo de software no Brasil tem crescidovertiginosamente nas ltimas dcadas. O Brasil tem o stimo maior mercado mundial de
software com vendas de US$ 7,7 bilhes em 2001, importa o equivalente a US$ 1 bilho e
exporta em torno de US$ 100 milhes. O mercado brasileiro apresentou um crescimento
anual mdio de 11% entre 1995 e 2002, cerca de cinco vezes maior do que a expanso do
PIB no perodo. o segmento que mais cresce dentro da indstria brasileira de Tecnologia da
Informao (hardware, servios e software).
Com tanta concorrncia no mercado nacional, no mercado internacional o cenrio no
diferente, as empresas esto em busca constante da melhoria de qualidade no
desenvolvimento de produtos de software e prestao de servios.
Como prova disso tem-se o aumento de empresas de software certificadas em Capability
Maturity Model(CMM), que um modelo de qualidade de processo de software, saltando de
uma empresa certificada em 1997 para 30 certificaes em 2003 [MCT, 2005].
Dentro deste contexto, saber o tamanho, a complexidade, custos efetivos, tempo e esforo
despendidos na construo de seus produtos pode representar para as empresas de tecnologia
de informao um diferencial competitivo muito grande, tanto para aumentar o nvel de
qualidade do seu processo de desenvolvimento, sempre se certificando de que o cliente ir
receber o produto no prazo correto, quanto na melhora em matrias administrativas como
contratao de recursos humanos, medidas de produtividade, decises de projetos, anlise de
risco, relacionamento cliente fornecedor, entre outros [Andrade, 2004 apud Hazan, 1999;
Garmus & Herron, 2000; Longstreet, 2002].
7/28/2019 _pontos de Casos de Uso
15/182
Captulo 1 Introduo 2___________________________________________________________________________
Entre as mtricas citadas, a de tamanho de um produto de software , talvez, uma das mais
importantes, pois por meio dela que se faz possvel estimar o cronograma, custos, esforos
e tempo de desenvolvimento do software [Andrade, 2004 ; Karner, 1993 ; Chen et al., 2004],
informaes estas imprescindveis para a construo do plano de desenvolvimento de
software [Caldieira et al., 1998].
Contudo, pelos motivos apresentados anteriormente, necessrio ento que a medida de
tamanho de software seja feita logo nas fases iniciais do processo de desenvolvimento, e que
seja atualizada no decorrer do projeto, com todas as informaes sobre o software que
estiverem disponveis.
Sendo assim, vrias mtricas vm sendo estudadas ao longo dos anos com o intuito de se
desenvolver novas tecnologias que garantam medidas de tamanho de software mais precisas,
para um melhor gerenciamento do processo de desenvolvimento do software, entre elas
pode-se citar: Linhas de Cdigo Fonte, Pontos por Funo,Bang,Feature Points, Pontos de
Caso de Uso,Internet Points,Domino Points,entre outros [Chen et al., 2004 & McPhee, 1999
& Costxpert, 2005].
Pressman (2006) faz uma diviso entre mtricas orientadas a tamanho (como a Linhas deCdigo Fonte) e mtricas orientadas a funo (como Pontos por Funo e Pontos de Caso de
Uso). Contudo, ele afirma tambm que mtricas orientadas a funo, ao final do seu clculo,
so usadas de forma anloga s mtricas orientadas a tamanho. Ainda, Albrecht (1979)
afirma que Pontos por Funo medem o tamanho de um software de acordo com as
funcionalidades identificadas nos requisitos dos usurios. Portanto, neste trabalho, assim
como em Andrade (2004), as mtricas orientadas a funo sero consideradas como uma
forma de medir o tamanho do software e por isso sero tratadas como mtricas de tamanho[Medeiros, 2004], mesmo porque j sabido da literatura que h vrios mtodos de
transformao de mtricas orientadas a funo para mtricas orientadas a tamanho
[Sommerville, 2003; Anda et al., 2001; Smith, 1999, Fetcke et al., 1998].
Desde a dcada de 1970 h duas mtricas de tamanho de software que predominaram na
indstria nacional e internacional de desenvolvimento: SLOC (Source Lines of Code) e
Pontos por Funo. No Brasil, em 2001, de 30% das empresas pesquisadas que usavam
algum tipo de mtrica de tamanho de software, 10,3% utilizavam o SLOC e 18,2%
utilizavam Pontos por Funo [MCT, 2002].
7/28/2019 _pontos de Casos de Uso
16/182
Captulo 1 Introduo 3___________________________________________________________________________
No entanto, segundo Chen et. al (2004), h algumas desvantagens em usar as mtricas de
SLOC e Pontos por Funo. Chen et al. (2004) diz que a contagem exata do SLOC s
acontece depois que a construo do software j foi finalizada quando, na verdade, o
interessante seria que essa contagem fosse a mais acurada possvel j no incio do
desenvolvimento do software. J a mtrica de Pontos por Funo no apoiada por nenhuma
ferramenta que faa a contagem automaticamente, sendo que esta uma operao manual e
totalmente dependente da experincia do profissional que est fazendo a contagem, tornando
a mtrica totalmente subjetiva e dependente do ponto de vista desse profissional.
Alm disso, a mtrica Pontos por Funo baseada no paradigma procedimental, o qual
separa dados de funo, deixando esse tipo de mtrica pouco adequada para os novosdesenvolvimentos baseados no paradigma de orientao a objetos, o qual trabalha com dados
e funcionalidades de forma combinada [Carbone & Santucci, 2002].
Por ltimo, de acordo com Andrade (2004), a tcnica Pontos por Funo, apesar de medir o
tamanho do software sob o ponto de vista do usurio, usa como base as informaes geradas
durante todo o processo de desenvolvimento do produto, principalmente as da fase de
projeto. Sendo assim, a medida vai ficando mais acurada somente na fase do projeto, o que,
embora seja muito mais vantajoso do que o oferecido pelo SLOC, ainda no to satisfatrio
quanto a indstria de desenvolvimento de software necessita.
Com o aumento do uso do paradigma de desenvolvimento orientado a objeto, o Modelo de
Caso de Uso tem sido amplamente utilizado para a modelagem de requisitos. No entanto,
apesar dele ter surgido junto com o modelo de desenvolvimento de software orientado a
objeto, o Objectory [Jacobson et al., 1992], o Modelo de Casos de Uso pode ser usado
independentemente deste paradigma, dando suporte para outras fases do desenvolvimento[Belgamo, 2004].
O Modelo de Casos de Uso se prope a capturar e descrever os requisitos funcionais do
software, se configurando como uma atividade que poder ser executada normalmente
durante a fase de elicitao e anlise de requisitos para a representao com preciso dos
requisitos descritos pelos usurios logo no incio do processo de desenvolvimento do
software.
7/28/2019 _pontos de Casos de Uso
17/182
Captulo 1 Introduo 4___________________________________________________________________________
Pensando na adaptao da tcnica Anlise de Pontos por Funo para atender o novo
paradigma de desenvolvimento e ainda tentando prover uma medida de tamanho de software
mais precisa logo nas fases iniciais do desenvolvimento do software, Gustav Kerner definiu
uma nova mtrica para medir tamanho de software chamada Pontos de Caso de Uso (PCU)
[Karner, 1993; Damodaran, 2003].
Como o PCU usa um modelo como base para o clculo da mtrica de tamanho, fica vivel a
construo de ferramentas para a realizao do clculo automtico dessa mtrica deixando o
processo mais barato, rpido e manutenvel.
O problema para a construo desse tipo de ferramenta que um Caso de Uso pode ser
especificado de diversas maneiras, a saber: texto estruturado informal, texto estruturado
formal, pseudocdigo, fluxograma, redes de Petri ou linguagens de programao e ainda
podendo fazer uso de diversos graus de detalhamento [Cockburn, 2001; Boock et al., 2000].
Sendo assim, a maneira de especificao do Caso de Uso e o grau de detalhamento usado
podem influenciar muito a contagem dos Pontos de Caso de Uso bem como tornar invivel a
automatizao do processo. No entanto, embora existam vrios trabalhos que discutem e
propem frameworks, templates e protocolos na tentativa de padronizar a escrita deste
modelo [Cockburn, 2001; Ryser & Glinz, 2000; Belgamo 2004], no existe um formato
padro para tanto.
Assim, diferentemente dos Pontos por Funo, que segundo Kusumoto et al. (2004) no
podem ser automatizados, pois os itens envolvidos na contagem so subjetivos e melhor
identificados j na fase de projeto, o Pontos de Caso de Uso podem ser computados logo no
incio do desenvolvimento desde que adote um padro de especificao de Caso de Uso.
1.1 Contexto
Dada a importncia da fase de Engenharia de Requisitos para o ciclo de desenvolvimento de
software, o que sabido da prpria literatura e que ficou caracterizado com alguns dados
apresentados anteriormente, alguns trabalhos relacionados com esse tema tm sido orientados
na mesma linha de pesquisa que este trabalho est inserido.
Um desses trabalhos foi o mestrado de Belgamo [Belgamo, 2004; Belgamo & Fabbri, 2005],
que props uma tcnica de leitura para dar apoio construo de Modelos de Casos de Uso
(Diagrama e Especificao dos Casos de Uso), de tal forma que medida que esses modelos
7/28/2019 _pontos de Casos de Uso
18/182
Captulo 1 Introduo 5___________________________________________________________________________
so construdos, faz-se tambm uma reviso do Documento de Requisitos, uma vez que este
pode no ter passado por um processo de inspeo ou que, mesmo que tenha passado, nem
todos os defeitos podem ter sido detectados.
Com base nos resultados de alguns estudos experimentais j realizados e publicados por
Belgamo [Belgamo & Fabbri, 2004a; Belgamo & Fabbri, 2004b] pode-se dizer que a tcnica
proposta TUCCA1: Technique for Use Case Construction and Construction-based
Requirements Analysis contribui substancialmente para a construo de Modelos de Casos
de Uso mais padronizados, de tal forma que a experincia e a subjetividade do projetista no
tenham tanta interferncia nessa construo. Os Modelos de Casos de Uso gerados nos
estudos experimentais realizados por Belgamo foram tambm avaliados por uma tcnicaproposta por Anda & Sjoberg (2002) e, de acordo com essa tcnica, os modelos satisfazem os
requisitos de qualidade que um bom modelo deve apresentar [Belgamo et al., 2005].
Como vrios passos da TUCCA so bastante procedimentais, vivel a construo de uma
ferramenta que d apoio aplicao da tcnica. Alm disso, um outro trabalho de mestrado
[Kawai, 2005] definiu um formato para especificao de requisitos de forma que a aplicao
da TUCCA seja facilitada.
Assim, dada a relevncia da fase de engenharia de requisitos; dado que os modelos de casos
de uso so bastante utilizados na prtica; que se tem a tcnica TUCCA que ajuda na
padronizao para gerao desses modelos; que se tm diretrizes para especificao dos
requisitos de um sistema de forma a facilitar a aplicao da TUCCA; e que a determinao
do prazo de entrega de um produto uma das principais caractersticas de qualidade de um
processo de desenvolvimento, decidiu-se, no grupo de pesquisa desenvolver um ambiente de
apoio ao desenvolvimento de software que pudesse dar suporte a vrias atividades, tendocomo foco principal o modelo de casos de uso. Outras funcionalidades que podem compor
esse ambiente e que j esto em desenvolvimento no grupo de pesquisa so o gerenciamento
de requisitos e a gerao de casos de teste a partir de casos de uso.
1 Essa tcnica era referenciada anteriormente por GUCCRA-Guidelines for Use Case Construction andRequirements Analysis.
7/28/2019 _pontos de Casos de Uso
19/182
Captulo 1 Introduo 6___________________________________________________________________________
1.2 Motivao e Objetivos
Dado o contexto apresentado anteriormente o principal objetivo deste trabalho foi especificar
e automatizar a mtrica PCU no ambiente COCAR. Para tanto, foi preciso que se tivesse o
modelo de casos de uso do sistema para que outras funcionalidades pudessem ser geradas
com base nele. Assim, como a TUCCA [Belgamo, 2004] e as diretrizes para especificao de
requisitos [Kawai, 2005] foram definidas em outros trabalhos de mestrado, e no se
encontravam implementadas, o objetivo deste trabalho foi implementar essas duas
funcionalidades para dar incio construo do ambiente COCAR, de forma que fosse
tambm possvel implementar a mtrica PCU, que foi o principal alvo de estudo. A
implementao da TUCCA e das diretrizes foram compartilhadas com outro mestrando [Di
Tommazo, 2007], que desenvolveu a funcionalidade de gerenciamento de requisitos,
simultaneamente a este trabalho.
1.3 Organizao do Trabalho
O trabalho em questo est dividido em 8 captulos, sendo que neste captulo foi apresentado
o contexto no qual o trabalho est inserido e os objetivos para sua elaborao.
No Captulo 2 apresentam-se os principais conceitos relacionados Engenharia de Requisitos
bem como as dificuldades existentes nessa etapa do desenvolvimento de software, com base
na viso estabelecida no SWEBOK(2004).
No Captulo 3 apresentada a tcnica de modelagem de requisitos denominada Casos de
Uso, juntamente com a citao de alguns trabalhos que abordam aspectos de padronizao da
especificao dos Casos de Uso.
No Captulo 4 so abordadas duas mtricas de tamanho de software, Pontos de Caso de Uso,
que alvo do trabalho em questo, e a Anlise de Pontos por Funo.
7/28/2019 _pontos de Casos de Uso
20/182
Captulo 1 Introduo 7___________________________________________________________________________
No Captulo 5 descrito o ambiente COCAR, mostrando a sua estrutura e aspectos de
implementao, bem como as funcionalidades deste ambiente implementadas por este
trabalho, alm de um pequeno exemplo que mostra o funcionamento desse ambiente.
No Captulo 6 apresenta-se um exemplo de uso do ambiente COCAR com base em um projeto
de software retirado da indstria de desenvolvimento de software brasileira.
No Captulo 7 so apresentadas as concluses deste trabalho bem como propostas para
trabalhos futuros.
No Apndice I encontram-se partes do Documento de Especificao de Requisitos do
ambiente COCAR que segue as diretrizes para a escrita de documentos de requisitos definidas
por Kawai (2005).
No Apndice II so encontradas partes do Modelo de Casos de Uso projetado por meio da
tcnica TUCCA [Belgamo, 2004] baseando-se no documento de requisitos apresentado no
Apndice I.
Tanto o documento de Especificao de Requisitos quanto o Modelo de Casos de Uso do
ambiente COCAR apresentados nos Apndices I e II ficaram com um volume grande
impossibilitando sua incluso por completo neste trabalho de mestrado.
7/28/2019 _pontos de Casos de Uso
21/182
Captulo 2 Engenharia de Requisitos 8_________________________________________________________________________
Captulo 2 - Engenharia de RequisitosEngenharia de Requisitos
2.1 Consideraes Iniciais
A Engenharia de Requisitos, segundo [Thayer & Dorfman, 1997], a primeira etapa de todo
o processo da Engenharia de Software, tendo como preocupao principal entender o que os
usurios realmente precisam, traduzindo este entendimento num conjunto de especificaes
de requisitos.
Segundo Sommerville (2003), a definio clssica de qualidade de produto que o produto
desenvolvido deve estar de acordo com as suas especificao. Portanto, entender o que o
usurio quer primordial para o sucesso do software. Dessa forma, segundo o SWEBOK
(2004), quando as prticas de Engenharia de Requisitos so realizadas de forma displicente, o
projeto pode levar ao desenvolvimento de um produto de baixa qualidade que no atende a
aquilo que osstakeholders pediram.
Como a estimativa de tamanho de software esta diretamente relacionada com os requisitos
especificados para o software em questo [Sommerville, 2003] especificar bem o software imprescindvel para o sucesso da estimativa. Portanto, estudar a teoria associada
Engenharia de Requisitos de fundamental importncia para este trabalho.
Assim, o objetivo principal deste captulo apresentar os principais conceitos relacionados
Engenharia de Requisitos, o que est feito nos tpicos na Seo 2.2, segundo a viso do
SWEBOK (2004). Em seguida, na Seo 2.3 apresentam-se as consideraes finais.
7/28/2019 _pontos de Casos de Uso
22/182
Captulo 2 Engenharia de Requisitos 9_________________________________________________________________________
2.2 Engenharia de Requisitos Principais Conceitos
Segundo o SWEBOK (2004) a Engenharia de Requisitos uma das reas chaves da
Engenharia de Software e responsvel por coletar, analisar, especificar e validar requisitos
de software, tendo como principal preocupao traduzir a vontade dos usurios do software
em um conjunto de especificao de requisitos de software.
Para melhor explicar a Engenharia de Requisitos, o SWEBOK (2004) a divide em sete
subreas, a saber:
Fundamentos da Engenharia de Requisitos. Processo de Requisitos Elicitao de Requisitos. Anlise de Requisitos. Especificao de Requisitos. Validao de Requisitos. Consideraes Prticas.
A Figura 1 mostra cada um dessas subreas com seus respectivos tpicos. Cada subrea ser
tratada no decorrer desta seo segundo as definies do prprio SWEBOK (2004).
As duas primeiras subreas, Fundamentos da Engenharia de Requisitos e Processo de
Requisitos, trazem definies necessrias para o entendimento das quatro outras subreas
que as seguem: Elicitao de Requisitos, Anlise de Requisitos, Especificao de
Requisitos e Validao de Requisitos, considerados pelo SWEBOK (2004) como sendo as
subreas de maior interesse para a Engenharia de Requisitos em si. Por ltimo h a subrea
Consideraes Prticas a qual mostra algumas prticas importantes que acompanham o
processo de Engenharia de Requisitos.
7/28/2019 _pontos de Casos de Uso
23/182
Captulo 2 Engenharia de Requisitos 10_________________________________________________________________________
Figura 1 Subreas da engenharia de requisitos [SWEBOK, 2004]
Reviso dosRequisitos
Elicitao deRequisitos
Anlise deRequisitos
Especificaode Requisitos
Validao deRequisitos
Engenharia deRequisitos
Fontes deRequisitos
Tcnicas deElicitao
Classificaodos Requisitos
ModeloConceitual
Arquitetura
Design eAlocao deRequisitos
Negociao deRequisitos
Documento deDefinio doSistema
Especificaodos Requisitosdo Sistema
Especificaodos Requisitosde Software
Prototipao
Validao do
modelo
Teste deaceitao
Fundamentos deEngenharia deRequisitos
Definio deRequisitos de Software
Requisitos Funcionaise No-Funcionais
Propriedades Emergentes
Requisitos de Sistema
e de Software
Requisitos de Produto e
Processo
Requisitos Quantificveis
Processo deRequisitos
Modelo de Processo
Atores do Processo
Melhoria e Qualidade
do Processo
Gerenciamento e Suportedo Processo
ConsideraesPrticas
Gerenciamento deMudan as
Atributos de Requisitos
Medindo Requisitos
Natureza Interativa doProcesso de Engenharua
de Requisitos
Rastreabilidade deRequisitos
7/28/2019 _pontos de Casos de Uso
24/182
Captulo 2 Engenharia de Requisitos 11_________________________________________________________________________
a) Fundamentos da Engenharia de Requisitos
Nesta subrea so tratadas algumas definies necessrias para o entendimento das prximas
subreas da Engenharia de Requisitos. Aqui se detalha a definio de requisitos, suaspropriedades e suas classificaes.
Definio de Requisitos de Software
Um requisito de software uma propriedade que o software deve possuir para resolver um
problema especfico do mundo real. Dessa forma um requisito de software deve expressar a
necessidade e as restries colocadas em um produto de software.
Normalmente este problema do mundo real no simples e o requisito de software para
resolv-lo uma combinao complexa de requisitos conhecidos por diferentes pessoas
atuando em diferentes papis no contexto de onde o software ir operar.
Essas diferentes pessoas, que de alguma forma tem influncia direta ou indireta sobre os
requisitos do software, denominam-sestakeholders [Sommerville, 2005].
Dada a complexidade envolvendo os requisitos de um software uma caracterstica importanteque qualquer conjunto de requisitos de software deve possuir de poderem ser verificados.
Mesmo que isso seja difcil e custoso o engenheiro de software deve sempre assegurar que os
requisitos sejam verificados para que o produto final possa atender s necessidades dos
usurios.
Outras caractersticas importantes relacionadas aos requisitos de softwareso:
Prioridade: usada para determinar a ordem com a qual os requisitos devero serimplementados na fase de construo do software;
Unicamente identificvel: cada requisito tem que estar unicamente identificvel peloseu relacionado a um determinado objetivo sustentado por um determinado
stakeholder ou por um determinado grupo de stakeholders que o software deve
atender. Isto para possibilitar o controle de configurao de cada requisito e permitir o
gerenciamento desse requisito por todo o ciclo de desenvolvimento do software.
7/28/2019 _pontos de Casos de Uso
25/182
7/28/2019 _pontos de Casos de Uso
26/182
7/28/2019 _pontos de Casos de Uso
27/182
Captulo 2 Engenharia de Requisitos 14_________________________________________________________________________
Portanto, para evitar essa interpretao errnea do processo de Engenharia de Requisitos, o
SWEBOK (2004) prope a subrea de Processo de Requisitos o qual tratado nesta seo.
Desta forma, neste tpico melhor explicado o funcionamento do Modelo de Processo deEngenharia de Requisitos bem como algumas caractersticas importantes desse modelo.
Modelos de Processo
O processo de engenharia de requisitos no se configura to somente como uma fase inicial
isolada do ciclo de vida do desenvolvimento do software e sim como um processo que se
inicia nas primeiras fases do desenvolvimento e segue sendo refinado conforme o ciclo de
vida do softwareevolui.
Neste contexto, os requisitos do software podem sofrer alteraes ao longo do
desenvolvimento e por isso interessante que o processo de Engenharia de Requisitos esteja
preparado para tratar essas alteraes dando suporte a gerncia de configurao desses
requisitos alterados.
Atores do Processo
Atores do processo de Engenharia de Requisitos so os papis por meio dos quais os
stakeholders atuam no processo. Visto que um software possui vrios stakeholders que
possuem necessidades especficas e participam do processo de Engenharia de Requisitos
assumindo diferentes posturas. Tipicamente se tem os seguintessatakeholders:
Usurios: grupo formado pelas pessoas que iro operar o software. Normalmentebastante heterogneo contendo indivduos com diferentes papis e solicitando
diferentes requisitos;
Clientes: Grupo composto por pessoas que esto patrocinando a implementao dosoftware ou ainda por pessoas que so o mercado alvo para o qual o software esta
sendo construdo;
Analistas de Mercados: softwareimplementado destinado para um mercado de massa(sem um cliente patrocinador especfico) necessita do papel do analista de mercado
para definir o que este mercado esta demandando.
Reguladores: h vrios domnios de aplicao que necessitam de rgos reguladorescomo instituio bancrias e transporte pblico. Desta maneira se faz necessrio que
7/28/2019 _pontos de Casos de Uso
28/182
Captulo 2 Engenharia de Requisitos 15_________________________________________________________________________
o software implementado para estes domnios de aplicao sejam regulamentados
pelas autoridades competentes.
Engenheiros de Software: so as pessoas que tem verdadeiro interesse em gerar lucrocom a implementao do software.
Dado o grande nmero destakeholders normalmente envolvidos no processo de Engenharia
de Requisitos simplesmente impossvel atender todos os requisitos de todos os
stakeholders. Por isso, funo do Engenheiro de Requisitos intermediar os interesses dos
stakeholders, elicitando todos os requisitos, entendendo a natureza da necessidade de cada
requisito de cada stakeholdere negociando esses requisitos com os principais stakeholders,
sempre levando em considerao as restries oramentrias e tcnicas do projeto.
Gerenciamento e Suporte do Processo
O processo de engenharia de requisitos requer alguns recursos gerenciais que sejam capazes
de fazer a ligao entre as atividades deste processo e custos, recursos humanos, treinamento
e ferramentas. Por isso, importante levar em considerao, desde o incio da Engenharia de
Requisitos, as prticas estabelecidas na rea chave de Gerenciamento de Engenharia de
Software abordadas no SWEBOK (2004).
Melhoria e Qualidade do Processo
Alguns dos principais papis desenvolvidos pela Engenharia de Requisitos so: melhorar a
satisfao do cliente em relao ao produto desenvolvido e gerenciar melhor custos e prazos
do projeto. Desta forma muito importante avaliar a qualidade do processo de Engenharia de
Requisitos, analisando a sua eficcia e o quanto este processo esta contribuindo para o papel
acima definido.
Portanto, muito importante que o processo de Engenharia de Requisitos seja regido por
padres de qualidade e melhoria de processo de software e sistemas, principalmente no
quesito qualidade do softwaree estimativas.
7/28/2019 _pontos de Casos de Uso
29/182
Captulo 2 Engenharia de Requisitos 16_________________________________________________________________________
c) Elicitao de Requisitos
Segundo SWEBOK (2004), esta a primeira fase de quatro que compem o processo de
Engenharia de Requisitos de Software, na qual o objetivo o entendimento sobre o propsitodo softwareque est sendo implementado. O principal interesse na elicitao de requisitos
identificar as fontes nas quais os requisitos de software sero elicitados e definir como o
Engenheiro de Software poder fazer o levantamento de requisitos.
Fontes de Requisitos
Requisitos podem vir de vrias fontes e essencial que todas essas fontes sejam identificadas
e os seus impactos sobre os requisitos do software sejam avaliados.
Para ser capaz de identificar e avaliar as fontes de requisitos importante que os engenheiros
de software fiquem atentos aos seguintes itens:
i. Objetivos do Software este item tambm conhecido como fator crtico de sucesso dosoftware e seu propsito dar uma viso superficial sobre o software, ressaltando seus
objetivos gerais e a motivao para a sua construo;
ii. Conhecimento do domnio Os engenheiros de software devem adquirir conhecimentosobre o domnio da aplicao. Isto permite a eles inferir conhecimento intuitivo que os
stakeholders no foram capazes de exteriorizar.
iii. Stakeholders de suma importncia que os engenheiros de software no foquem todaa ateno para apenas um grupo de stakeholders. O engenheiro de software deve
identificar, representar e gerenciar os pontos de vistas de vrios e diferentes tipos de
stakeholders para que o produto de software no seja concebido com uma viso
unilateral das necessidades dosstakeholders.
iv. Ambiente operacional Requisitos tambm sero derivados do ambiente no qual osoftware ser executado e por isso importante que o engenheiro de software conhea
esse ambiente, j que ele pode influenciar bastantes custos e decises no projeto do
software.
v. Ambiente organizacional Software construdo geralmente para dar suporte aprocessos de um determinado negcio e podem estar condicionados a uma estrutura,
cultura e polticas internas de uma organizao. Os engenheiros de software precisamser sensveis a esses aspectos, pois software que iro rodar nesses ambientes no podem
7/28/2019 _pontos de Casos de Uso
30/182
Captulo 2 Engenharia de Requisitos 17_________________________________________________________________________
implicar (pelo menos no sem um planejamento prvio) em mudanas nas regras de
negcio da organizao.
Uma vez que as fontes de requisitos tenham sido identificadas e os seus impactos sobre osrequisitos do software avaliados, o engenheiro de software pode comear a coletar os
requisitos do sistema a partir dessas fontes.
Tcnicas de Elicitao
A coleta dos requisitos do sistema uma atividade muito difcil e o engenheiro de software
deve estar ciente de que os usurios apresentam extrema dificuldade em descrever as tarefas
do software, podendo deixar passar despercebido informaes importantes. Por isso, mesmo
com a cooperao dos stakeholders, os engenheiros de software tm um trabalho difcil na
fase de elicitao dos requisitos.
Segundo Sommerville (2003) esta dificuldade ocorre pois:
i. Normalmente os stakeholders so generalistas na definio do que desejam dosistema;
ii. Para os stakeholders os requisitos do sistema so quase intuitivos pois, na grandemaioria das vezes, expressam conhecimento implcito da prpria rea de atuao dos
envolvidos;
iii. Como os stakeholders so formados por um grupo de pessoas grande emultidisciplinar, freqente acontecer conflitos entre os requisitos;
iv. Fatores polticos dentro de organizao podem afetar diretamente os requisitos dosoftware. Gerentes podem definir certos requisitos apenas para aumentar sua
influncia na organizao;
v. bastante comum que o ambiente de negcios associado ao sistema seja dinmico, oque leva os requisitos a sofrerem alteraes a todo momento;
Exatamente pela elicitao de requisitos ser um processo extremamente complicado, h
vrias tcnicas para contemplar essa fase da Engenharia de Requisitos. As principais tcnicas
sugeridas no SWEBOK (2004) so:
7/28/2019 _pontos de Casos de Uso
31/182
Captulo 2 Engenharia de Requisitos 18_________________________________________________________________________
i. Entrevistas meio tradicional de elicitao de requisitos. importante para oengenheiro de software saber das vantagens e limitaes desse mtodo e como conduzi-
la bem.
ii. Cenrios meio valioso para prover contexto para a elicitao de requisitos juntamentecom o usurio. Esse mtodo capaz de prover para o engenheiro de software em um
conjunto de questes sobre as tarefas do usurio como o que ... se isso? ou ainda
como isto feito ?. O tipo mais comum de cenrio o Casos de Uso.
iii. Prottipos abordagem eficiente para tornar claro os requisitos ainda no entendidos eavaliar o sistema antes dele ser construdo. Essa ferramenta pode atuar de forma similar
aos cenrios, provendo aos usurios um contexto no qual ele pode entender melhor qual
informao ele precisa fornecer, para que o software fique o mais completo possvel deacordo com suas necessidades. H uma gama enorme de tcnicas de prototipao que
vo desde mock-up (tcnica de prototipao que usa grficos, imagens e ilustraes em
papel para descrever telas e interao com o usurio) at verses executveis no
oficiais do software (verso beta para teste) que tambm so usados para a validao dos
requisitos.
iv. Reunies intermediadas o propsito desta tcnica tentar alcanar um efeito sinrgico,partindo do princpio de que um grupo de pessoas pode contribuir mais para a coleta derequisitos do que cada pessoa individualmente contribuiria. Essa tcnica pode trazer
idias por meio de brainstorms (reunio na qual vrias idias so enunciadas pelos
participantes sem nenhuma restrio e depois as melhores so selecionadas para
anlise) que dificilmente seriam descobertas por tcnicas de entrevistas usuais. Quando
funciona bem, essa tcnica pode trazer um conjunto de requisitos mais consistente do
que outras tcnicas.
v.
Observao a importncia do contexto do software dentro do ambiente da organizaotem conduzido adaptaes das tcnicas observacionais para a elicitao de requisitos de
software. Engenheiros de software aprendem sobre as tarefas do usurio por meio de
uma imerso em seu ambiente de trabalho, observando como os usurios interagem com
seus software e entre eles. O grande problema dessa tcnica que os usurios tendem a
se policiar mais em suas atividades quando tem alguma pessoa observando as suas
atividades; sendo assim, o que o engenheiro de software vai observar uma tarefa que
nem sempre executada da forma que est sendo mostrada.
7/28/2019 _pontos de Casos de Uso
32/182
Captulo 2 Engenharia de Requisitos 19_________________________________________________________________________
De posse dos requisitos elicitados por meio dos interessados na construo do sistema, tm-
se artefatos suficientes para se avanar para a prxima fase da engenharia de requisitos, a
anlise dos requisitos elicitados.
d) Anlise de Requisitos
Na elaborao dos requisitos de um software deve-se tentar assegurar que estes sempre sejam
descritos de forma a possibilitar a sua validao, a verificao de sua implementao e a
estimativa de seus custos. Para tanto, modelos conceituais so muito aceitos nesta fase,
contudo deve ser claro que, ao contrrio da viso tradicional, esta fase no deve se resumir a
apenas a elaborao desses modelos conceituais.
Assim, a fase de anlise de requisitos tambm tem por objetivo:
Detectar e resolver conflitos entre os requisitos. Descobrir os limites do software e como ele deve interagir com o seu ambiente. Elaborar requisitos de sistema para derivar requisitos de software.
Desta forma, nesta subrea, alm dos modelos conceituais, sero tratados tambm assuntos
importantes para garantir os objetivos dessa fase.
Classificao de Requisitos
Para melhor entender o domnio do software e suas funcionalidades, de acordo com o
SWEBOK Guide 2004 [SWEBOK, 2004], os requisitos devem ser classificados. Existem
vrias formas para a classificao dos requisitos, por exemplo:
i. Requisito Funcional ou Requisito No Funcional.ii. Requisito Derivado ou Emergente: quando um requisito derivado de um ou mais
outros requisitos de alto nvel, ou uma propriedade emergente ou est sendo imposto
diretamente por umstakeholderou outra fonte de requisitos.
iii. Requisito de Produto ou Requisito de Processo: requisitos de processo podem restringira escolha de um contratado ou o processo de engenharia de software a ser escolhido.
iv. Prioridade do requisito: em geral, quanto mais alta a prioridade do requisito maisessencial o requisito para o software. A prioridade tem sempre que ser balanceada deacordo com o seu custo de desenvolvimento e implementao.
7/28/2019 _pontos de Casos de Uso
33/182
Captulo 2 Engenharia de Requisitos 20_________________________________________________________________________
v. Escopo: refere-se extenso com a qual o requisito afeta o software e seuscomponentes.
vi. Volatilidade e Estabilidade: Alguns requisitos iro mudar durante o ciclo de vida dedesenvolvimento do software. Sendo assim, seria muito interessante classificar os
requisitos de acordo com uma probabilidade de mudana que esses requisitos venham a
ter. Sinalizar requisitos potencialmente volteis pode ajudar ao engenheiro de software a
estabelecer um projeto mais tolerante a mudanas.
Tendo classificado os requisitos e entendido melhor o escopo do problema pode-se seguir
com o desenvolvimento de modelos que considerado como a chave da anlise de requisitos
de software, pois esses modelos podero ser usados para a especificao, validao everificao de requisitos, projeto e teste do software.
Modelo Conceitual
Para efeitos prticos, SWEBOK (2004) define um modelo como sendo uma notao ou um
conjunto de notaes includas em um processo que guia a aplicao dessas notaes.
Modelos conceituais devem representar o domnio do problema do mundo real atravs da
modelagem de suas partes e dos relacionamentos e dependncias entre essas partes. Portanto
o principal objetivo da modelagem no ser o incio do projeto do software, apesar de poder
ser usado para tal, mas sim ajudar a compreender melhor o problema do mundo real a ser
implementado pelo software.
Segundo Pressman (2006), o modelo de anlise deve atingir trs objetivos principais:
descrever o que o cliente exige; estabelecer a base para a criao de um projeto de software;
definir um conjunto de requisitos que possam ser validados quando o software for construdo.
Para tanto SWEBOK (2004) sugere vrios modelos que podem ser construdos nesta fase,
incluindo fluxo de dados, modelos de estado, modelos de rastreamento de eventos, modelos
de interao com usurio, modelos de objeto, modelo de dados entre outros.
Para escolher esses modelos h vrios fatores que devem ser levados em considerao,
podendo-se citar [SEWBOK, 2004]:
7/28/2019 _pontos de Casos de Uso
34/182
Captulo 2 Engenharia de Requisitos 21_________________________________________________________________________
i. A natureza do problema: Alguns tipos de software demandam que certos aspectospossam ser analisados particularmente e rigorosamente. Por exemplo, modelos de estado
e fluxo de controle parecem ser mais importantes para software de tempo real do que
para software de gerenciamento de informaes.
ii. A percia do engenheiro de software: geralmente mais produtivo adotar um modelocom o qual o engenheiro de software tenha experincia.
iii. O processo de engenharia de requisitos do cliente: Clientes podem impor algum mtodoou ainda proibir que algum mtodo seja utilizado. Este fator pode entrar em conflito
com o fator anterior.
iv. A disponibilidade de mtodos e ferramentas: Mtodos para os quais no existemferramentas ou treinamento que o do suporte podem no ser aceitos mesmo que sejammais indicados para tipos particulares de problemas.
Arquitetura Design e Alocao de Requisitos
Segundo SWEBOK (2004), o software implementar os requisitos que esto sendo elicitados
por meio de vrios componentes que sero desenvolvidos.
A arquitetura e modelagem desses componentes so realizadas na fase de Projeto doSoftware, contudo a identificao desses componentes e a alocao dos requisitos para esses
componentes deve ser realizada nesta fase da engenharia de requisitos.
Realizar a alocao de requisitos com componentes significa identificar os componentes do
software necessrios para a implementao de um determinado requisito. Por isso, comum
dizer que esta fase da Engenharia de Requisitos se sobrepe com a fase de Projeto de
Software, fazendo com que o engenheiro de requisitos atue como um arquiteto de software.
SWEBOK(2004) chama a ateno para a importncia da execuo dessa atividade na fase de
engenharia de requisitos, pois com ela possvel realizar mais uma anlise detalhada dos
requisitos de software, j que s desta maneira possvel identificar os componentes e os
relacionamentos entre os componentes necessrios para a sua implementao, ou seja, alocar
componentes para requisitos demanda uma nova rodada detalhada de anlise de cada
requisitos.
Porm, o mapeamento de entidades do mundo real para componentes de software no
sempre bvio e, por isso, o Projeto da Arquitetura considerado como um tpico separado da
7/28/2019 _pontos de Casos de Uso
35/182
Captulo 2 Engenharia de Requisitos 22_________________________________________________________________________
modelagem de requisitos e deve ser continuado em fases posteriores (fase de Projeto de
Software) do ciclo de vida de desenvolvimento do software.
Estando os requisitos classificados, modelados e com o projeto da arquitetura do softwareiniciado, fica mais fcil identificar requisitos conflitantes, perfazendo a atividade de
negociao de requisitos, que tambm comumente chamada de resoluo de conflitos.
Negociao de Requisitos
Essa atividade consiste em resolver problemas com requisitos conflitantes que ocorrem
quando dois stakeholders requerem concomitantemente caractersticas incompatveis entre
requisitos e recursos ou entre requisitos funcionais e no funcionais. Na maioria das
vezes no aconselhvel o engenheiro de software tomar uma deciso unilateral, sendo mais
conveniente consultar osstakeholders para chegar a um consenso. Geralmente, por questes
contratuais, importante que esse tipo de deciso seja levada at o cliente.
Com isso, contemplam-se todas as atividades da fase de anlise de requisitos e parte-se para a
fase de especificao.
e) Especificao dos Requisitos
Segundo SWEBOK (2004), para muitas outras engenharias o termo especificao significa o
ato de se atribuir valores ou limites para os objetivos do projeto que esta sendo desenvolvido.
Contudo, na rea de desenvolvimento de software, tipicamente h um nmero pequeno
desses valores, sendo que a nfase esta na quantificao e no gerenciamento da interao
entre o grande nmero de requisitos existente.
Sendo assim, na engenharia de software, a especificao de requisitos de software geralmente
se refere produo de um documento, ou sua verso eletrnica equivalente, que possa ser
sistematicamente revisto, avaliado e aprovado, buscando um melhor gerenciamento dos
requisitos e suas relaes.
Para sistemas complexos, geralmente, se desenvolvem trs tipos desses documentos, a saber:
Documento de Definio do Sistema. Documento de Requisitos do Sistema.
7/28/2019 _pontos de Casos de Uso
36/182
Captulo 2 Engenharia de Requisitos 23_________________________________________________________________________
Documento de Requisitos de Software.Documento de Definio do Sistema
O documento de definio do sistema, tambm conhecido como documento de requisitos do
usurio, guarda os requisitos do sistema definindo-os em alto nvel segundo uma perspectiva
do domnio da aplicao.
Sendo assim, este documento deve listar os requisitos de acordo com uma viso mais abstrata
do sistema e deve ser escrito tendo como pblico alvo o prprio cliente/usurio do software e
utilizar termos do escopo da aplicao (usando os termos do domnio para o qual a aplicao
ser desenvolvida), tendo como objetivo listar os requisitos do sistema, trazendo informaes
relevantes sobre o ambiente no qual o sistema ir operar, restries da operao do sistema e
ainda requisitos no funcionais.
Este documento tambm pode incluir alguns modelos conceituais do sistema como modelos
de contexto e modelos de cenrios.
Documento de Requisitos do Sistema
Para sistemas que renem uma grande quantidade de componentes de software e
componentes no-software (hardware, por exemplo), costuma-se separar a especificao
dos requisitos do sistema da especificao dos requisitos de software.
Para esse tipo de sistema o documento de especificao do sistema dever ser elaborado.
Contudo, segundo o SWEBOK(2004), especificar sistemas uma atividade estritamente da
rea de engenharia de sistemas e foge do escopo desse trabalho, de qualquer maneira pode-se
encontrar informaes sobre esse tipo de documento e especificao em IEEE std 1233
(IEEE1234-98).
Documento de Requisitos de Software
O documento de especificao de requisitos do software estabelece as bases para um acordo
entre clientes e desenvolvedores definindo o produto de software que ir ser construdo.
7/28/2019 _pontos de Casos de Uso
37/182
Captulo 2 Engenharia de Requisitos 24_________________________________________________________________________
A especificao de requisitos do software permite que seja feito um julgamento rigoroso dos
requisitos antes que a fase de projeto se inicie, reduzindo, desta forma, possveis re-projetos
tardios do software.
Tambm possvel com este documento prover uma base para a realizao de estimativas de
custo, risco e cronograma do produto. Ainda algumas indstrias usam esse documento como
entrada para se planejar a fase de validao e verificao de forma mais produtiva.
O documento de especificao de requisitos de software deve ser escrito usando linguagens
formais ou semi-formais, sendo que a escolha de uma boa notao permite que certos
requisitos ou aspectos da arquitetura do software sejam descritos com mais preciso e
consistncia do que se fossem especificados usando uma linguagem natural. Sendo assim,
como regra geral, adotam-se notaes sempre que se deseje descrever os requisitos da
maneira mais precisa possvel.
Por essa caracterstica formal e tcnica do documento de especificao de requisitos
comum este vir acompanhado com o documento de definio do sistema para que leitores
leigos sejam capazes de compreender melhor o documento.
f) Validao de Requisitos
De acordo com SWEBOK(2004), os documentos de requisitos descritos no tpico e
servem de entrada para esta fase da Engenharia de Requisitos, j que esses documentos sero
aqui avaliados quanto ao grau de entendimento dos requisitos por parte dos engenheiros de
software que iro desenvolver o produto, quanto conformidade com padres estabelecidos,
clareza, consistncia e completeza.
Sendo assim, o objetivo principal dessa atividade de validao analisar os documentos de
requisitos especificados na fase anterior para certificar-se de que o software que ser
construdo o software que o usurio espera ver. Ou seja, nessa fase que se procura validar
se os requisitos especificados realmente definem o sistema que o cliente deseja.
[Sommerville, 2005]
Desta forma, considera-se aqui uma vantagem ter os documentos de requisitos escritos com
uma linguagem formal, pois isto permite que a consistncia e a clareza dos requisitos possam
ser testadas.
7/28/2019 _pontos de Casos de Uso
38/182
Captulo 2 Engenharia de Requisitos 25_________________________________________________________________________
Ainda nessa fase importante que diferentes stakeholders, incluindo representantes dos
clientes e desenvolvedores, revisem o(s) documento(s) de requisitos que ainda servir como
entrada para outras atividades derivadas do ciclo de vida do processo de desenvolvimento do
software, sendo normal que essas revises aconteam mais de uma vez durante o processo de
levantamento de requisitos.
Segundo SWEBOK(2004), para se realizar a validao de requisitos vrias tcnicas podem
ser usadas, como por exemplo:
Reviso de requisitos. Prototipao. Validao de modelo. Planejamento de Testes de aceitao.
Em seguida se explica cada uma delas:
Reviso de Requisitos
Este o meio de validao mais comum e tambm conhecido como inspeo de requisitos.
Nesta tarefa um grupo responsabilizado por rever os documentos de requisitos em busca de
erros, suposies errneas, falta de clareza e desvios de padres estabelecidos.
aconselhvel que o grupo que ir fazer a reviso dos requisitos tenha a presena de um
cliente, para que a reviso seja direcionada sob o ponto de vista do usurio, que um dos
principais interessados.
Prototipao
A prototipao um timo meio para validar a interpretao do engenheiro de software em
relao aos requisitos coletados, alm de configurar-se como uma ferramenta muito poderosa
para se elicitar novos requisitos que ainda no foram descobertos.
Contudo, essa tcnica apresenta algumas desvantagens. Uma delas o fato da possibilidade
do cliente se desviar das principais funcionalidades do sistema e ficar mais atento a
problemas cosmticos ou a problemas de falta de qualidade do prottipo. Por isso, algumas
7/28/2019 _pontos de Casos de Uso
39/182
Captulo 2 Engenharia de Requisitos 26_________________________________________________________________________
pessoas recomendam que a prototipao seja feita sem o uso de um software e sim atravs de
mock-ups desenhados em papel.
Validao de Modelo
H a possibilidade de se validar tambm os modelos conceituais estabelecidos durante a fase
de anlise. Para tanto existem vrias tcnicas de validao que buscam analisar a qualidade
desses modelos. Se uma notao formal de especificao tiver sido usada possvel utilizar
lgica formal para testar certas propriedades dos modelos.
Planejamento de Testes de Aceitao
Uma propriedade fundamental dos requisitos de software que seja possvel validar se o
produto final os implementa. Desta forma, uma importante tarefa planejar como cada
requisito ser verificado aps a sua implementao e, na maioria dos casos, planejar testes de
aceitao uma tima estratgia para isso.
A grande dificuldade em se planejar testes de aceitao para todos os requisitos encontra-se
quando estes so requisitos no funcionais. Sendo assim importante, antes de realizar o
planejamento dos testes de aceitao, ainda na fase de anlise, encontrar uma forma de
quantificar os requisitos no funcionais, possibilitando o planejamento dos testes de aceitao
para esses requisitos.
g) Consideraes Prticas
Este ltimo tpico abordado pelo SWEBOK (2004) concentra-se em mostrar alguns
comportamentos dos requisitos ou do Processo de Engenharia de Requisitos que precisam ser
entendidas na prtica.
Assim nesta subrea da Engenharia de Requisitos sero tratados tpicos como a
interatividade do processo de Engenharia de Requisitos e a Gerncia de Requisitos
A natureza interativa do Processo de Engenharia de Requisitos
praticamente impossvel conceber um processo de Engenharia de Requisitos que seja linear
e determinstico no qual os requisitos so elicitados atravs dosstakeholders uma nica vez e
7/28/2019 _pontos de Casos de Uso
40/182
Captulo 2 Engenharia de Requisitos 27_________________________________________________________________________
depois so armazenados dessa forma durante todo o processo de desenvolvimento do
software.
Um ponto que deve ficar claro na Engenharia de Requisitos que os requisitos de softwaremudam conforme o desenvolvimento do software avana. Essas mudanas podem ser
causadas por alguma falha no momento da elicitao do requisitos, mas frequentemente essas
mudanas so reflexos de uma mudana no ambiente no qual o software ir operar como por
exemplo mudanas no mercado onde este software ser vendido ou ainda mudanas nas
regras de negcio do cliente.
Como essas mudanas nos requisitos so inevitveis muito importante que o processo de
Engenharia de Requisitos no seja considerado como um simples processo que termina assim
que a fase de projeto se inicia. Ao invs disso, o processo de Engenharia de Requisitos deve
se preocupar em gerenciar os requisitos durante todo o processo de desenvolvimento de
software gerenciando as mudanas dos requisitos ocorridas para garantir que cada uma
dessas mudanas seja submetida a um processo de aprovao, tenha o seu histrico de
alteraes armazenado e tenha o seu impacto analisado.
Gerenciamento de Mudanas
Para o SWEBOK (2004), o gerenciamento de mudanas a atividade central para o
gerenciamento de requisitos pois neste tpico que se descrevem todos os procedimentos
necessrios e as anlises que devem ser feitas para controlar as alteraes feitas nos
requisitos.
Contudo, o SWEBOK (2004) prefere tratar esse tpico na rea chave de Gerncia de
Configurao de Software.
Atributos dos Requisitos
Todo requisito deve ser composto no apenas pela descrio da especificao do que
requerido pelo software, mas tambm por informaes complementares que ajudam a
gerenciar e interpretar melhor os requisitos.
7/28/2019 _pontos de Casos de Uso
41/182
7/28/2019 _pontos de Casos de Uso
42/182
Captulo 2 Engenharia de Requisitos 29_________________________________________________________________________
documento de requisitos do sistema e o Modelo de Casos de Uso o qual ser melhor
explicado no prximo captulo.
7/28/2019 _pontos de Casos de Uso
43/182
Captulo 3 Modelagem de Requisitos com Casos de Uso 30________________________________________________________________________
Captulo 3 - Modelagem de Requisitos com Casos de Uso
Modelagem de Requisitoscom Casos de Uso
3.1 Consideraes Iniciais
Neste captulo sero apresentados os principais conceitos associados tcnica Casos de Uso,
uma vez que o ambiente COCAR essencialmente baseado no Modelo de Casos de Uso de
um sistema, para o qual se deseja prover algumas informaes, inclusive a funcionalidade de
gerao dos Pontos de Casos de Uso, que foi o principal objeto de estudo deste trabalho.
O conceito de Casos de Uso foi proposto inicialmente por Ivar Jacobson, em 1992, como
parte de seu modelo de processo Objectory [Jacobson et al., 1992]. Embora essa tcnicatenha sido incorporada UML [OMG, 2005], como um dos modelos a ser construdo, ela no
uma tcnica restrita ao paradigma de orientao a objetos, podendo ser utilizada em
qualquer contexto.
Por ser uma tcnica simples e que facilita o entendimento do sistema que est sendo
modelado, ressaltando as funcionalidades e as interaes com os atores (usurios) dessas
funcionalidades, ela tem sido muito utilizada na prtica. Jacobson et al (1992) salientam que
o Modelo de Casos de Uso tambm serve como um modelo central que deve ser utilizado
para todos os demais modelos das prximas fases de Anlise, Projeto, Implementao, Testes
e Manuteno. No entanto, no existem diretrizes associadas tcnica que determinem como
um modelo de casos de uso deva ser construdo, permitindo com que a experincia e
subjetividades tenham grande interferncia nessa atividade. Em decorrncia disso, o trabalho
de Belgamo (2004), desenvolvido anteriormente, props a tcnica de leitura TUCCA, cujo
objetivo principal a construo desses modelos e corresponde funcionalidade bsica do
ambiente COCAR, pois, com base nesses modelos que outras funcionalidades so
oferecidas.
7/28/2019 _pontos de Casos de Uso
44/182
Captulo 3 Modelagem de Requisitos com Casos de Uso 31________________________________________________________________________
O captulo est organizado da seguinte forma: na Seo 3.2 apresentam-se os conceitos
relacionados com o Diagrama de Casos de Uso, na Seo 3.3 comenta-se sobre a
Especificao dos Casos de Uso e na Seo 3.4 apresentam-se as Consideraes Finais.
3.2 Diagramas de Casos de Uso
Os Modelos de Caso de Uso so representaes pictricas do documento de requisitos, que
tm como objetivo mostrar a funcionalidade do sistema, bem como a interao dos usurios
com o mesmo [Belgamo, 2004]. Esses modelos so compostos pelo Diagrama de Casos deUso e pelas Especificaes dos Casos de Uso e so considerados uma tcnica para capturar
os requisitos funcionais de um sistema, descrevendo as interaes tpicas entre os usurios
desse sistema e o prprio sistema, alm de fornecer uma narrativa de como o sistema
utilizado [Fowler, 2005].
Conceitualmente, de acordo com Booch et al. (2000), um Caso de Uso uma descrio de
um conjunto de seqncias de aes, incluindo tambm as variantes dessas aes, que um
sistema executa para produzir um resultado de valor observvel por um ator. Graficamente, o
Caso de Uso representado como uma elipse.
Sendo assim, um Caso de Uso um tipo de classificador que representa: uma unidade
coerente de funcionalidade provida por sistema ou por um sub-sistema; uma ou mais
interaes desta unidade com componentes externos (representado pelos atores); aes
realizadas pelo prprio sistema [UML 2003].
Todo Caso de Uso deve ter um nome nico (uma seqncia de caracteres textuais) que seja
capaz de diferenci-lo dos demais Casos de Uso.
A Figura 2 mostra a representao de um Caso de Uso com o seu nome.
Figura 2Representao grfica de um Caso de Uso
Validarusurio
7/28/2019 _pontos de Casos de Uso
45/182
Captulo 3 Modelagem de Requisitos com Casos de Uso 32________________________________________________________________________
Para mostrar a interao entre o Caso de Uso com entidades externas a ele existe a figura do
ator.
Um ator representa um conjunto coerente de papis que os usurios dos Casos de Usodesempenham quando interagem com esses Casos de Uso. O ator no precisa
necessariamente desempenhar apenas o papel de algum usurio humano; ele tambm pode
desempenhar o papel de um dispositivo de hardware ou at de um outro sistema que interage
com o sistema em questo. Por isso Fowler (2005) afirma que papel seria o termo mais
correto para o que hoje a comunidade de Engenharia de Software chama de ator.
Portanto, pode-se concluir que os Casos de Usos modelam aquilo que o sistema deve fazer
enquanto os atores definem a interao de alguma coisa de fora com o sistema [Jacobson et
al., 1992].
Schneider & Winters (2001) propem algumas questes bsicas para auxilio identificao
de atores no sistema, a saber:
Quem usa o sistema?
Quem instala o sistema? Quem inicia o sistema? Quem mantm o sistema? Quem finaliza o sistema? Quais outros sistemas fazem uso deste sistema? Quem recebe informaes do sistema? Quem envia informaes para o sistema? Alguma coisa acontece automaticamente em um determinado tempo?
A representao de um ator acontece por meio de figuras estilizadas que lembram um ser
humano caricato. Esse tipo de representao o bastante para o ator, pois como ele
representa alguma coisa externa ao sistema, no necessrio descrev-lo em detalhes
[Jacobson et al., 1992].
Existe a possibilidade de se definirem grupos gerais de atores que depois podero ser
especializados, como por exemplo, pode-se definir um ator pessoa, que generaliza um grupo
7/28/2019 _pontos de Casos de Uso
46/182
Captulo 3 Modelagem de Requisitos com Casos de Uso 33________________________________________________________________________
de pessoas qualquer, e depois especializar outros atores como funcionrio, professor e aluno,
usando o relacionamento de generalizao, como mostrado na Figura 3.
Figura 3Atores com relacionamento de generalizao (adaptado de Boock et al., 2000)
O relacionamento de generalizao um relacionamento da UML que relaciona itens gerais
em tipos mais especficos desses itens, ou seja, h a necessidade das partes que esto se
relacionando serem de um mesmo tipo.
Cockburn (2001) inseriu uma forma de se classificar atores, a saber:
Atores Primrios: so aqueles que esto em constante contato com o sistema e porisso iro executar as principais tarefas do sistema. Este ator freqentemente aquele
que aciona o Caso de Uso
Atores Secundrios: so aqueles que fazem o sistema funcionar atravs dofornecimento de um servio para o mesmo. Sendo assim no esto em contato
constante com o sistema e no costumam realizar as tarefas principais deixando issopara o ator principal. importante identificar esses atores, pois a partir deles se
identificam as interfaces externas que o sistema usar e os protocolos que cruzam esta
interface.
A conexo entre os Casos de Uso e os atores acontece por meio de um relacionamento de
associao. Este tipo de relacionamento usado na UML como um relacionamento estrutural
que especifica a conexo de objetos de um item com objetos de outro item. Quando usado
para relacionar o Caso de Uso com o ator, essa associao indica que existe uma
Pessoa
Funcionrio
Professor
Aluno
7/28/2019 _pontos de Casos de Uso
47/182
Captulo 3 Modelagem de Requisitos com Casos de Uso 34________________________________________________________________________
comunicao entre esses itens, tendo cada parte a possibilidade de envio e recebimento de
mensagens.
Os Casos de Uso podem ser relacionados entre si atravs de generalizaes, incluses ouextenses [Boock et al., 2000].
Em uma generalizao de Casos de Uso o que acontece que um Caso de Uso filho ir
herdar o comportamento e significado do Caso de Uso pai e poder acrescentar ou
sobrescrever algum comportamento.
Para evitar a escrita de um mesmo fluxo de eventos vrias vezes, existe a possibilidade da
incluso de Casos de Uso. Dessa forma, um Caso de Uso (que ser chamado de Caso de Uso
base), poder incluir, em algum momento do seu fluxo de eventos, um outro Caso de Uso.
Esse Caso de Uso includo nunca poder aparecer isoladamente sendo que no momento da
incluso o seu comportamento explicitamente incorporado pelo Caso de Uso base que o
est incluindo.
Um relacionamento de incluso pode ser representado como uma dependncia estereotipada
com include. Dependncia um relacionamento de utilizao definido pela UML. Exemplos
de incluso podem ser vistos na Figura 4.
Contudo, se o comportamento a ser includo em um Caso de Uso no for obrigatrio, ou seja,
h um fluxo de evento no Caso de Uso base que no passa pelo Caso de Uso que esta sendo
includo, o que acontece ento uma extenso de um Caso de Uso. Sendo assim, o Caso de
Uso base poder aparecer isolado e, sob certas condies, seu comportamento poder ser
estendido pelo comportamento de um outro Caso de Uso. O relacionamento estendido
representado como uma dependncia estereotipada como extend. Exemplos de extenso
podem ser vistos na Figura 4.
Apenas o nome e a interao do Caso de Uso com atores no so suficientes para se
descrever o comportamento desse Caso de Uso. preciso algo que deixe claro o
comportamento dos Casos de Uso para qualquer pessoa que precise entender o modelo. Para
isso, elaboram-se as Especificaes dos Casos de Uso. Na Especificao dos Casos de Uso,
existe o que se chama de fluxo de eventos no qual se pode incluir como e quando o Caso de
Uso inicia e termina, quando o Caso de Uso interage com os atores, quais objetos so
7/28/2019 _pontos de Casos de Uso
48/182
Captulo 3 Modelagem de Requisitos com Casos de Uso 35________________________________________________________________________
transferidos e o fluxo bsico e alternativo do comportamento, tambm conhecidos como
curso normal e curso alternativo.
Figura 4 Casos de Uso e seus relacionamentos (adaptado de Boock et al., 2000)
O fluxo de eventos de um Caso de Uso pode ser especificado de diversas formas: por meio
de um texto estruturado informal, texto estruturado formal (com pr e ps condies),
pseudocdigo, fluxograma, redes de Petri ou linguagens de programao [Sommerville,2005].
3.3 Especificao de Casos de Uso
Segundo Fowler (2005), apesar da UML adotar os Casos de Uso como um de seus
diagramas, ela apresenta uma definio bastante superficial da tcnica, se limitando apenas a
formalizar o Diagrama de Caso de Uso, sem preocupao em padronizar a Especificao dos
mesmos.
Essa falta de padronizao sobre a forma de escrita do fluxo de eventos de um Caso de Uso
dificulta a determinao de mtricas a partir desse modelo [Damodaran, 2003], apesar de
vrias tcnicas usadas atualmente considerarem os Casos de Uso como sendo um indicador
de tamanho e complexidade de um sistema [Vinsen et al, 2004].
7/28/2019 _pontos de Casos de Uso
49/182
Captulo 3 Modelagem de Requisitos com Casos de Uso 36________________________________________________________________________
Por outro lado, Belgamo (2004) mostra que existem alguns autores que sugerem a utilizao
de templates na Especificao de Casos de Uso, como por exemplo, [Kulak & Guiney, 2000;
Ryser & Glinz, 2000; Cockburn, 2001, Schneider & Winters, 2001].
No trabalho de Schneider & Winters (2001) so sugeridas algumas questes que auxiliam na
identificao dos atores do Modelo de Casos de Uso, bem como algumas diretrizes para a
criao de Casos de Uso.
Kulak & Guiney (2000), sugerem um mtodo com quatro interaes pr-estabelecidas, com
base no qual o Modelo de Casos de Uso evolui gradativamente.
Ryser & Glinz, (1999) desenvolveram um mtodo denominado SCENT (SCENarios-Based
Validation and Test of Software) no qual a partir do Modelo de Casos de Uso so elaborados
Statecharts que sero utilizados na criao de Casos de Teste. Embora o principal objetivo do
trabalho seja o desenvolvimento de Casos de Testes um formulrio de especificao de Casos
de Uso apresentado neste trabalho.
J Cockburn (2001) trabalha com o conceito de objetivos para transform-los em Casos de
Uso. Desta forma, os objetivos de um determinado sistema so classificados em trs
possveis nveis: usurio (so objetivos que mostram as necessidades que o ator tem em
relao ao sistema), resumo (so os que mostram as necessidades que contexto no qual o
sistema esta inserido tem) e sub-funes (so os objetivos necessrios para que os objetivos
do usurio possam ser executados).
Dos trabalhos acima analisados nenhuma proposta rene todas as necessidades que a
especificao de Casos de Uso exige em um s template. Por isso, analisando essas
propostas, Belgamo (2004) definiu o template de Especificao de Casos de Uso apresentado
no Quadro 1, o qual utilizado no ambiente COCAR, como resultado da aplicao da TUCCA.
Assim, com base na maneira em que as informaes relacionadas ao Caso de Uso so
armazenadas nesse template, podem-se calcular os Pontos de Casos de Uso, que o principal
objetivo deste trabalho.
7/28/2019 _pontos de Casos de Uso
50/182
7/28/2019 _pontos de Casos de Uso
51/182
Captulo 3 Modelagem de Requisitos com Casos de Uso 38________________________________________________________________________
uma representao do sistema que d apoio a vrias outra
Top Related