Análise e Projeto de Sistemas Da Informação 2a Ed

Cadastre-se em www.elsevier.com.brpara conhecer nosso catlogo completo,

ter acesso a servios exclusivos no site e receber informaes sobre nossos

lanamentos e promoes.

Raul Sidnei Wazlawick

Anlise e projeto de sistemas de informao orientados a objetos2a edio revista e atualizada

Pgina deixada intencionalmente em branco

CIP-Brasil. Catalogao-na-fonte.Sindicato Nacional dos Editores de Livros, RJ

_________________________________________________________________________

_________________________________________________________________________

W372aWazlawick, Raul Sidnei, 1967- Anlise e projeto de sistemas de informaes orientados a objetos [recurso eletrnico] / Raul Sidnei Wazlawick. - Rio de Janeiro : Elsevier, 2011. recurso digital (Srie SBC, Sociedade Brasileira de Computao)

Modo de acesso: World Wide Web Inclui bibliografia e ndice

1. Mtodos orientados a objetos (Computao). 2. UML (Computa-o). 3. Anlise de sistemas. 4. Projeto de sistemas. 5. Software - De-senvolvimento. 6. Livros eletrnicos. I. Sociedade Brasileira de Cmpu-tao. II. Ttulo. III. Srie.

11-4296 CDD: 005.117CDU: 004.414.2

2011, Elsevier Editora Ltda.

Todos os direitos reservados e protegidos pela Lei no 9.610, de 19/02/1998.Nenhuma parte deste livro, sem autorizao prvia por escrito da editora, poder ser reproduzida ou transmitida sejam quais forem os meios empregados: eletrnicos, mecnicos, fotogrficos, gravao ou quaisquer outros.

Copidesque: Ivone TeixeiraReviso: Bruno BarrioEditorao Eletrnica: SBNIGRI Artes e Textos Ltda.

Elsevier Editora Ltda.Conhecimento sem FronteirasRua Sete de Setembro, 111 16o andar20050-006 Centro Rio de Janeiro RJ Brasil

Rua Quintana, 753 8o andar04569-011 Brooklin So Paulo SP Brasil

Servio de Atendimento ao [email protected]

Nota: Muito zelo e tcnica foram empregados na edio desta obra. No entanto, podem ocorrer erros de digitao, impresso ou dvida conceitual. Em qualquer das hipteses, solicitamos a comunicao ao nosso Servio de Atendimento ao Cliente, para que possamos esclarecer ou encaminhar a questo.

Nem a editora nem o autor assumem qualquer responsabilidade por eventuais danos ou perdas a pessoas ou bens, originados do uso desta publicao.

ISBN 978-85-352-1117-7 (recurso eletrnico)

ISBN 978-85-352-1117-7 (recurso eletrnico)

Formato: FLASH Requisitos do sistema: Adobe FLASH PLAYER

Este livro dedicado aos meus pais e antepassados, sem os quais eu no existiria.

Dedicatria

Desejo agradecer a vrias pessoas que, de uma forma ou outra, torna-ram este livro possvel: ao mestre Luiz Fernando Bier Melgarejo, por apresen-tar as ideias de orientao a objetos j em 1987; ao colega Marcos Eduardo Casa, por todos os trabalhos desenvolvidos em conjunto nos tempos em que orientao a objetos era coisa de outro mundo; ao colega Antnio Carlos Mariani, pelo Mundo dos Atores, ferramenta que tanto usamos para ensinar programao orientada a objetos; ao ex-aluno Leonardo Ataide Minora, por inicialmente me chamar a ateno para o livro de Larman; s empresas e r-gos pblicos que possibilitaram a implantao dessas tcnicas em ambientes reais de produo de software e especialmente ao engenheiro de software Gil-mar Purim, pelas interessantes discusses que muito contriburam para dar a forma final a este livro; aos ex-alunos Everton Luiz Vieira e Kuesley Fernandes do Nascimento, por terem ajudado a consolidar algumas das tcnicas quando da aplicao delas a um interessante sistema Web; ao Departamento de Infor-mtica e Estatstica da UFSC, pela oportunidade de concretizar este trabalho; e a Dayane Montagna, por digitar o primeiro rascunho deste livro a partir das gravaes das minhas aulas.

Agradeo tambm aos mais de mil ex-alunos, vtimas da minha disci-plina de Anlise e Projeto de Sistemas Orientados a Objetos suas dvidas e dificuldades me fizeram pesquisar e aprender muito mais; ao colega Rogrio Cid Bastos, por muitas orientaes recebidas; e, finalmente, aos amigos e ir-mos, pelos momentos de descontrao e higiene mental.

Agradecimentos

Este livro apresenta, de maneira didtica e aprofundada, elementos de anlise e projeto de sistemas de informao orientados a objetos.

A rea de desenvolvimento de software tem se organizado nos ltimos anos em torno da linguagem de modelagem UML (Unified Modeling Langua-ge) e do processo UP (Unified Process), transformados em padro internacio-nal pela OMG (Object Management Group).

No se procura aqui realizar um trabalho enciclopdico sobre UP ou UML, mas uma apresentao de cunho estritamente prtico, baseada em mais de vinte anos de experincia em ensino, prtica e consultoria em anlise, pro-jeto e programao orientada a objetos.

Este livro diferencia-se da maioria de outros livros da rea por apresen-tar em detalhes as tcnicas de construo de contratos de operao e consulta de sistema de forma que esses contratos possam ser usados para efetiva gera-o de cdigo.

Novos padres e tcnicas de modelagem conceitual so detalhadamente apresentados, tcnicas estas tambm adequadas para uso com contratos e dia-gramas de comunicao, de forma a garantir gerao automtica de cdigo; no apenas de esqueletos, mas de cdigo final executvel.

Em relao aos casos de uso de anlise, o livro apresenta, em detalhes, tcnicas para ajudar a decidir o que considerar efetivamente como caso de uso. Essa dificuldade tem sido sistematicamente relatada por analistas de vrias par-tes do Brasil, a partir do contato obtido em cursos ministrados pelo autor.

Ao contrrio de outros livros da rea, que se organizam em torno da apresentao dos diagramas UML e procuram explicar todos os seus poss-

Prefcio

veis usos, este livro se concentra nas atividades com as quais o analista e o projetista de software possivelmente vo se deparar e sugere quais diagramas poderiam ajud-los e de que forma.

Algumas empresas brasileiras ainda tm dificuldade em conseguir ex-portar software devido falta de flexibilidade e manutenibilidade dos sistemas gerados. Este livro apresenta um conjunto de informaes e tcnicas que pode suprir essa carncia. As tcnicas em questo foram implementadas com xito pelo autor na empresa TEClgica Ltda., em Blumenau, no desenvolvimento de um projeto de grande porte em 2004. Posteriormente, as tcnicas fo-ram aplicadas e aperfeioadas nos departamentos de tecnologia de informa-o do Ministrio Pblico de Santa Catarina, Tribunal Regional do Trabalho do Mato Grosso e Justia Federal de Santa Catarina, contendo agora ainda mais orientaes e detalhes do que na primeira edio deste livro.

O livro direcionado a profissionais de computao (analistas, proje-tistas e programadores) e a estudantes de graduao e ps-graduao das dis-ciplinas de Anlise e Projeto de Sistemas e Engenharia de Software. Como conhecimentos prvios so recomendados rudimentos sobre orientao a ob-jetos, notao UML e fundamentos de banco de dados.

Para que o livro pudesse aprofundar ainda mais as informaes sobre anlise e projeto orientados a objetos sem se tornar demasiadamente longo, foram suprimidas nesta segunda edio algumas informaes referentes ao processo de Engenharia de Software que estavam presentes na primeira edio. Esses processos sero descritos de forma detalhada pelo autor em um novo livro sobre Engenharia de Software a ser lanado brevemente. Alm disso, para ganhar espao e dinamismo, os exerccios, anteriormente includos no livro, passam a estar disponveis apenas na Internet (www.elsevier.com.br/wazlawick ou www.inf.ufsc.br/~raul/).

Raul Sidnei WazlawickFlorianpolis, 19 de fevereiro de 2010.

Sumrio

Captulo 1 Introduo .............................................................................. 11.1. Desenvolvimento de Sistemas Orientados a Objetos ............................... 21.2. Linguagem de Modelagem Unificada UML ........................................... 31.3. Processo Unificado UP ............................................................................. 41.4. As Atividades de Anlise e Projeto no Contexto do Processo

Unificado ........................................................................................................ 6

Captulo 2 Viso Geral do Sistema .......................................................... 92.1. Modelagem de Negcio com Diagrama de Atividades .......................... 112.2. Modelagem de Aspectos de Negcio com Diagrama de Mquina de

Estados .......................................................................................................... 152.3. Comentrios ................................................................................................ 19

Captulo 3 Requisitos ............................................................................. 213.1. Levantamento de Requisitos ...................................................................... 22

3.1.1. Levantar Requisitos no Projeto! .............................................. 223.1.2. Desafios dos Requisitos................................................................. 233.1.3. Requisitos Funcionais ................................................................... 243.1.4. Requisitos No Funcionais ........................................................... 253.1.5. Requisitos Suplementares ............................................................. 263.1.6. Documento de Requisitos ............................................................ 26

3.2. Anlise de Requisitos .................................................................................. 293.2.1. Permanncia e Transitoriedade ................................................... 293.2.2. Requisitos Evidentes e Ocultos .................................................... 303.2.3. Requisitos Obrigatrios e Desejados .......................................... 313.2.4. Classificao de Requisitos No Funcionais

e Suplementares ............................................................................. 31

Captulo 4 Casos de Uso de Alto Nvel ................................................... 354.1. Caracterizao de Casos de Uso................................................................ 37

4.1.1. Monossesso ................................................................................... 384.1.2. Interativo ......................................................................................... 384.1.3. Resultado Consistente ................................................................... 38

4.2. Complexidade de Casos de Uso ................................................................ 394.3. Priorizao de Casos de Uso...................................................................... 404.4. Fronteira do Sistema ................................................................................... 41

Captulo 5 Casos de Uso Expandidos ..................................................... 435.1. Caso de Uso Essencial Versus Caso de Uso Real .................................... 445.2. Fluxo Principal ............................................................................................ 46

5.2.1. Passos Obrigatrios ....................................................................... 475.2.2. Passos Complementares ............................................................... 525.2.3. Passos Imprprios ......................................................................... 53

5.3. Estilos de Escrita ......................................................................................... 555.4. Tratamento de Excees em Casos de Uso .............................................. 565.5. Variantes do Fluxo Principal ..................................................................... 605.6. Casos de Uso Includos .............................................................................. 625.7. Cenrios e Casos de Uso ............................................................................ 635.8. Expanso de Casos de Uso Padro ........................................................... 64

5.8.1. Relatrio Expandido ..................................................................... 645.8.2. CRUD Expandido .......................................................................... 65

5.9. Outras Sees de um Caso de Uso Expandido ....................................... 685.9.1. Atores .............................................................................................. 685.9.2. Interessados .................................................................................... 695.9.3. Precondies .................................................................................. 705.9.4. Ps-condies de Sucesso ............................................................. 705.9.5. Requisitos Correlacionados.......................................................... 705.9.6. Variaes Tecnolgicas ................................................................. 715.9.7. Questes em Aberto ...................................................................... 71

Captulo 6 Diagramas de Sequncia de Sistema .................................... 736.1. Elementos do Diagrama de Sequncia ..................................................... 746.2. Representao de Casos de Uso Expandidos como Diagramas

de Sequncia de Sistema ............................................................................. 766.3. Ligao da Interface com o Domnio ....................................................... 776.4. Estratgias Statefull e Stateless ................................................................... 806.5. Excees em Diagramas de Sequncia ..................................................... 836.6. Padro DTO Data Transfer Object ........................................................ 86

Captulo 7 Modelagem Conceitual ........................................................ 897.1. Atributos ....................................................................................................... 92

7.1.1. Tipagem .......................................................................................... 927.1.2. Valores Iniciais ............................................................................... 937.1.3. Atributos Derivados ...................................................................... 947.1.4. Enumeraes .................................................................................. 957.1.5. Tipos Primitivos ............................................................................ 96

7.2. Conceitos ...................................................................................................... 977.2.1. Identifi cadores ................................................................................ 977.2.2. Classe Controladora de Sistema .................................................. 987.2.3. Conceitos Dependentes e Independentes .................................. 98

7.3. Como Encontrar Conceitos e Atributos .................................................. 997.4. Associaes ................................................................................................102

7.4.1. Como Encontrar Associaes ....................................................1057.4.2. Multiplicidade de Papis .............................................................1067.4.3. Direo das Associaes .............................................................1077.4.4. Associao Derivada ...................................................................1087.4.5. Colees ........................................................................................110

7.4.5.1. Conjuntos ....................................................................1117.4.5.2. Conjunto Ordenado ..................................................1117.4.5.3. Multiconjunto .............................................................1117.4.5.4. Lista ..............................................................................1127.4.5.5. Mapeamento ...............................................................1137.4.5.6. Partio ........................................................................1137.4.5.7. Relao ........................................................................114

7.4.6. Agregao e Composio ...........................................................1157.4.7. Associaes n-rias .....................................................................116

7.5. Organizao do Modelo Conceitual .......................................................1187.5.1. Generalizao, Especializao e Herana .................................1197.5.2. Classes de Associao .................................................................1227.5.3. Classes Modais .............................................................................124

7.5.3.1. Transio Estvel ........................................................1257.5.3.2. Transio Monotnica ...............................................1267.5.3.3. Transio No Monotnica ......................................129

7.6. Padres de Anlise ....................................................................................1317.6.1. Coeso Alta ..................................................................................1327.6.2. Classes de Especifi cao .............................................................1347.6.3. Quantidade ...................................................................................1357.6.4. Medida ..........................................................................................1367.6.5. Estratgia ......................................................................................137

7.6.6. Hierarquia Organizacional .........................................................1397.6.7. Juno de Objetos ........................................................................140

7.6.7.1. Copiar e Substituir .....................................................1417.6.7.2. Sucessor .......................................................................1417.6.7.3. Essncia/Aparncia ....................................................1427.6.7.4. Desfazendo a Juno ..................................................143

7.6.8. Conta/Transao ..........................................................................1447.6.9. Associao Histrica ...................................................................1467.6.10. Intervalo ........................................................................................148

7.7. Invariantes ..................................................................................................1497.8. Discusso ....................................................................................................151

Captulo 8 Contratos .............................................................................1538.1. Precondies ..............................................................................................155

8.1.1. Garantia de Parmetros ..............................................................1578.1.2. Restrio Complementar ............................................................1578.1.3. Garantia das Precondies .........................................................1588.1.4. Precondio versus Invariante ...................................................158

8.2. Associaes Temporrias .........................................................................1598.3. Retorno de Consulta .................................................................................1608.4. Ps-condies ............................................................................................162

8.4.1. Modificao de Valor de Atributo .............................................1648.4.2. Criao de Instncia ....................................................................1658.4.3. Criao de Associao ................................................................1668.4.4. Destruio de Instncia ..............................................................1688.4.5. Destruio de Associao ...........................................................1698.4.6. Ps-condies bem Formadas ...................................................1698.4.7. Combinaes de Ps-condies ................................................1708.4.8. Ps-condies sobre Colees de Objetos ...............................171

8.5. Excees .....................................................................................................1718.6. Contratos Padro CRUD .........................................................................173

8.6.1. Operaes de Criao (Create) ..................................................1748.6.2. Operaes de Alterao (Update) .............................................1748.6.3. Operaes de Excluso (Delete) ................................................1758.6.4. Consultas (Retrieve) ....................................................................178

8.7. Contrato Padro Listagem .......................................................................1788.8. Contratos Relacionados com Casos de Uso ..........................................179

8.8.1. Contratos para Estratgia Stateless ............................................1808.8.2. Contratos para a Estratgia Statefull .........................................186

Captulo 9 Projeto da Camada de Domnio .........................................1939.1. Responsabilidades e Operaes Bsicas .................................................1979.2. Visibilidade ................................................................................................199

9.2.1. Visibilidade por Associao .......................................................2009.2.1.1. Visibilidade para Um .................................................2009.2.1.2. Visibilidade para Muitos ...........................................2019.2.1.3. Associaes Ordenadas .............................................2019.2.1.4. Associaes Qualifi cadas ..........................................2029.2.1.5. Classes de Associao ................................................2049.2.1.6. Infl uncia das Precondies na Visibilidade

por Associao ...........................................................2059.2.2. Visibilidade por Parmetro ........................................................2069.2.3. Visibilidade Localmente Declarada...........................................2079.2.4. Visibilidade Global ......................................................................208

9.3. Realizao Dinmica das Ps-condies ...............................................2099.3.1. Criao de Instncia ....................................................................2099.3.2. Criao de Associao ................................................................2129.3.3. Modifi cao de Valor de Atributo .............................................2149.3.4. Destruio de Instncia ..............................................................2169.3.5. Destruio de Associao ...........................................................2179.3.6. Ps-condies Condicionais ......................................................2189.3.7. Ps-condies sobre Colees ...................................................220

9.4. Consultas de Sistema ................................................................................2219.4.1. Padres de Consulta com Filtro ................................................223

9.5. Delegao e Acoplamento Baixo .............................................................2269.6. Diagrama de Classes de Projeto ..............................................................231

Captulo 10 Projeto da Camada de Interface (Web) .............................23510.1. WebML .......................................................................................................23610.2. Unidades.....................................................................................................237

10.2.1. Data Units .....................................................................................23710.2.2. Multidata Units ............................................................................24010.2.3. Index Units ...................................................................................242

10.2.3.1. Multi-Choice Index Unit ...........................................24310.2.3.2. Hierarchical Index Unit ............................................24310.2.3.3. Hierarchical Index Unit Recursiva ..........................245

10.2.4. Scroller Units ................................................................................24610.2.5. Entry Units ...................................................................................247

10.3. Pginas ........................................................................................................24910.3.1. Links ..............................................................................................251

10.3.1.1. Link de Transporte .....................................................25410.3.1.2. Link Automtico ........................................................255

10.4. Organizao de Hipertexto ......................................................................25610.4.1. Vises de Site ................................................................................25610.4.2. reas ..............................................................................................25710.4.3. Tipos de Pginas ..........................................................................257

10.5. Padres de Interface Web .........................................................................25810.5.1. ndice em Cascata ........................................................................25810.5.2. ndice Filtrado ..............................................................................25910.5.3. Tour Guiado .................................................................................26010.5.4. Pontos de Vista .............................................................................261

10.6. Modelagem de Operaes na Interface ..................................................26110.7. Construo de Modelos WebML a Partir de Diagramas

de Sequncia de Sistema ...........................................................................265

Captulo 11 Persistncia ........................................................................26911.1. Equivalncia entre Projeto Orientado a Objetos e

Modelo Relacional ....................................................................................27011.1.1. Classes e Atributos.......................................................................27011.1.2. Associaes de Muitos para Muitos ..........................................27111.1.3. Associaes de Um para Muitos ................................................27211.1.4. Associaes de Um para Um .....................................................27311.1.5. Associaes Ordenadas ..............................................................27411.1.6. Associaes Representando Multiconjuntos ...........................27511.1.7. Associaes Qualificadas ............................................................27611.1.8. Classes de Associao .................................................................27811.1.9. Associaes Temporrias e Associaes da Controladora .....27911.1.10. Herana .........................................................................................280

11.2. Proxy Virtual..............................................................................................28211.2.1. Estruturas de Dados Virtuais .....................................................284

11.3. Materializao ...........................................................................................28511.4. Caches .........................................................................................................28611.5. Commit e Rollback ...................................................................................28811.6. Controle das Caches em um Servidor Multiusurio ............................288

Captulo 12 Gerao de Cdigo e Testes ...............................................29112.1. Classes e Atributos ....................................................................................29112.2. Associaes Unidirecionais .....................................................................292

12.2.1. Associao Unidirecional para Um ...........................................29312.2.2. Associao Unidirecional para Muitos .....................................295

12.2.3. Associao Unidirecional Qualificada ......................................29612.2.4. Associao Unidirecional com Classe de Associao .............298

12.3. Associao Bidirecional ...........................................................................29912.3.1. Implementao nas Duas Direes ...........................................30012.3.2. Implementao Unidirecional ...................................................30112.3.3. Implementao de um Objeto Associao ...............................303

12.4. Mtodos Delegados e Operaes de Sistema ........................................30412.5. Testes ...........................................................................................................307

12.5.1. Teste de Unidade ..........................................................................30812.5.2. Teste de Integrao ......................................................................30912.5.3. Teste de Sistema ...........................................................................30912.5.4. Testes de Aceitao, Operao e Regresso ..............................310

Apndice: Sumrio OCL ..........................................................................313

Bibliografia ...............................................................................................319

ndice Remissivo ......................................................................................323

1Captulo

1

Introduo

O principal objetivo deste livro apresentar um conjunto de informa-es prticas que possibilite aos desenvolvedores de software a compreenso e utilizao da orientao a objetos de forma consciente e eficaz.

A justificativa deste trabalho parte da observao de que h uma vasta literatura que visa apenas a apresentar os diagramas da UML (OMG, 2009) de forma sinttica (por exemplo, Erickson & Penker, 1998), mas poucos li-vros que ofeream informaes suficientes para viabilizar a aplicao eficaz da orientao a objetos no desenvolvimento de software no mundo real.

Neste livro, so feitos uma interpretao e um detalhamento de par-tes do mtodo de anlise e projeto apresentado por Larman (2002), o qual basea do no Processo Unificado ou UP (Jacobson, Booch & Rumbaugh, 1999; Scott, 2001).

A motivao para o uso do mtodo de Larman como base para este trabalho deve-se ao fato de que Larman apresenta uma abordagem concisa e eficiente para anlise e projeto de sistemas orientados a objetos. Nessa aborda-gem, cada artefato (documento ou diagrama) tem uma razo muito clara para existir, e as conexes entre os diferentes artefatos so muito precisas.

Pode-se at dizer que o mtodo seria inspirado em Extreme Program-ming ou XP (Beck, 2004) no qual, em vez de usar uma linguagem de progra-

Anlise e Projeto de Sistemas de Informao Orientados a Objetos ELSEVIER2

mao (como Java ou PHP), utilizam-se diagramas e outros artefatos. Dentro dessa proposta, diagramas e artefatos s fazem sentido se contribuem direta-mente para a gerao automtica de cdigo. No so usados, portanto, como mera documentao, mas como programao em nvel muito alto.

Em relao ao processo descrito por Larman, este livro aprofunda e apresenta conceitos originais em vrios tpicos, como, por exemplo, o uso de Object Constraint Language ou OCL (OMG, 2006) para construo de con-tratos de operao de sistema, a discusso sobre quais passos so realmente obrigatrios em casos de uso expandidos, a noo de contratos de consultas de sistema, a interconexo entre os contratos e os diagramas de comunicao ou sequncia e o projeto da camada de interface com o uso de WebML (Ceri et al., 2003).

Desde o incio, o uso dessas prticas vai levando sistematicamente produo de software de boa qualidade, isto , bem organizado, baseado em uma arquitetura multicamadas e com possibilidade de incluir novos requisi-tos e modificar os requisitos existentes.

1.1. Desenvolvimento de Sistemas Orientados a Objetos

Em primeiro lugar, deve-se discutir o que realmente desenvolver sis-temas orientados a objetos. Ao observar a forma como a anlise e o projeto de sistemas vm sendo ensinados e praticados em certos lugares, pode-se verifi-car que muitos profissionais simplesmente adotam uma linguagem orientada a objetos ou at algum fragmento de processo orientado a objetos, mas sem ter realmente muita noo do que esto fazendo.

O problema de fazer os profissionais migrarem de paradigmas mais an-tigos para orientao a objetos apresenta situaes caricatas. Em determinada ocasio, durante uma palestra, algum comentou que programava h muitos anos usando a linguagem C e que havia resolvido comear a trabalhar com C++, mas que aps alguns meses no notou absolutamente nenhuma vanta-gem nessa migrao. Essa pessoa realmente no viu diferena entre as lingua-gens porque faltou a ela saber o que havia por trs da nova abordagem, e que a linguagem C++ mais interessante do que a linguagem C no porque tem mais recursos ou eficincia, mas porque traz consigo uma maneira muito mais sensata de se pensar e organizar sistemas.

Captulo 1 | Introduo 3

O seguinte ditado tem relao com essa situao: Comprar um martelo no transforma voc em um arquiteto; pode ser necessrio, mas no suficiente.

Tambm no suficiente organizar o sistema em classes e hierarquias se o cdigo implementado nos mtodos desorganizado. Alguns programa-dores organizam o sistema adequadamente em classes e pacotes, mas fazem o cdigo dos mtodos to desorganizado como uma macarronada. Outros ainda aplicam tcnicas de decomposio top-down que no so apropriadas quando se trata de desenvolvimento orientado a objetos (para isso existe a programao estruturada).

Para a correta construo de cdigo orientado a objetos deve-se conhe-cer as tcnicas de delegao e distribuio de responsabilidades, que levam a cdigo reusvel e baixo acoplamento, de acordo com padres de projeto. Essas tcnicas so explicadas ao longo deste livro.

De nada adianta realizar pesados investimentos em ferramentas CASE orientadas a objetos sem que se compreenda a forma de pensar orientada a objetos.

O uso de diagramas no vai melhorar necessariamente a qualidade do software produzido.

Para que um profissional possa chegar a ser um arquiteto de software, existe uma srie de conhecimentos que precisam ser compreendidos, e espe-ra-se que este livro possa dar uma boa contribuio para que esses tpicos sejam abordados com profundidade em todas as fases do processo de desen-volvimento de software.

1.2. Linguagem de Modelagem Unificada UML

Algumas pessoas menos informadas acreditam que a UML uma meto-dologia, talvez por causa do M na sigla. Mas no . A letra mais importante nessa sigla o L, de linguagem. UML quer dizer Unified Modeling Language (Linguagem de Modelagem Unificada) e , portanto, uma linguagem que pode ser usada para descrever coisas.

Porm, conhecer uma linguagem no implica a habilidade de saber us-la para produzir artefatos teis. Por exemplo, a lngua portuguesa uma linguagem, mas uma pessoa que sabe escrever em portugus no sabe neces-sariamente fazer bons discursos ou boa poesia. Existem, por trs da lingua-gem, tcnicas e conhecimento de melhores prticas, que auxiliam os grandes


oradores e poetas a colocar os elementos da linguagem na ordem e estrutura adequadas para produzir um efeito esperado.

A UML foi sendo gradativamente definida a partir de 1994 quando Ja-mes Rumbaugh e Grady Booch criaram a empresa Rational e unificaram suas j conhecidas linguagens de diagramas. Um ano depois, Ivar Jacobson entrou na parceria e adicionou seus casos de uso e outras notaes ao sistema de dia-gramas que vinha sendo definido.

A UML vem sendo constantemente revisada e, correntemente, tem trs famlias de diagramas:

a) Diagramas estruturais, compreendendo os diagramas de pacotes, clas-ses, objetos, estrutura composta, componentes e distribuio.

b) Diagramas comportamentais, compreendendo os diagramas de casos de uso, atividades e mquina de estados.

c) Diagramas de interao, compreendendo os diagramas de comunicao, sequncia, tempo e viso geral de integrao.Nem todos os diagramas precisam ser usados durante o desenvolvimen-

to de um sistema. Usam-se apenas aqueles que possam apresentar alguma in-formao til para o processo. Neste livro enfatizado o uso dos diagramas de atividades, estados, caso de uso, sequncia, classes e comunicao, para mode-lar sistemas de informao. Em alguns momentos, porm, outros diagramas podero ser necessrios, conforme as caractersticas do sistema. Para mais informaes sobre os diferentes diagramas da UML em portugus, pode-se consultar o livro de Pereira e Silva (2007).

1.3. Processo Unificado UP

As tcnicas apresentadas neste livro so adequadas para uso com o pro-cesso unificado que, da forma como foi proposto, est fortemente associado, embora no exclusivamente, com a notao UML.

O UP tambm foi proposto pelos trs gurus da orientao a objetos: Grady Booch, James Rumbaugh e Ivar Jacobson (Jacobson, Booch & Rumbau-gh, 1999), sendo o resultado de mais de trinta anos de experincia acumulada.

O processo se fundamenta em trs valores:a) dirigido por casos de uso: o planejamento do desenvolvimento feito

em funo dos casos de uso identificados, tratando-se prioritariamente os mais complexos;


b) centrado na arquitetura: o processo de desenvolvimento prioriza a construo de uma arquitetura de sistema que permita a realizao dos requisitos. Essa arquitetura baseia-se na identificao de uma estrutura de classes, produzida a partir de um modelo conceitual;

c) iterativo e incremental: a cada ciclo de trabalho realizado, novas ca-ractersticas so adicionadas arquitetura do sistema, deixando-a mais completa e mais prxima do sistema final.O UP comporta, em suas disciplinas as atividades de estudo de viabili-

dade, anlise de requisitos, anlise de domnio, projeto etc. Porm, essas ati-vidades aparecem no UP associadas, com maior ou menor nfase, s quatro grandes fases do UP, que so: concepo, elaborao, construo e transio.

A fase de concepo incorpora o estudo de viabilidade, o levantamento dos requisitos e uma parte da sua anlise. A fase de elaborao incorpora o detalhamento da anlise de requisitos, a modelagem de domnio e o projeto. A fase de construo corresponde programao e testes, e a fase de transio consiste na instalao do sistema e migrao de dados.

A fase de concepo, denominada inception em ingls, a primeira fase do processo unificado, na qual se procura levantar os principais requi-sitos e compreender o sistema de forma abrangente. Os resultados dessa fase usualmente so um documento de requisitos e riscos, uma listagem de casos de uso de alto nvel e um cronograma de desenvolvimento baseado nesses casos de uso.

As fases de elaborao e construo ocorrem em ciclos iterativos. A ela-borao incorpora a maior parte da anlise e projeto, e a construo incorpora a maior parte da implementao e testes. durante os ciclos iterativos pro-priamente ditos que acontece a anlise detalhada do sistema, a modelagem de domnio e o projeto do sistema usando os padres de projeto.

Na fase de transio, o sistema, depois de pronto, ser implantado subs-tituindo o sistema atual, seja ele manual ou computadorizado.

Apesar de ser um processo prescritivo, o UP pode tambm ser realizado como um processo gil, com poucos artefatos e burocracia, permitindo o de-senvolvimento de software de forma eficiente, uma vez que o que interessa ao cliente o software pronto e no uma pilha de documentos justificando por que no ficou pronto.

Para que isso seja obtido, a documentao deve ser dirigida produo do software. Cada atividade realizada pelo desenvolvedor deve ter um obje-


tivo muito claro e uma utilizao precisa visando sempre produo de um cdigo que atenda aos requisitos da melhor forma possvel no menor tempo.

1.4. As Atividades de Anlise e Projeto no Contexto do Processo Unificado

As diferentes atividades de anlise e projeto no ocorrem de forma es-tanque em cada uma das fases do processo unificado, mas podem ocorrer com maior ou menor nfase nas diferentes fases. A Figura 1.1 a representao clssica da distribuio das atividades de desenvolvimento de sistemas e sua nfase nas diferentes fases da implementao mais conhecida do UP, denomi-nada RUP, ou Rational Unified Process (Kruchten, 2003).

Figura 1.1: As diferentes nfases das atividades de desenvolvimento ao longo das quatro fases do Processo Unificado (fonte: IBM).

Este livro vai abordar com maior nfase as atividades tpicas de anlise e projeto. Para uma viso maior sobre gerenciamento de projeto e processo deve-se consultar um livro de engenharia de software, como, por exemplo, o de Pressman (2010). J as atividades de programao so orientadas de acordo com a linguagem escolhida.

Ento, com o foco nas atividades de anlise e projeto, a fase de concep-o vai exigir do analista uma viso inicial e geral do sistema a ser desenvol-vido (Captulo 2). Essa viso pode ser obtida a partir de entrevistas, docu-mentos e sistemas. Para apoiar a modelagem dessa viso geral pode-se usar


diagramas de mquina de estados ou diagramas de atividades da UML, que correspondem, nessa fase, modelagem de negcios.

A partir dessa compreenso do negcio pode-se analisar mais aprofun-dadamente cada uma das atividades ou estados para obter os requisitos fun-cionais e no funcionais do sistema (Captulo 3).

Ainda na fase de concepo pode-se elaborar com o diagrama de classes um modelo conceitual preliminar (Captulo 7) para compreenso da estrutura da informao a ser gerenciada pelo sistema.

Esse modelo conceitual preliminar e os requisitos j levantados ajuda-ro a compreender quais so os processos de negcio e processos complemen-tares da empresa, obtendo-se assim os casos de uso de alto nvel (Captulo 4). Esses casos de uso devero ser usados como base para planejar o restante do desenvolvimento.

A fase de elaborao inicia com a expanso dos casos de uso de alto n-vel (Captulo 5) e posterior representao de seus fluxos atravs dos diagramas de sequncia de sistema (Captulo 6), quando so descobertas as operaes e consultas de sistema.

Na fase de elaborao, o modelo conceitual poder ser refinado, e mais informaes agregadas a ele a partir das descobertas feitas durante a expanso dos casos de uso.

Ainda nessa fase podero ser feitos os contratos de operao e consulta de sistema (Captulo 8) que definem a funcionalidade, ou seja, os resultados de cada operao e consulta realizadas.

Posteriormente, com os contratos e modelo conceitual mo, podem ser criados os diagramas de comunicao ou sequncia (Captulo 9), que, seguindo critrios de delegao e distribuio de responsabilidades, vo mostrar quais mtodos devem ser criados em cada classe e como esses mtodos devem ser implementados, produzindo assim o diagrama de classes de projeto, ou DCP.

Ainda na fase de elaborao, pode-se passar ao projeto da interface (Ca-ptulo 10). Como grande parte dos sistemas de informao so desenvolvidos para Web ou interfaces compatveis com modelos Web, este livro apresenta o WebML (Ceri et al., 2003) como opo para a modelagem para esse aspecto do sistema.

A fase de construo inclui a gerao de bancos de dados (Captulo 11) e a gerao de cdigo e testes (Captulo 12). A persistncia dos dados usual-


mente no precisa ser modelada, pois pode ser gerada automaticamente. As-sim mesmo, o livro mostra como ela ocorre quando se usa um framework orientado a objetos para persistncia. Tambm a gerao de cdigo apre-sentada como um conjunto de regras que podem ser automatizadas. As ati-vidades de teste de software so adaptadas neste livro para as caractersticas peculiares da orientao a objetos.

9Captulo

2

Viso Geral do Sistema

A fase de concepo do UP consiste em uma etapa em que o analista vai buscar as primeiras informaes sobre o sistema a ser desenvolvido. Nessa eta-pa, assume-se que o analista possui pouco conhecimento sobre o sistema e que a interao com o usurio e cliente ser grande. O objetivo dessa fase descobrir se vale a pena fazer a anlise, mas sem fazer a anlise propriamente dita.

Os artefatos dessa fase no precisam ser ainda perfeitamente estrutura-dos, ou seja, eles no so necessariamente completos e organizados. A cada reunio realizada com o usurio ou cliente, um registro (uma ata simplificada) deve ser produzido, o qual possivelmente apresentar vrias ideias sobre o sistema sem ter necessariamente uma organizao sistemtica.

O levantamento da viso geral do sistema deve durar poucos dias. Nesse perodo, deve-se levantar todas as informaes possveis sobre o negcio da empresa, a partir de entrevistas com os usurios e clientes, bem como atravs de exame de documentos, relatrios, sistemas e bibliografia.

A fase de concepo inclui o primeiro contato do analista com o cliente, no qual o analista vai descobrir o que o cliente quer. Essa fase tem de ser rpi-da e deve produzir um relatrio sucinto do sistema a ser desenvolvido.

A maioria dos projetos exige que o analista responda primeiro qual a viso da empresa para o projeto, ou seja, o que a empresa quer com o projeto, por que ele est sendo proposto e por que a empresa vai gastar dinheiro com ele.


Essas so as questes que devem ser trabalhadas no primeiro momento. Nessa fase, tambm surge outra questo que os analistas frequentemente es-quecem: comprar ou construir? Muitas vezes, o produto que o cliente quer j est pronto, podendo-se comprar um pacote e adapt-lo para as necessidades da empresa, em vez de construir a partir do zero.

Essas questes devem ser respondidas em um tempo relativamente cur-to. Por isso, sugere-se que a fase de concepo no dure muito tempo. Por que motivo? Porque, nessa fase, normalmente, o analista e o cliente ainda no tm um contrato fechado; ela , do ponto de vista do analista, um investimento no futuro.

A viso geral do sistema, ou sumrio executivo, um documento em formato livre, no qual o analista deve escrever o que ele conseguiu desco-brir de relevante sobre o sistema aps as conversas iniciais com os clientes e usurios.

Aqui no so propostas regras sobre como deve ser escrito esse documen-to. Mas sugere-se que ele no seja longo demais. Uma ou duas pginas de texto e alguns diagramas parece ser suficiente para descrever, de forma resumida, a maioria dos sistemas. Com mais do que isso, possivelmente estaro sendo inclu-dos detalhes que no so relevantes nesse resumo e que deveriam ser tratados em outros documentos, como anlise de riscos, requisitos ou casos de uso.

Na Figura 2.1 apresentada a viso geral de um sistema de livraria vir-tual fictcio, que ser usado como exemplo para as tcnicas de modelagem ao longo do livro.

Sistema Livir: Livraria VirtualViso Geral do SistemaO sistema deve gerenciar todos os processos de uma livraria virtual, desde a aquisio at a venda dos livros. O acesso dos compradores e gerentes deve ser feito atravs de um site Web e possivelmente com outras tecnologias. Os compradores fazem as transaes pagando com carto de crdito. Existem promoes eventuais pelas quais os livros podem ser comprados com desconto. De incio, a livraria vai trabalhar apenas com livros novos a serem adquiridos de editoras que tenham sistema automatizado de aquisio. O sistema a ser de-senvolvido deve conectar-se aos sistemas das editoras para efetuar as compras.

Captulo 2 | Viso Geral do Sistema 11

O sistema deve calcular o custo de entrega baseado no peso dos livros e na distncia do ponto de entrega. Eventualmente pode haver promoes do tipo entrega gratuita para determinadas localidades. O sistema deve permitir a um gerente emitir relatrios de livros mais ven-didos e de compradores mais assduos, bem como sugerir compras para compradores baseadas em seus interesses anteriores. Quando um livro pedido, se existe em estoque, entregue imediatamente, seno o livro solicitado ao fornecedor, e um prazo compatvel informado ao comprador.

Figura 2.1: Sumrio executivo do sistema Livir.

Para permitir a apresentao do sistema no curto espao disponvel nes-te livro, vrias simplificaes foram consideradas. A descrio e a modelagem de um sistema real poderiam ser bem mais extensas.

Observa-se que a viso geral do sistema apenas uma descrio deses-truturada. Existem aqui informaes de nvel gerencial e de nvel operacional. Muitas vezes, at detalhes sobre tecnologias a serem empregadas tambm so descritos.

O que o analista deve ter em mente que esse documento descreve as principais preocupaes do cliente, as quais sero mais bem estruturadas nas fases posteriores do processo de anlise.

2.1. Modelagem de Negcio com Diagrama de Atividades

Para melhor compreenso do funcionamento da empresa, pode-se criar um ou mais modelos das atividades de negcio. Para tal, pode ser usa-do o diagrama de atividades da UML. Os diagramas de atividades podem ser usados para representar processos em nvel organizacional, ou seja, de forma muito mais ampla do que a mera viso de requisitos de um sistema informatizado.

O diagrama pode ser dividido em raias (swimlanes), de forma que cada raia represente um ator ou sistema que participa de um conjunto de ativi-dades. O ator pode ser um ser humano, um departamento ou mesmo uma organizao completa.


O processo, esquematizado no diagrama da Figura 2.2 deve ter uma pseudoatividade inicial representada por um crculo preto e uma pseudoativi-dade final representada por um crculo preto dentro de outro crculo.

Figura 2.2: Primeira verso de um diagrama de atividades para modelar o processo de venda de livros.

As atividades so representadas por figuras oblongas. Quando uma ativi-dade representada dentro de uma determinada raia, isso significa que o ator ou sistema correspondente quela raia o responsvel pela sua execuo.

Fluxos ou dependncias entre atividades so representados por setas. Os fluxos normalmente ligam duas atividades indicando precedncia entre elas.

Um caminho uma sequncia de atividades ligadas por fluxos.O diagrama de atividades pode ser ento usado como ferramenta de vi-

sualizao do negcio da livraria virtual. A modelagem apresentada na Figura 2.2 mostra uma primeira aproximao do processo de venda de livros. Trs entidades participam do processo: a livraria virtual, o comprador (um ator humano) e a empresa de carto de crdito.

Esse diagrama no tem a inteno de ser um modelo do sistema a ser construdo e no deve ser pensado dessa forma. Sua funo ajudar o ana-lista a entender quais so as atividades e os atores envolvidos nos principais processos de negcio da empresa, para que, a partir dessas informaes, ele possa efetuar uma captura de requisitos mais eficaz. Assim, cada uma das ati-vidades descritas no diagrama deve estar corretamente encadeada para que o caminho lgico delas seja efetivamente executado. Posteriormente, o analista vai examinar em detalhe como cada uma das atividades deve ser realizada. Se a atividade em questo envolver o sistema a ser desenvolvido, ento um levantamento de requisitos mais detalhado deve ser feito referente atividade.


Duas estruturas de controle de fluxo so usuais nesse diagrama:a) a estrutura de seleo (branch e merge), representada por losangos. Do

n branch saem fluxos com condies de guarda (expresses lgicas en-tre colchetes). Todos os caminhos devem voltar a se encontrar em um n merge. Dois ou mais fluxos podem sair de uma estrutura de seleo, mas importante que as condies de guarda sejam mutuamente exclu-dentes, ou seja, exatamente uma delas pode ser verdadeira de cada vez;

b) a estrutura de paralelismo (fork e join), representada por barras pretas. Caminhos independentes entre os n fork e join podem ser executados em paralelo, ou seja, sem dependncias entre suas atividades. O diagrama da Figura 2.3 ainda um esboo muito rudimentar do real

processo de venda de livros. Apenas para ilustrar uma possvel evoluo desse diagrama, pode-se analisar o que aconteceria se algum dos livros em ques-to no estivesse em estoque. Seria necessrio solicit-lo a uma das editoras e adicion-lo ao pedido quando chegasse.

A Figura 2.3 mostra essa situao indicando que, se nem todos os livros esto disponveis, ento, antes de o pedido ser entregue, alguns livros devem ser solicita-dos s editoras, e apenas aps a chegada desses livros que o pedido atendido.

Figura 2.3: O processo de venda considerando a necessidade de comprar livros que no estejam em estoque.


Logo abaixo da atividade Confirma pagamento, h um n branch repre-sentado pelo losango. Como foi dito, o n branch permite que apenas um dos fluxos de sada seja executado. As condies de guarda colocadas ([nem todos os livros em estoque] e [todos livros em estoque]) so, portanto, mutuamente excludentes. A partir desse ponto, as atividades vo por um ou outro caminho at chegarem ao n merge, que aparece ao lado da atividade Envia livros.

Porm, o analista poderia descobrir que esse modelo ainda no sa-tisfatrio. Por exemplo, na falta de livros em estoque, o pedido poderia ser enviado em dois lotes. Assim, dois caminhos poderiam ocorrer em paralelo: o envio dos livros em estoque e, se necessrio, a encomenda e posterior envio dos demais livros, como ilustrado na Figura 2.4.

Figura 2.4: Processo de venda com envio em dois lotes.

A barra preta superior ( direita), no diagrama da Figura 2.4, representa um n fork, porque ela inicia dois caminhos paralelos, e a barra preta inferior ( esquer-da) representa um n join porque ela novamente sincroniza os caminhos paralelos.

Depois do n join, o processo s pode prosseguir se todos os caminhos que entram nele tiverem sido executados. Em funo dos ns branch e merge no mo-delo, ainda se pode verificar que, se todos os livros estiverem em estoque, apenas


um dos caminhos paralelos ser efetivamente executado (o que tem a ao Envia livros em estoque ), j que o outro finaliza imediatamente no n merge.

Para o diagrama estar sintaticamente correto, deve-se observar que:a) a cada n branch deve corresponder um n merge;b) a cada n fork deve corresponder um n join;c) os ns branch, merge, fork e join devem estar perfeitamente aninhados

(ou seja, um branch no pode terminar com join e um fork no pode terminar com merge nem podem estar entrelaados);

d) s pode existir um n inicial;e) s pode existir um n final;f) cada atividade s pode ter um nico fluxo de entrada e um nico fluxo

de sada (isso no vale para os ns join, fork, merge e branch, que no so atividades). Os ns fork, join, branch e merge podem estar em qualquer uma das

raias, pois seu significado no afetado por elas.

2.2. Modelagem de Aspectos de Negcio com Diagrama de Mquina de Estados

Outro diagrama que pode ser til ao analista para entender o negcio da em-presa o diagrama de mquina de estados. Assim como o diagrama de atividades, esse um diagrama comportamental, mas, em vez de modelar atividades e proces-sos, ele apresenta estados de um sistema, ator ou entidade que se deseja estudar.

Um diagrama de mquina de estados tambm tem um n (ou estado) inicial. Mas, ao contrrio do diagrama de atividades, ele pode ter mais de um estado final. Em outras palavras, ele pode finalizar em diferentes estados, cada um dos quais com um significado diferente.

Outra diferena entre esses diagramas que, no caso do diagrama de atividades, os fluxos representam apenas as condies para a realizao das atividades. Assim, se existe um fluxo de A para B, a atividade B s poder ser executada depois que a atividade A for executada. Mas o diagrama no esta-belece quando essas atividades sero executadas.

J o diagrama de mquina de estados especifica, nos seus fluxos, um evento que provoca a mudana de estado. Ou seja, os fluxos so rotulados com eventos que, se ocorrerem, fazem com que a entidade passe de um estado a outro.

Essas ocorrncias podem ser, porm, restringidas por condies de guarda. Por exemplo, o evento login s pode levar o sistema de um estado ini-


cial a um estado logado se a senha do usurio estiver correta. Graficamente, os eventos so representados nos fluxos por expresses simples e as condies de guarda, por expresses entre colchetes.

Os diagramas de mquina de estado tambm podem representar aes que so executadas durante uma transio de estado. Por exemplo, a transio ativada pelo evento login e guardada pela condio [senha correta] pode ainda ativar a ao /autorizar acesso, a qual uma consequncia da transio (mas no a sua causa nem sua condio). As aes associadas s transies devem ser representadas por expresses iniciadas por uma barra (/).

Para exemplificar, pode-se considerar que o analista interessado em en-tender melhor o ciclo de vida de um livro na livraria virtual resolve estudar os estados pelos quais ele passa. Assim, ele descobre que, inicialmente, um livro disponibilizado no catlogo de um fornecedor. A livraria pode ento encomendar um conjunto de cpias desse livro. Quando a encomenda chega, o livro adicionado ao estoque e disponibilizado para venda. Uma vez vendi-do, o livro baixado do estoque e vai ao departamento de remessa. Depois de enviado, o livro considerado definitivamente vendido. Eventualmente, livros enviados podem retornar, por exemplo, em funo de endereo incorreto ou ausncia de uma pessoa para receber a encomenda. Nesse caso, a livraria en-tra em contato com o comprador e, conforme for, cancela a venda ou reenvia o material. O livro considerado definitivamente entregue apenas quando o correio confirma a entrega. Todas essas mudanas de estado (transies) esto representadas na Figura 2.5.

Figura 2.5: Uma primeira modelagem do ciclo de vida de um livro no sistema Livir como mquina de estados.


Porm, o modelo representado na Figura 2.5 ainda incompleto em relao s possveis transies de estados de um livro. Por exemplo, um livro enviado pode retornar danificado devido ao manuseio e, nesse caso, no pode ser reenviado. Isso pode ser representado pela adio de uma condi-o de guarda transio que vai do estado Devolvido para Enviado, e com a adio de um novo estado final em que o livro descartado, conforme a Figura 2.6.

Figura 2.6: Diagrama de mquina de estados com condies de guarda.

Porm, essas condies de guarda ainda so bastante informais. Para ter condies de guarda efetivamente formais seria necessrio usar uma lingua-gem formal como a OCL (Object Constraint Language), que ser apresentada mais adiante neste livro.

Em algumas situaes, possvel que um evento ocorra em mais de um estado, levando a uma transio para outro estado. No exemplo da Figura 2.6 pode-se imaginar que um livro pode ser danificado no apenas a partir do estado Devolvido, mas tambm a partir dos estados Em estoque e Vendido, pois, estando no depsito da livraria, possvel que venha a ser danificado tambm. Nos trs casos, cabe uma transio para o estado final atravs do evento descarte. possvel representar um conjunto de transies com o mesmo evento de/ou para o mesmo estado utilizando o conceito de superestado.


Na Figura 2.7, qualquer transio de/ou para o superestado No depsito corresponde ao conjunto de transies de cada um de seus trs subestados. No caso de transies para o superestado, necessrio estabelecer entre seus subestados qual seria o inicial. Para isso, basta incluir um pseudoestado inicial dentro do superestado ou fazer as transies diretamente para um dos subes-tados, como na Figura 2.7.

Figura 2.7: Diagrama de mquina de estados com um superestado.

Um objeto pode estar simultaneamente em mais de um estado. Por exemplo, um livro pode estar em oferta ou no desde o momento em que encomendado at o momento em que seja descartado ou que sua entrega ao comprador seja confirmada. Assim, pode-se modelar um livro com dois estados paralelos: o primeiro estabelece se o livro est em oferta ou no, e o segundo estabelece seu status em relao venda. No diagrama da Figura 2.8 os estados paralelos so representados dentro de regies concorrentes de um superestado. As transies para dentro de regies concorrentes devem ocor-rer atravs de um n fork, e as transies para fora das regies concorrentes, atravs de um n join.


Figura 2.8: Diagrama de mquina de estados com subestados paralelos.

As transies divididas por fork e unidas por join devem ser rotuladas apenas na parte em que so de fluxo nico, ou seja, na entrada, no caso de fork, e na sada, no caso de join.

Continuando a modelagem, ainda seria possvel estabelecer que um li-vro no subestado vendido, devolvido ou enviado no pode mudar do subestado preo normal para em oferta ou vice-versa. Isso pode ser modelado adicionan-do-se uma condio de guarda s transies dos subestados preo normal e em oferta: [no est em vendido, devolvido ou enviado].

2.3. Comentrios

importante frisar que o objetivo dessa etapa da anlise obter uma vi-so geral do sistema, e no uma especificao detalhada do seu funcionamen-to. Ento, na maioria dos casos, a preocupao do analista deve se centrar em descobrir informaes sobre o sistema e no, ainda, especificar formalmente o seu funcionamento.


Fica a pergunta: para quais elementos do sistema deve-se fazer diagra-mas de mquina de estados ou de atividades durante essa fase? No reco-mendvel criar diagramas para todo e qualquer elemento do futuro sistema porque essa fase demoraria demais e sua objetividade seria prejudicada, j que h pouco conhecimento sobre o sistema para poder realizar tal modelagem. Nesse ponto, necessrio a modelagem de alguns elementos-chave para que se possa entender melhor seu funcionamento.

Uma pista para identificar esses elementos-chave verificar qual o ob-jeto do negcio. No caso da livraria, so os livros; no caso de um hotel, so as hospedagens; no caso de um sistema de controle de processos, so os prprios processos. Ento, so esses elementos que devem ser modelados para serem mais bem compreendidos nessa fase.

A segunda pergunta seria: devo usar um diagrama de mquina de esta-dos ou um de atividades? A resposta depende da natureza do que vai ser mo-delado. Observa-se que um estado no comporta necessariamente uma ativi-dade. Uma TV, por exemplo, pode estar no estado desligada quando no est fazendo nada. Um diagrama de atividades til quando se trata de pessoas ou sistemas fazendo coisas, como numa linha de produo ou na execuo de um processo. J o diagrama de mquina de estados mais til quando a entidade em questo passa por diferentes estados nos quais no est necessariamente realizando alguma atividade.

Alm disso, o diagrama de mquina de estados usualmente apresenta diferentes estados de uma nica entidade, enquanto o diagrama de atividades apresenta atividades realizadas por um conjunto de pessoas, sistemas ou orga-nizaes representados nas swimlanes.

21

Captulo

3

Requisitos

O levantamento e a anlise de requisitos compem uma parte significa-tiva da fase de concepo dentro do UP. O analista pode e deve utilizar todas as informaes disponveis para identificar as fontes de requisitos (departa-mentos, pessoas, clientes, interfaces, sistemas etc.) e, para cada fonte, identifi-car as funes que o sistema dever disponibilizar.

No caso da existncia de diagramas de atividades ou de estados para en-tidades-chave do sistema, o levantamento de requisitos deve identificar quais as funes necessrias para realizar as atividades previstas ou as mudanas de estado.

A etapa de levantamento de requisitos corresponde a buscar todas as informaes possveis sobre as funes que o sistema deve executar e as restries sobre as quais o sistema deve operar. O produto dessa etapa ser o documento de requisitos, principal componente do anteprojeto de software.

A etapa de anlise de requisitos serve para estruturar e detalhar os re-quisitos de forma que eles possam ser abordados na fase de elaborao para o desenvolvimento de outros elementos como casos de uso, classes e inter-faces.


3.1. Levantamento de Requisitos

O levantamento de requisitos o processo de descobrir quais so as funes que o sistema deve realizar e quais so as restries que existem sobre essas funes. No caso do sistema Livir, por exemplo, o levantamento de re-quisitos vai permitir descobrir que o sistema deve controlar a compra e venda de livros, calcular automaticamente os pagamentos, permitir o registro de da-nos aos livros, gerar relatrios de vendas, verificar a disponibilidade de livros em estoque etc. Essas operaes e muitas outras viro a constituir a funciona-lidade do sistema, e por isso so chamadas tambm de requisitos funcionais.

As restries sobre essas funes tm a ver com a questo: de que forma essas operaes se realizam? Ou, ainda, quando, como, onde, para quem, por quem, por quanto tempo etc. essas operaes se realizam? Essas restries so tambm conhecidas como requisitos no funcionais.

3.1.1. Levantar Requisitos no Projeto!

Um sistema a ser analisado como uma floresta. Para explorar uma floresta desconhecida no possvel, em um primeiro momento, conhecer cada planta e inseto. Apenas no final da implantao do sistema que a equipe poder dizer que adquiriu conhecimento sobre cada uma das suas diminutas partes. Porm, no primeiro momento do processo de anlise, no se pode en-trar na floresta para estudar planta por planta porque assim no se ir adquirir uma viso do todo. H um ditado que diz que os detalhistas no conseguem enxergar a floresta devido ao excesso de rvores.

Ento, a fase de concepo deve fornecer a viso do todo, para que se possa ver o que mais importante, e depois dividir o todo em partes nas quais os detalhes possam ser analisados e finalmente uma soluo possa ser proje-tada. A organizao de ciclos iterativos nas fases de elaborao e construo corresponde a subdividir a floresta em setores para olhar um setor de cada vez e, dessa forma, poder trabalhar com a complexidade inerente. Ento, um dos objetivos finais da fase de concepo justamente organizar a diviso do trabalho em casos de uso, que sero associados aos diferentes ciclos iterativos.

Na fase de concepo, o levantamento de requisitos rpido e genrico. Ele feito em extenso e no em profundidade. O analista deve entender a extenso do que o sistema deve fazer, mas sem detalhar como ele vai fazer. Somente na fase de elaborao, a anlise dos requisitos ser aprofundada.

Captulo 3 | Requisitos 23

A etapa de levantamento de requisitos deve ser de descoberta e no de inveno. Nela, a equipe de analistas, juntamente com o cliente e usurios, vai procurar listar o maior nmero possvel de capacidades e restries, mas sem se preocupar demasiadamente em ter uma lista completa por enquanto, o que normalmente impossvel. Os requisitos no descobertos nessa etapa devero ser convenientemente acomodados ao longo do resto do processo de desenvolvimento.

Deve ficar claro para o analista que requisitos so coisas que o cliente ou usurio solicita, e no coisas que ele, como analista, planeja. Alguns analistas confundem o registro dos requisitos, que so a memria das solicitaes do cliente, com o incio do projeto do sistema. Um exemplo desse tipo de confu-so consiste em colocar projetos de tabelas do banco de dados no documento de requisitos. Como justificar que um determinado projeto de tabelas relacio-nais seja uma solicitao do cliente? Isso eventualmente pode ser possvel com clientes mais sofisticados ou que tenham sistemas legados, mas no a regra geral. As tabelas de banco de dados so parte do domnio da soluo (projeto), e no da anlise. O analista deve buscar os requisitos que correspondem s informaes que o cliente precisa que sejam gerenciadas. Depois, ele pode decidir se armazena essa informao em um banco de dados ou em alguma outra estrutura.

3.1.2. Desafios dos Requisitos

O documento ou diagrama de requisitos deve registrar as capacidades do sistema e as condies s quais ele deve se conformar. Os desafios ligados a essas informaes so os seguintes:

a) como descobrir os requisitos;b) como comunicar os requisitos para as outras fases ou equipes do projeto;c) como lembrar dos requisitos durante o desenvolvimento e verificar se

foram todos atendidos; d) como gerenciar a mudana dos requisitos.

No adiantaria escrever um belo documento de requisitos e depois no saber se os requisitos foram ou no atendidos pelo projeto. importante que se tenham mecanismos para fazer sistematicamente essa verificao. Por isso, importante manter relaes de rastreabilidade entre os requisitos e outras partes do projeto do software.


Deve-se ter em mente tambm que os requisitos inevitavelmente mu-dam durante o desenvolvimento do projeto. Deve-se esperar, ento, poder ge-renciar a mudana dos requisitos nas demais fases de desenvolvimento.

Outras vezes, os requisitos mudam depois do desenvolvimento. Podem mudar as condies de contexto ou a forma de trabalho ou as polticas da em-presa. Embora essas mudanas no possam ser previstas pelo analista, podem ser criados mecanismos que as acomodem ao sistema quando surgirem. Exis-tem padres de projeto especficos para tratar essas instabilidades do sistema (como, por exemplo, o padro Estratgia).

Essas mudanas so totalmente imprevisveis. Se o sistema no estiver estruturado para acomodar mudanas nos requisitos, haver excesso de tra-balho para implement-las.

Esse tipo de situao faz com que os processos de anlise e projeto diri-gidos por requisitos (Alford, 1991) sejam inadequados para muitos sistemas. Fundamentar a arquitetura de um sistema em seus requisitos como cons-truir um prdio sobre areia movedia. Quando os requisitos mudam, a estru-tura do sistema muda. O UP, porm, prope que a arquitetura do sistema seja fundamentada em elementos muito mais estveis: as classes (e componentes) que encapsulam informao e comportamento.

Essas classes, mais adiante, vo implementar as funcionalidades que, combi-nadas, permitem a realizao dos requisitos. Mudando-se os requisitos, mudam-se as combinaes, mas no a estrutura bsica. Essa estrutura usualmente segue o princpio aberto-fechado (Meyer, 1988), no sentido de que est sempre pronta para funcionar (fechada), mas aberta para incorporar novas funcionalidades.

3.1.3. Requisitos Funcionais

Os requisitos funcionais devem conter basicamente os seguintes elementos:a) a descrio de uma funo a ser executada pelo sistema (usualmente

entrada, sada ou transformao da informao);b) a origem do requisito (quem solicitou) e/ou quem vai executar a funo

em questo (usurio);c) quais as informaes que so passadas do sistema para o usurio e vice-

versa quando a funo for executada;d) quais restries lgicas (regras de negcio) ou tecnolgicas se aplicam

funo.


Cada requisito funcional deve conter, portanto, uma funo, que pode ser uma entrada (exemplo, cadastrar comprador) ou sada (exemplo, emitir relatrio de vendas no ms).

importante identificar a origem ou usurio do requisito, pois sempre necessrio validar os requisitos com essas fontes, verificando se esto bem escritos, completos e consistentes.

Algumas vezes tambm acontece de pessoas ou departamentos dife-rentes apresentarem o mesmo requisito de forma discrepante. Nesse caso, necessrio realizar um acordo ou identificar quem teria autoridade para de-terminar a forma aceitvel do requisito.

As informaes de entrada e sada so importantssimas para que a an-lise de requisitos ocorra de forma sistemtica. Sem essas informaes, os re-quisitos ficam muito vagos e pouco aprendido sobre o sistema nessa fase. Dizer simplesmente que o sistema deve permitir o cadastro de compradores muito vago como requisito. O analista deve sempre procurar saber quais movimentos de informao essas funes envolvem. Por exemplo, o cadastro do comprador envolve apenas nome, endereo e telefone? No caso do sistema Livir, no. Deve incluir com certeza dados de um ou mais cartes de crdito, pois sero necessrios para efetuar os pagamentos. Essa verificao de infor-maes que entram e saem do sistema que vai permitir ao analista descobrir a maioria dos conceitos e funes, realizando a pesquisa em extenso no es-pao de requisitos para ter uma viso abrangente do todo. No exemplo visto, fica patente, aps o detalhamento das informaes que entram e saem, a ne-cessidade de definir um requisito funcional para cadastrar cartes de crdito adicionais para o comprador.

3.1.4. Requisitos No Funcionais

Os requisitos no funcionais aparecem sempre ligados a requisitos fun-cionais e podem ser basicamente de dois tipos: lgicos ou tecnolgicos.

As restries lgicas so as regras de negcio relacionadas funo em questo. Por exemplo, no registro de uma venda, uma srie de restries l-gicas poderia ser considerada, como por exemplo: no efetuar a venda caso a operadora de carto no autorize o pagamento ou no efetuar a venda caso a venda anterior tenha sido cancelada devido a um endereo invlido que ainda no foi corrigido.


As restries tecnolgicas dizem respeito tecnologia para a realizao da funo, como, por exemplo, a interface (Web, por exemplo), o tipo de pro-tocolo de comunicao, restries de segurana ou tolerncia a falhas etc.

Por exemplo, registrar a venda de um conjunto de livros um requisito funcional. Estabelecer que o tipo de interface para efetuar uma venda deve seguir um padro de interface de fluxo sequencial de telas uma restrio tecnolgica (de interface) sobre a forma como essa funo realizada.

Outro exemplo de requisito no funcional seria a autorizao de dbito no carto de crdito no deve levar mais do que 5 segundos. Isso seria uma restrio tecnolgica de desempenho e afetaria a forma como o projetista iria pensar no mecanismo de acesso ao sistema da operadora de cartes. Nesse caso, o projeto do sistema teria de considerar seriamente o uso de conexes fixas com as operadoras de carto em vez de linhas discadas.

3.1.5. Requisitos Suplementares

Os requisitos suplementares so todo tipo de restrio tecnolgica ou lgica que se aplica ao sistema como um todo e no apenas a funes indivi-duais. Por exemplo, um requisito suplementar pode estabelecer que o sistema deva ser compatvel com um banco de dados legado ou ser implementado em uma determinada linguagem de programao, ou ainda, seguir um determi-nado padro de interface ou look and feel.

Deve-se tomar certo cuidado no enunciado dos requisitos suplemen-tares. Um requisito como o sistema deve ser fcil de usar muito pouco esclarecedor para que possa ser til. Melhor seria dizer: o sistema ter ajuda on-line em todas as telas e para todas as funes. Isso d uma ideia mais pre-cisa sobre o que realmente deve ser realizado pelo sistema.

3.1.6. Documento de Requisitos

O documento de requisitos registra todos os tpicos relativos ao que o sistema deve fazer e sob quais condies. Esse documento ainda no precisa ser totalmente estruturado, e assume-se que no ser completo em profundi-dade, embora se possa esperar que esteja razoavelmente completo em exten-so. Eventuais lacunas desse documento sero preenchidas durante a fase de elaborao.


O documento de requisitos pode ser organizado de forma textual ou na forma de um diagrama (o diagrama de requisitos existente em algumas ferra-mentas CASE, porm, no pertence especificao da UML).

Os requisitos funcionais podem ainda ser subdivididos em subsistemas, especialmente se a quantidade de funes for muito grande. Essa uma pri-meira forma de organizao do sistema.

Sugere-se que o documento de requisitos tenha um ndice consistindo no nome da funo ou requisito suplementar e que o corpo do documento contenha os detalhes mencionados na Seo 3.1.3.

A Figura 3.1 apresenta um exemplo de documento de requisitos para o sistema Livir. Se houvesse subsistemas, eles seriam o primeiro nvel de diviso dentro de Requisitos funcionais, contendo cada diviso um conjunto de re-quisitos numerados.

Sistema Livir Documento de RequisitosRequisitos funcionais

1. Registrar novos ttulos a partir do catlogo das editoras.2. Registrar vendas de livros.3. Realizar encomendas de livros.4. Registrar e autorizar pagamentos com carto de crdito.5. Registrar e aplicar promoes.6. Calcular custos de entrega.7. Emitir relatrio de livros mais vendidos.8. Emitir relatrio de compradores mais assduos.9. Emitir sugestes de compra para compradores baseadas em compras

anteriores.10. ...

Requisitos suplementares1. O sistema deve operar via interface Web.2. Todos os controles de interface devem ter um campo de ajuda asso-

ciado.3. ...

Figura 3.1: O ndice de um documento de requisitos para o sistema Livir.


O detalhamento de cada requisito (especialmente os funcionais) deve aparecer no corpo do documento. Esse detalhamento deve conter as partes mencionadas na Seo 3.1.3. A Figura 3.2 apresenta um exemplo.

1. Registrar novos ttulos a partir do catlogo das editorasDescrio:O gerente seleciona as editoras para as quais pretende fazer a atualizao. O processo automtico. O sistema consulta os ISBN disponibilizados e os compara com os existentes na base. Havendo novos ISBN, o sistema atuali-za a base com as novas informaes.Fontes: Sr. Fulano de Tal (gerente) e manual tcnico da interface de catlogo das editoras.Usurio: O prprio gerente.Informaes de entrada: O gerente informa quais so as editoras para as quais pretende fazer a atua-lizao a partir de uma lista fornecida pelo sistema.Informaes de sada:

A lista de editoras (nome). O relatrio de atualizaes efetuadas (uma lista contendo: nome da

editora, ISBN, ttulo e preo de compra).Restries lgicas: No h.Restries tecnolgicas:

1. Deve ser usado o sistema de interface com as editoras, de acordo com o manual XYZ.1234.

2. A seleo feita pelo gerente se d atravs de uma lista de seleo ml-tipla, a qual deve ser ordenada de forma alfabtica.

3. ...Figura 3.2: Detalhamento de um requisito.

Observa-se que o detalhamento das informaes que entram e saem do sistema fundamental para a compreenso mais detalhada dessa funo. Atravs desse detalhamento que a verdadeira dimenso do sistema vai sendo descoberta.


Sem esse detalhamento, o sistema pode parecer mais simples do que real-mente , o que explica por que, em muitos casos, os analistas esperam desenvol-ver um sistema em determinado tempo mas levam muito mais tempo, estouran-do prazos e oramentos.

3.2. Anlise de Requisitos

Na anlise de requisitos, o analista vai procurar caracterizar certas pro-priedades dos requisitos j levantados, conforme as subsees seguintes.

3.2.1. Permanncia e Transitoriedade

Uma primeira caracterizao considerada importante na anlise de re-quisitos decidir se determinado requisito no funcional ou suplementar permanente ou transitrio.

Requisitos no funcionais podem ser considerados permanentes (no vo mudar) ou transitrios (podem mudar) de acordo com uma deciso to-mada pelo analista em conjunto com o cliente. O requisito no tem a proprie-dade de permanncia ou transitoriedade por si: ela decidida de acordo com a convenincia. Um mesmo requisito pode ser considerado permanente ou transitrio dependendo do que se queira em relao ao tempo de desenvolvi-mento ou custo da manuteno do software.

Por exemplo, um requisito suplementar poderia estabelecer que o siste-ma Livir trabalhe com uma nica moeda: o real. Se esse requisito suplementar for considerado permanente, todo o sistema ser construdo de forma que o real seja a nica moeda. Se o requisito for considerado transitrio, o sistema dever ser construdo de forma a poder acomodar futuramente outras moe-das ou, ainda, mais de uma moeda de cada vez.

As consequncias de decidir que um requisito permanente so as se-guintes:

a) fica mais barato e rpido desenvolver o sistema em si;b) fica mais caro e demorado mudar o sistema caso o requisito, por algum moti-

vo, mude no futuro (com a implantao de uma nova moeda, por exemplo).Por outro lado, decidir que um requisito transitrio tem como conse-

quncias:a) fica mais caro e complexo desenvolver o sistema (ele dever acomodar

funcionalidades para a mudana da moeda);


b) fica mais barato e rpido fazer a manuteno no sistema (caso a moeda mude, o sistema j est preparado para acomodar esse fato com uma simples reconfigurao).Ento, a natureza dos requisitos no funcionais no vai decidir se eles

so permanentes ou transitrios. O analista que tem de tomar essa deciso (com o aval do cliente). O ideal seria elencar aqueles requisitos de maior im-portncia (que se espera que possam mesmo mudar num futuro prximo e cuja mudana tenha maior impacto no sistema) e consider-los transitrios, deixando os demais como permanentes.

3.2.2. Requisitos Evidentes e Ocultos

Os requisitos funcionais podem ser opcionalmente classificados em evi-dentes ou ocultos:

a) os requisitos funcionais evidentes so funes efetuadas com conheci-mento do usurio. Esses requisitos usualmente correspondem a trocas de informao, como consultas e entrada de dados, que ocorrem com o meio exterior atravs da interface do sistema;

b) os requisitos funcionais ocultos so funes efetuadas pelo sistema sem o conhecimento explcito do usurio. Usualmente, so clculos ou atua-lizaes feitas pelo sistema sem a solicitao explcita do usurio, mas como consequncia de outras funes solicitadas por ele. importante classificar os requisitos dessa forma porque, posteriormen-

te, eles sero associados aos casos de uso atravs de relaes de rastreabilidade. Apenas os requisitos evidentes correspondero aos passos do caso de uso ex-pandido porque so executados com o conhecimento explcito do usurio. Os requisitos ocultos so executados internamente pelo sistema. Ento, embora no apaream explicitamente nos passos de um caso de uso expandido, esses precisam ser adequadamente associados a aqueles para ser lembrados no mo-mento de projetar e implementar as operaes do caso de uso.

Um exemplo de requisito evidente emitir um relatrio de livros mais vendidos por requisio do gerente. Um exemplo de requisito oculto seria aplicar uma poltica de desconto, se ela existir. Nesse caso, nenhum usurio solicita explicitamente ao sistema para fazer essa aplicao. uma atividade que o sistema executa independentemente dos usurios e, portanto, de forma oculta.


3.2.3. Requisitos Obrigatrios e Desejados

Os requisitos ainda podem ser classificados em obrigatrios e desejados, ou seja, aqueles que devem ser obtidos de qualquer maneira e aqueles que podem ser obtidos caso isso no cause maiores transtornos no processo de desenvolvimento.

No caso dos requisitos funcionais, essa classificao indica uma priori-zao de desenvolvimento. Um bom analista tomaria as funes como base para calcular o tempo de desenvolvimento. Assim, no faria muito sentido falar em funes obrigatrias e desejveis, mas sim em quanto tempo levaria para desenvolver esse ou aquele conjunto de funes.

Entretanto, nem sempre a coisa funciona assim. No caso de alguns sis-temas pode-se querer trabalhar com prioridades, desenvolvendo inicialmente determinadas funes consideradas obrigatrias e, posteriormente (se sobrar tempo), outras funes consideradas desejadas.

Mas os requisitos no funcionais e suplementares so bem mais imprevis-veis do que os funcionais para efeito de estimativa de esforo. Assim, em alguns casos, pode ser necessrio efetivamente classificar esses requisitos por graus de prioridade.

Definem-se algumas restries que devem ser obtidas a qualquer custo e outras que seria desejvel obter, desde que isso no extrapole o tempo ou recursos disponibilizados para o projeto.

Por exemplo, no caso do sistema Livir, o requisito de que a interface seja Web poderia ser considerado obrigatrio. Nesse caso, no se aceita outra coisa. Porm, o acesso atravs de telefone celular poderia ser um requisito desejvel, j que no absolutamente necessrio para o efetivo funcionamento do sistema.

Com a formalizao dos contratos de desenvolvimento de software, po-rm, cada vez menos flexibilidade se tem em relao a requisitos desejveis. O desenvolvedor deve dizer claramente quais requisitos vai implementar, quan-to tempo vai levar e quanto vai custar. Qualquer desvio dessas previses pode implicar multas ou cancelamento de contratos.

3.2.4. Classificao de Requisitos No Funcionais e Suplementares

Os requisitos no funcionais e suplementares podem ser classificados por atributo, ou seja, se so requisitos de interface, de implementao, de efi-


cincia, de tolerncia a falhas etc. A finalidade principal das classificaes de requisitos em categorias a organizao. Algumas sugestes de possveis ca-tegorias so:

a) usabilidade: quais fatores humanos esto envolvidos no sistema? Que tipo de ajuda o sistema vai prover? Quais as formas de documentao ou manuais estaro disponveis? Como esses manuais vo ser produzi-dos? Que tipo de informao eles vo conter? Seria interessante definir esses tpicos na fase de concepo, visto que o contrato com o cliente deve especificar muitas dessas questes;

b) confiabilidade: que tipo de tratamento de falhas o sistema vai ter? O ana-lista no obrigado a produzir um sistema totalmente tolerante a falhas, mas deve estabelecer que tipo de falhas o sistema ser capaz de geren-ciar: falta de energia, falha de comunicao, falha na mdia de gravao etc. No se deve confundir falha com erro de programao, visto que erros de programao so elementos que nenhum software deveria con-ter. As falhas so situaes anormais que podem ocorrer mesmo para um software implementado sem nenhum erro de programao;

c) desempenho: que tipo de eficincia e preciso o sistema ser capaz de apresentar? Pode-se estabelecer, por exemplo, como requisito de efi-cincia, que nenhuma consulta base de dados de compradores vai de-morar mais de cinco segundos. Na fase de concepo no se define como o sistema far para cumprir o requisito, apenas se diz que de alguma forma ele ter de ser cumprido no projeto. Cabe ao projetista e progra-mador garantir que o requisito seja satisfeito. Se o analista por algum motivo conclui que o requisito dificilmente poder ser implementado, o requisito passa a ser um risco do sistema e eventualmente necessitar de um estudo mais aprofundado ainda na fase de concepo, para verificar a possibilidade de sua realizao;

d) configurabilidade: o que pode ser configurado no sistema? Deve-se de-finir os elementos que podero ser configura

Documents

Análise e Projeto de Sistemas Da Informação 2a Ed