Vous êtes sur la page 1sur 779

Engenharia de Software

Uma Abordagem Prossional


Stima Edio

Roger S. Pressman

P934e

Pressman, Roger S.
Engenharia de software [recurso eletrnico] : uma
abordagem profissional / Roger S. Pressman ; traduo
Ariovaldo Griesi ; reviso tcnica Reginaldo Arakaki, Julio
Arakaki, Renato Manzan de Andrade. 7. ed. Dados
eletrnicos. Porto Alegre : AMGH, 2011.
Editado tambm como livro impresso em 2011.
ISBN 978-85-8055-044-3
1. Engenharia de programas de computador. 2. Gesto de
projetos de softwares. I. Ttulo.
CDU 004.41

Catalogao na publicao: Ana Paula M. Magnus CRB-10/2052

Engenharia de Software
UMA ABORDAGEM PROFISSIONAL

STIMA EDIO

Roger S. Pressman, Ph.D.

Traduo
Ariovaldo Griesi
Mario Moro Fecchio
Reviso Tcnica
Reginaldo Arakaki
Professor Doutor do Departamento de Engenharia de Computao e Sistemas
Digitais da EPUSP
Julio Arakaki
Professor Doutor do Departamento de Computao da PUC-SP
Renato Manzan de Andrade
Doutorando do Departamento de Engenharia de Computao e
Sistemas Digitais da EPUSP

Verso impressa
desta obra: 2011

2011

Obra originalmente publicada sob o ttulo


Software Engineering: a Practitioners Approach, 7th Edition
ISBN 0073375977 / 9780073375977
2011, The McGraw-Hill Companies, Inc., New York, NY, EUA
Preparao do original: Mnica de Aguiar Rocha
Leitura final: Vera Lcia Pereira
Capa: Triall Composio Editorial Ltda, arte sobre capa original
Editora snior: Arysinha Jacques Affonso
Assistente editorial: Csar Crivelaro
Diagramao: Triall Composio Editorial Ltda

Reservados todos os direitos de publicao em lngua portuguesa


AMGH Editora Ltda (AMGH Editora uma parceria entre
Artmed Editora S.A. e McGraw-Hill Education)
Av. Jernimo de Ornelas, 670 - Santana
90040-340 Porto Alegre RS
Fone (51) 3027-7000 Fax (51) 3027-7070
proibida a duplicao ou reproduo deste volume, no todo ou em parte,
sob quaisquer formas ou por quaisquer meios (eletrnico, mecnico, gravao,
fotocpia, distribuio na Web e outros) sem permisso expressa da Editora.
SO PAULO
Av. Embaixador Macedo Soares, 10.735 - Pavilho 5 - Cond. Espace Center
Vila Anastcio 05095-035 So Paulo SP
Fone (11) 3665-1100 Fax (11) 3667-1333
SAC 0800 703-3444
IMPRESSO NO BRASIL
PRINTED IN BRAZIL

O Autor

oger S. Pressman uma autoridade reconhecida internacionalmente nas tecnologias em melhoria de processos de software e engenharia de software. Por mais de
trs dcadas, trabalhou como engenheiro de software, gerente, professor, autor e
consultor, concentrando-se nas questes da engenharia de software. Como profissional
tcnico e gerente nesta rea, trabalhou no desenvolvimento de sistemas CAD/CAM para
avanadas aplicaes de engenharia e manufatura. Tambm ocupou cargos com responsabilidade pela programao cientfica e de sistemas.
Aps receber o ttulo de Ph.D. em engenharia da University of Connecticut, Pressman
comeou a dedicar-se vida acadmica ao se tornar professor-adjunto de Engenharia da
Computao na University of Bridgeport e diretor do Centro de Projeto e Fabricao Apoiados
por Computador (Computer-Aided Design and Manufacturing Center) dessa Universidade.
Atualmente, presidente da R. S. Pressman & Associates, Inc., uma consultoria especializada em treinamento e mtodos em engenharia de software. Atua como consultor-chefe
e projetou e desenvolveu o Essential Software Engineering, um conjunto de vdeos em engenharia de software, e o Process Advisor, um sistema autodirigido para aperfeioamento
de processos de software. Ambos so usados por milhares de empresas em todo o mundo.
Mais recentemente, trabalhou em conjunto com a EdistaLearning, na ndia, desenvolvendo
extenso treinamento em engenharia de software baseado na Internet .
Publicou vrios artigos tcnicos, escreve regularmente para peridicos do setor e autor de sete livros tcnicos. Alm de Engenharia de software: uma abordagem profissional, foi
coautor de Web engineering (McGraw-Hill), um dos primeiros livros a aplicar um conjunto
personalizado de princpios e prticas de engenharia de software para o desenvolvimento
de aplicaes e sistemas baseados na Web. Tambm escreveu o premiado A managers guide
to software engineering (McGraw-Hill); Making software engineering happen (Prentice Hall),
primeiro livro a tratar dos crticos problemas de gerenciamento associados ao aperfeioamento de processos de software, e Software shock (Dorset House), um tratado que se concentra em software e seu impacto sobre os negcios e a sociedade. O dr. Pressman participou dos comits editoriais de uma srie de peridicos do setor e, por muitos anos, foi
editor da coluna Manager no IEEE Software.
ainda um palestrante renomado, destacando-se em uma srie das principais conferncias do setor. associado da IEEE e Tau Beta Pi, Phi Kappa Phi, Eta Kappa Nu e Pi Tau
Sigma.
Vive no sul da Flrida com sua esposa, Barbara. Atleta por grande parte de sua vida,
continua a ser um dedicado jogador de tnis (NTRP 4.5) e jogador de golfe com handicap
de apenas um dgito. Nas horas vagas, escreveu dois romances, The Aymara bridge e The
Puppeteer, e planeja comear um novo romance.

Em memria de meu querido


pai, que viveu 94 anos
e ensinou-me, acima de tudo,
que a honestidade e a integridade
seriam os meus melhores guias na
jornada da vida.

Prefcio

uando um software bem-sucedido atende s necessidades dos usurios,


opera perfeitamente durante um longo perodo, fcil de modificar e, mais fcil ainda, de utilizar , ele realmente capaz de mudar as coisas para melhor.
Porm, quando um software falha quando seus usurios esto insatisfeitos, quando
propenso a erros, quando difcil modific-lo e mais difcil ainda utiliz-lo , fatos desagradveis podem e, de fato, acontecem. Todos queremos construir softwares que facilitem
o trabalho, evitando pontos negativos latentes nas tentativas mal-sucedidas. Para termos
xito, precisamos de disciplina no projeto e na construo do software. Precisamos de uma
abordagem de engenharia.
J faz quase trs dcadas que a primeira edio deste livro foi escrita. Durante esse
perodo, a engenharia de software evoluiu de algo obscuro praticado por um nmero relativamente pequeno de adeptos para uma disciplina de engenharia legtima. Hoje, reconhecida como uma matria digna de pesquisa sria, estudo consciencioso e debates
acalorados. Neste segmento, o cargo preferido passou a ser o de engenheiro de software
e no mais o de programador. Modelos de processos de software, mtodos de engenharia
de software, bem como ferramentas de software, vm sendo adotados com sucesso em um
amplo espectro de aplicaes na indstria.
Apesar de gerentes e profissionais envolvidos com a rea tcnica reconhecerem a necessidade de uma abordagem mais disciplinada em relao ao software, eles continuam a
discutir a maneira como essa disciplina deve ser aplicada. Muitos indivduos e empresas
desenvolvem software de forma desordenada, mesmo ao construrem sistemas dirigidos s
mais avanadas tecnologias. Grande parte de profissionais e estudantes no esto cientes
dos mtodos modernos. E, como consequncia, a qualidade do software que produzem
afetada. Alm disso, a discusso e a controvrsia sobre a real natureza da abordagem de
engenharia de software continuam. A engenharia de software um estudo repleto de contrastes. A postura mudou, progressos foram feitos, porm, falta muito para essa disciplina
atingir a maturidade.
A stima edio do livro Engenharia de software: uma abordagem profissional destina-se a servir de guia para uma disciplina de engenharia em maturao. Assim como nas seis
edies anteriores, esta voltada tanto para estudantes no final do curso de graduao ou
no primeiro ano de ps-graduao e para profissionais da rea.
A stima edio muito mais do que uma simples atualizao. O livro foi revisado
e reestruturado para adquirir maior fluncia em termos pedaggicos e enfatizar novos e
importantes processos e prticas de engenharia de software. Alm disso, um sistema de
suporte revisado e atualizado, ilustrado na figura da pgina seguinte, fornece um conjunto
completo de recursos para estudantes, professores e profissionais complementarem o contedo do livro. Tais recursos so apresentados como parte do site do livro em ingls (www.
mhhe.com/pressman), especificamente projetado para este livro.
A Stima Edio. Os 32 captulos foram reorganizados em cinco partes, que diferem
consideravelmente da sexta edio para melhor compartimentalizar tpicos e auxiliar os
professores que talvez no tenham tempo suficiente para abordar o livro inteiro em um
semestre.

viii

PREFCIO

Figura
Sistema de
suporte para a
7a ed.

Guia de
estudos dos
captulos
Tpicos
adicionais de
Engenharia
de Software

Provas
prticas

Problemas
Recursos resolvidos
para os
estudantes

Manual
do
professor

SEPA
7a ed.

slides em
Powerpoint
Recursos
para os
professores
Conjunto
de testes

Recursos
profissionais

Recursos Web
(mais de mil links)
Biblioteca de referncias
(mais de 500 links)
Listas de controle
Gabaritos de artefatos
Pequenas ferramentas
Modelo de processos adaptveis
Conjunto de tarefas de
atividades universais
Estudo de caso completo

Comentrios
do setor

Aprendizagem
a distncia

A Parte 1, O Processo, apresenta uma srie de vises diferentes de processo de software,


considerando todos os modelos importantes e contemplando o debate entre as filosofias de
processos geis e preceptivos. A Parte 2, Modelagem, fornece mtodos de projeto e anlise com
nfase em tcnicas orientadas a objetos e modelagem UML. O projeto baseado em padres,
bem como o projeto para aplicaes da Web, tambm considerado. A Parte 3, Gesto da Qualidade, apresenta conceitos, procedimentos, tcnicas e mtodos que permitem a uma equipe de
software avaliar a qualidade de software, revisar produtos gerados por engenharia de software,
realizar procedimentos SQA e aplicar uma estratgia e ttica de testes eficazes. Alm disso, so
considerados tambm mtodos de modelagem e verificao formais. A Parte 4, Gerenciamento
de Projetos de Software, aborda tpicos relevantes para os que planejam, gerenciam e controlam
um projeto de desenvolvimento de software. A Parte 5, Tpicos Avanados, considera aperfeioamento de processos de software e tendncias da engenharia de software. Preservando a tradio
de edies anteriores, usa-se uma srie de quadros ao longo do livro para apresentar as atribulaes de uma equipe de desenvolvimento (fictcia), bem como fornecer material suplementar
sobre mtodos e ferramentas relevantes para os tpicos do captulo. Dois novos apndices fornecem tutoriais curtos sobre a filosofia de orientao a objetos e UML para os leitores que no
esto familiarizados com esses itens.
A organizao da edio em cinco partes possibilita ao professor aglutinar tpicos tomando como base o tempo disponvel e a necessidade dos alunos. Por exemplo, cursos de
um semestre podem ser montados baseando-se em uma ou mais das cinco partes; cursos que
ofeream uma viso geral da engenharia de software selecionariam captulos de todas as cinco

PREFCIO

IX

partes; outro, sobre engenharia de software que enfatize anlise e projeto, utilizaria tpicos das
Partes 1 e 2; cursos de engenharia de software voltado para testes enfatizaria tpicos das Partes
1 e 3, com uma breve incurso na Parte 2; j cursos voltados para administradores concentrariam-se nas Partes 1 e 4. Organizada dessa maneira, a stima edio oferece ao professor uma
srie de opes didticas. Esse contedo complementado pelos seguintes elementos.
Recursos para os estudantes. A ampla gama de instrumentos para os estudantes inclui um
completo centro de aprendizagem on-line englobando guias de estudo captulo por captulo,
testes prticos, solues de problemas e uma srie de recursos baseados na Web, incluindo
listas de controle de engenharia de software, um conjunto em constante evoluo de pequenas
ferramentas, um estudo de caso completo, gabaritos de artefatos e muitos outros. H, ainda,
mais de 1.000 Referncias na Web, classificadas por categoria, que permitem ao estudante explorar a engenharia de software de forma mais detalhada, e uma Biblioteca de Referncias com
links de mais de 500 artigos, os quais fornecem uma extensa fonte de informaes avanadas
sobre engenharia de software.
Recursos para os professores. Desenvolveu-se uma ampla gama de recursos para os professores para suplementar a stima edio. Entre eles: um completo Guia do Instrutor on-line (que
tambm pode ser baixado) e materiais didticos, como, por exemplo, um conjunto completo
com mais de 700 slides em PowerPoint que pode ser usado em aulas, alm de uma srie de
testes. Tambm esto disponveis todos os recursos dirigidos aos estudantes (como as pequenas ferramentas, as Referncias na Web, a Biblioteca de Referncias que pode ser baixada) e os
recursos para profissionais.
O Guia do Instrutor apresenta sugestes para a realizao de vrios tipos de cursos de
engenharia de software, recomendaes para uma variedade de projetos de software a ser
realizados com um curso, solues para problemas escolhidos e uma srie de ferramentas
didticas teis.
Recursos para os pr ossionais. No conjunto de recursos disponveis para profissionais da

rea (bem como para estudantes e corpo docente), temos resumos e exemplos de documentos
de engenharia de software e outros artefatos, um til conjunto de listas de controle de engenharia de software, um catlogo de ferramentas de engenharia de software (CASE), uma completa
coleo de recursos baseados na Web e um modelo de processos adaptveis, que compe de
forma detalhada as tarefas do processo de engenharia de software.
Quando associada ao seu sistema de suporte on-line, esta edio gera flexibilidade e profundidade do contedo que no poderiam ser atingidas por um livro-texto isolado.
Agradecimentos. Meu trabalho nas sete edies de Engenharia de software: uma abordagem
profissional tem sido o mais longo e contnuo projeto tcnico de minha vida. Mesmo quando
termino a atividade de redao, informaes extradas da literatura tcnica continuam a ser
assimiladas e organizadas, bem como sugestes e crticas de leitores ao redor do mundo so
avaliadas e catalogadas. Por essa razo, meus agradecimentos aos muitos autores de livros e artigos acadmicos (tanto em papel quanto em meio eletrnico) que me forneceram vises, ideias
e comentrios adicionais ao longo de aproximadamente 30 anos.
Agradecimentos especiais a Tim Lethbridge, da University of Ottawa, que me ajudou no desenvolvimento de exemplos em UML e OCL e a desenvolver o estudo de caso que acompanha
este livro, bem como Dale Skrien do Colby College, que desenvolveu o tutorial UML do Apndice 1.
Sua ajuda e comentrios foram inestimveis. Um agradecimento especial a Bruce Maxim, da
University of MichiganDearborn, que me ajudou a desenvolver grande parte do contedo do
site pedaggico que acompanha a edio em ingls. Por fim, gostaria de agradecer aos revisores
da stima edio: seus comentrios profundos e crticas inteligentes foram valiosas.

PREFCIO

Osman Balci,
Virginia Tech University
Max Fomitchev,
Penn State University
Jerry (Zeyu) Gao,
San Jose State University
Guillermo Garcia,
Universidad Alfonso X Madrid
Pablo Gervas,
Universidad Complutense de Madrid

SK Jain,
National Institute of Technology Hamirpur
Saeed Monemi,
Cal Poly Pomona
Ahmed Salem,
California State University
Vasudeva Varma,
IIIT Hyderabad

O contedo da stima edio de Engenharia de software: uma abordagem profissional foi


moldado por profissionais da rea, professores universitrios e estudantes que usaram edies
anteriores do livro e se deram ao trabalho de enviar sugestes, crticas e ideias. Meus agradecimentos a cada um de vocs. Alm disso, meus agradecimentos pessoais vo a muitas pessoas
da indstria, distribudas por todo o mundo, que me ensinaram tanto ou mais do que eu poderia
ensinar-lhes.
Assim como as edies deste livro evoluram, meus filhos, Mathew e Michael, cresceram e
se tornaram homens. Sua maturidade, carter e sucesso me inspiraram. Nada mais me deixou
to orgulhoso. E, finalmente, para voc, Barbara, meu amor, agradeo por ter tolerado as vrias
horas que dediquei ao trabalho e por ter me estimulado para mais uma edio do livro.
Roger S. Pressman

Sumrio Resumido

CAPTULO 1

Engenharia de Software 29

PARTE UM

PROCESSOS DE SOFTWARE

CAPTULO 2

Modelos de Processo 52

CAPTULO 3

Desenvolvimento gil 81

PARTE DOIS

MODELAGEM

107

CAPTULO 4

Princpios que Orientam a Prtica 108

CAPTULO 5

Engenharia de Requisitos 126

51


CAPTULO 6

Modelagem de Requisitos: Cenrios, Informaes e Classes


de Anlise 150


CAPTULO 7

Modelagem de Requisitos: Fluxo, Comportamento, Padres e


Aplicaes Baseadas na Web (WebApp) 181

CAPTULO 8

Conceitos de Projeto 206

CAPTULO 9

Projeto de Arquitetura 229

CAPTULO 10

Projeto de Componentes 257

CAPTULO 11

Projeto de Interfaces do Usurio 287

CAPTULO 12

Projeto Baseado em Padres 316

CAPTULO 13

Projeto de WebApps 338

PARTE TRS

GESTO DA QUALIDADE

CAPTULO 14

Conceitos de Qualidade 358

CAPTULO 15

Tcnicas de Reviso 373

CAPTULO 16

Garantia da Qualidade de Software 387

CAPTULO 17

Estratgias de Teste de Software 401

CAPTULO 18

Testando Aplicativos Convencionais 428

CAPTULO 19

Testando Aplicaes Orientadas a Objeto 453

CAPTULO 20

Testando Aplicaes para Web 468

CAPTULO 21

Modelagem Formal e Verificao 491

CAPTULO 22

Gesto de Configurao de Software 514

CAPTULO 23

Mtricas de Produto 538

PARTE QUATRO

GERENCIAMENTO DE PROJETOS DE SOFTWARE

CAPTULO 24

Conceitos de Gerenciamento de Projeto 566

CAPTULO 25

Mtricas de Processo e Projeto 583

CAPTULO 26

Estimativas de Projeto de Software 604

CAPTULO 27

Cronograma de Projeto 629

357

565

xii

Sumrio resumido

CAPTULO 28

Gesto de Risco 648

CAPTULO 29

Manuteno e Reengenharia 662

PARTE CINCO

TPICOS AVANADOS

CAPTULO 30

Melhoria do Processo de Software 682


CAPTULO 31

Tendncias Emergentes na Engenharia de


Software 701

CAPTULO 32

Comentrios Finais 721

APNDICE 1

Introduo UML 727

APNDICE 2

Conceitos Orientados a Objeto 744

REFERNCIAS 751

NDICE 773

681

Sumrio

Captulo 1
1.1

Engenharia de Software 29

A Natureza do Software 31
1.1.1 Definindo software 32
1.1.2 Campos de aplicao de software 34
1.1.3 Software legado 36

1.2

A Natureza nica das Webapps 37

1.3

Engenharia de Software 38

1.4

O Processo de Software 40

1.5

A Prtica da Engenharia de Software 42


1.5.1 A essncia da prtica 42
1.5.2 Princpios gerais 44

1.6

Mitos Relativos ao Software 45

1.7

Como Tudo Comeou 47

1.8

Resumo 48

Problemas e Pontos a Ponderar 49


Leituras e Fontes de Informao Complementares 49
PARTE UM

PROCESSOS DE SOFTWARE 51

CAPTULO 2
2.1

Modelos de Processo 52

Um Modelo de Processo Genrico 53


2.1.1 Definindo atividade metodolgica 55
2.1.2 Identificao de um conjunto de tarefas 55
2.1.3 Padres de processos 55

2.2

Avaliao e Aperfeioamento de Processos 58

2.3

Modelos de Processo Prescritivo 58


2.3.1 O modelo cascata 59
2.3.2 Modelos de processo incremental 61
2.3.3 Modelos de processo evolucionrio 62
2.3.4 Modelos concorrentes 67
2.3.5 Um comentrio final sobre processos evolucionrios 68

2.4

Modelos de Processo Especializado 69


2.4.1 Desenvolvimento baseado em componentes 69
2.4.2 O modelo de mtodos formais 69
2.4.3 Desenvolvimento de software orientado a aspectos 70

2.5

O Processo Unificado 71
2.5.1 Breve histrico 72
2.5.2 Fases do processo unificado 72

2.6

Modelos de Processo Pessoal e de Equipe 74


2.6.1 Processo de Software Pessoal (PSP) 74
2.6.2 Processo de Software em Equipe (TSP) 75

2.7

Tecnologia de Processos 76

2.8

Processo do Produto 77

2.9

Resumo 78

Problemas e Pontos a Ponderar 78


Leituras e Fontes de Informao Complementares 79

xiv

SUMRIO

captulo 3

Desenvolvimento gil 81

3.1

O que Agilidade? 82

3.2

Agilidade e o Custo das Mudanas 83

3.3

O que Processo gil? 84


3.3.1 Princpios da agilidade 84
3.3.2 A poltica do desenvolvimento gil 85
3.3.3 Fatores humanos 86

3.4

Extreme Programming XP (Programao Extrema) 87


3.4.1 Valores da XP 87
3.4.2 O processo XP 88
3.4.3 Industrial XP 91
3.4.4 O debate XP 92

3.5

Outros Modelos de Processos geis 93


3.5.1 Desenvolvimento de Software Adaptativo (ASD) 94
3.5.2 Scrum 95
3.5.3 Mtodo de Desenvolvimento de Sistemas Dinmicos (DSDM) 96
3.5.4 Crystal 97
3.5.5 Desenvolvimento Dirigido a Funcionalidades (FDD) 98
3.5.6 Desenvolvimento de Software Enxuto (LSD) 99
3.5.7 Modelagem gil (AM) 99
3.5.8 Processo Unificado gil (AUP) 101

3.6

Um Conjunto de Ferramentas para o Processo gil 102

3.7

Resumo 102

Problemas e Pontos a Ponderar 103


Leituras e Fontes de Informao Complementares 104
PARTE DOIS

MODELAGEM 107

CAPTULO 4

Princpios Que Orientam a Prtica 108

4.1

Conhecimento da Engenharia de Software 109

4.2

Princpios Fundamentais 109


4.2.1 Princpios que orientam o processo 110
4.2.2 Princpios que orientam a prtica 111

4.3

Princpios das Atividades Metodolgicas 112


4.3.1 Princpios da comunicao 112
4.3.2 Princpios de planejamento 114
4.3.3 Princpios de modelagem 116
4.3.4 Princpios de construo 120
4.3.5 Princpios de disponibilizao 122

4.4

Resumo 123

Problemas e Pontos a Ponderar 123


Leituras e Fontes de Informao Complementares 124

CAPTULO 5

Engenharia de Requisitos 126

5.1

Engenharia de Requisitos 127

5.2

Incio do Processo de Engenharia de Requisitos 131


5.2.1 Identificao de interessados 131
5.2.2 Reconhecimento de diversos pontos de vista 131
5.2.3 Trabalho na busca da colaborao 132
5.2.4 Perguntas iniciais 132

xv

SUMRIO

5.3

Levantamento de Requisitos 133


5.3.1 Coleta colaborativa de requisitos 133
5.3.2 Disponibilizao da funo de qualidade 136
5.3.3 Cenrios de uso 136
5.3.4 Artefatos do levantamento de requisitos 137

5.4

Desenvolvimento de Casos de Uso 137

5.5

Construo do modelo de anlise 142


5.5.1 Elementos do modelo de anlise 142
5.5.2 Padres de anlise 145

5.6

Negociao de Requisitos 145

5.7

Validao dos Requisitos 146

5.8

Resumo 147

Problemas e Pontos a Ponderar 147


Leituras e Fontes de Informao Complementares 148

CAPTULO 6
Modelagem de Requisitos: Cenrios, Informaes e Classes
de Anlise 150
6.1

nalise de Requisitos 151


6.1.1 Filosofia e objetivos gerais 152
6.1.2 Regras prticas para a anlise 152
6.1.3 Anlise de domnio 153
6.1.4 Abordagens modelagem de requisitos 154

6.2

Modelagem Baseada em Cenrios 155


6.2.1 Criao de um caso de uso preliminar 155
6.2.2 Refinamento de um caso de uso preliminar 158
6.2.3 Criao de um caso de uso formal 159

6.3

Modelos Uml que Complementam o Caso de Uso 161


6.3.1 Desenvolvimento de um diagrama de atividade 161
6.3.2 Diagramas de raias 162

6.4

Conceitos de Modelagem de Dados 163


6.4.1 Objetos de dados 163
6.4.2 Atributos de dados 163
6.4.3 Relacionamentos 164

6.5

Modelagem Baseada em Classes 166


6.5.1 Identificao de classes de anlise 166
6.5.2 Especificao de atributos 169
6.5.3 Definio das operaes 170
6.5.4 Modelagem CRC (Classe-Responsabilidade-Colaborador) 171
6.5.5 Associaes e dependncias 176
6.5.6 Pacotes de anlise 178

6.6

Resumo 178

Problemas e Pontos a Ponderar 179


Leituras e Fontes de Informao Complementares 180

CAPTULO 7

Modelagem de Requisitos: Fluxo, Comportamento, Padres e


Aplicaes Baseadas na Web (WebApp) 181

7.1

Estratgias de Modelagem de Requisitos 182

7.2

Modelagem Orientada a Fluxos 182


7.2.1 Criao de um modelo de fluxo de dados 182
7.2.2 Criao de um modelo de fluxo de controle 185
7.2.3 A especificao de controles 185
7.2.4 A especificao de processos 186

xvi

SUMRIO

7.3

Criao de um Modelo Comportamental 188


7.3.1 Identificao de eventos com o caso de uso 189
7.3.2 Representaes de estados 189

7.4

Padres Para a Modelagem de Requisitos 192


7.4.1 Descoberta de padres de anlise 192
7.4.2 Exemplo de padro de requisitos: atuador-sensor 193

7.5

Modelagem de Requisitos para WebApps 197


7.5.1 Que nvel de anlise suficiente? 197
7.5.2 Entrada da modelagem de requisitos 197
7.5.3 Sada da modelagem de requisitos 198
7.5.4 Modelo de contedo para WebApps 199
7.5.5 Modelo de interaes para WebApps 200
7.5.6 Modelo funcional para WebApps 200
7.5.7 Modelos de configurao para WebApps 201
7.5.8 Modelo de navegao 202

7.6

Resumo 203

Problemas e Pontos a Ponderar 204


Leituras e Fontes de Informao Complementares 204

CAPTULO 8

Conceitos de PROJETO 206

8.1

Projeto no Contexto da Engenharia de Software 207

8.2

O Processo de Projeto 209


8.2.1 Diretrizes e atributos da qualidade de software 209
8.2.2 A evoluo de um projeto de software 211

8.3

Conceitos de Projeto 212


8.3.1 Abstrao 212
8.3.2 Arquitetura 213
8.3.3 Padres 214
8.3.4 Separao por interesses (por afinidades) 214
8.3.5 Modularidade 214
8.3.6 Encapsulamento de informaes 215
8.3.7 Independncia funcional 216
8.3.8 Refinamento 217
8.3.9 Aspectos 217
8.3.10 Refatorao 218
8.3.11 Conceitos de projeto orientado a objetos 218
8.3.12 Classes de projeto 218

8.4

O Modelo de Projeto 221


8.4.1 Elementos de projeto de dados 222
8.4.2 Elementos de projeto de arquitetura 222
8.4.3 Elementos de projeto de interfaces 222
8.4.4 Elementos de projeto de componentes 224
8.4.5 Elementos de projeto de implantao 224

8.5

Resumo 226

Problemas e Pontos a Ponderar 226


Leituras e Fontes de Informao Complementares 227

CAPTULO 9
9.1

Projeto da Arquitetura 229

Arquitetura de Software 230


9.1.1 O que arquitetura? 230
9.1.2 Por que a arquitetura importante? 231

xvii

SUMRIO

9.1.3 Descries de arquitetura 231


9.1.4 Decises de arquitetura 232
9.2

Gneros de Arquitetura 232

9.3

Estilos de Arquitetura 234


9.3.1 Uma breve taxonomia dos estilos de arquitetura 235
9.3.2 Padres de arquitetura 238
9.3.3 Organizao e refinamento 239

9.4

Projeto da Arquitetura 239


9.4.1 Representao do sistema no contexto 240
9.4.2 Definio de arqutipos 241
9.4.3 Refinamento da arquitetura em componentes 242
9.4.4 Descrio das instncias 243

9.5

Avaliao de Projetos de Arquiteturas Alternativos 244


9.5.1 Um mtodo de anlise dos prs e contras de uma arquitetura 245
9.5.2 Complexidade da arquitetura 246
9.5.3 Linguagens de descrio da arquitetura 247

9.6

Mapeamento de Arquitetura Utilizando Fluxo de Dados 247


9.6.1 Mapeamento de transformao 248
9.6.2 Refinamento do projeto da arquitetura 254

9.7

Resumo 255

Problemas e Pontos a Ponderar 255


Leituras e Fontes de Informao Complementares 256

CAPTULO 10

Projeto de Componentes 257

10.1 O Que Componente? 258


10.1.1 Uma viso orientada a objetos 258
10.1.2 A viso tradicional 260
10.1.3 Uma viso relacionada com processos 262
10.2 Projeto de Componentes Baseados em Classes 262
10.2.1 Princpios bsicos de projeto 262
10.2.2 Diretrizes para o projeto de componentes 265
10.2.3 Coeso 266
10.2.4 Acoplamento 267
10.3 Conduo de Projetos de Componentes 269
10.4 Projeto de Componentes para Webapps 274
10.4.1 Projeto de contedo para componentes 274
10.4.2 Projeto funcional para componentes 275
10.5 Projeto de Componentes Tradicionais 275
10.5.1 Notao grfica em projeto 276
10.5.2 Notao tabular de projeto 277
10.5.3 Linguagem de projeto de programas 278
10.6 Desenvolvimento Baseado em Componentes 279
10.6.1 Engenharia de domnio 280
10.6.2 Qualificao, adaptao e composio de componentes 280
10.6.3 Anlise e projeto para reutilizao 282
10.6.4 Classificao e recuperao de componentes 283
10.7 Resumo 284
Problemas e Pontos a Ponderar 285
Leituras e Fontes de Informao Complementares 286

xviii

SUMRIO

CAPTULO 11

Projeto de Interfaces do Usurio 287

11.1 As Regras de Ouro 288


11.1.1 Deixar o usurio no comando 288
11.1.2 Reduzir a carga de memria do usurio 289
11.1.3 Tornar a interface consistente 290
11.2 Anlise e Projeto de Interfaces 291
11.2.1 Modelos de anlise e projeto de interfaces 291
11.2.2 O processo 292
11.3 Anlise de Interfaces 294
11.3.1 Anlise de usurios 294
11.3.2 Anlise e modelagem de tarefas 295
11.3.3 Anlise do contedo exibido 299
11.3.4 Anlise do ambiente de trabalho 300
11.4 Etapas no Projeto de Interfaces 300
11.4.1 Aplicao das etapas para projeto de interfaces 301
11.4.2 Padres de projeto de interfaces do usurio 302
11.4.3 Questes de projeto 303
11.5 Projeto de Interfaces para WebApp 306
11.5.1 Princpios e diretrizes para projeto de interfaces 306
11.5.2 Fluxo de trabalho de projeto de interfaces para WebApps 310
11.6 Avaliao de Projeto 311
11.7 Resumo 313
Problemas e Pontos a Ponderar 313
Leituras e Fontes de Informao Complementares 314

CAPTULO 12

Projeto Baseado em Padres 316

12.1 Padro de Projeto 317


12.1.1 Tipos de padres 318
12.1.2 Estruturas de uso de padres de projeto 320
12.1.3 Descrio de padres 320
12.1.4 Linguagens e repositrios de padres 321
12.2 Projeto de Software Baseado em Padres 322
12.2.1 Contexto do projeto baseado em padres 322
12.2.2 Pensando em termos de padres 323
12.2.3 Tarefas de projeto 324
12.2.4 Construo de uma tabela para organizao de padres 325
12.2.5 Erros comuns de projeto 326
12.3 Padres de Arquitetura 327
12.4 Padres de Projeto de Componentes 329
12.5 Padres de Projeto para Interfaces do Usurio 331
12.6 Padres de Projeto para WebApps 333
12.6.1 Foco do projeto 333
12.6.2 Granularidade do projeto 334
12.7 Resumo 335
Problemas e Pontos a Ponderar 336
Leituras e Fontes de Informao Complementares 336

CAPTULO 13

Projeto de WebApps 338

13.1 Qualidade de Projeto em WebApps 339


13.2 Objetivos de Projeto 341
13.3 Uma Pirmide de Projeto para WebApps 342

xix

SUMRIO

13.4 Projeto de Interfaces para WebApps 342


13.5 Projeto Esttico 344
13.5.1 Problemas de layout 344
13.5.2 Questes de design grfico 344
13.6 Projeto de Contedo 345
13.6.1 Objetos de contedo 345
13.6.2 Questes de projeto de contedo 345
13.7 Projeto Arquitetural 346
13.7.1 Arquitetura de contedo 347
13.7.2 Arquitetura de uma WebApp 349
13.8 Projeto da Navegao 350
13.8.1 Semntica de navegao 350
13.8.2 Sintaxe de navegao 351
13.9 Projeto dos Componentes 352
13.10 Mtodo de Projeto de Hipermdia Orientado a Objetos (Object-Oriented Hypermedia Design

Method OOHDM) 352
13.10.1 Projeto conceitual para o OOHDM 352
13.10.2 Projeto da navegao para o OOHDM 353
13.10.3 Projeto da interface abstrata e implementao 353
13.11 Resumo 354
Problemas e Pontos a Ponderar 355
Leituras e Fontes de Informao Complementares 356
PARTE TRS GESTO DE QUALIDADE 357

CAPTULO 14

Conceitos de qualidade 358

14.1 O Que Qualidade? 359


14.2 Qualidade de Software 360
14.2.1 Dimenses de qualidade de Garvin 360
14.2.2 Fatores de qualidade de McCall 361
14.2.3 Fatores de qualidade ISO 9126 362
14.2.4 Fatores de qualidade desejados 363
14.2.5 A transio para uma viso quantitativa 364
14.3 O Dilema da Qualidade de Software 365
14.3.1 Software bom o suficiente 365
14.3.2 Custo da qualidade 366
14.3.3 Riscos 368
14.3.4 Negligncia e responsabilidade civil 368
14.3.5 Qualidade e segurana 368
14.3.6 O impacto das aes administrativas 369
14.4 Alcanando a Qualidade de Software 370
14.4.1 Mtodos de engenharia de software 370
14.4.2 Tcnicas de gerenciamento de software 370
14.4.3 Controle de qualidade 370
14.4.4 Garantia da qualidade 370
14.5 Resumo 371
Problemas e Pontos a Ponderar 371
Leituras e Fontes de Informao Complementares 372

CAPTULO 15

Tcnicas de Reviso 373

15.1 Impacto de Defeitos de Software nos Custos 374


15.2 Amplificao e Eliminao de Defeitos 375

xx

SUMRIO

15.3 Mtricas de Reviso e seu Emprego 376


15.3.1 Anlise de mtricas 377
15.3.2 Eficcia dos custos de revises 377
15.4 Revises: Um Espectro de Formalidade 379
15.5 Revises Informais 380
15.6 Revises Tcnicas Formais 381
15.6.1 Uma reunio de reviso 381
15.6.2 Relatrio de reviso e manuteno de registros 382
15.6.3 Diretrizes de reviso 382
15.6.4 Revises por amostragem 384
15.7 Resumo 385
Problemas e Pontos a Ponderar 385
Leituras e Fontes de Informao Complementares 386

CAPTULO 16

Garantia da Qualidade de Software 387

16.1 Problemas de Background 388


16.2 Elementos de Garantia da Qualidade de Software 388
16.3 Tarefas, Metas e Mtricas da Sqa 390
16.3.1 Tarefas da SQA 390
16.3.2 Metas, atributos e mtricas 391
16.4 Abordagens Formais da Sqa 392
16.5 Estatstica da Garantia da Qualidade de Software 393
16.5.1 Um exemplo genrico 393
16.5.2 Seis sigma para engenharia de software 394
16.6 Confiabilidade de Software 395
16.6.1 Medidas de confiabilidade e cisponibilidade 395
16.6.2 Proteo do software 396
16.7 Os Padres de Qualidade Iso 9000 397
16.8 O Plano de Sqa 398
16.9 Resumo 399
Problemas e Pontos a Ponderar 399
Leituras e Fontes de Informao Complementares 400

CAPTULO 17

Estratgias de Teste de Software 401

17.1 Uma Abordagem Estratgica do Teste de Software 402


17.1.1 Verificao e validao 402
17.1.2 Organizando o teste de software 403
17.1.3 Estratgia de teste de software a viso ampla 404
17.1.4 Critrios para concluso do teste 405
17.2 Problemas Estratgicos 406
17.3 Estratgias Para Software Convencional 407
17.3.1 Teste de unidade 407
17.3.2 Teste de integrao 409
17.4 Estratgias de Teste Para Software Orientado a Objeto 415
17.4.1 Teste de unidade no contexto OO 415
17.4.2 Teste de integrao no contexto OO 415
17.5 Estratgias de Teste Para WebApps 416
17.6 Teste de Validao 416
17.6.1 Critrio de teste de validao 417
17.6.2 Reviso da configurao 417
17.6.3 Teste alfa e beta 417

xxi

SUMRIO

17.7 Teste de Sistema 418


17.7.1 Teste de recuperao 419
17.7.2 Teste de segurana 419
17.7.3 Teste por esforo 419
17.7.4 Teste de desempenho 420
17.7.5 Teste de disponibilizao 420
17.8 A Arte da Depurao 421
17.8.1 O processo de depurao 421
17.8.2 Consideraes psicolgicas 422
17.8.3 Estratgias de depurao 423
17.8.4 Correo do erro 424
17.9 Resumo 425
Problemas e Pontos a Ponderar 425
Leituras e Fontes de Informao Complementares 426

CAPTULO 18

Testando Aplicativos Convencionais 428

18.1 Fundamentos do Teste de Software 429


18.2 Vises Interna e Externa do Teste 430
18.3 Teste Caixa Branca 431
18.4 Teste do Caminho Bsico 431
18.4.1 Notao de grafo de fluxo 432
18.4.2 Caminhos de programa independentes 433
18.4.3 Derivao de casos de teste 435
18.4.4 Matrizes de grafos 436
18.5 Teste de Estrutura de Controle 437
18.5.1 Teste de condio 437
18.5.2 Teste de fluxo de dados 438
18.5.3 Teste de ciclo 438
18.6 Teste Caixa Preta 439
18.6.1 Mtodos de teste com base em grafo 440
18.6.2 Particionamento de equivalncia 441
18.6.3 Anlise de valor limite 442
18.6.4 Teste de matriz ortogonal 442
18.7 Teste Baseado em Modelos 445
18.8 Teste Para Ambientes, Arquiteturas e Aplicaes Especializados 446
18.8.1 Testando GUIs 446
18.8.2 Teste de arquiteturas cliente-servidor 446
18.8.3 Testando a documentao e os recursos de ajuda 447
18.8.4 Teste para sistema em tempo real 448
18.9 Padres para Teste de Software 449
18.10 Resumo 450
Problemas e Pontos a Ponderar 451
Leituras e Fontes de Informao Complementares 452

CAPTULO 19

Testando Aplicaes Orientadas a Objeto 453

19.1 Ampliando a Verso do Teste 454


19.2 Testando Modelos de Anlise Orientada a Objeto (Ooa) e Projeto Orientado a Objeto (Ood) 455
19.2.1 Exatido dos modelos de OOA e OODs 455
19.2.2 Consistncia dos modelos orientados a objeto 455
19.3 Estratgias de Teste Orientado a Objeto 457
19.3.1 Teste de unidade em contexto orientado a objeto 457

xxii

SUMRIO

19.3.2 Teste de integrao em contexto orientado a objeto 457


19.3.3 Teste de validao em contexto orientado a objeto 458
19.4 Mtodos de Teste Orientados a Objeto 458
19.4.1As implicaes no projeto de casos de teste dos conceitos orientados a objeto 459
19.4.2Aplicabilidade dos mtodos convencionais de projeto de casos de teste 459
19.4.3 Teste baseado em falhas 459
19.4.4 Casos de teste e a hierarquia de classe 460
19.4.5 Projeto de teste baseado em cenrio 460
19.4.6 Teste da estrutura superficial e estrutura profunda 462
19.5 Mtodos de Teste Aplicveis no Nvel de Classe 462
19.5.1 Teste aleatrio para classes orientadas a objeto 462
19.5.2 Teste de partio em nvel de classe 463
19.6 Projeto de Caso de Teste Interclasse 464
19.6.1 Teste de mltiplas classes 464
19.6.2 Testes derivados de modelos comportamentais 465
19.7 Resumo 466
Problemas e Pontos a Ponderar 467
Leituras e Fontes de Informao Complementares 467

CAPTULO 20

Testando Aplicaes Para Web 468

20.1 Conceitos de Teste para WebApps 469


20.1.1 Dimenses da qualidade 469
20.1.2 Erros em um ambiente WebApp 469
20.1.3 Estratgia de teste 470
20.1.4 Planejamento de teste 470
20.2 O Processo de Teste uma Viso Geral 471
20.3 Teste de Contedo 472
20.3.1 Objetivos do teste de contedo 472
20.3.2 Teste de base de dados 473
20.4 Teste da Interface de Usurio 474
20.4.1 Estratgia de teste de interface 474
20.4.2 Testando mecanismos de interface 475
20.4.3 Testando semnticas de interface 477
20.4.4 Testes de usabilidade 477
20.4.5 Testes de compatibilidade 478
20.5 Teste no Nvel de Componente 479
20.6 Testes de Navegao 480
20.6.1 Testando a sintaxe de navegao 481
20.6.2 Testando as semnticas de navegao 481
20.7 Teste de Configurao 482
20.7.1 Tpicos no lado do servidor 483
20.7.2 Tpicos no lado do cliente 483
20.8 Teste de Segurana 484
20.9 Teste de Desempenho 485
20.9.1 Objetivos do teste de desempenho 485
20.9.2 Teste de carga 486
20.9.3 Teste de esforo (stress) 486
20.10 Resumo 487
Problemas e Pontos a Ponderar 488
Leituras e Fontes de Informao Complementares 489

xxiii

SUMRIO

CAPTULO 21

Modelagem Formal e Verificao 491

21.1 Estratgia Sala Limpa 492


21.2 Especificao Funcional 493
21.2.1 Especificao caixa preta 495
21.2.2 Especificao caixa de estado 495
21.2.3 Especificao caixa clara 495
21.3 Projeto Sala Limpa 496
21.3.1 Refinamento de projeto 496
21.3.2 Verificao de projeto 497
21.4 Teste Sala Limpa 498
21.4.1 Teste estatstico de uso 498
21.4.2 Certificao 499
21.5 Conceitos de Mtodos Formais 500
21.6 Aplicando Notao Matemtica para Especificao Formal 503
21.7 Linguagens de Especificao Formal 504
21.7.1 Object Constraint Language (OCL) 505
21.7.2 A linguagem de especificao Z 508
21.8 Resumo 510
Problemas e Pontos a Ponderar 511
Leituras e Fontes de Informao Complementares 512

CAPTULO 22

Gesto de Configurao de Software 514

22.1 Gesto de Configurao de Software 515


22.1.1 Um cenrio SCM 515
22.1.2 Elementos de um sistema de gesto de configurao 516
22.1.3 Referenciais 517
22.1.4 Itens de configurao de software 518
22.2 O Repositrio SCM 519
22.2.1 O papel do repositrio 519
22.2.2 Caractersticas gerais e contedo 519
22.2.3 Caractersticas SCM 520
22.3 O Processo SCM 521
22.3.1 Identificao de objetos na configurao de software 522
22.3.2 Controle de verso 523
22.3.3 Controle de alteraes 524
22.3.4 Auditoria de configurao 526
22.3.5 Relatrio de status 527
22.4 Gesto de Configurao para WebApps 528
22.4.1 Problemas dominantes 528
22.4.2 Objetos de configurao de WebApp 529
22.4.3 Gesto de contedo 530
22.4.4 Gesto de alteraes 531
22.4.5 Controle de verso 534
22.4.6 Auditoria e relatrio 534
22.5 Resumo 535
Problemas e Pontos a Ponderar 536
Leituras e Fontes de Informao Complementares 537

CAPTULO 23

Mtricas de Produto 538

23.1 Estrutura para Mtricas de Produto 539


23.1.1 Medidas, mtricas e indicadores 539

xxiv

SUMRIO

23.1.2 O desafio das mtricas de produto 539


23.1.3 Princpios de medio 540
23.1.4 Medio de software orientada a objetivo 541
23.1.5 Atributos de mtricas efetivas de software 542
23.2 Mtricas para o Modelo de Requisitos 543
23.2.1 Mtricas baseadas em funo 543
23.2.2 Mtricas para qualidade de especificao 546
23.3 Mtricas para o Modelo de Projeto 547
23.3.1 Mtricas de projeto da arquitetura 547
23.3.2 Mtricas para projeto orientado a objeto 549
23.3.3 Mtricas orientadas a classe o conjunto de mtricas CK 551
23.3.4 Mtricas orientadas a classe o conjunto de mtricas MOOD 553
23.3.5 Mtricas orientadas a objeto propostas por Lorenz e Kidd 554
23.3.6 Mtricas de projeto em nvel de componente 554
23.3.7 Mtricas orientadas a operao 556
23.3.8 Mtricas de projeto de interface de usurio 557
23.4 Mtricas de Projeto para WebApps 557
23.5 Mtricas para Cdigo-Fonte 559
23.6 Mtricas para Teste 560
23.6.1 Mtricas de Halstead aplicadas ao teste 561
23.6.2 Mtricas para teste orientado a objeto 561
23.7 Mtricas para Manuteno 562
23.8 Resumo 563
Problemas e Pontos a Ponderar 563
Leituras e Fontes de Informao Complementares 564
PARTE QUATRO

GERENCIAMENTO DE PROJETOS DE SOFTWARE 565

CAPTULO 24

Conceitos de Gerenciamento de Projeto 566

24.1 O Espectro de Gerenciamento 567


24.1.1 Pessoal 567
24.1.2 O produto 567
24.1.3 O processo 568
24.1.4 O projeto 568
24.2 Pessoas 568
24.2.1 Os interessados (comprometidos) 569
24.2.2 Lderes de equipe 569
24.2.3 Equipe de software 570
24.2.4 Equipes geis 572
24.2.5 Itens de comunicao e coordenao 573
24.3 O Produto 574
24.3.1 Escopo de software 574
24.3.2 Decomposio do problema 574
24.4 O Processo 575
24.4.1 Combinando o produto e o processo 575
24.4.2 Decomposio do processo 576
24.5 O Projeto 577
24.6 O Princpio W5HH 578
24.7 Prticas Vitais 579
24.8 Resumo 579
Problemas e Pontos a Ponderar 580
Leituras e Fontes de Informao Complementares 581

xxv

SUMRIO

CAPTULO 25

Mtricas de Processo e Projeto 583

25.1 Mtricas no domnio de processo e projeto 584


25.1.1 Mtricas de processo e aperfeioamento do processo de software 584
25.1.2 Mtricas de projeto 586
25.2 Medidas de Software 586
25.2.1 Mtricas orientadas a tamanho 588
25.2.2 Mtricas orientadas a funo 589
25.2.3 Reconciliando mtricas LOC e FP 589
25.2.4 Mtricas orientadas a objeto 591
25.2.5 Mtricas orientadas a casos de uso 592
25.2.6 Mtricas de projeto WebApp 592
25.3 Mtricas para Qualidade de Software 594
25.3.1 Medio da qualidade 594
25.3.2 Eficincia na remoo de defeitos 595
25.4 Integrando Mtricas Dentro do Processo de Software 596
25.4.1 Argumentos favorveis a mtricas de software 597
25.4.2 Estabelecendo uma linha de base 597
25.4.3 Coleta, clculo e avaliao de mtricas 597
25.5 Mtricas para Pequenas Organizaes 598
25.6 Estabelecendo um Programa de Mtricas de Software 599
25.7 Resumo 601
Problemas e Pontos a Ponderar 601
Leituras e Fontes de Informao Complementares 602

CAPTULO 26

Estimativas de Projeto de Software 604

26.1 Observaes e Estimativas 605


26.2 O Processo de Planejamento do Projeto 606
26.3 Escopo e Viabilidade do Software 606
26.4 Recursos 607
26.4.1 Recursos humanos 608
26.4.2 Recursos de software reutilizveis 608
26.4.3 Recursos de ambiente 608
26.5 Estimativa do Projeto de Software 609
26.6 Tcnicas de Decomposio 610
26.6.1 Dimensionamento do software 610
26.6.2 Estimativa baseada em problema 611
26.6.3 Um exemplo de estimativa baseada em LOC 612
26.6.4 Um exemplo de estimativa baseada em FP 613
26.6.5 Estimativas baseadas em processo 614
26.6.6 Um exemplo de estimativa baseada em processo 615
26.6.7 Estimativa com casos de uso 616
26.6.8 Exemplo de estimativa baseada em caso de uso 617
26.6.9 Reconciliando estimativas 617
26.7 Modelos Empricos de Estimativa 618
26.7.1 Estrutura dos modelos de estimativa 619
26.7.2 O modelo COCOMO II 619
26.7.3 A equao do software 621
26.8 Estimativa para Projetos Orientados a Objeto 622
26.9 Tcnicas Especializadas de Estimativa 622
26.9.1 Estimativa para desenvolvimento gil 622
26.9.2 Estimativa para projetos para WebApp 623

xxvi

SUMRIO

26.10 A Deciso Fazer/Comprar 624


26.10.1 Criando uma rvore de decises 624
26.10.2 Terceirizao 625
26.11 Resumo 627
Problemas e Pontos a Ponderar 627
Leituras e Fontes de Informao Complementares 628

CAPTULO 27

Cronograma de Projeto 629

27.1 Conceitos Bsicos 630


27.2 Cronograma de Projeto 631
27.2.1 Princpios bsicos 632
27.2.2 Relao entre pessoas e esforo 632
27.2.3 Distribuio de esforo 634
27.3 Definindo um Conjunto de Tarefas para o Projeto de Software 635
27.3.1 Exemplo de conjunto de tarefas 635
27.3.2 Refinamento das aes de engenharia de software 636
27.4 Definindo uma Rede de Tarefas 636
27.5 Cronograma 637
27.5.1 Grfico de Gantt 638
27.5.2 Acompanhando o cronograma 638
27.5.3 Acompanhando o progresso de um projeto orientado a objeto 640
27.5.4 Cronograma para projetos para WebApp 641
27.6 Anlise de Valor Agregado 643
27.8 Resumo 645
Problemas e Pontos a Ponderar 645
Leituras e Fontes de Informao Complementares 646

CAPTULO 28

Gesto de Riscos 648

28.1 Estratgias de Riscos Reativa versus Proativa 649


28.2 Riscos de Software 649
28.3 Identificao do Risco 650
28.3.1 Avaliando o risco geral do projeto 651
28.3.2 Componentes e fatores de risco 651
28.4 Previso de Risco 652
28.4.1 Desenvolvendo uma tabela de risco 653
28.4.2 Avaliando o impacto do risco 655
28.5 Refinamento do Risco 656
28.6 Mitigao, Monitorao e Controle de Riscos (RMMM) 657
28.7 O Plano RMMM 658
28.8 Resumo 660
Problemas e Pontos a Ponderar 660
Leituras e Fontes de Informao Complementares 661

CAPTULO 29

Manuteno e Reengenharia 662

29.1 Manuteno de Software 663


29.2 Suportabilidade do Software 664
29.3 Reengenharia 665
29.4 Reengenharia de Processo de Negcio 665
29.4.1 Processos de negcio 665
29.4.2 Um modelo de BPR 666

xxvii

SUMRIO

29.5 Reengenharia de Software 667


29.5.1 Um modelo de processo de reengenharia de software 668
29.5.2 Atividades de reengenharia de software 669
29.6 Engenharia Reversa 670
29.6.1 Engenharia reversa para entender os dados 672
29.6.2 Engenharia reversa para entender o processamento 672
29.6.3 Engenharia reversa das interfaces de usurio 673
29.7 Reestruturao 674
29.7.1 Reestruturao de cdigo 674
29.7.2 Reestruturao de dados 674
29.8 Engenharia Direta 675
29.8.1 Engenharia direta para arquiteturas cliente-servidor 676
29.8.2 Engenharia direta para arquiteturas orientadas a objeto 677
29.9 A Economia da Reengenharia 677
29.10 Resumo 678
Problemas e Pontos a Ponderar 679
Leituras e Fonte de Informao Complementares 679
PARTE CINCO

TPICOS AVANADOS 681

CAPTULO 30

Melhoria do Processo de Software 682

30.1 O Que SPI? 683


30.1.1 Abordagens para SPI 683
30.1.2 Modelos de maturidade 685
30.1.3 A SPI para todos? 685
30.2 O Processo de SPI 686
30.2.1 Avaliao e anlise de lacunas 686
30.2.2 Educao e treinamento 687
30.2.3 Seleo e justificao 688
30.2.4 Instalao/migrao 689
30.2.5 Mensurao 689
30.2.6 Gerenciamento de risco para SPI 689
30.2.7 Fatores crticos de sucesso 690
30.3 A CMMI 691
30.4 A CMM das Pessoas 695
30.5 Outras Estruturas SPI 696
30.6 Retorno sobre Investimento em SPI 697
30.7 Tendncias da SPI 698
30.8 Resumo 698
Problemas e Pontos a Ponderar 699
Leituras e Fontes de Informao Complementares 699

CAPTULO 31

Tendncias Emergentes na Engenharia de Software 701

31.1 Evoluo da Tecnologia 702


31.2 Observando Tendncias na Engenharia de Software 703
31.3 Identificando as Tendncias Leves 704
31.3.1 Administrando a complexidade 705
31.3.2 Software aberto 706
31.3.3 Requisitos emergentes 707
31.3.4 O mix de talentos 707
31.3.5 Blocos bsicos de software 708

xxviii

SUMRIO

31.3.6 Mudando as percepes de valor 708


31.3.7 Cdigo aberto 709
31.4 Direes da Tecnologia 710
31.4.1 Tendncias de processo 710
31.4.2 O grande desafio 711
31.4.3 Desenvolvimento colaborativo 712
31.4.4 Engenharia de requisitos 713
31.4.5 Desenvolvimento de software controlado por modelo 714
31.4.6 Projeto ps-moderno 714
31.4.7 Desenvolvimento baseado em teste 715
31.5 Tendncias Relacionadas com Ferramentas 716
31.5.1 Ferramentas que respondem a tendncias leves 717
31.5.2 Ferramentas que lidam com as tendncias tecnolgicas 718
31.6 Resumo 719
Problemas e Pontos a Ponderar 719
Leituras e Fontes de Informao Complementares 720

CAPTULO 32

Comentrios Finais 721

32.1 A Importncia do Software Revisitada 722


32.2 Profissionais e a Maneira como Constroem Sistemas 722
32.3 Novos Modos de Representar as Informaes 723
32.4 A Viso no Longo Prazo 724
32.5 A Responsabilidade do Engenheiro de Software 725
32.6 Comentrio Final 726

APNDICE 1

Introduo UML 727

APNDICE 2

Conceitos Orientados ao Objeto 744

REFERNCIAS 751

NDICE 773

captulo

Engenharia
Conceitos- Chave
atividades de
apoio . . . . . . . . . . . 40
campos de
aplicao . . . . . . . . 34
caractersticas
de software . . . . . . 32
engenharia de
software . . . . . . . . 38
metodologia . . . . . . 40
mitos de software . 45
prtica . . . . . . . . . . 45
princpios . . . . . . . . 44
processo de
software . . . . . . . . 40
software legado . . .36
WebApps . . . . . . . . 37

Software e
de S oftware

le tinha a aparncia clssica de um executivo snior de uma grande empresa de


software cerca de 40 anos de idade, as tmporas levemente grisalhas, elegante
e atltico, olhos penetrantes enquanto falava. Mas o que ele disse me deixou em
choque: O software est morto.
Fiquei surpreso e ento sorri. Voc est brincando, no mesmo? O mundo comandado pelo software e sua empresa tem lucrado imensamente com isso... Ele no est
morto! Est vivo e crescendo.
Balanando a cabea enftica e negativamente, acrescentou: No, ele est morto...
Pelo menos da forma que, um dia, o conhecemos.
Assenti e disse: Continue.
Ele falava batendo na mesa para enfatizar: A viso da velha escola de software voc
o compra, seu proprietrio e o responsvel pelo seu gerenciamento est chegando
ao fim. Atualmente, com a Web 2.0 e a computao pervasiva, que vem surgindo com fora,
estamos por ver uma gerao completamente diferente de software. Ele ser distribudo
via Internet e parecer estar residente nos dispositivos do computador de cada usurio...
Porm, estar residente em um servidor bem distante.

O que ? Software de computador

Panorama o produto que profissionais de software

desenvolvem e ao qual do suporte no


longo prazo. Abrange programas executveis em um computador de qualquer porte ou
arquitetura, contedos (apresentados medida
que os programas so executados), informaes
descritivas tanto na forma impressa (hard copy)
como na virtual, abrangendo praticamente qualquer mdia eletrnica. A engenharia de software
abrange um processo, um conjunto de mtodos
(prticas) e um leque de ferramentas que possibilitam aos profissionais desenvolverem software de
altssima qualidade.
Quem realiza? Os engenheiros de software criam e
do suporte a ele e, praticamente, todos do mundo
industrializado o utilizam, direta ou indiretamente.
Por que ele importante? Software importante porque afeta a quase todos os aspectos de
nossas vidas e tornou-se pervasivo (incorporado)
no comrcio, na cultura e em nossas atividades
cotidianas. A engenharia de software importante

porque ela nos capacita para o desenvolvimento


de sistemas complexos dentro do prazo e com alta
qualidade.
Quais so as etapas envolvidas? Cria-se software para computadores da mesma forma que
qualquer produto bem-sucedido: aplicando-se um
processo adaptvel e gil que conduza a um
resultado de alta qualidade, atendendo s necessidades daqueles que usaro o produto. Aplica-se
uma abordagem de engenharia de software.
Qual o artefato? Do ponto de vista de um engenheiro de software, um conjunto de programas,
contedo (dados) e outros artefatos que so software. Porm, do ponto de vista do usurio, o artefato consiste em informaes resultantes que, de
alguma forma, tornam a vida dele melhor.
Como garantir que o trabalho foi feito corretamente? Leia o restante deste livro, selecione
as ideias que so aplicveis ao software que voc
desenvolver e use-as em seu trabalho.

29

30

captulo 1 software e ENGENHARIA DE SOFTWARE

Eu tive de concordar: Assim, sua vida ser muito mais simples. Vocs, meus amigos, no
tero de se preocupar com cinco verses diferentes do mesmo aplicativo em uso por dezenas de
milhares de usurios espalhados.
Ele sorriu e acrescentou: Absolutamente. Apenas a verso mais atual residindo em nossos servidores. Quando fizermos uma modificao ou correo, forneceremos funcionalidade e
contedo atualizados para todos os usurios. Todos tero isso instantaneamente!.
Fiz uma careta: Mas, da mesma forma, se houver um erro, todos o tero instantaneamente.
Ele riu: verdade, por isso estamos redobrando nossos esforos para aplicarmos a engenharia de software de uma forma ainda melhor. O problema que temos de fazer isso rapidamente, pois o mercado tem se acelerado, em todas as reas de aplicao.
Recostei-me e, com minhas mos por trs da cabea, disse: Voc sabe o que falam por a:
voc pode ter algo rpido, voc pode ter algo correto ou voc pode ter algo barato. Escolha
dois!.
Eu fico com rpido e correto, disse, levantando-se.
Tambm me levantei, concluindo: Ento, ns realmente precisamos de engenharia de software.
Sei disso, afirmou, enquanto se afastava. O problema : temos de convencer ainda outra
gerao de techies* de que isso verdadeiro!.

Ideias e descobertas tecnolgicas so


as foras propulsoras do crescimento
econmico.
The Wall Street
Journal

O software est realmente morto? Se estivesse, voc no estaria lendo este livro!
Software de computadores continua a ser a tecnologia nica mais importante no cenrio mundial. E tambm um timo exemplo da lei das consequncias no intencionais. H
cinquenta anos, ningum poderia prever que o software iria se tornar uma tecnologia indispensvel para negcios, cincia e engenharia; que software iria viabilizar a criao de novas
tecnologias (por exemplo, engenharia gentica e nanotecnologia), a extenso de tecnologias
existentes (por exemplo, telecomunicaes) e a mudana radical nas tecnologias mais antigas
(por exemplo, indstria grfica); que software se tornaria a fora motriz por trs da revoluo do computador pessoal; que produtos de pacotes de software seriam comprados pelos
consumidores em lojas de bairro; que software evoluiria lentamente de produto para servio,
na medida que empresas de software sob encomenda oferecessem funcionalidade imediata
(just-in-time), via um navegador Web; que uma companhia de software iria se tornar a maior e
mais influente do que quase todas as companhias da era industrial; que uma vasta rede comandada por software, denominada Internet, iria evoluir e modificar tudo: de pesquisa em bibliotecas a compras feitas pelos consumidores, incluindo discurso poltico, hbitos de namoros de
jovens e de adultos no to jovens.
Ningum poderia prever que o software seria incorporado em sistemas de todas as reas:
transportes, medicina, telecomunicaes, militar, industrial, entretenimento, mquinas de escritrio... A lista quase infindvel. E se voc acredita na lei das consequncias no intencionais,
h muitos efeitos que ainda no somos capazes de prever.
Ningum poderia prever que milhes de programas de computador teriam de ser corrigidos,
adaptados e ampliados medida que o tempo passasse. A realizao dessas atividades de manuteno absorve mais pessoas e recursos do que todo o esforo aplicado na criao de um
novo software.
Conforme aumenta a importncia do software, a comunidade da rea tenta desenvolver tecnologias que tornem mais fcil, mais rpido e mais barato desenvolver e manter programas de
computador de alta qualidade. Algumas dessas tecnologias so direcionadas a um campo de
aplicao especfico (por exemplo, projeto e implementao de sites); outras so focadas em um
campo de tecnologia (por exemplo, sistemas orientados a objetos ou programao orientada
a aspectos); e ainda outras so de bases amplas (por exemplo, sistemas operacionais como o
*

N. de R.T.: fanticos por tecnologia.

captulo 1 software e ENGENHARIA DE SOFTWARE

31

Linux). Entretanto, ns ainda temos de desenvolver uma tecnologia de software que faa tudo
isso, sendo que a probabilidade de surgir tal tecnologia no futuro pequena. Ainda assim, as
pessoas apostam seus empregos, seu conforto, sua segurana, seu entretenimento, suas decises e suas prprias vidas em software. Tomara que estejam certas.
Este livro apresenta uma estrutura que pode ser utilizada por aqueles que desenvolvem
software pessoas que devem faz-lo corretamente. A estrutura abrange um processo, um
conjunto de mtodos e uma gama de ferramentas que chamaremos de engenharia de software.

1 .1

Software tanto um
produto como um
veculo que distribui
um produto.

Software um
lugar onde sonhos
so plantados e
pesadelos so colhidos, um pntano
abstrato e mstico
onde demnios terrveis competem com
mgicas panaceias,
um mundo de
lobisomens e balas
de prata.
Brad J. Cox

A N at u r e z a

do

S o f t wa r e

Hoje, o software assume um duplo papel. Ele um produto e, ao mesmo tempo, o veculo para distribuir um produto. Como produto, fornece o potencial computacional representado pelo hardware ou, de forma mais abrangente, por uma rede de computadores que podem ser
acessados por hardware local. Independentemente de residir em um celular ou operar dentro
de um mainframe, software um transformador de informaes produzindo, gerenciando,
adquirindo, modificando, exibindo ou transmitindo informaes que podem ser to simples
quanto um nico bit ou to complexas quanto uma apresentao multimdia derivada de dados obtidos de dezenas de fontes independentes. Como veculo de distribuio do produto, o
software atua como a base para o controle do computador (sistemas operacionais), a comunicao de informaes (redes) e a criao e o controle de outros programas (ferramentas de
software e ambientes).
O software distribui o produto mais importante de nossa era a informao. Ele transforma
dados pessoais (por exemplo, transaes financeiras de um indivduo) de modo que possam ser
mais teis num determinado contexto; gerencia informaes comerciais para aumentar a competitividade; fornece um portal para redes mundiais de informao (Internet) e os meios para
obter informaes sob todas as suas formas.
O papel desempenhado pelo software tem passado por grandes mudanas ao longo dos ltimos cinquenta anos. Aperfeioamentos significativos no desempenho do hardware, mudanas
profundas nas arquiteturas computacionais, vasto aumento na capacidade de memria e armazenamento, e uma ampla variedade de exticas opes de entrada e sada, tudo isso resultou em
sistemas computacionais mais sofisticados e complexos. Sofisticao e complexidade podem
produzir resultados impressionantes quando um sistema bem-sucedido, porm, tambm podem trazer enormes problemas para aqueles que precisam desenvolver sistemas robustos.
Atualmente, uma enorme indstria de software tornou-se fator dominante nas economias
do mundo industrializado. Equipes de especialistas em software, cada qual concentrando-se
numa parte da tecnologia necessria para distribuir uma aplicao complexa, substituram o
programador solitrio de antigamente. Ainda assim, as questes levantadas por esse programador solitrio continuam as mesmas feitas hoje, quando os modernos sistemas computacionais
so desenvolvidos:1
Por que concluir um software leva tanto tempo?
Por que os custos de desenvolvimento so to altos?
Por que no conseguimos encontrar todos os erros antes de entregarmos o software aos
clientes?
Por que gastamos tanto tempo e esforo mantendo programas existentes?
Por que continuamos a ter dificuldade em medir o progresso enquanto o software est
sendo desenvolvido e mantido?

Em um excelente livro de ensaio sobre o setor de software, Tom DeMarco [DeM95] contesta. Ele afirma: Em vez de perguntar
por que software custa tanto, precisamos comear perguntando: O que fizemos para tornar possvel que o software atual
custe to pouco? A resposta a essa pergunta nos ajudar a continuarmos com o extraordinrio nvel de realizao que sempre
tem distinguido a indstria de software.

32

captulo 1 software e ENGENHARIA DE SOFTWARE

Figura 1.1

Taxa de defeitos*

Curva de
defeitos para
hardware
Mortalidade
infantil

Desgaste

Tempo

Essas e muitas outras questes demonstram a preocupao com o software e a maneira como
desenvolvido uma preocupao que tem levado adoo da prtica da engenharia de software.

1.1.1Definindo software
Hoje em dia, a maior parte dos profissionais e muitos outros indivduos do pblico em geral
acham que entendem de software. Mas entendem mesmo?
Uma descrio de software em um livro-texto poderia ser a seguinte:

? Como
devemos

Software consiste em: (1) instrues (programas de computador) que, quando executadas, fornecem
caractersticas, funes e desempenho desejados; (2) estruturas de dados que possibilitam aos programas manipular informaes adequadamente; e (3) informao descritiva, tanto na forma impressa
como na virtual, descrevendo a operao e o uso dos programas.

definir software?

Sem dvida, poderamos dar outras definies mais completas.


Mas, provavelmente, uma definio mais formal no melhoraria, de forma considervel, a
compreenso do que software. Para conseguir isso, importante examinar as caractersticas
do software que o tornam diverso de outras coisas que os seres humanos constroem. Software
mais um elemento de sistema lgico do que fsico. Dessa forma, tem caractersticas que so
consideravelmente diferentes daquelas do hardware:

Software um processo de engenharia,


no fabricao.

1. Software desenvolvido ou passa por um processo de engenharia; ele no fabricado no sentido clssico.
Embora existam algumas similaridades entre o desenvolvimento de software e a fabricao de
hardware, as duas atividades so fundamentalmente diferentes. Em ambas, alta qualidade
obtida por meio de bom projeto, entretanto, a fase de fabricao de hardware pode gerar problemas de qualidade inexistentes (ou facilmente corrigveis) para software. Ambas as atividades so dependentes de pessoas, mas a relao entre pessoas envolvidas e trabalho realizado
completamente diferente (ver Captulo 24). Ambas requerem a construo de um produto,
entretanto, as abordagens so diferentes. Os custos de software concentram-se no processo
de engenharia. Isso significa que projetos de software no podem ser geridos como se fossem
projetos de fabricao.
*

N. de R.T.: os defeitos do software nem sempre se manifestam como falha, geralmente devido a tratamentos dos erros decorrentes destes defeitos pelo software. Esses conceitos sero precisamente mais detalhados e diferenciados nos captulos sobre
qualidade. Neste ponto, optou-se por traduzir failure rate por taxa de defeitos, sem prejuzo para a assimilao dos conceitos
apresentados pelo autor neste captulo.

33

captulo 1 software e ENGENHARIA DE SOFTWARE

Figura 1.2
Curvas de defeitos
para software

Mudana
Curva real

Curva idealizada
Tempo

2. Software no se desgasta.
A Figura 1.1 representa a taxa de defeitos em funo do tempo para hardware. Essa relao,
normalmente denominada curva da banheira, indica que o hardware apresenta taxas de
defeitos relativamente altas no incio de sua vida (geralmente, atribudas a defeitos de projeto ou de fabricao); os defeitos so corrigidos e a taxa cai para um nvel estvel (felizmente,
bastante baixo) por certo perodo. Entretanto, medida que o tempo passa, a taxa aumenta
novamente, conforme os componentes de hardware sofrem os efeitos cumulativos de poeira,
vibrao, impactos, temperaturas extremas e vrios outros males ambientais. Resumindo, o
hardware comea a desgastar-se.

Software no se
desgasta, mas ele se
deteriora.

Software no suscetvel aos males ambientais que fazem com que o hardware se desgaste.
Portanto, teoricamente, a curva da taxa de defeitos para software deveria assumir a forma
da curva idealizada, mostrada na Figura 1.2. Defeitos ainda no descobertos iro resultar
em altas taxas logo no incio da vida de um programa. Entretanto, esses sero corrigidos e
a curva se achata como mostrado. A curva idealizada uma simplificao grosseira de modelos de defeitos reais para software. Porm, a implicao clara: software no se desgasta,
mas sim se deteriora!

AVISO
Caso queira reduzir
a deteriorao do
software, ter de fazer
um projeto melhor de
software (Captulos 8
a 13).

Essa aparente contradio pode ser elucidada pela curva real apresentada na Figura 1.2.
Durante sua vida2, o software passar por alteraes. medida que estas ocorram, provvel
que sejam introduzidos erros, fazendo com que a curva de taxa de defeitos se acentue, conforme mostrado na curva real (Figura 1.2). Antes que a curva possa retornar taxa estvel
original, outra alterao requisitada, fazendo com que a curva se acentue novamente. Lentamente, o nvel mnimo da taxa comea a aumentar o software est deteriorando devido
modificao.

Os mtodos de engenharia de software


tentam reduzir ao
mximo a magnitude
das elevaes (picos)
e a inclinao da
curva real da Figura
1.2.

Outro aspecto de desgaste ilustra a diferena entre hardware e software. Quando um componente de hardware se desgasta, ele substitudo por uma pea de reposio. No existem
peas de reposio de software. Cada defeito de software indica um erro no projeto ou no
processo pelo qual o projeto foi traduzido em cdigo de mquina executvel. Portanto, as
tarefas de manuteno de software, que envolvem solicitaes de mudanas, implicam em
complexidade consideravelmente maior do que a de manuteno de hardware.

De fato, desde o momento em que o desenvolvimento comea, e muito antes da primeira verso ser entregue, podem ser
solicitadas mudanas por uma variedade de diferentes interessados.

34

Ideias so a
matria-prima
para construo de
ideias.

captulo 1 software e ENGENHARIA DE SOFTWARE

3. Embora a indstria caminhe para a construo com base em componentes, a maioria dos
softwares continua a ser construda de forma personalizada (sob encomenda).
medida que a disciplina da engenharia evolui, uma coleo de componentes de projeto
padronizados criada. Parafusos padronizados e circuitos integrados de linha so apenas
dois dos milhares de componentes padronizados utilizados por engenheiros mecnicos e eltricos ao projetarem novos sistemas. Os componentes reutilizveis foram criados para que o
engenheiro possa se concentrar nos elementos realmente inovadores de um projeto, isto ,
nas partes do projeto que representam algo novo. No mundo do hardware, a reutilizao de
componentes uma parte natural do processo de engenharia. No mundo do software, algo
que, em larga escala, apenas comeou a ser alcanado.

Jason Zebehazy

Um componente de software deve ser projetado e implementado de modo que possa ser
reutilizado em muitos programas diferentes. Os modernos componentes reutilizveis encapsulam tanto dados quanto o processamento aplicado a eles, possibilitando criar novas
aplicaes a partir de partes reutilizveis.3 Por exemplo, as atuais interfaces interativas com
o usurio so construdas com componentes reutilizveis que possibilitam criar janelas grficas, menus pull-down (suspensos e retrteis) e uma ampla variedade de mecanismos de
interao. Estruturas de dados e detalhes de processamento necessrios para a construo
da interface ficam em uma biblioteca de componentes reutilizveis para a construo de
interfaces.

1.1.2Campos de aplicao de software


Hoje em dia, sete grandes categorias de software apresentam desafios contnuos para os engenheiros de software:
Software de sistema conjunto de programas feito para atender a outros programas.
Certos softwares de sistema (por exemplo, compiladores, editores e utilitrios para gerenciamento de arquivos) processam estruturas de informao complexas, porm, determinadas.4
Outras aplicaes de sistema (por exemplo, componentes de sistema operacional, drivers,
software de rede, processadores de telecomunicaes) processam dados amplamente indeterminados. Em ambos os casos, a rea de software de sistemas caracterizada por pesada interao com o hardware do computador; uso intenso por mltiplos usurios; operao
concorrente que requer escala da ordem, compartilhamento de recursos e gesto de processo sofisticada; estruturas de dados complexas e mltiplas interfaces externas.
Software de aplicao programas sob medida que solucionam uma necessidade especfica de negcio. Aplicaes nessa rea processam dados comerciais ou tcnicos de uma
forma que facilite operaes comerciais ou tomadas de deciso administrativas/tcnicas.
Alm das aplicaes convencionais de processamento de dados, o software de aplicao
usado para controlar funes de negcio em tempo real (por exemplo, processamento de
transaes em pontos de venda, controle de processos de fabricao em tempo real).

WebRef
Uma das mais
abrangentes bibliotecas
de shareware/
freeware (software
compartilhado/livre)
pode ser encontrada
em shareware.
cnet.com

Software cientfico/de engenharia tem sido caracterizado por algoritmos number crunching
(para processamento numrico pesado). As aplicaes vo da astronomia vulcanologia, da
anlise de tenses na indstria automotiva dinmica orbital de nibus espaciais, e da biologia molecular fabricao automatizada. Entretanto, aplicaes modernas dentro da rea
de engenharia/cientfica esto se afastando dos algoritmos numricos convencionais. Projeto
com o auxlio de computador, simulao de sistemas e outras aplicaes interativas comearam a ter caractersticas de sistemas em tempo real e at mesmo de software de sistemas.

3
4

O desenvolvimento com base em componentes discutido no Captulo 10.


Um software determinado se a ordem e o timing (periodicidade, frequncia, medidas de tempo) de entradas, processamento
e sadas forem previsveis. indeterminado, se ordem e timing de entradas, processamento e sadas no puderem ser previstos antecipadamente.

captulo 1 software e ENGENHARIA DE SOFTWARE

35

Software embutido residente num produto ou sistema e utilizado para implementar e


controlar caractersticas e funes para o usurio final e para o prprio sistema. Executa funes limitadas e especficas (por exemplo, controle do painel de um forno micro-ondas) ou
fornece funo significativa e capacidade de controle (por exemplo, funes digitais de automveis, tal como controle do nvel de combustvel, painis de controle e sistemas de freios).
Software para linha de produtos projetado para prover capacidade especfica de utilizao por muitos clientes diferentes. Pode focalizar um mercado limitado e particularizado (por
exemplo, produtos para controle de estoques) ou direcionar-se para mercados de consumo de
massa (por exemplo, processamento de texto, planilhas eletrnicas, computao grfica, multimdia, entretenimento, gerenciamento de bancos de dados e aplicaes financeiras pessoais
e comerciais).
Aplicaes para a Web chamadas de WebApps, essa categoria de software centralizada em redes abarca uma vasta gama de aplicaes. Em sua forma mais simples, as WebApps
podem ser pouco mais que um conjunto de arquivos de hipertexto interconectados, apresentando informaes por meio de texto e informaes grficas limitadas. Entretanto, com
o aparecimento da Web 2.0, elas tm evoludo e se transformado em sofisticados ambientes
computacionais que no apenas fornecem recursos especializados, funes computacionais
e contedo para o usurio final, como tambm esto integradas a bancos de dados corporativos e aplicaes comerciais.
No existe
computador que
tenha bom senso.
Marvin Minsky

Software de inteligncia artificial faz uso de algoritmos no numricos para solucionar problemas complexos que no so passveis de computao ou de anlise direta.
Aplicaes nessa rea incluem: robtica, sistemas especialistas, reconhecimento de padres
(de imagem e de voz), redes neurais artificiais, prova de teoremas e jogos.
Milhes de engenheiros de software em todo o mundo trabalham arduamente em projetos
de software em uma ou mais dessas categorias. Em alguns casos, novos sistemas esto sendo
construdos, mas em muitos outros, aplicaes j existentes esto sendo corrigidas, adaptadas e
aperfeioadas. No incomum para um jovem engenheiro de software trabalhar num programa
mais velho que ele! Geraes passadas de pessoal de software deixaram um legado em cada
uma das categorias discutidas. Espera-se que o legado a ser deixado por essa gerao facilite
o trabalho de futuros engenheiros de software. Ainda assim, novos desafios (Captulo 31) tm
surgido no horizonte:
Computao mundial aberta o rpido crescimento de redes sem fio pode, em breve,
conduzir a uma verdadeira computao distribuda e pervasiva (ampliada, compartilhada
e incorporada nos ambientes domsticos e comerciais). O desafio para os engenheiros de
software ser o de desenvolver sistemas e software aplicativo que permitam que dispositivos mveis, computadores pessoais e sistemas corporativos se comuniquem atravs de
extensas redes.
Netsoursing (recursos via Internet) a Internet est se tornando, rapidamente, tanto
um mecanismo computacional, como um provedor de contedo. O desafio para os engenheiros de software consiste em arquitetar aplicaes simples (isto , planejamento financeiro pessoal) e sofisticadas que forneam benefcios aos mercados mundiais de usurios
finais visados.
Software aberto uma tendncia crescente que resulta na distribuio de cdigo-fonte
para aplicaes de sistemas (por exemplo, sistemas operacionais, bancos de dados e ambientes de desenvolvimento), de forma que muitas pessoas possam contribuir para seu desenvolvimento. O desafio para os engenheiros de software consiste em construir um cdigo-fonte
autodescritivo, porm, mais importante ainda, ser desenvolver tcnicas que permitam que
tanto clientes quanto desenvolvedores saibam quais alteraes foram feitas e como se manifestam dentro do software.

36

Voc no pode
sempre prever,
mas pode sempre
se preparar.
Annimo

captulo 1 software e ENGENHARIA DE SOFTWARE

Cada um desses desafios obedecer, sem dvida, lei das consequncias no intencionais,
produzindo efeitos (para executivos, engenheiros de software e usurios finais) que, hoje, no
podem ser previstos. Entretanto, os engenheiros de software podem se preparar, iniciando um
processo que seja gil e suficientemente adaptvel para assimilar as profundas mudanas na
tecnologia e nas regras comerciais, que certamente viro na prxima dcada.

1.1.3 Software legado


Centenas de milhares de programas de computador caem em um dos sete amplos campos
de aplicao discutidos na subseo anterior. Alguns deles so software de ponta recm-lanados para indivduos, indstria e governo. Outros programas so mais antigos, em alguns
casos muito mais antigos.
Esses programas mais antigos frequentemente denominados software legado tm
sido foco de contnua ateno e preocupao desde os anos 1960. Dayani-Fard e seus colegas
[Day99] descrevem software legado da seguinte maneira:
Sistemas de software legado... Foram desenvolvidos dcadas atrs e tm sido continuamente modificados para se adequar a mudanas dos requisitos de negcio e a plataformas computacionais. A proliferao de tais sistemas est causando dores de cabea para grandes organizaes que os consideram
dispendiosos de manter e arriscados de evoluir.

fao
? Ocasoqueencontre

um sistema
legado de baixa
qualidade?

Liu e seus colegas [Liu98] ampliam essa descrio observando que muitos sistemas
legados permanecem dando suporte para funes de negcio vitais e so indispensveis
para o mesmo. Por isso, um software legado caracterizado pela longevidade e criticidade
de negcios.
Infelizmente, algumas vezes, h uma caracterstica adicional que pode estar presente em
um software legado: baixa qualidade.5 Os sistemas legados, algumas vezes, tm projetos no
expansveis, cdigo intrincado, documentao pobre ou inexistente, casos de testes e resultados
que nunca foram arquivados, um histrico de modificaes mal administrado a lista pode
ser bem longa. Ainda assim, esses sistemas do suporte a funes vitais de negcio e so
indispensveis para ele. O que fazer ento?
A nica resposta razovel talvez seja: No faa nada, pelo menos at que o sistema legado
tenha que passar por alguma modificao significativa. Se o software legado atende s necessidades de seus usurios e roda de forma confivel, ele no est quebrado e no precisa ser
consertado. Entretanto, com o passar do tempo, esses sistemas, frequentemente, evoluem por
uma ou mais das seguintes razes:

tipos de
? Que
mudanas

O software deve ser adaptado para atender s necessidades de novos ambientes ou de


novas tecnologias computacionais.

so feitas em
sistemas legados?

O software deve ser aperfeioado para implementar novos requisitos de negcio.


O software deve ser expandido para torn-lo interopervel com outros bancos de dados
ou com sistemas mais modernos.
O software deve ser rearquitetado para torn-lo vivel dentro de um ambiente de rede.

AVISO
Todo engenheiro de
software deve reconhecer que modificaes
so naturais. No tente
combat-las.

Quando essas modalidades de evoluo ocorrerem, um sistema legado deve passar por reengenharia (Captulo 29) para que permanea vivel no futuro. O objetivo da engenharia de software moderna o de elaborar metodologias baseadas na noo de evoluo; isto , na noo
de que os sistemas de software modificam-se continuamente, novos sistemas so construdos a
partir dos antigos e... Todos devem interoperar e cooperar um com o outro [Day99].

Nesse caso, a qualidade julgada pensando-se em termos de engenharia de software moderna um critrio um tanto injusto, j que alguns conceitos e princpios da engenharia de software moderna talvez no tenham sido bem entendidos na poca
em que o software legado foi desenvolvido.

captulo 1 software e ENGENHARIA DE SOFTWARE

1.2
Quando notarmos
qualquer tipo de
estabilidade, a
Web ter se transformado em algo
completamente
diferente.
Louis Monier

A N at u r e z a n i c a

da s

37

W e b a pp s

Nos primrdios da World Wide Web (por volta de 1990 a 1995), os sites eram formados por
nada mais que um conjunto de arquivos de hipertexto lincados que apresentavam informaes
usando texto e grficos limitados. Com o tempo, o aumento da HTML, via ferramentas de desenvolvimento (por exemplo, XML, Java), tornou possvel aos engenheiros da Internet oferecerem capacidade computacional juntamentecom as informaes. Nasciam, ento, os sistemas e
aplicaes baseados na Web6 (refiro-me a eles coletivamente como aplicaes WebApps). Atualmente, as WebApps evoluram para sofisticadas ferramentas computacionais que no apenas
oferecem funes especializadas (stand-alone functions) ao usurio final, como tambm foram
integradas aos bancos de dados corporativos e s aplicaes de negcio.
Conforme observado na Seo 1.1.2, WebApps so apenas uma dentre uma srie de diferentes categorias de software. Ainda assim, pode-se afirmar que elas so diferentes. Powell [Pow98]
sugere que sistemas e aplicaes baseados na Web envolvem uma mistura de publicao impressa e desenvolvimento de software, de marketing e computao, de comunicaes internas
e relaes externas e de arte e tecnologia. Os seguintes atributos so encontrados na grande
maioria das WebApps:
Uso intensivo de redes. Uma WebApp reside em uma rede e deve atender s necessidades de uma comunidade diversificada de clientes. A rede possibilita acesso e comunicao
mundiais (isto , a Internet) ou acesso e comunicao mais limitados (por exemplo, uma
Intranet corporativa).
Simultaneidade. Um grande nmero de usurios pode acessar a WebApp ao mesmo tempo. Em muitos casos, os padres de utilizao entre os usurios finais variam amplamente.
Carga no previsvel. O nmero de usurios da WebApp pode variar, em ordem de grandeza, de um dia para outro. Uma centena de usurios pode conectar-se na segunda-feira e
10.000 na quinta.
Desempenho. Se um usurio de uma WebApp tiver de esperar muito (para acesso, processamento no servidor, formatao e exibio no cliente), talvez ele procure outra opo.
Disponibilidade. Embora a expectativa de 100% de disponibilidade no seja razovel,
usurios de WebApps populares normalmente exigem acesso 24 horas por dia, 7 dias por
semana, 365 dias por ano. Usurios na Austrlia ou sia podem requerer acesso quando
aplicaes de software domsticas tradicionais na Amrica do Norte estejam off-line para
manuteno.
Orientadas a dados. A funo principal de muitas WebApps usar hipermdias para
apresentar texto, grficos, udio e vdeo para o usurio final. Alm disso, as WebApps so
comumente utilizadas para acessar informaes em bancos de dados que no so parte
integrante do ambiente baseado na Web (por exemplo, comrcio eletrnico e/ou aplicaes
financeiras).
Sensibilidade no contedo. A qualidade e a natureza esttica do contedo so fatores
importantes que determinam a qualidade de uma WebApp.
Evoluo contnua. Diferentemente de softwares de aplicao convencionais que evoluem ao longo de uma srie de verses planejadas e cronologicamente espaadas, as WebApps evoluem continuamente. No incomum algumas delas (especificamente seu contedo)
serem atualizadas segundo uma escala minuto a minuto ou seu contedo ser computado
independentemente para cada solicitao.

carac
? Que
tersticas

diferenciam as
WebApps de
outros softwares?

No contexto deste livro, o termo aplicao Web (WebApp) engloba tudo, de uma simples pgina Web que possa ajudar um
consumidor a processar o pagamento do aluguel de um automvel a um amplo site que fornece servios de viagem completos para executivos e turistas. Dentro dessa categoria, esto sites completos, funcionalidade especializada dentro de sites e
aplicaes para processamento de informaes residentes na Internet ou em uma Intranet ou Extranet.

38

captulo 1 software e ENGENHARIA DE SOFTWARE

Imediatismo. Embora imediatismo a imperativa necessidade de colocar rapidamente


um software no mercado seja uma caracterstica de diversos campos de aplicao, as
WebApps normalmente apresentam um tempo de colocao no mercado que pode consistir
de poucos dias ou semanas.7
Segurana. Pelo fato de estarem disponveis via acesso Internet, torna-se difcil, se no
impossvel, limitar o nmero dos usurios finais que podem acessar as WebApps. A fim de
proteger contedos sensveis e oferecer modos seguros de transmisso de dados, fortes medidas de segurana devem ser implementadas ao longo da infraestrutura que suporta uma
WebApp e dentro da prpria aplicao.
Esttica. Parte inegvel do apelo de uma WebApp consiste na sua aparncia e na impresso
que desperta. Quando uma aplicao for desenvolvida para o mercado ou para vender produtos ou ideias, a esttica pode ser to importante para o sucesso quanto o projeto tcnico.
Pode-se argumentar que outras categorias de aplicao discutidas na Seo 1.1.2 podem exibir alguns dos atributos citados. Entretanto, as WebApps quase sempre apresentam todos esses
atributos.

1.3

Engenharia

de

S o f t wa r e

Para desenvolver software que esteja preparado para enfrentar os desafios do sculo vinte e
um, devemos perceber uns poucos fatos reais:
Software tornou-se profundamente incorporado em praticamente todos os aspectos de
nossas vidas e, consequentemente, o nmero de pessoas interessadas nos recursos e
nas funes oferecidas por uma determinada aplicao8 tem crescido significativamente.
Quando uma aplicao ou um sistema embutido esto para ser desenvolvidos, muitas
vozes devem ser ouvidas. E, algumas vezes, parece que cada uma delas possui uma ideia
ligeiramente diferente de quais funes ou recursos o software deve oferecer. Depreende-se, portanto, que se deve fazer um esforo concentrado para compreender o problema
antes de desenvolver uma soluo de software.

Entenda o problema
antes de elaborar
uma soluo.

Os requisitos de tecnologia de informao demandados por indivduos, empresas e rgos


governamentais esto se tornando cada vez mais complexos a cada ano. Atualmente, equipes numericamente grandes desenvolvem programas de computador que antigamente eram
desenvolvidos por um nico indivduo. Software sofisticado, outrora implementado em um
ambiente computacional independente e previsvel, hoje em dia est incorporado em tudo,
de produtos eletrnicos de consumo a equipamentos mdicos e sistemas de armamentos. A
complexidade desses novos produtos e sistemas baseados em computadores demanda uma
maior ateno para com as interaes de todos os elementos do sistema. Depreende-se,
portanto, que projetar tornou-se uma atividade-chave (fundamental).

Projetar uma
atividade fundamental
na engenharia de
software.

Indivduos, negcios e governos dependem, de forma crescente, de software para decises estratgicas e tticas, assim como para controle e para operaes cotidianas. Se
o software falhar, as pessoas e as principais empresas podero vivenciar desde pequenos inconvenientes a falhas catastrficas. Depreende-se, portanto, que um software deve
apresentar qualidade elevada.

Qualidade e facilidade
de manuteno so
resultantes de um
projeto bem feito.

medida que o valor de uma aplicao especfica aumente, a probabilidade de que sua
base de usurios e longevidade tambm cresam. medida que sua base de usurios e seu
tempo em uso forem aumentando, a demanda por adaptao e aperfeioamento tambm
ir aumentar. Conclui-se, portanto, que um software deve ser passvel de manuteno.
7
8

Com o uso de ferramentas modernas, sofisticadas, pginas de sites podem ser produzidas em apenas algumas horas.
Neste livro, mais frente, chamarei tais pessoas de interessados.

captulo 1 software e ENGENHARIA DE SOFTWARE

39

Figura 1.3
Camadas da
engenharia
de software

Mais do que
uma simples
disciplina ou ramo
do conhecimento,
engineering um
verbo [engenhar,
engendrar], uma
palavra de ao,
uma maneira
de abordar um
problema.
Scott Whitmir

Essas simples constataes nos conduzem a uma nica concluso: software, em todas as
suas formas e em todos os seus campos de aplicao, deve passar pelos processos de engenharia.
E isso nos leva ao tpico principal deste livro engenharia de software.
Embora centenas de autores tenham criado suas definies pessoais de engenharia de software, uma definio proposta por Fritz Bauer [Nau69] na conferncia sobre o tema serve de base
para discusso:
[Engenharia de software ] o estabelecimento e o emprego de slidos princpios de engenharia de modo
a obter software de maneira econmica, que seja confivel e funcione de forma eficiente em mquinas
reais.

Ficamos tentados a acrescentar algo a essa definio.9 Ela diz pouco sobre os aspectos tcnicos da qualidade de software; ela no trata diretamente da necessidade de satisfao do cliente
ou da entrega do produto dentro do prazo; ela no faz meno importncia das medies e
mtricas; ela no declara a importncia de um processo eficaz. Ainda assim, a definio de Bauer
nos fornece uma base. Quais so os slidos princpios de engenharia que podem ser aplicados ao desenvolvimento de software? Como criar software economicamente vivel e de modo
confivel? O que necessrio para desenvolver programas de computador que funcionem de
forma eficiente no apenas em uma, mas sim em vrias e diferentes mquinas reais? Essas
so as questes que continuam a desafiar os engenheiros de software.
A IEEE [IEE93a] desenvolveu uma definio mais abrangente ao afirmar o seguinte:

? Como
definimos

Engenharia de software: (1) A aplicao de uma abordagem sistemtica, disciplinada e quantificvel no


desenvolvimento, na operao e na manuteno de software; isto , a aplicao de engenharia ao software. (2) O estudo de abordagens como definido em (1).

engenharia de
software?

A engenharia de
software engloba um
processo, mtodos
de gerenciamento e
desenvolvimento de
software, bem como
ferramentas.

Entretanto, uma abordagem sistemtica, disciplinada e quantificvel, aplicada por uma


equipe de desenvolvimento de software, pode ser pesada para outra. Precisamos de disciplina,
mas tambm precisamos de adaptabilidade e agilidade.
A engenharia de software uma tecnologia em camadas. Referindo-se Figura 1.3, qualquer
abordagem de engenharia (inclusive engenharia de software) deve estar fundamentada em um
comprometimento organizacional com a qualidade. A gesto da qualidade total Seis Sigma e
filosofias similares10 promovem uma cultura de aperfeioamento contnuo de processos, e esta
cultura que, no final das contas, leva ao desenvolvimento de abordagens cada vez mais efetivas
na engenharia de software. A pedra fundamental que sustenta a engenharia de software o foco
na qualidade.
A base para a engenharia de software a camada de processos. O processo de engenharia de
software a liga que mantm as camadas de tecnologia coesas e possibilita o desenvolvimento
de software de forma racional e dentro do prazo. O processo define uma metodologia que deve
ser estabelecida para a entrega efetiva de tecnologia de engenharia de software. O processo de
9

Para inmeras definies adicionais de engenharia de software, consulte: www.answers.com/topic/software-engineering#wp-_


note-13.
10 A gesto da qualidade e metodologias relacionadas so discutidas no Captulo 14 e ao longo da Parte 3 deste livro.

40

captulo 1 software e ENGENHARIA DE SOFTWARE

WebRef

CrossTalk um
jornal que divulga
informaes prticas
a respeito de
processo, mtodos
e ferramentas. Pode
ser encontrado no
endereo: www.
stsc.hill.af.mil.

1.4
so os
? Quais
elementos

de um processo de
software?

Um processo
define quem est
fazendo o qu,
quando e como
para atingir
determinado
objetivo.
Ivar Jacobson,
Grady Booch
e James
Rumbaugh

so
? Quais
as cinco

atividades
genricas de
metodologia de
processo?

software constitui a base para o controle do gerenciamento de projetos de software e estabelece


o contexto no qual so aplicados mtodos tcnicos, so produzidos produtos derivados (modelos, documentos, dados, relatrios, formulrios etc.), so estabelecidos marcos, a qualidade
garantida e mudanas so geridas de forma apropriada.
Os mtodos da engenharia de software fornecem as informaes tcnicas para desenvolver
software. Os mtodos envolvem uma ampla gama de tarefas, que incluem: comunicao, anlise
de requisitos, modelagem de projeto, construo de programa, testes e suporte.
Os mtodos da engenharia de software baseiam-se em um conjunto de princpios bsicos
que governam cada rea da tecnologia e inclui atividades de modelagem e outras tcnicas descritivas.
As ferramentas da engenharia de software fornecem suporte automatizado ou semiautomatizado para o processo e para os mtodos. Quando as ferramentas so integradas, de modo que
as informaes criadas por uma ferramenta possam ser usadas por outra, estabelecido um
sistema para o suporte ao desenvolvimento de software, denominado engenharia de software
com o auxlio do computador.

O Processo

de

S o f t wa r e

Processo um conjunto de atividades, aes e tarefas realizadas na criao de algum produto de trabalho (work product). Uma atividade esfora-se para atingir um objetivo amplo (por
exemplo, comunicar-se com os interessados) e utilizada independentemente do campo de
aplicao, do tamanho do projeto, da complexidade de esforos ou do grau de rigor com que a
engenharia de software ser aplicada. Uma ao (por exemplo, projeto de arquitetura) envolve
um conjunto de tarefas que resultam num artefato de software fundamental (por exemplo, um
modelo de projeto de arquitetura). Uma tarefa se concentra em um objetivo pequeno, porm,
bem definido (por exemplo, realizar um teste de unidades) e produz um resultado tangvel.
No contexto da engenharia de software, um processo no uma prescrio rgida de como
desenvolver um software. Ao contrrio, uma abordagem adaptvel que possibilita s pessoas
(a equipe de software) realizar o trabalho de selecionar e escolher o conjunto apropriado de
aes e tarefas. A inteno a de sempre entregar software dentro do prazo e com qualidade
suficiente para satisfazer queles que patrocinaram sua criao e queles que iro utiliz-lo.
Uma metodologia (framework) de processo estabelece o alicerce para um processo de engenharia
de software completo, por meio da identificao de um pequeno nmero de atividades estruturais
aplicveis a todos os projetos de software, independentemente de tamanho ou complexidade. Alm
disso, a metodologia de processo engloba um conjunto de atividades de apoio (umbrella activities
abertas) aplicveis em todo o processo de software. Uma metodologia de processo genrica para
engenharia de software compreende cinco atividades:
Comunicao. Antes de iniciar qualquer trabalho tcnico, de vital importncia comunicar-se e colaborar com o cliente (e outros interessados)11. A inteno compreender os objetivos das partes interessadas para com o projeto e fazer o levantamento das necessidades
que ajudaro a definir as funes e caractersticas do software.
Planejamento. Qualquer jornada complicada pode ser simplificada caso exista um mapa.
Um projeto de software uma jornada complicada, e a atividade de planejamento cria um
mapa que ajuda a guiar a equipe na sua jornada. O mapa denominado plano de projeto de
software define o trabalho de engenharia de software, descrevendo as tarefas tcnicas a ser

11 Interessado qualquer um que tenha interesse no xito de um projeto executivos, usurios finais, engenheiros de software, o
pessoal de suporte etc. Rob Thomsett ironiza: Interessado [stakeholder, em ingls] uma pessoa que est segurando [holding, em
ingls] uma estaca [stake, em ingls] grande e pontiaguda. Se voc no cuidar de seus interessados, voc sabe exatamente onde ir
parar essa estaca.

captulo 1 software e ENGENHARIA DE SOFTWARE

Einstein argumentou que devia


haver uma explicao simplificada
da natureza, pois
Deus no caprichoso ou arbitrrio.
Tal f no conforta
o engenheiro
de software.
Grande parte da
complexidade com
a qual ter de lidar
arbitrria.
Fred Brooks

Atividades de apoio
ocorrem ao longo do
processo de software
e se concentram,
principalmente, no
gerenciamento,
acompanhamento e
controle do projeto.

41

conduzidas, os riscos provveis, os recursos que sero necessrios, os produtos resultantes a


ser produzidos e um cronograma de trabalho.
Modelagem. Independentemente de ser um paisagista, um construtor de pontes, um engenheiro aeronutico, um carpinteiro ou um arquiteto, trabalha-se com modelos todos os
dias. Cria-se um esboo da coisa, de modo que se possa ter uma ideia do todo qual
ser o seu aspecto em termos de arquitetura, como as partes constituintes se encaixaro e vrias outras caractersticas. Se necessrio, refina-se o esboo com mais detalhes,
numa tentativa de compreender melhor o problema e como resolv-lo. Um engenheiro de
software faz a mesma coisa criando modelos para melhor entender as necessidades do
software e o projeto que ir atender a essas necessidades.
Construo. Essa atividade combina gerao de cdigo (manual ou automatizada) e testes necessrios para revelar erros na codificao.
Emprego. O software (como uma entidade completa ou como um incremento parcialmente efetivado) entregue ao cliente, que avalia o produto entregue e fornece feedback,
baseado na avaliao.
Essas cinco atividades metodolgicas genricas podem ser utilizadas para o desenvolvimento de programas pequenos e simples, para a criao de grandes aplicaes para a Internet e
para a engenharia de grandes e complexos sistemas baseados em computador. Os detalhes do
processo de software sero bem diferentes em cada um dos casos, mas as atividades metodolgicas permanecero as mesmas.
Para muitos projetos de software, as atividades metodolgicas so aplicadas iterativamente conforme o projeto se desenvolve. Ou seja, comunicao, planejamento, modelagem,
construo e emprego so aplicados repetidamente quantas forem as iteraes do projeto,
sendo que cada iterao produzir um incremento de software. Este disponibilizar uma parte
dos recursos e funcionalidades do software. A cada incremento, o software torna-se mais e mais
completo.
As atividades metodolgicas do processo de engenharia de software so complementadas
por uma srie de atividades de apoio; em geral, estas so aplicadas ao longo de um projeto,
ajudando a equipe a gerenciar, a controlar o progresso, a qualidade, as mudanas e o risco. As
atividades de apoio tpicas so:
Controle e acompanhamento do projeto possibilita que a equipe avalie o progresso
em relao ao plano do projeto e tome as medidas necessrias para cumprir o cronograma.
Administrao de riscos avalia riscos que possam afetar o resultado ou a qualidade
do produto/projeto.
Garantia da qualidade de software define e conduz as atividades que garantem a
qualidade do software.
Revises tcnicas avaliam artefatos da engenharia de software, tentando identificar e
eliminar erros antes que se propaguem para a atividade seguinte.
Medio define e coleta medidas (do processo, do projeto e do produto). Auxilia na entrega do software de acordo com os requisitos; pode ser usada com as demais atividades
(metodolgicas e de apoio).

A adaptao do
processo de software
essencial para
o sucesso de um
projeto.

Gerenciamento da configurao de software gerencia os efeitos das mudanas ao


longo do processo.
Gerenciamento da reusabilidade define critrios para o reso de artefatos (inclusive
componentes de software) e estabelece mecanismos para a obteno de componentes reutilizveis.

42

captulo 1 software e ENGENHARIA DE SOFTWARE

Preparo e produo de artefatos de software engloba as atividades necessrias para


criar artefatos como, por exemplo, modelos, documentos, logs, formulrios e listas.
Cada uma dessas atividades universais ser discutida de forma aprofundada mais adiante.
Anteriormente, declarei que o processo de engenharia de software no rgido nem deve ser
seguido risca. Mais que isso, ele deve ser gil e adaptvel (ao problema, ao projeto, equipe e
cultura organizacional). Portanto, o processo adotado para um determinado projeto pode ser
muito diferente daquele adotado para outro. Entre as diferenas, temos:

Como os
modelos
de processo se
diferenciam?

Sinto que uma


receita consiste em
apenas um tema
com o qual um
cozinheiro inteligente pode brincar,
cada vez, com uma
variao.
Madame Benoit

que
? Ocaracteriza

um processo
gil?

1.5
WebRef

Uma variedade de
citaes provocativas
acerca da prtica
da engenharia de
software pode ser
encontrada em
www.literate
programming.
com

fluxo geral de atividades, aes e tarefas e suas interdependncias;


grau pelo qual aes e tarefas so definidas dentro de cada atividade da metodologia;
grau pelo qual artefatos de software so identificados e exigidos;
modo de aplicar as atividades de garantia de qualidade;
modo de aplicar as atividades de acompanhamento e controle do projeto;
grau geral de detalhamento e rigor da descrio do processo;
grau de envolvimento com o projeto (por parte do cliente e de outros interessados);
nvel de autonomia dada equipe de software;
grau de prescrio da organizao da equipe.

A Parte I deste livro examina o processo de software com grau de detalhamento considervel.
Os modelos de processo prescritivo (Captulo 2) abordam detalhadamente a definio, a identificao e a aplicao de atividades e tarefas do processo. A inteno melhorar a qualidade do
sistema, tornar os projetos mais gerenciveis, tornar as datas de entrega e os custos mais previsveis e orientar as equipes de engenheiros de software conforme realizam o trabalho de desenvolvimento de um sistema. Infelizmente, por vezes, tais objetivos no so alcanados. Se os
modelos prescritivos forem aplicados de forma dogmtica e sem adaptaes, podero aumentar
a burocracia associada ao desenvolvimento de sistemas computacionais e, inadvertidamente,
criaro dificuldades para todos os envolvidos.
Os modelos geis de processo (Captulo 3) ressaltam a agilidade do projeto, seguindo princpios que conduzam a uma abordagem mais informal (porm, no menos eficiente) para o
processo de software. Tais modelos de processo geralmente so caracterizados como geis,
porque enfatizam a flexibilidade e adaptabilidade. Eles so apropriados para vrios tipos de projetos e so particularmente teis quando aplicaes para a Internet so projetadas.

A Prtica

da

Engenharia

de

S o f t wa r e

A Seo 1.4 apresentou uma introduo a um modelo de processo de software genrico composto por um conjunto de atividades que estabelecem uma metodologia para a prtica da engenharia de software. As atividades genricas da metodologia comunicao, planejamento,
modelagem, construo e emprego , bem como as atividades de apoio, estabelecem um
esquema para o trabalho da engenharia de software. Mas como a prtica da engenharia de
software se encaixa nisso? Nas sees seguintes, voc adquirir um conhecimento bsico dos
princpios e conceitos genricos que se aplicam s atividades de uma metodologia.12

1.5.1A essncia da prtica


Em um livro clssico, How to Solve It, sobre os modernos computadores, George Polya [Pol45]
apontou em linhas gerais a essncia da soluo de problemas e, consequentemente, a essncia
da prtica da engenharia de software:
1. Compreender o problema (comunicao e anlise).
2. Planejar uma soluo (modelagem e projeto de software).
12 Voc deve rever sees relevantes contidas neste captulo medida que mtodos de engenharia de software e atividades de
apoio especficas forem discutidos posteriormente neste livro.

captulo 1 software e ENGENHARIA DE SOFTWARE

AVISO
Pode-se afirmar que a
abordagem de Polya
simplesmente questo
de bom senso. verdade. Mas espantoso
quo frequentemente o
bom senso incomum
no mundo do software.

43

3. Executar o plano (gerao de cdigo).


4. Examinar o resultado para ter preciso (testes e garantia da qualidade).
No contexto da engenharia de software, essas etapas de bom senso conduzem a uma srie de
questes essenciais [adaptado de Pol45]:
Compreenda o problema. Algumas vezes difcil de admitir, porm, a maioria de ns arrogante quando nos apresentado um problema. Ouvimos por alguns segundos e ento pensamos:
Ah, sim, estou entendendo, vamos comear a resolver este problema. Infelizmente, compreender
nem sempre assim to fcil. Vale a pena despender um pouco de tempo respondendo a algumas
questes simples:
Quem tem interesse na soluo do problema? Ou seja, quem so os interessados?
Quais so as incgnitas? Que dados, funes e recursos so necessrios para resolver
apropriadamente o problema?
O problema pode ser compartimentalizado? possvel represent-lo em problemas menores que talvez sejam mais fceis de ser compreendidos?
O problema pode ser representado graficamente? possvel criar um modelo analtico?

H um gro de
descoberta na soluo de qualquer
problema.
George Polya

Planeje a soluo. Agora voc entende o problema (ou assim pensa) e no v a hora de comear a codificar. Antes de fazer isso, relaxe um pouco e faa um pequeno projeto:
Voc j viu problemas similares anteriormente? Existem padres que so reconhecveis
em uma potencial soluo? Existe algum software que implemente os dados, as funes
e caractersticas necessrias?
Algum problema similar j foi resolvido? Em caso positivo, existem elementos da soluo
que podem ser reutilizados?
possvel definir subproblemas? Em caso positivo, existem solues aparentes e imediatas para
eles?
possvel representar uma soluo de maneira que conduza a uma implementao efetiva? possvel criar um modelo de projeto?
Execute/leve adiante o plano. O projeto elaborado que criamos serve como um mapa para
o sistema que se quer construir. Podem surgir desvios inesperados e possvel que se descubra
um caminho ainda melhor medida que se prossiga, porm, o planejamento nos permitir
que continuemos sem nos perder.
A soluo se adqua ao plano? O cdigo-fonte pode ser atribudo ao modelo de projeto?
Cada uma das partes componentes da soluo est provavelmente correta? O projeto
e o cdigo foram revistos, ou, melhor ainda, provas da correo foram aplicadas ao
algoritmo?
Examine o resultado. No se pode ter certeza de que uma soluo seja perfeita, porm,
pode-se assegurar que um nmero de testes suficiente tenha sido realizado para revelar o maior
nmero de erros possvel.
possvel testar cada parte componente da soluo? Foi implementada uma estratgia de
testes razovel?
A soluo produz resultados que se adquam aos dados, s funes e caractersticas necessrios? O software foi validado em relao a todas as solicitaes dos interessados?
No surpresa que grande parte dessa metodologia consiste no bom senso. De fato, razovel afirmar que uma abordagem de bom senso engenharia de software jamais o levar ao
mau caminho.

44

AVISO
Antes de iniciar um
projeto, certifique-se
de que o software tem
um propsito para a
empresa e de que seus
usurios reconheam
seu valor.

captulo 1 software e ENGENHARIA DE SOFTWARE

1.5.2Princpios gerais
O dicionrio define a palavra princpio como uma importante afirmao ou lei subjacente
em um sistema de pensamento. Ao longo deste livro sero discutidos princpios em vrios
nveis de abstrao. Alguns se concentram na engenharia de software como um todo, outros
consideram uma atividade de metodologia genrica especfica (por exemplo, comunicao) e
outros ainda destacam as aes de engenharia de software (por exemplo, projeto de arquitetura)
ou tarefas tcnicas (por exemplo, redigir um cenrio de uso). Independentemente do seu nvel
de enfoque, os princpios ajudam a estabelecer um modo de pensar para a prtica segura da
engenharia de software esta a razo porque so importantes.
David Hooker [Hoo96] props sete princpios que se concentram na prtica da engenharia de
software como um todo. Eles so reproduzidos nos pargrafos a seguir:13
Primeiro princpio: a razo de existir

Um sistema de software existe por uma nica razo: gerar valor a seus usurios. Todas as
decises deveriam ser tomadas tendo esse princpio em mente. Antes de especificar uma necessidade de um sistema, antes de indicar alguma parte da funcionalidade de um sistema, antes
de determinar as plataformas de hardware ou os processos de desenvolvimento, pergunte a si
mesmo: Isso realmente agrega valor real ao sistema?. Se a resposta for no, no o faa. Todos os demais princpios se apoiam neste primeiro.
H uma certa
majestade na simplicidade que est
muito acima de
toda a excentricidade do saber.
Papa Alexandre
(1688-1744)

Segundo princpio: KISS (Keep It Simple, Stupid!, ou seja: Faa de forma simples, tapado!)

O projeto de software no um processo casual; h muitos fatores a ser considerados em


qualquer esforo de projeto todo projeto deve ser o mais simples possvel, mas no to simples assim. Esse princpio contribui para um sistema mais fcil de compreender e manter. Isso
no significa que caractersticas, at mesmo as internas, devam ser descartadas em nome da
simplicidade.
De fato, frequentemente os projetos mais elegantes so os mais simples, o que no significa
rpido e malfeito na realidade, simplificar exige muita anlise e trabalho durante as iteraes, sendo que o resultado ser um software de fcil manuteno e menos propenso a erros.
Terceiro princpio: mantenha a viso

Uma viso clara essencial para o sucesso. Sem ela, um projeto se torna ambguo. Sem uma
integridade conceitual, corre-se o risco de transformar o projeto numa colcha de retalhos de
projetos incompatveis, unidos por parafusos inadequados... Comprometer a viso arquitetnica
de um sistema de software debilita e at poder destruir sistemas bem projetados. Ter um arquiteto responsvel e capaz de manter a viso clara e de reforar a adequao ajuda a assegurar o
xito de um projeto.
Quarto princpio: o que um produz outros consomem

Um software de
valor mudar ao
longo de sua vida.
Por essa razo, um
software deve ser
desenvolvido para
fcil manuteno.

Raramente um sistema de software de fora industrial construdo e utilizado de forma


isolada. De uma maneira ou de outra, algum mais ir usar, manter, documentar ou, de alguma
forma, depender da capacidade de entender seu sistema. Portanto, sempre especifique, projete
e implemente ciente de que algum mais ter de entender o que voc est fazendo. O pblico para
qualquer produto de desenvolvimento de software potencialmente grande. Especifique tendo
em vista os usurios; projete, tendo em mente os implementadores; e codifique considerando
aqueles que tero de manter e estender o sistema. Algum ter de depurar o cdigo que voc
escreveu e isso o faz um usurio de seu cdigo; facilitando o trabalho de todas essas pessoas
voc agrega maior valor ao sistema.

13 Reproduzido com a permisso do autor [Hoo96]. Hooker define padres para esses princpios em http://c2.com/cgi/wiki?Seven
PrinciplesOfSoftwareDevelopment.

captulo 1 software e ENGENHARIA DE SOFTWARE

45

Quinto princpio: esteja aberto para o futuro

Um sistema com tempo de vida mais longo tem mais valor. Nos ambientes computacionais
de hoje, em que as especificaes mudam de um instante para outro e as plataformas de
hardware se tornam rapidamente obsoletas, a vida de um software, em geral, medida em meses. Entretanto, verdadeiros sistemas de software com fora industrial devem durar um perodo
muito maior e, para isso, devem estar preparados para se adaptar a mudanas. Sistemas que
obtm sucesso so aqueles que foram projetados dessa forma desde seu princpio.
Jamais faa projetos limitados, sempre pergunte e se e prepare-se para todas as possveis
respostas, criando sistemas que resolvam o problema geral, no apenas aquele especfico.14 Isso
muito provavelmente conduziria reutilizao de um sistema inteiro.
Sexto princpio: planeje com antecedncia, visando a reutilizao

A reutilizao economiza tempo e esforo;15 alcanar um alto grau de reso indiscutivelmente a meta mais difcil de ser atingida ao se desenvolver um sistema de software. A reutilizao de cdigo e projetos tem sido proclamada como o maior benefcio do uso de tecnologias
orientadas a objetos, entretanto, o retorno desse investimento no automtico. Alavancar as
possibilidades de reutilizao (oferecida pela programao orientada a objetos [ou convencional]) requer planejamento e capacidade de fazer previses. Existem vrias tcnicas para levar a
cabo a reutilizao em cada um dos nveis do processo de desenvolvimento do sistema. Planejar
com antecedncia para o reso reduz o custo e aumenta o valor tanto dos componentes reutilizveis quanto dos sistemas aos quais eles sero incorporados.
Stimo princpio: pense!

Este ltimo princpio , provavelmente, aquele que mais menosprezado. Pensar bem e de
forma clara antes de agir quase sempre produz melhores resultados. Quando se analisa alguma
coisa, provavelmente esta sair correta. Ganha-se tambm conhecimento de como fazer correto
novamente. Se voc realmente analisar algo e mesmo assim o fizer da forma errada, isso se
tornar uma valiosa experincia. Um efeito colateral da anlise aprender a reconhecer quando
no se sabe algo, e at que ponto poder buscar o conhecimento. Quando a anlise clara fez
parte de um sistema, seu valor aflora. Aplicar os seis primeiros princpios requer intensa reflexo, para a qual as recompensas potenciais so enormes.
Se todo engenheiro de software e toda a equipe de software simplesmente seguissem os sete
princpios de Hooker, muitas das dificuldades enfrentadas no desenvolvimento de complexos
sistemas baseados em computador seriam eliminadas.

1.6
Na falta de
padres significativos substituindo
o folclore, surge
uma nova indstria
como a do
software.
Tom DeMarco

M i t o s R e l at i v o s

ao

S o f t wa r e

Os mitos criados em relao ao software crenas infundadas sobre o software e sobre o


processo usado para cri-lo remontam aos primrdios da computao. Os mitos possuem
uma srie de atributos que os tornam insidiosos. Por exemplo, eles parecem ser, de fato, afirmaes razoveis (algumas vezes contendo elementos de verdade), tm uma sensao intuitiva e
frequentemente so promulgados por praticantes experientes que entendem do riscado.
Atualmente, a maioria dos profissionais versados na engenharia de software reconhece os
mitos por aquilo que eles representam atitudes enganosas que provocaram srios problemas
tanto para gerentes quanto para praticantes da rea. Entretanto, antigos hbitos e atitudes so
difceis de ser modificados e resqucios de mitos de software permanecem.
14 Esse conselho pode ser perigoso se levado a extremos. Projetar para o problema geral algumas vezes requer compromissos
de desempenho e pode tornar ineficientes as solues especficas.
15 Embora isso seja verdade para aqueles que reutilizam o software em futuros projetos, a reutilizao pode ser cara para aqueles que precisem projetar e desenvolver componentes reutilizveis. Estudos indicam que o projeto e o desenvolvimento de
componentes reutilizveis pode custar de 25 a 200% mais que o prprio software. Em alguns casos, o diferencial de custo no
pode ser justificado.

46

WebRef
Software Project
Managers Network,
no endereo www.
spmn.com, pode
ajud-lo a dissipar
esses e outros mitos.

captulo 1 software e ENGENHARIA DE SOFTWARE

Mitos de gerenciamento. Gerentes com responsabilidade sobre software, assim como gerentes da maioria das reas, frequentemente esto sob presso para manter os oramentos,
evitar deslizes nos cronogramas e elevar a qualidade. Como uma pessoa que est se afogando
e se agarra a uma tbua, um gerente de software muitas vezes se agarra crena num mito do
software, para aliviar a presso (mesmo que temporariamente).
Mito:

J temos um livro que est cheio de padres e procedimentos para desenvolver software. Ele no supre meu pessoal com tudo que eles precisam saber?

Realidade: O livro com padres pode muito bem existir, mas ele usado? Os praticantes
da rea esto cientes de que ele existe? Esse livro reflete a prtica moderna
da engenharia de software? completo? adaptvel? Est alinhado para melhorar o tempo de entrega, mantendo ainda o foco na qualidade? Em muitos
casos, a resposta para todas essas perguntas no.
Mito:

Se o cronograma atrasar, poderemos acrescentar mais programadores e ficarmos em dia (algumas vezes denominado conceito da horda mongol).

Realidade: O desenvolvimento de software no um processo mecnico como o de fbrica. Nas palavras de Brooks [Bro95]: acrescentar pessoas num projeto de
software atrasado s o tornar mais atrasado ainda. A princpio, essa afirmao pode parecer um contrassenso, no entanto, o que ocorre que, quando
novas pessoas entram, as que j estavam tero de gastar tempo situando os recm-chegados, reduzindo, consequentemente, o tempo destinado ao
desenvolvimento produtivo. Pode-se adicionar pessoas, mas somente de forma planejada e bem coordenada.
Mito:

Se eu decidir terceirizar o projeto de software, posso simplesmente relaxar e


deixar essa empresa realiz-lo.

Realidade: Se uma organizao no souber gerenciar e controlar projetos de software, ela


ir, invariavelmente, enfrentar dificuldades ao terceiriz-los.

AVISO
Esforce-se ao mximo
para compreender o
que deve fazer antes
de comear. Voc pode
no chegar a todos os
detalhes, mas quanto
mais voc souber,
menor ser o risco.

Mitos dos clientes. O cliente solicitante do software computacional pode ser uma pessoa na
mesa ao lado, um grupo tcnico do andar de baixo, de um departamento de marketing/vendas,
ou uma empresa externa que encomendou o projeto por contrato. Em muitos casos, o cliente
acredita em mitos sobre software porque gerentes e profissionais da rea pouco fazem para
corrigir falsas informaes. Mitos conduzem a falsas expectativas (do cliente) e, em ltima instncia, insatisfao com o desenvolvedor.
Mito:

Uma definio geral dos objetivos suficiente para comear a escrever os


programas podemos preencher detalhes posteriormente.

Realidade:

Embora nem sempre seja possvel uma definio ampla e estvel dos requisitos, uma definio de objetivos ambgua receita para um desastre. Requisitos no ambguos (normalmente derivados da iteratividade) so obtidos
somente pela comunicao contnua e eficaz entre cliente e desenvolvedor.

Mito:

Os requisitos de software mudam continuamente, mas as mudanas podem


ser facilmente assimiladas, pois o software flexvel.

Realidade:

verdade que os requisitos de software mudam, mas o impacto da mudana


varia dependendo do momento em que ela foi introduzida. Quando as mudanas dos requisitos so solicitadas cedo (antes do projeto ou da codificao terem comeado), o impacto sobre os custos relativamente pequeno.
Entretanto, conforme o tempo passa, ele aumenta rapidamente recursos
foram comprometidos, uma estrutura de projeto foi estabelecida e mudar
pode causar uma revoluo que exija recursos adicionais e modificaes
fundamentais no projeto.

captulo 1 software e ENGENHARIA DE SOFTWARE

AVISO
Toda vez que pensar:
no temos tempo
para engenharia de
software, pergunte a
si mesmo, teremos
tempo para fazer de
novo?.

47

Mitos dos profissionais da rea. Mitos que ainda sobrevivem nos profissionais da rea
tm resistido por mais de 50 anos de cultura de programao. Durante seus primrdios, a programao era vista como uma forma de arte. Modos e atitudes antigos dificilmente morrem.
Mito:

Uma vez feito um programa e o colocado em uso, nosso trabalho est terminado.

Realidade:

Uma vez algum j disse que o quanto antes se comear a codificar, mais
tempo levar para termin-lo. Levantamentos indicam que entre 60 e 80%
de todo o esforo ser despendido aps a entrega do software ao cliente pela
primeira vez.

Mito:

At que o programa entre em funcionamento, no h maneira de avaliar sua


qualidade.

Realidade:

Um dos mecanismos de garantia da qualidade de software mais eficaz pode


ser aplicado desde a concepo de um projeto a reviso tcnica.Revisores de software (descritos no Captulo 15) so um filtro de qualidade que
mostram ser mais eficientes do que testes para encontrar certas classes de
defeitos de software.

Mito:

O nico produto passvel de entrega o programa em funcionamento.

Realidade:

Um programa funcionando somente uma parte de uma configurao de


software que inclui muitos elementos. Uma variedade de produtos derivados
(por exemplo, modelos, documentos, planos) constitui uma base para uma
engenharia bem-sucedida e, mais importante, uma orientao para suporte
de software.

Mito:

A engenharia de software nos far criar documentao volumosa e desnecessria e, invariavelmente, ir nos retardar.

Realidade: A engenharia de software no trata de criao de documentos, trata da criao de um produto de qualidade. Melhor qualidade conduz reduo do
retrabalho, e menos retrabalho resulta em maior rapidez na entrega.
Muitos profissionais de software reconhecem a falcia dos mitos que acabamos de descrever.
Lamentavelmente, mtodos e atitudes habituais fomentam tanto gerenciamento quanto medidas tcnicas deficientes, mesmo quando a realidade exige uma abordagem melhor. Ter cincia
das realidades do software o primeiro passo para buscar solues prticas na engenharia de
software.

1.7

Como Tudo Comeou


Todo projeto de software motivado por alguma necessidade de negcios a necessidade
de corrigir um defeito em uma aplicao existente; a necessidade de adaptar um sistema legado a um ambiente de negcios em constante transformao; a necessidade de estender as
funes e os recursos de uma aplicao existente, ou a necessidade de criar um novo produto,
servio ou sistema.
No incio de um projeto de software, a necessidade do negcio , com frequncia, expressa
informalmente como parte de uma simples conversa. A conversa apresentada no quadro a seguir
tpica.
Exceto por uma rpida referncia, o software mal foi mencionado como parte da conversao.
Ainda assim, o software ir decretar o sucesso ou o fracasso da linha de produtos CasaSegura.
A empreitada de engenharia ter xito apenas se o software para a linha CasaSegura tiver xito;
e o mercado ir aceitar o produto apenas se o software incorporado atender adequadamente s
necessidades (ainda no declaradas) do cliente. Acompanharemos a evoluo da engenharia do
software CasaSegura em vrios dos captulos que esto por vir.

48

captulo 1 software e ENGENHARIA DE SOFTWARE

C asa S egura 16
Como comea um projeto
Cena: Sala de reunies da CPI Corporation,
empresa (fictcia) que fabrica produtos de
consumo para uso domstico e comercial.
Atores: Mal Golden, gerente snior, desenvolvimento do produto; Lisa Perez, gerente de marketing; Lee Warren, gerente de
engenharia; Joe Camalleri, vice-presidente executivo, desenvolvimento de negcios.
Conversa:
Joe: Lee, ouvi dizer que o seu pessoal est construindo algo.
Do que se trata? Um tipo de caixa sem fio de uso amplo e genrico?
Lee: Trata-se de algo bem legal... Aproximadamente do tamanho
de uma caixa de fsforos, conectvel a todo tipo de sensor, como
uma cmera digital ou seja, conectvel a quase tudo. Usa o
protocolo sem fio 802.11g, permitindo que acessemos sadas de
dispositivos sem o emprego de fios. Acreditamos que nos levar a
uma gerao de produtos inteiramente nova.

Mal (evitando comprometimento direto): Conte a ele


sobre nossa ideia, Lisa.
Lisa: Trata-se de uma gerao completamente nova na linha de
produtos de gerenciamento domstico. Chamamos esses produtos que criamos de CasaSegura. Eles usam uma nova interface sem
fio e oferecem a pequenos empresrios e proprietrios de casas
um sistema que controlado por seus PCs, envolvendo segurana
domstica, sistemas de vigilncia, controle de eletrodomsticos e
dispositivos. Por exemplo, seria possvel diminuir a temperatura do
aparelho de ar condicionado enquanto voc est voltando para
casa, esse tipo de coisa.
Lee (reagindo sem pensar): O departamento de engenharia fez um estudo de viabilidade tcnica dessa ideia, Joe.
possvel faz-lo com um baixo custo de fabricao. A maior parte dos componentes do hardware encontrada no mercado; o
software um problema, mas no nada que no possamos
resolver.
Joe: Interessante, mas eu perguntei sobre o levantamento final.

Mal: Sim. Na verdade, com as vendas to em baixa quanto neste ano, precisamos de algo novo. Lisa e eu fizemos uma pequena
pesquisa de mercado e acreditamos que conseguimos uma linha
de produtos que poder ser ampla.

Mal: Os PCs esto em mais de 70% dos lares, se formos capazes


de estabelecer um preo baixo para essa coisa, ela poderia se
tornar um produto revolucionrio. Ningum mais tem nosso dispositivo sem fio... Ele exclusivo! Estaremos 2 anos frente de nossos
concorrentes... E as receitas? Algo em torno de 30 a 40 milhes de
dlares no segundo ano...

Joe: Ampla em que sentido?

Joe (sorrindo): Vamos levar isso adiante. Estou interessado.

Joe: Voc concorda, Mal?

1.8

Resumo
Software o elemento-chave na evoluo de produtos e sistemas baseados em computador
e uma das mais importantes tecnologias no cenrio mundial. Ao longo dos ltimos 50 anos, o
software evoluiu de uma ferramenta especializada em anlise de informaes e resoluo de
problemas para uma indstria propriamente dita. Mesmo assim, ainda temos problemas para
desenvolver software de boa qualidade dentro do prazo e oramento estabelecidos.16
Softwares programas, dados e informaes descritivas contemplam uma ampla gama
de reas de aplicao e tecnologia. O software legado continua a representar desafios especiais
queles que precisam fazer sua manuteno.
As aplicaes e os sistemas baseados na Internet passaram de simples conjuntos de contedo informativo para sofisticados sistemas que apresentam funcionalidade complexa e contedo
multimdia. Embora essas WebApps possuam caractersticas e requisitos exclusivos, elas no
deixam de ser um tipo de software.
A engenharia de software engloba processos, mtodos e ferramentas que possibilitam a
construo de sistemas complexos baseados em computador dentro do prazo e com qualidade. O processo de software incorpora cinco atividades estruturais: comunicao, planejamento,
modelagem, construo e emprego; e elas se aplicam a todos os projetos de software. A prtica

16 O projeto CasaSegura ser usado ao longo deste livro para ilustrar o funcionamento interno de uma equipe de projeto medida que ela constri um produto de software. A empresa, o projeto e as pessoas so inteiramente fictcias, porm as situaes
e os problemas so reais.

captulo 1 software e ENGENHARIA DE SOFTWARE

49

da engenharia de software uma atividade de resoluo de problemas que segue um conjunto


de princpios bsicos.
Inmeros mitos em relao ao software continuam a levar gerentes e profissionais para o
mau caminho, mesmo com o aumento do conhecimento coletivo de software e das tecnologias
necessrias para constru-los. medida que for aprendendo mais sobre a engenharia de software, voc comear a compreender porque esses mitos devem ser derrubados toda vez que se
deparar com eles.

Problemas

Pontos

Ponderar

1.1. Cite pelo menos cinco outros exemplos de como a lei das consequncias no intencionais se aplica ao software.
1.2. Fornea uma srie de exemplos (positivos e negativos) que indiquem o impacto do software em nossa sociedade.
1.3. Desenvolva suas prprias respostas s cinco perguntas colocadas no incio da Seo
1.1. Discuta-as com seus colegas.
1.4. Muitas aplicaes modernas mudam com frequncia antes de serem apresentadas ao
usurio final e s ento a primeira verso ser colocada em uso. Sugira algumas maneiras de
construir software para impedir a deteriorao decorrente de mudanas.
1.5. Considere as sete categorias de software apresentadas na Seo 1.1.2. Voc acha que a
mesma abordagem em relao engenharia de software pode ser aplicada a cada uma delas?
Justifique sua resposta.
1.6. A Figura 1.3 coloca as trs camadas de engenharia de software acima de uma camada
intitulada foco na qualidade. Isso implica um programa de qualidade organizacional como
o de gesto da qualidade total. Pesquise um pouco a respeito e crie um sumrio dos princpios bsicos de um programa de gesto da qualidade total.
1.7. A engenharia de software aplicvel quando as WebApps so construdas? Em caso positivo, como poderia ser modificada para atender s caractersticas nicas das WebApps?
1.8. medida que o software invade todos os setores, riscos ao pblico (devido a programas
com imperfeies) passam a ser uma preocupao cada vez maior. Crie um cenrio o mais
catastrfico possvel, porm realista, cuja falha de um programa de computador poderia causar um grande dano (em termos econmico ou humano).
1.9. Descreva uma estrutura de processos com suas prprias palavras. Ao afirmarmos que
atividades de modelagem se aplicam a todos os projetos, isso significa que as mesmas tarefas so aplicadas a todos os projetos, independentemente de seu tamanho e complexidade?
Justifique.
1.10. As atividades de apoio ocorrem ao longo do processo de software. Voc acredita que
elas so aplicadas de forma homognea ao longo do processo ou algumas delas so concentradas em uma ou mais atividades de metodologia?
1.11. Acrescente dois outros mitos lista apresentada na Seo 1.6 e declare a realidade que
acompanha tais mitos.1 7

Leituras

Fontes

de

I n f o r m a o C o m p l e m e n ta r e s 17

H literalmente milhares de livros sobre o tema software. A grande maioria trata de linguagens de programao ou aplicaes de software, porm poucos tratam do software em si.
17 A seo Leitura e fontes de informao adicionais apresentada no final de cada captulo apresenta uma breve viso geral de
publicaes que podem ajudar a expandir o seu entendimento dos principais tpicos apresentados no captulo. H um site
bem abrangente para dar suporte ao livro Engenharia de Software: uma abordagem prtica no endereo www.mhhe.com/
pressman. Entre os diversos tpicos contemplados no site esto recursos de engenharia de software captulo a captulo e
dicas de sites que podero complementar o material apresentado em cada captulo.

50

captulo 1 software e ENGENHARIA DE SOFTWARE

Pressman e Herron (Software Shock, Dorset House, 1991) apresentaram uma discusso preliminar (dirigida ao grande pblico) sobre software e a maneira pela qual os profissionais o desenvolvem. O best-seller de Negroponte (Being Digital, Alfred A. Knopf, Inc., 1995) d uma viso
geral da computao e seu impacto global no sculo XXI. DeMarco (Why Does Software Cost So
Much? Dorset House, 1995) produziu um conjunto de divertidos e perspicazes ensaios sobre
software e o processo pelo qual ele desenvolvido.
Minasi (The Software Conspiracy: Why Software Companies Put out Faulty Products, How
They Can Hurt You, and What You Can Do, McGraw-Hill, 2000) argumenta que o flagelo moderno dos bugs de software pode ser eliminado e sugere maneiras para concretizar isso.
Compaine (Digital Divide: Facing a Crisis or Creating a Mith, MIT Press, 2001) defende que
a separao entre aqueles que tm acesso a fontes de informao (por exemplo, a Web) e
aqueles que no o tm est diminuindo, medida que avanamos na primeira dcada deste
sculo. Livros de Greenfield (Everyware: The Dawning Age of Ubiquitous Computing, New
Riders Publishing, 2006) e Loke (Context-Aware Pervasive Systems: Architectures for a New
Breed of Applications, Auerbach, 2006) introduzem o conceito de software aberto e preveem um ambiente sem fio no qual o software deve se adaptar s exigncias que surgem em
tempo real.
O estado atual da engenharia de software e do processo de software pode ser mais bem
determinado a partir de publicaes como IEEE Software, IEEE Computer, CrossTalk e IEEE
Transactions on Software Engineering. Peridicos do setor como Application Development
Trends e Cutter IT Journal normalmente contm artigos sobre tpicos da engenharia de software. A disciplina sintetizada todos os anos no Proceeding of the International Conference
on Software Engineering, patrocinado pelo IEEE e ACM e discutida de forma aprofundada
em peridicos como ACM Transactions on Software Engineering and Methodology, ACM Software Engineering Notes e Annals of Software Engineering. Dezenas de milhares de sites so
dedicados engenharia de software e ao processo de software.
Foram publicados vrios livros sobre o processo de desenvolvimento de software e sobre
a engenharia de software nos ltimos anos. Alguns fornecem uma viso geral de todo o processo, ao passo que outros se aprofundam em tpicos especficos importantes em detrimento dos demais. Entre as ofertas mais populares (alm deste livro, claro!), temos:
Abran, A. e J. Moore, SWEBOK: Guide to the Software Engineering Body of Knowledge, IEEE, 2002.
Andersson, E. et al., Software Engineering for Internet Applications, The MIT Press, 2006.
Christensen, M. e R. Thayer, A Project Managers Guide to Software Engineering Best Practices, IEEECS Press (Wiley), 2002.
Glass, R., Fact and Fallacies of Software Engineering, Addison-Wesley, 2002.
Jacobson, I., Object-Oriented Software Engineering: A Use Case Driven Approach, 2. ed., AddisonWesley, 2008.
Jalote, P., An Integrated Approach to Software Engineering, Springer, 2006.
Pfleeger, S., Software Engineering: Theory and Practice, 3. ed., Prentice-Hall, 2005.
Schach, S., Object-Oriented and Classical Software Engineering, 7. ed., McGraw-Hill, 2006.
Sommerville, I., Software Engineering, 8. ed., Addison-Wesley, 2006.
Tsui, F. e O. Karam, Essentials of Software Engineering, Jones & Bartlett Publishers, 2006.

Foram publicados diversos padres de engenharia de software pelo IEEE, pela ISO e suas
organizaes de padronizao ao longo das ltimas dcadas. Moore (The Road Map to Software Engineering: A Standards-Based Guide, Wiley-IEEE Computer Society Press, 2006) disponibiliza uma pesquisa til de padres relevantes e como aplic-los a projetos reais.
Uma ampla gama de fontes de informao sobre engenharia de software e processo de
software se encontra disposio na Internet. Uma lista atualizada de referncias relevantes para o processo para o software pode ser encontrada no site www.mhhe.com/engcs/
compsci/pressman/professional/olc/ser.htm.

PA

RTE

Processos

de

UM

Software

esta seo voc aprender sobre o processo que fornece uma metodologia
para a prtica da engenharia de software. As questes abaixo so tratadas nos
captulos seguintes:

O que um processo de software?


Quais so as atividades metodolgicas genricas presentes em todos os processos
de software?
Como os processos so modelados e o que so padres de processo?
O que so modelos de processo prescritivo e quais so seus pontos fortes e fracos?
Por que agilidade um lema no trabalho da engenharia de software moderna?
O que desenvolvimento de software gil e como ele difere dos modelos de processos mais tradicionais?

Respondidas tais questes, voc estar mais bem preparado para compreender o contexto no qual a prtica da engenharia de software aplicada.

captulo

Conceitos- Chave
conjunto de tarefas . 55
desenvolvimento
baseado em
componentes . . . . . 69
modelo de mtodos
formais . . . . . . . . . 69
modelo de processo
genrico . . . . . . . . 53
modelos
concorrentes . . . . . 67
modelos de processo
evolucionrio . . . . . 62
modelos de processo
incremental . . . . . . 61
modelos de processo
prescritivo . . . . . . . 58
padres de
processo . . . . . . . . 55
processo de software
em equipe . . . . . . . 75
processo de software
pessoal . . . . . . . . . 74
processo unificado . . 71

Modelos

de

Processo

m um livro fascinante, que nos d a viso de um economista acerca do software


e da engenharia de software, Howard Baetjer, Jr. [Bae98], comenta o processo de
software:

Pelo fato de software, como todo capital, ser conhecimento incorporado, e pelo fato de esse conhecimento ser, inicialmente, disperso, tcito, latente e em considervel medida, incompleto, o
desenvolvimento de software um processo de aprendizado social. Esse processo um dilogo
no qual o conhecimento, que dever tornar-se o software, coletado, reunido e incorporado ao
software. Tal processo possibilita a interao entre usurios e projetistas, entre usurios e ferramentas em evoluo e entre projetistas e ferramentas em evoluo (tecnologia). Trata-se de um
processo iterativo no qual a prpria ferramenta em evoluo serve como meio de comunicao,
com cada nova rodada do dilogo extraindo mais conhecimento til das pessoas envolvidas.

De fato, construir software um processo de aprendizado social iterativo e o resultado,


algo que Baetjer denominaria capital de software, a incorporao do conhecimento
coletado, filtrado e organizado conforme se desenvolve o processo.
Mas o que exatamente um processo de software do ponto de vista tcnico? No contexto desse livro, processo de software definido como uma metodologia para as atividades,
aes e tarefas necessrias para desenvolver um software de alta qualidade. Processo
sinnimo de engenharia de software? A resposta sim e no. Um processo de software
define a abordagem adotada conforme um software elaborado pela engenharia. Mas a
engenharia de software tambm engloba tecnologias que fazem parte do processo mtodos tcnicos e ferramentas automatizadas.
Mais importante, a engenharia de software realizada por pessoas criativas e com amplos conhecimentos e que devem adaptar um processo de software maduro, de forma que
fique apropriado aos produtos desenvolvidos e s demandas de seu mercado.

O que ? Quando se trabalha na

Panorama elaborao de um produto ou sistema,

importante seguir uma srie de passos


previsveis um roteiro que ajude a
criar um resultado de alta qualidade e dentro do
prazo estabelecido. O roteiro denominado processo de software.
Quem realiza? Os engenheiros de software e seus
gerentes adaptam o processo s suas necessidades e ento o seguem. Os solicitantes do software
tm um papel a desempenhar no processo de
definio, construo e teste do software.
Por que ele importante? Porque propicia
estabilidade, controle e organizao para uma atividade que pode, sem controle, tornar-se bastante
catica. Entretanto, uma abordagem de engenharia de software moderna deve ser gil. Deve
demandar apenas atividades, controles e produtos
de trabalho que sejam apropriados para a equipe
do projeto e para o produto a ser produzido.

52

Quais so as etapas envolvidas? O processo


adotado depende do software a ser desenvolvido.
Um determinado processo pode ser apropriado
para um software do sistema avinico de uma
aeronave, enquanto um processo totalmente diferente pode ser indicado para a criao de um site.
Qual o artefato? Do ponto de vista de um engenheiro de software, os produtos de trabalho so os
programas, os documentos e os dados produzidos
em consequncia das atividades e tarefas definidas pelo processo.
Como garantir que o trabalho foi feito corretamente? H muitos mecanismos de avaliao
dos processos de software que possibilitam s
organizaes determinarem o nvel de maturidade de seu processo de software. Entretanto, a
qualidade, o cumprimento de prazos e a viabilidade a longo prazo do produto que se desenvolve
so os melhores indicadores da eficcia do processo utilizado.

53

captulo 2 Modelos de Processo

2.1

A hierarquia de
trabalho tcnico,
dentro do processo
de software, consiste
em: atividades,
aes abrangentes,
compostas por tarefas.

Figura 2.1
Uma metodologia
do processo
de software

Um Modelo

de

Processo Genrico

No Captulo 1, processo foi definido como um conjunto de atividades de trabalho, aes e


tarefas realizadas quando algum artefato de software deve ser criado. Cada uma dessas atividades, aes e tarefas alocam-se dentro de uma metodologia ou modelo que determina seu
relacionamento com o processo e seu relacionamento umas com as outras.
O processo de software representado esquematicamente na Figura 2.1. De acordo com a
figura, cada atividade metodolgica composta por um conjunto de aes de engenharia de
software. Cada ao definida por um conjunto de tarefas, o qual identifica as tarefas de trabalho a ser completadas, os artefatos de software que sero produzidos, os fatores de garantia da
qualidade que sero exigidos e os marcos utilizados para indicar progresso.
Como discutido no Captulo 1, uma metodologia de processo genrica para engenharia de
software estabelece cinco atividades metodolgicas: comunicao, planejamento, modelagem, construo e entrega. Alm disso, um conjunto de atividades de apoio (umbrella
activities) so aplicadas ao longo do processo, como o acompanhamento e controle do projeto,
a administrao de riscos, a garantia da qualidade, o gerenciamento das configuraes, as revises tcnicas e outras.

Processo de software

Metodologia do processo
Atividades de apoio
atividade metodolgica n 1
ao de engenharia de software n 1.1
Conjuntos
de tarefas

tarefas de trabalho
artefatos de software
fatores de garantia da qualidade
pontos de controle do projeto

ao de engenharia de software n 1.k


Conjuntos
de tarefas

tarefas de trabalho
artefatos de software
fatores de garantia da qualidade
pontos de controle do projeto

atividade metodolgica n n
ao de engenharia de software n n.1
Conjuntos
de tarefas

tarefas de trabalho
artefatos de software
fatores de garantia da qualidade
pontos de controle do projeto

ao de engenharia de software n n.m


Conjuntos
de tarefas

tarefas de trabalho
artefatos de software
fatores de garantia da qualidade
pontos de controle do projeto

54

Achamos que
desenvolvedores
de software no
percebem uma
verdade essencial:
a maioria das
organizaes no
sabe o que faz.
Elas acham que
sabem, mas no
sabem.
Tom DeMarco

Figura 2.2

PARTE 1O processo de Software

Deve-se notar que um importante aspecto do processo de software ainda no foi discutido.
Esse aspecto chamado fluxo de processo descreve como so organizadas as atividades
metodolgicas, bem como as aes e tarefas que ocorrem dentro de cada atividade em relao
sequncia e ao tempo, como ilustrado na Figura 2.2.
Um fluxo de processo linear executa cada uma das cinco atividades metodolgicas em sequncia, comeando com a de comunicao e culminando com a do emprego (Figura 2.2a). Um fluxo
de processo iterativo repete uma ou mais das atividades antes de prosseguir para a seguinte
(Figura 2.2b). Um fluxo de processo evolucionrio executa as atividades de uma forma circular.
Cada volta pelas cinco atividades conduz a uma verso mais completa do software (Figura 2.2c).
Um fluxo de processo paralelo (Figura 2.2d) executa uma ou mais atividades em paralelo com outras atividades (por exemplo, a modelagem para um aspecto do software poderia ser executada
em paralelo com a construo de um outro aspecto do software).

Fluxo de processo

Comunicao

Planejamento

Modelagem

Construo

Entrega

Construo

Entrega

(a) Fluxo de processo linear

Comunicao

Planejamento

Modelagem

(b) Fluxo de processo iterativo

Planejamento

Modelagem

Comunicao

Liberado por
incremento

Entrega

Construo

(c) Fluxo de processo evolucionrio

Comunicao

Planejamento

Modelagem

Tempo

Construo
(d) Fluxo de processo paralelo

Entrega

captulo 2 Modelos de Processo

55

2.1.1Definindo atividade metodolgica

uma
? Como
atividade

metodolgica
modificada
de acordo com
as alteraes
da natureza do
projeto?

Embora tenham sido descritas cinco atividades metodolgicas e se tenha fornecido uma
definio bsica de cada uma delas no Captulo 1, uma equipe de software precisa de muito
mais informaes antes de poder executar apropriadamente qualquer uma dessas atividades
como parte do processo de software. Consequentemente, depara-se com uma questo-chave:
Que aes so apropriadas para uma atividade metodolgica, uma vez fornecidos a natureza do
problema a ser solucionado, as caractersticas das pessoas que estaro executando o trabalho e
os interessados que estaro propondo o projeto?
Para um pequeno projeto de software solicitado por uma nica pessoa (numa localidade longnqua) com necessidades simples e objetivas, a atividade de comunicao pode resumir-se a
pouco mais de um telefonema para o devido solicitante. Portanto, a nica ao necessria uma
conversao telefnica, e as tarefas de trabalho (o conjunto de tarefas) que essa ao envolve so:
1. Contactar o interessado via telefone.
2. Discutir as necessidades e tomar notas.
3. Organizar anotaes em uma breve relao de requisitos, por escrito.
4. Enviar um e-mail para o interessado para reviso e aprovao.
Se o projeto fosse consideravelmente mais complexo, com muitos interessados, cada qual
com um conjunto de necessidades diferentes (por vezes conflitantes), a atividade de comunicao poderia ter seis aes distintas (descritas no Captulo 5): insero, elucidao, elaborao,
negociao, especificao e validao. Cada uma dessas aes de engenharia de software conteria muitas tarefas de trabalho e uma srie de diferentes artefatos.

2.1.2Identificao de um conjunto de tarefas


Projetos diferentes
demandam conjuntos
de tarefas diferentes.
A equipe de software
escolhe o conjunto de
tarefas fundamentada
no problema e nas
caractersticas do
projeto.

Referindo-se novamente Figura 2.1, cada ao de engenharia de software (por exemplo,


elucidao, uma ao associada atividade de comunicao) pode ser representada por vrios e
diferentes conjuntos de tarefas cada um constitudo por uma gama de tarefas de trabalho de
engenharia de software, artefatos relativos, fatores de garantia da qualidade e pontos de controle
do projeto. Deve-se escolher um conjunto de tarefas mais adequado s necessidades do projeto
e s caractersticas da equipe. Isso significa que uma ao de engenharia de software pode ser
adaptada s necessidades especficas do projeto de software e s caractersticas da equipe.

2.1.3Padres de processos
que
? Opadro
de

processo?

A repetio de
padres algo
bem diferente
da repetio de
partes. De fato, as
partes diferentes
sero nicas, pois
os padres so os
mesmos.
Christopher
Alexander

Toda equipe de desenvolvimento encontra problemas medida que avana no processo de


software. Seria til se solues comprovadas estivessem prontamente disposio da equipe,
de modo que os problemas pudessem ser localizados e resolvidos rapidamente. Um padro de
processo1 descreve um problema de processo encontrado durante o trabalho de engenharia
de software, identificando o ambiente onde foi encontrado e sugerindo uma ou mais solues
comprovadas para o problema. Em termos mais genricos, um padro de processo fornece um
modelo (template) [Amb98] um mtodo consistente para descrever solues de problemas
no contexto do processo de software. Combinando padres, uma equipe conseguir solucionar
problemas e elaborar um processo que melhor atenda s necessidades de um projeto.
Padres podem ser definidos em qualquer nvel de abstrao.2 Em alguns casos, um padro
poderia ser utilizado para descrever um problema (e sua soluo) associado ao modelo de processo completo (por exemplo, prototipao). Em outras situaes, os padres podem ser usados para descrever um problema (e sua soluo) associado a uma atividade metodolgica (por
1
2

Uma discusso detalhada sobre padres apresentada no Captulo 12.


Os padres so aplicveis a vrias atividades de engenharia de software. Padres de anlise, de projeto e de testes so discutidos nos Captulos 7, 9, 10, 12 e 14. Padres e antipadres para atividades de gerenciamento de projetos so discutidos na
Parte 4 deste livro.

56

paRtE 1

o ProCesso De software

INfORMAES

Conjunto de tarefas
Um conjunto de tarefas define o verdadeiro trabalho
a ser feito para se atingir os objetivos de uma ao
de engenharia de software. Por exemplo, elucidao
(mais comumente denominada levantamento de requisitos)
uma importante ao de engenharia de software que ocorre durante a atividade de comunicao. A meta do levantamento de
requisitos compreender o que os vrios interessados esperam
do software a ser desenvolvido.
Para um projeto pequeno, relativamente simples, o conjunto de
tarefas para levantamento das necessidades seria semelhante ao
seguinte:
1. Fazer uma lista dos envolvidos no projeto.
2. Fazer uma reunio informal com todos os interessados.
3. Solicitar para cada interessado uma lista com as caractersticas e funes necessrias.

3. Fazer uma lista preliminar das funes e caractersticas,


com base nas informaes fornecidas pelos interessados.
4. Agendar uma srie de reunies facilitadoras para especificao de aplicaes.
5. Promover reunies.
6. Incluir cenrios informais de usurios como parte de cada
reunio.
7. Aprimorar os cenrios de usurios, com base no feedback
dos interessados.
8. Fazer uma lista revisada das necessidades dos interessados.
9. Empregar tcnicas de aplicao de funes de qualidade
para estabelecer graus de prioridade dos requisitos.
10. Agrupar os requisitos de modo que eles possam ser entregues incrementalmente.

4. Discutir sobre os requisitos e construir uma lista final.

11. Fazer um levantamento das limitaes e restries que sero aplicadas ao sistema.

5. Organizar os requisitos por grau de prioridade.

12. Discutir sobre os mtodos para validao do sistema.

6. Destacar pontos de incertezas.


Para um projeto de software maior e mais complexo, necessita-se de um conjunto diferente de tarefas. Tal conjunto pode incluir
as seguintes tarefas de trabalho:
1. Fazer uma lista dos envolvidos no projeto.
2. Entrevistar separadamente cada um dos envolvidos para levantamento geral de suas expectativas e necessidades.

Esses dois conjuntos de tarefas atingem o objetivo de levantamento de necessidades, porm, so bem diferentes em relao
aos graus de profundidade e formalidade. A equipe de software
deve escolher o conjunto de tarefas que lhe possibilitar atingir
o objetivo de cada ao, mantendo, inclusive, a qualidade e
a agilidade.

exemplo, planejamento) ou uma ao dentro de uma atividade metodolgica (por exemplo,


estimativa de custos do projeto).
Ambler [Amb98] props um modelo para descrever um padro de processo:
Nome do Padro. O padro deve receber um nome significativo que o descreva no contexto do processo de software (por exemplo, RevisesTcnicas).
Um modelo de
padres propicia um
meio consistente para
descrever um padro.

Foras. Ambiente onde se encontram o padro e as questes que tornam visvel o problema e que poderiam afetar sua soluo.
Tipo. especificado o tipo de padro. Ambler sugere trs tipos:
1. Padro de estgio define um problema associado a uma atividade metodolgica
para o processo. Como uma atividade metodolgica envolve mltiplas aes e tarefas
de trabalho, um padro de estgio engloba mltiplos padres de tarefas (veja o prximo padro) que so relevantes ao estgio (atividade metodolgica). Podemos citar
como um exemplo de padro de estgio EstabelecendoComunicao. Esse padro
incorpora o padro de tarefas LevantamentodeNecessidades e outros.
2. Padro de tarefas define um problema associado a uma ao de engenharia de software ou tarefa de trabalho relevante para a prtica de engenharia de software bem-sucedida (por exemplo, LevantamentodeNecessidades um padro de tarefas).
3. Padro de fases define a sequncia das atividades metodolgicas que ocorrem dentro do processo, mesmo quando o fluxo geral de atividades iterativo por natureza.
Um exemplo de padro de fases seria ModeloEspiral ou Prototipao.3
3

Esses padres de fases so discutidos na Seo 2.3.3.

captulo 2

57

MODELOS DE PrOCESSO

Contexto Inicial. Descreve as condies sob as quais o padro se aplica. Antes do incio
do padro: (1) Que atividades organizacionais ou relacionadas equipe j ocorreram? (2)
Qual o estado inicial para o processo? (3) Que informao de engenharia de software ou de
projeto j existe?
Por exemplo, o padro Planejamento (um padro de estgio) requer que: (1) clientes
e engenheiros de software tenham estabelecido uma comunicao colaborativa; (2) Tenha
ocorrido a finalizao bem-sucedida de uma srie de padres de tarefas [especificados] para
o padro Comunicao; e (3) Sejam conhecidos o escopo do projeto, as necessidades bsicas do negcio, bem como as restries do projeto.
Problema.

O problema especfico a ser resolvido pelo padro.

Soluo. Descreve como implementar o padro de forma bem-sucedida. Esta seo descreve como o estado inicial do processo (que existe antes de o padro ser implementado) modificado como consequncia do incio do padro. Descreve tambm como as informaes de
engenharia de software ou de projeto que se encontram disposio antes do incio do padro
so transformadas como consequncia da execuo do padro de forma bem-sucedida.
Contexto Resultante. Descreve as condies que resultaro assim que o padro tiver
sido implementado com xito. Aps a finalizao do padro:
(1) Quais atividades organizacionais ou relacionadas equipe devem ter ocorrido?
(2) Qual o estado de sada para o processo?
(3) Quais informaes de engenharia de software ou de projeto foram desenvolvidas?
Padres Relativos. Fornee uma lista de todos os padres de processo que esto diretamente relacionados ao processo em questo. Essa lista pode ser representada de forma
hierrquica ou em alguma outra forma com diagramas. Por exemplo, o padro de estgio
Comunicao envolve os padres de tarefas: EquipeDeProjeto, DiretrizesColaborativas, IsolamentoDoEscopo, LevantamentoDeNecessidades, DescrioDasRestries e CriaoDeCenrios.

Um exemplo de padro de processo


O padro de processo sintetizado a seguir descreve
uma abordagem que pode ser aplicada quando os
interessados tm uma ideia geral do que precisa ser
feito, mas esto incertos quanto aos requisitos especficos do
software.
Nome do padro. RequisitosImprecisos
Intento. Este padro descreve uma abordagem voltada para
a construo de um modelo (um prottipo) passvel de ser avaliado iterativamente pelos interessados, num esforo para identificar ou solidificar os requisitos de software.
Tipo. Padro de fase.
Contexto inicial. As condies seguintes devem ser atendidas antes de iniciar esse padro: (1) interessados identificados;
(2) forma de comunicao entre interessados e equipe de software j determinada; (3) principal problema de software a ser
resolvido j identificado pelos interessados; (4) compreenso
inicial do escopo do projeto, dos requisitos de negcio bsicos
e das restries do projeto j atingida.
Problema. Os requisitos so vagos ou inexistentes, ainda assim h um reconhecimento claro de que existe um problema a

INfORMAES
ser solucionado e este deve ser identificado utilizando-se uma
soluo de software. Os interessados no sabem o que querem,
ou seja, eles no conseguem descrever os requisitos de software
em detalhe.
Soluo. Uma descrio do processo de prototipao poderia
ser apresentada nesta etapa, mas descrita posteriormente na
Seo 2.3.3.
Contexto resultante. Um prottipo de software que identifique
os requisitos bsicos (por exemplo, modos de interao, caractersticas computacionais, funes de processamento) aprovado
pelos interessados. Em seguida, (1) o prottipo pode evoluir por
uma srie de incrementos para se tornar o software de produo
ou (2) o prottipo pode ser descartado e o software de produo
ser construdo usando-se algum outro padro de processos.
Padres associados. Os seguintes padres esto relacionados a esse padro: ComunicaoComOCliente,
ProjetoIterativo, DesenvolvimentoIterativo, AvaliaoDoCliente, ExtraoDeRequisitos.
Usos conhecidos e um exemplo. A prototipao recomendada quando as necessidades so incertas.

58

PARTE 1O processo de Software

Usos Conhecidos e Exemplos. Indicam as instncias especficas onde o padro aplicvel. Por exemplo, Comunicao obrigatria no incio de todo projeto de software,
recomendvel ao longo de todo o projeto de software e obrigatria assim que a atividade
de emprego estiver em andamento.
WebRef
Recursos completos
para padres de
processo podem
ser encontrados em
www. ambysoft.
com/process
PatternsPage.html.

2 .2

Tentativas de
avaliao para
compreender o atual
estado do processo de
software com o intuito
de aperfeio-lo.

Padres de processo propiciam um mecanismo efetivo para localizao de problemas associados a qualquer processo de software. Os padres permitem que se desenvolva uma descrio
de processo de forma hierrquica que se inicia com nvel alto de abstrao (um padro de fases).
A descrio ento refinada em um conjunto de padres de estgio que descreve atividades
metodolgicas e so ainda mais refinadas de uma forma hierrquica, em padres de tarefa mais
detalhados para cada padro de estgio. Uma vez que os padres de processos tenham sido
desenvolvidos, eles podero ser reutilizados para a definio de variantes de processo isto ,
um modelo de processo personalizado pode ser definido por uma equipe de software usando os
padres como blocos de construo para o modelo de processo.

A va l i a o

Aperfeioamento

de

Processos

A existncia de um processo de software no garante que o software ser entregue dentro do


prazo, que estar de acordo com as necessidades do cliente ou que apresentar caractersticas
tcnicas que conduziro a caractersticas de qualidade de longo prazo (Captulos 14 e 16). Os
padres de processo devem ser combinados com uma prtica de engenharia de software consistente (Parte 2 deste livro). Alm disso, o prprio processo pode ser avaliado para assegurar que
est de acordo com um conjunto de critrios de processo bsicos comprovados como essenciais
para uma engenharia de software de sucesso.4
Ao longo das ltimas dcadas foi proposta uma srie de abordagens diferentes em relao
avaliao e ao aperfeioamento dos processos de software:

? Quais
tcnicas

SCAMPI (Standard CMMI Assessment Method for Process Improvement) (Mtodo Padro CMMI de Avaliao para Aperfeioamento de Processo da CMMI):
fornece um modelo de avaliao do processo de cinco etapas, contendo cinco fases: incio,
diagnstico, estabelecimento, atuao e aprendizado. O mtodo SCAMPI usa o CMMI da SEI
como base para avaliao [SEI00].

formais esto
disponveis para
avaliar o processo
de software?

CBA IPI (CMM Based Appraisal for Internal Process Improvement) (Avaliao para Aperfeioamento do Processo Interno baseada na CMM): fornece uma
tcnica de diagnstico para avaliar a maturidade relativa de uma organizao de software;
usa a CMM da SEI como base para a avaliao [Dun01].

As organizaes
de software
apresentaram
falhas significativas
quanto
habilidade em
capitalizar as
experincias
adquiridas
nos projetos
finalizados.

SPICE (ISO/IEC15504) padro que define um conjunto de requisitos para avaliao do


processo de software. A finalidade do padro auxiliar as organizaes no desenvolvimento
de uma avaliao objetiva da eficcia de um processo qualquer de software [ISO08].
ISO 9001:2000 para Software padro genrico aplicvel a qualquer organizao que
queira aperfeioar a qualidade global de produtos, sistemas ou servios fornecidos. Portanto, o padro aplicvel diretamente a organizaes e empresas de software [Ant06].
Uma discusso mais detalhada sobre mtodos de avaliao de software e aperfeioamento
de processo apresentada no Captulo 30.

Nasa

2 .3

Modelos

de

Processo Prescritivo

Originalmente, modelos de processo prescritivo foram propostos para trazer ordem ao


caos existente na rea de desenvolvimento de software. A histria tem demonstrado que esses
4

A CMMI [CMM07] da SEI descreve, de forma extremamente detalhada, as caractersticas de um processo de software e os
critrios para o xito de um processo.

captulo 2 Modelos de Processo

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

modelos tradicionais proporcionaram uma considervel contribuio quanto estrutura utilizvel no trabalho de engenharia de software e forneceram um roteiro razoavelmente eficaz
para as equipes de software. Entretanto, o trabalho de engenharia de software e o seu produto
permanecem beira do caos.
Em um intrigante artigo sobre o estranho relacionamento entre ordem e caos no mundo do
software, Nogueira e seus colegas [Nog00] afirmam que
O limiar do caos definido como um estado natural entre ordem e caos, um grande compromisso
entre estrutura e surpresa [Kau95]. O limiar do caos pode ser visualizado como um estado instvel,
parcialmente estruturado... Instvel porque constantemente atrado para o caos ou para a ordem
absoluta.
Temos uma tendncia de pensar que ordem o estado ideal da natureza. Isso pode ser um erro.
Pesquisas... Defendem a teoria de que a operao longe do equilbrio gera criatividade, processos auto-organizados e lucros crescentes [Roo96]. Ordem absoluta implica ausncia de variabilidade, o que
poderia ser uma vantagem em ambientes imprevisveis. A mudana ocorre quando existe uma estrutura
que permita que a mudana possa ser organizada, mas tal estrutura no deve ser to rgida a ponto de
impedir que a mudana ocorra. Por outro lado, caos em demasia pode tornar impossvel a coordenao
e a coerncia. A falta de estrutura nem sempre implica desordem.

Takashi Osada

Os modelos de
processo preceptivo
definem um conjunto
prescrito de elementos
de processo e um
fluxo de trabalho de
processo previsvel.

59

As implicaes filosficas desse argumento so significativas para a engenharia de software.


Se os modelos de processos prescritivos5 buscam ao mximo a estrutura e a ordem, seriam
eles inapropriados para um mundo de software que prospera com as mudanas? E mais, se
rejeitarmos os modelos de processo tradicionais (e a ordem implcita) e substitu-los por algo
menos estruturado, tornaramos impossvel atingir a coordenao e a coerncia no trabalho de
software?
No h respostas fceis para essas questes, mas existem alternativas disponveis para os
engenheiros de software. Nas sees seguintes, examina-se a abordagem de processos prescritivos no qual a ordem e a consistncia do projeto so questes dominantes. Denominam-se
prescritivos porque prescrevem um conjunto de elementos de processo atividades metodolgicas, aes de engenharia de software, tarefas, produtos de traballho, garantia da qualidade
e mecanismos de controle de mudanas para cada projeto. Cada modelo de processo tambm
prescreve um fluxo de processo (tambm denominado fluxo de trabalho) ou seja, a forma pela
qual os elementos do processo esto inter-relacionados.
Todos os modelos de processo de software podem acomodar as atividades metodolgicas
genricas descritas no Captulo 1, porm, cada um deles d uma nfase diferente a essas atividades e define um fluxo de processo que invoca cada atividade metodolgica (bem como tarefas
e aes de engenharia de software) de forma diversa.

2.3.1O modelo cascata


h casos em que os requisitos de um problema so bem compreendidos quando o trabalho flui da comunicao ao emprego de forma relativamente linear. Essa situao ocorre
algumas vezes quando adaptaes ou aperfeioamentos bem definidos precisam ser feitos em
um sistema existente (por exemplo, uma adaptao em software contbil exigida devido a mudanas nas normas governamentais). Pode ocorrer tambm em um nmero limitado de novos
esforos de desenvolvimento, mas apenas quando os requisitos esto bem definidos e so razoavelmente estveis.
O modelo cascata, algumas vezes chamado ciclo de vida clssico, sugere uma abordagem
sequencial e sistemtica6 para o desenvolvimento de software, comeando com o levantamento de necessidades por parte do cliente, avanando pelas fases de planejamento, modelagem,
construo, emprego e culminando no suporte contnuo do software concludo (Figura 2.3).
5
6

Os modelos de processos prescritivos so, algumas vezes, conhecidos como modelos de processos tradicionais.
Embora o modelo cascata proposto por Winston Royce [Roy70] previsse os feedback loops, a vasta maioria das organizaes que aplica esse modelo de processo os trata como se fossem estritamente lineares.

60

PARTE 1O processo de Software

Figura 2.3
Comunicao

O modelo
cascata

O modelo V ilustra
como as aes
de verificao
e validao esto
associadas a aes de
engenharia anteriores.

incio do projeto
levantamento
de necessidades

Planejamento
estimativas
cronograma
acompanhamento

Modelagem
anlise
projeto

Construo
codificao
testes

Emprego
entrega
suporte
feedback

Uma variao na representao do modelo cascata denominada modelo V. Representado


na Figura 2.4, o modelo V [Buc99] descreve a relao entre aes de garantia da qualidade e as
aes associadas comunicao, modelagem e atividades de construo iniciais. medida que
a equipe de software desce em direo ao lado esquerdo do V, os requisitos bsicos do problema so refinados em representaes progressivamente cada vez mais detalhadas e tcnicas do
problema e de sua soluo. Uma vez que o cdigo tenha sido gerado, a equipe se desloca para
cima, no lado direito do V, realizando basicamente uma srie de testes (aes de garantia da
qualidade) que validem cada um dos modelos criados medida que a equipe se desloca para
baixo, no lado esquerdo do V.7 Na realidade, no existe uma diferena fundamental entre o ciclo
de vida clssico e o modelo V. O modelo V fornece uma forma para visualizar como a verificao
e as aes de validao so aplicadas ao trabalho de engenharia anterior.
O modelo cascata o paradigma mais antigo da engenharia de software. Entretanto, ao
longo das ltimas trs dcadas, as crticas a este modelo de processo fez com que at mesmo
seus mais ardentes defensores questionassem sua eficcia [Han95]. Entre os problemas s vezes
encontrados quando se aplica o modelo cascata, temos:

Figura 2.4
Modelo V

Modelagem
de requisitos

Teste de
aceitao

Projeto
da arquitetura

Teste
do sistema

Projeto dos
componentes

Gerao
de cdigo

Teste
de integrao

Teste
de unidades

Software
executvel
7

Na Parte 3 deste livro apresentada uma discusso detalhada sobre aes de garantia da qualidade.

61

captulo 2 Modelos de Processo

que
? Por
algumas

vezes o modelo
cascata falha?

Muito
frequentemente, o
trabalho de software
segue a primeira
lei do ciclismo: No
importa para onde se
esteja indo, sempre
ladeira acima e
contra o vento.
Autor
desconhecido

1. Projetos reais raramente seguem o fluxo sequencial que o modelo prope. Embora o modelo
linear possa conter iteraes, ele o faz indiretamente. Como consequncia, mudanas podem provocar confuso medida que a equipe de projeto prossegue.
2. Frequentemente, difcil para o cliente estabelecer explicitamente todas as necessidades. O
modelo cascata requer isso e tem dificuldade para adequar a incerteza natural que existe no
incio de muitos projetos.
3. O cliente deve ter pacincia. Uma verso operacional do(s) programa(s) no estar disponvel
antes de estarmos prximos do final do projeto. Um erro grave, se no detectado at o programa operacional ser revisto, pode ser desastroso.
Em uma interessante anlise de projetos reais, Bradac [Bra94] descobriu que a natureza
linear do ciclo de vida clssico conduz a estados de bloqueio, nos quais alguns membros da
equipe do projeto tm de aguardar outros completarem tarefas dependentes. De fato, o tempo
gasto na espera pode exceder o tempo gasto em trabalho produtivo! Os estados de bloqueio
tendem a prevalecer no incio e no final de um processo sequencial linear.
Hoje em dia, o trabalho de software tem um ritmo acelerado e est sujeito a uma cadeia de
mudanas interminveis (em caractersticas, funes e contedo de informaes). O modelo
cascata frequentemente inapropriado para tal trabalho. Entretanto, ele pode servir como um
modelo de processo til em situaes nas quais os requisitos so fixos e o trabalho deve ser
realizado at sua finalizao de forma linear.

2.3.2Modelos de processo incremental


O modelo incremental
libera uma srie de
verses, denominadas
incrementais,
que oferecem,
progressivamente,
maior funcionalidade
para o cliente
medida que cada
incremento
entregue.

Em vrias situaes, os requisitos iniciais do software so razoavelmente bem definidos,


entretanto, devido ao escopo geral do trabalho de desenvolvimento, o uso de um processo puramente linear no utilizado. Pode ser necessrio o rpido fornecimento de um determinado
conjunto funcional aos usurios, para somente aps esse fornecimento, refinar e expandir sua
funcionalidade em verses de software posteriores. Em tais casos, pode-se optar por um modelo de processo projetado para desenvolver o software de forma incremental.
O modelo incremental combina elementos dos fluxos de processos lineares e paralelos, discutidos na Seo 2.1. Na Figura 2.5, o modelo incremental aplica sequncias lineares, de forma
escalonada, medida que o tempo vai avanando. Cada sequncia linear gera incrementais
(entregveis/aprovados/liberados) do software [McD93] de maneira similar aos incrementais gerados por um fluxo de processos evolucionrios (Seo 2.3.3).

Figura 2.5
O modelo
incremental
Funcionalidade e Recursos do Software

Comunicao
Planejamento
Modelagem (anlise, projeto)

incremento no n

Construo (codificao, testes)


Emprego (entrega, realimentao ou feedback)

entrega do
n-simo incremento

incremento no 2

entrega do
2o incremento

incremento no 1

entrega do
1o incremento

Cronograma do Projeto

62

AVISO
Se o cliente precisa
da entrega at uma
determinada data
impossvel de ser
atendida, sugira a
entrega de um ou mais
incrementos at a data
e o restante do software
(incrementos adicionais)
posteriormente.

PARTE 1O processo de Software

Por exemplo, um software de processamento de texto desenvolvido com o emprego do paradigma incremental, poderia liberar funes bsicas de gerenciamento de arquivos, edio e produo de documentos no primeiro incremento; recursos mais sofisticados de edio e produo
de documentos no segundo; reviso ortogrfica e gramatical no terceiro; e, finalmente, recursos
avanados de formatao (layout) de pgina no quarto incremento. Deve-se notar que o fluxo de
processo para qualquer incremento pode incorporar o paradigma da prototipao.
Quando se utiliza um modelo incremental, frequentemente, o primeiro incremento um
produto essencial. Isto , as os requisitos bsicos so atendidos, porm, muitos recursos complementares (alguns conhecidos, outros no) ainda no so entregues. Esse produto essencial
utilizado pelo cliente (ou passa por uma avaliao detalhada). Como resultado do uso e/ou
avaliao, desenvolvido um planejamento para o incremento seguinte. O planejamento j considera a modificao do produto essencial para melhor se adequar s necessidades do cliente e
entrega de recursos e funcionalidades adicionais. Esse processo repetido aps a liberao de
cada incremento, at que seja produzido o produto completo.
O modelo de processo incremental tem seu foco voltado para a entrega de um produto operacional com cada incremento. Os primeiros incrementos so verses seccionadas do produto
final, mas eles realmente possuem capacidade para atender ao usurio e tambm oferecem uma
plataforma para avaliao do usurio.8
O desenvolvimento incremental particularmente til nos casos em que no h pessoal
disponvel para uma completa implementao na poca de vencimento do prazo estabelecido para o projeto. Os primeiros incrementos podem ser implementados com nmero mais
reduzido de pessoal. Se o produto essencial for bem acolhido, ento um pessoal adicional (se
necessrio) poder ser acrescentado para implementar o incremento seguinte. Alm disso, os
incrementos podem ser planejados para administrar riscos tcnicos. Por exemplo, um sistema
importante pode exigir a disponibilidade de novo hardware que ainda est em desenvolvimento
e cuja data de entrega incerta. Poderia ser possvel planejar incrementos iniciais de modo a
evitar o uso desse hardware, possibilitando, portanto, a liberao de funcionalidade parcial aos
usurios finais, sem um atraso excessivo.

2.3.3Modelos de processo evolucionrio


Os modelos de
processo evolucionrio
produzem uma
verso cada vez mais
completa do software
a cada iterao.

Planeje para jogar


algo fora. Voc ir
faz-lo de qualquer
maneira. Sua
escolha consistir
em decidir se deve
tentar ou no
vender o que foi
descartado aos
clientes.
Frederick P.
Brooks

Software, assim como todos sistemas complexos, evolui ao longo do tempo. Conforme o desenvolvimento do projeto avana, as necessidades de negcio e de produto mudam frequentemente, tornando inadequado seguir um planejamento em linha reta de um produto final. Prazos
apertados, determinados pelo mercado, tornam impossvel completar um produto de software
abrangente, porm uma verso limitada tem de ser introduzida para aliviar e/ou atender s presses comerciais ou da concorrncia. Um conjunto do produto essencial ou das necessidades do
sistema est bem compreendido, entretanto, detalhes de extenses do produto ou do sistema
ainda devem ser definidos. Em situaes como essa ou similares, faz-se necessrio um modelo
de processo que tenha sido projetado especificamente para desenvolver um produto que evolua
ao longo do tempo.
Modelos evolucionrios so iterativos. Apresentam caractersticas que possibilitam desenvolver verses cada vez mais completas do software. Nos pargrafos seguintes, so apresentados dois modelos comuns em processos evolucionrios.
Prototipao. Frequentemente, o cliente define uma srie de objetivos gerais para o software, mas no identifica, detalhadamente, os requisitos para funes e recursos. Em outros
casos, o desenvolvedor encontra-se inseguro quanto eficincia de um algoritmo, quanto
adaptabilidade de um sistema operacional ou quanto forma em que deva ocorrer a interao
homem/mquina. Em situaes como essas, e em muitas outras, o paradigma de prototipao
pode ser a melhor escolha de abordagem.
8

importante notar que uma filosofia incremental tambm utilizada em todos os modelos de processos geis, discutidos
no Captulo 3.

63

captulo 2 Modelos de Processo

AVISO
Quando seu cliente
tiver uma necessidade
legtima, mas sem
a mnima ideia em
relao a detalhes,
faa um prottipo para
uma primeira etapa.

Embora a prototipao possa ser utilizada como um modelo de processo isolado (stand-alone process) mais comumente utilizada como uma tcnica passvel de ser implementada no
contexto de qualquer um dos modelos de processo citados neste captulo. Independentemente
da forma como aplicado, quando os requisitos esto obscuros, o paradigma da prototipao
auxilia os interessados a compreender melhor o que est para ser construdo .
O paradigma da prototipao (Figura 2.6) comea com a comunicao. Faz-se uma reunio
com os envolvidos para definir os objetivos gerais do software, identificar quais requisitos j
so conhecidos e esquematizar quais reas necessitam, obrigatoriamente, de uma definio
mais ampla . Uma iterao de prototipao planejada rapidamente e ocorre a modelagem (na
forma de um projeto rpido). Um projeto rpido se concentra em uma representao daqueles
aspectos do software que sero visveis aos usurios finais (por exemplo, o layout da interface
com o usurio ou os formatos de exibio na tela).
O projeto rpido leva construo de um prottipo, que empregado e avaliado pelos envolvidos, que fornecero um retorno (feedback), que servir para aprimorar os requisitos. A iterao ocorre conforme se ajusta o prottipo s necessidades de vrios interessados e, ao mesmo
tempo, possibilita a melhor compreenso das necessidades que devem ser atendidas.
Na sua forma ideal, o prottipo atua como um mecanismo para identificar os requisitos do
software. Caso seja necessrio desenvolver um prottipo operacional, pode-se utilizar partes de
programas existentes ou aplicar ferramentas (por exemplo, geradores de relatrios e gerenciadores de janelas) que possibilitem gerar rapidamente tais programas operacionais.
O que fazer com o prottipo quando este j serviu ao propsito descrito anteriormente?
Brooks [Bro95] fornece uma resposta:
Na maioria dos projetos, o primeiro sistema dificilmente utilizvel. Pode estar muito lento,
muito grande, estranho em sua utilizao ou as trs coisas juntas. No h alternativa, a no ser
comear de novo, ressentindo-se, porm, mais esperto (aprimorado), e desenvolver uma verso
redesenhada na qual esses problemas so resolvidos.
O prottipo pode servir como o primeiro sistema. Aquele que Brooks recomenda que se
jogue fora. Porm, essa pode ser uma viso idealizada. Embora alguns prottipos sejam construdos como descartveis, outros so evolucionrios, no sentido de que evoluem lentamente
at se transformar no sistema real.
Tanto os interessados como os engenheiros de software gostam do paradigma da prototipao. Os usurios podem ter uma ideia prvia do sistema final, ao passo que os desenvolvedores

Figura 2.6
O paradigma da
prototipao
Comunicao

Projeto
rpido
Modelagem
Projeto rpido

Emprego
Entrega e
Realimentao

Construo
de um
prottipo

64

PARTE 1O processo de Software

passam a desenvolver algo imediatamente. Entretanto, a prototipao pode ser problemtica


pelas seguintes razes:
AVISO
Resista presso de
estender um prottipo
grosseiro a um produto
final. Quase sempre,
como resultado,
a qualidade fica
comprometida.

1. Os interessados enxergam o que parece ser uma verso operacional do software, ignorando que
o prottipo mantido de forma no organizada e que, na pressa de fazer com que ele se torne
operacional, no se considera a qualidade global do software, nem sua manuteno a longo
prazo. Quando informados que o produto deve ser reconstrudo para que altos nveis de qualidade possam ser mantidos, os interessados protestam e solicitam que umas poucas correes
sejam feitas para tornar o prottipo um produto operacional. Frequentemente, a gerncia do
desenvolvimento de software aceita.
2. O engenheiro de software, com frequncia, assume compromissos de implementao para
conseguir que o prottipo entre em operao rapidamente. Um sistema operacional ou linguagem de programao inapropriados podem ser utilizados simplesmente porque se encontram disposio e so conhecidos; um algoritmo ineficiente pode ser implementado
simplesmente para demonstrar capacidade. Aps um tempo, pode-se acomodar com tais
escolhas e esquecer todas as razes pelas quais eram inapropriadas. Uma escolha longe da
ideal acaba se tornando parte integrante do sistema.
Embora possam ocorrer problemas, a prototipao pode ser um paradigma efetivo para a
engenharia de software. O segredo definir as regras do jogo logo no incio; isso significa que
todos os envolvidos devem concordar que o prottipo construdo para servir como um mecanismo para definio de requisitos. Portanto, ser descartado (pelo menos em parte) e o software
final arquitetado visando qualidade.

C asa S egura
Seleo de um Modelo de Processo,
Parte 1
Cena: Sala de reunies da equipe de engenharia de software na CPI Corporation, uma empresa (fictcia) que
fabrica produtos de consumo para uso domstico e comercial.
Participantes: Lee Warren, gerente de engenharia; Doug Miller,
gerente de engenharia de software; Jamie Lazar, membro da equipe
de software; Vinod Raman, membro da equipe de software; e Ed
Robbins, membro da equipe de software.
A conversa:
Lee: Ento, vamos recapitular. Passei algum tempo discutindo
sobre a linha de produtos CasaSegura, da forma como a visualizamos no momento. Sem dvida, temos um monte de trabalho a
ser feito para simplesmente definir as coisas, mas eu gostaria que
vocs comeassem a pensar sobre como iro abordar a parte do
software deste projeto.
Doug: Parece que temos sido bastante desorganizados em nossa
abordagem sobre software no passado.
Ed: Eu no sei, Doug, ns sempre conseguimos entregar o produto.
Doug: verdade, mas no sem grande sofrimento, e esse projeto parece ser maior e mais complexo do que qualquer outro
que fizemos no passado.
Jamie: No parece assim to difcil, mas eu concordo... nossa abordagem ad hoc adotada para projetos anteriores no
dar certo neste caso, principalmente se tivermos um cronograma muito apertado.

Doug (sorrindo): Quero ser um pouco mais profissional em


nossa abordagem. Participei de um curso rpido na semana passada e aprendi bastante sobre engenharia de software... Bom
contedo. Precisamos de um processo aqui.
Jamie (franzindo a testa): Minha funo desenvolver programas, no ficar mexendo em papis.
Doug: D uma chance antes de me dizer no. Eis o que quero
dizer. [Doug prossegue descrevendo a metodologia de processo
descrita neste captulo e os modelos de processo prescritivos apresentados at agora.]
Doug: Mas de qualquer forma, parece-me que um modelo linear no adequado para ns... Ele assume que temos todos
os requisitos antecipadamente e, conhecendo este lugar, isso
pouco provvel.
Vinod: Isso mesmo, e parece orientado demais tecnologia
da informao... Provavelmente bom para construir um sistema
de controle de estoque ou algo parecido, mas certamente no
adequado para o CasaSegura.
Doug: Eu concordo.
Ed: Essa abordagem de prototipao me parece OK. Bastante
parecido com o que fazemos aqui.
Vinod: Isso um problema. Estou preocupado que ela no nos
d estrutura suficiente.
Doug: No para se preocupar. Temos um monte de outras opes e quero que vocs escolham o que for melhor para a equipe
e para o projeto.

65

captulo 2 Modelos de Processo

Modelo Espiral. Originalmente proposto por Barry Boehm [Boe88], o modelo espiral
um modelo de processo de software evolucionrio que acopla a natureza iterativa da prototipao com os aspectos sistemticos e controlados do modelo cascata. Fornece potencial para
o rpido desenvolvimento de verses cada vez mais completas do software. Boehm [Boe01a]
descreve o modelo da seguinte maneira:
O modelo espiral de desenvolvimento um gerador de modelos de processos dirigidos a riscos e utilizado para guiar a engenharia de sistemas intensivos de software, que ocorre de forma concorrente e
tem mltiplos envolvidos. Possui duas caractersticas principais que o distinguem. A primeira consiste
em uma abordagem cclica voltada para ampliar, incrementalmente, o grau de definio e a implementao de um sistema, enquanto diminui o grau de risco do mesmo. A segunda caracterstica consiste em
uma srie de pontos ncora de controle para assegurar o comprometimento de interessados quanto
busca de solues de sistema que sejam mutuamente satisfatrias e praticveis.

O modelo espiral pode


ser adaptado para ser
aplicado ao longo de
todo o ciclo de vida de
uma aplicao, desde
o desenvolvimento
de conceitos at sua
manuteno.

Usando-se o modelo espiral, o software ser desenvolvido em uma srie de verses evolucionrias. Nas primeiras iteraes, a verso pode consistir em um modelo ou em um prottipo.
J nas iteraes posteriores, so produzidas verses cada vez mais completas do sistema que
passa pelo processo de engenharia.
Um modelo espiral dividido em um conjunto de atividades metodolgicas definidas pela
equipe de engenharia de software. Para fins ilustrativos, utilizam-se as atividades metodolgicas genricas discutidas anteriormente.9 Cada uma dessas atividades representa um segmento
do caminho espiral ilustrado na Figura 2.7. Assim que esse processo evolucionrio comea, a
equipe de software realiza atividades indicadas por um circuito em torno da espiral no sentido horrio, comeando pelo seu centro. Os riscos (Captulo 28) so considerados medida
que cada revoluo realizada. Pontos ncora de controle uma combinao de produtos de
trabalho e condies que so satisfeitas ao longo do trajeto da espiral so indicados para
cada passagem evolucionria.
O primeiro circuito em volta da espiral pode resultar no desenvolvimento de uma especificao de produto; passagens subsequentes em torno da espiral podem ser usadas para desenvolver um prottipo e, ento, progressivamente, verses cada vez mais sofisticadas do software.
Cada passagem pela regio de planejamento resulta em ajustes no planejamento do projeto.

Figura 2.7
Modelo
espiral tpico

Planejamento
estimativa de custos
cronograma
anlise de riscos
Comunicao
Modelagem
anlise
projeto

Incio

Emprego

entrega
feedback

Construo
codificao
testes

O modelo espiral discutido nesta seo uma variao do modelo proposto por Boehm. Para mais informaes sobre o
modelo espiral original, consulte [Boe88]. Material mais recente sobre o modelo espiral de Boehm pode ser encontrado em
[Boe98].

66

PARTE 1O processo de Software

WebRef
Informaes teis
sobre o modelo espiral
podem ser obtidas
em: www.sei.cmu.
edu/publications/
documents/00.
reports/00sr008.
html.

AVISO
Se a gerncia quiser
um desenvolvimento
com oramento fixo
(geralmente uma
pssima ideia), a
espiral pode ser
um problema.
medida que cada
circuito for realizado,
o custo do projeto
ser repetidamente
revisado.
Estou to perto,
mas apenas o
amanh guia o meu
caminho.
Dave Matthews
Band

Custo e cronograma so ajustados de acordo com o feedback (a realimentao) obtido do cliente aps entrega. Alm disso, o gerente de projeto faz um ajuste no nmero de iteraes planejadas para completar o software.
Diferente de outros modelos de processo, que terminam quando o software entregue, o
modelo espiral pode ser adaptado para ser aplicado ao longo da vida do software. Portanto,
o primeiro circuito em torno da espiral pode representar um projeto de desenvolvimento de
conceitos que comea no ncleo da espiral e continua por vrias iteraes10, at que o desenvolvimento de conceitos esteja completo. Se o conceito for desenvolvido para ser um produto
final, o processo prossegue pela espiral pelas bordas e um novo projeto de desenvolvimento
de produto se inicia. O novo produto evoluir, passando por uma srie de iteraes, em torno
da espiral. Posteriormente, uma volta em torno da espiral pode ser usada para representar um
projeto de aperfeioamento do produto. Em sua essncia, a espiral, caracterizada dessa maneira, permanece em operao at que o software seja retirado. H casos em que o processo fica
inativo, porm, toda vez que uma mudana iniciada, comea no ponto de partida apropriado
(por exemplo, aperfeioamento do produto).
O modelo espiral uma abordagem realista para o desenvolvimento de sistemas e de software
em larga escala. Pelo fato de o software evoluir medida que o processo avana, o desenvolvedor e o cliente compreendem e reagem melhor aos riscos em cada nvel evolucionrio. Esse
modelo usa a prototipao como mecanismo de reduo de riscos e, mais importante, torna
possvel a aplicao da prototipao em qualquer estgio do processo evolutivo do produto.
Mantm a abordagem em etapas, de forma sistemtica, sugerida pelo ciclo de vida clssico,
mas a incorpora em uma metodologia iterativa que reflete mais realisticamente o mundo real. O
modelo espiral requer considerao direta dos riscos tcnicos em todos os estgios do projeto
e, se aplicado apropriadamente, reduz os riscos antes de se tornarem problemticos.
Mas como outros paradigmas, esse modelo no uma panaceia. Pode ser difcil convencer os clientes (particularmente em situaes contratuais) de que a abordagem evolucionria
controlvel. Ela exige considervel especializao na avaliao de riscos e depende dessa especializao para seu sucesso. Se um risco muito importante no for descoberto e administrado,
indubitavelmente ocorrero problemas.

C asa S egura
Seleo de um modelo de processo,
Parte 2
Cena: Sala de reunies do grupo de engenharia de software na CPI Corporation, empresa (fictcia) que
fabrica produtos de consumo de uso domstico e comercial.
Participantes: Lee Warren, gerente de engenharia; Doug Miller,
gerente de engenharia de software; Vinod e Jamie, membros da
equipe de engenharia de software.
Conversa: [Doug descreve as opes do processo evolucionrio.]
Jamie: Agora estou vendo algo de que gosto. Faz sentido
uma abordagem incremental e eu realmente gosto do fluxo dessa coisa de modelo espiral. Isso tem a ver com a realidade.
Vinod: Concordo. Entregamos um incremento, aprendemos
com o feedback do cliente, replanejamos e, ento, entregamos

outro incremento. Tambm se encaixa na natureza do produto.


Podemos colocar alguma coisa no mercado rapidamente, ter
algo no mercado e, depois, acrescentar funcionalidade a cada
verso, digo, incremento.
Lee: Espere um pouco, voc disse que reformulamos o plano a
cada volta na espiral, Doug? Isso no to legal; precisamos de
um plano, um cronograma e temos de nos ater a ele.
Doug: Essa linha de pensamento antiga, Lee. Como o pessoal
disse, temos de mant-lo real. Acho que melhor ir ajustando
o planejamento na medida em que formos aprendendo mais e
as mudanas sejam solicitadas. muito mais realista. Para que
serve um plano se no refletir a realidade?
Lee (franzindo a testa): Suponho que esteja certo, porm... A
alta gerncia no vai gostar disso... Querem um plano fixo.
Doug (sorrindo): Ento, voc ter que reeduc-los, meu amigo.

10 As setas que apontam para dentro, ao longo do eixo, separando a regio de emprego da regio de comunicao, indicam
potencial para iterao local ao longo do mesmo trajeto da espiral.

67

captulo 2 Modelos de Processo

2.3.4Modelos concorrentes

AVISO
O modelo concorrente,
com frequncia,
mais adequado para
projetos de engenharia
de produto nos quais
diferentes equipes
de engenharia esto
envolvidas.

O modelo de desenvolvimento concorrente, algumas vezes denominado engenharia concorrente, possibilita equipe de software representar elementos concorrentes e iterativos de
qualquer um dos modelos de processos descritos neste captulo. Por exemplo, a atividade de
modelagem definida para o modelo espiral realizada invocando uma ou mais das seguintes
aes de engenharia de software: prototipagem, anlise e projeto.11
A Figura 2.8 mostra um esquema de uma atividade da engenharia de software, dentro da
atividade de modelagem, usando uma abordagem de modelagem concorrente. A atividade
modelagem poderia estar em qualquer um dos estados12 observados em qualquer instante
determinado. Similarmente, outras atividades, aes ou tarefas (por exemplo, comunicao
ou construo) podem ser representadas de maneira anloga. Todas as atividades de engenharia de software existem concorrentemente, porm esto em diferentes estados.
Por exemplo, no incio de um projeto, a atividade de comunicao (no mostrada na figura)
completou sua primeira iterao e se encontra no estado aguardando modificaes. A atividade de modelagem (que se encontrava no estado inativo enquanto a comunicao inicial era
completada, agora faz uma transio para o estado em desenvolvimento. Se, entretanto, o
cliente indicar que mudanas nos requisitos devem ser feitas, a atividade de modelagem passa
do estado em desenvolvimento para o estado aguardando modificaes.
A modelagem concorrente define uma srie de eventos que iro disparar transies de
estado para estado para cada uma das atividades, aes ou tarefas da engenharia de software.

Figura 2.8
Um elemento do
modelo de processo
concorrente

Inativo
Atividade de modelagem
Representa o estado
de uma tarefa ou atividade
de engenharia de software

Em
desenvolvimento

Aguardando
modificaes

Em exame
Em reviso

Ponto de partida

Concludo

11 Deve-se notar que a anlise e o projeto so tarefas complexas que requerem discusso substancial. A Parte 2 deste livro considera esses tpicos em detalhe.
12 Um estado algum modo externamente observvel do comportamento.

68

Em todo processo
h um cliente, pois,
sem cliente, um
processo deixa de
ter sentido.
V. Daniel
Hunt

PARTE 1O processo de Software

Por exemplo, durante estgios de projeto iniciais (uma ao de engenharia de software importante que ocorre durante a atividade de modelagem), uma inconsistncia no modelo de
requisitos no descoberta. Isso gera o evento correo do modelo de anlise, que ir disparar
a ao de anlise de requisitos, passando do estado concludo para o estado aguardando
modificaes.
A modelagem concorrente se aplica a todos os tipos de desenvolvimento de software e fornece uma imagem precisa do estado atual de um projeto. Em vez de limitar as atividades, aes
e tarefas da engenharia de software a uma sequncia de eventos, ela define uma rede de processos. Cada atividade, ao ou tarefa na rede existe simultaneamente com outras atividades,
aes ou tarefas. Eventos gerados em um ponto da rede de processos disparam transies entre
os estados.

2.3.5Um comentrio final sobre processos evolucionrios


Como j foi mencionado anteriormente, os softwares modernos so caracterizados por contnuas modificaes, prazos muito apertados e por uma nfase na satisfao do clienteusurio.
Em muitos casos, o tempo de colocao de um produto no mercado o requisito mais importante a ser gerenciado. Se o momento oportuno de entrada no mercado for perdido, o projeto
de software pode ficar sem sentido.13
Os modelos de processo evolucionrio foram concebidos para tratar dessas questes e, mesmo assim, como uma classe genrica de modelos de processo, apresentam seus pontos fracos.
Esses pontos fracos foram resumidos por Nogueira e seus colegas [Nog00]:
Apesar dos inquestionveis benefcios proporcionados pelos processos de software evolucionrios,
temos algumas preocupaes. A primeira delas que a prototipao [e outros processos evolucionrios mais sofisticados] traz um problema para o planejamento do projeto devido ao nmero incerto
de ciclos necessrios para construir o produto. A maior parte das tcnicas de gerenciamento e de estimativas do projeto baseia-se em layouts lineares das atividades, o que faz com que no se adequem
completamente.
Em segundo lugar, os processos de software evolucionrios no estabelecem a velocidade mxima da
evoluo. Se as evolues ocorrerem numa velocidade excessivamente rpida, sem um perodo de acomodao, certo que o processo cair no caos. Por outro lado, se a velocidade for muito lenta, ento a
produtividade poderia ser afetada...
Em terceiro lugar, os processos de software devem manter seu foco mais na flexibilidade e na extensibilidade do que na alta qualidade. Essa afirmao soa assustadora. Entretanto, deve-se priorizar mais
a velocidade de desenvolvimento do que a do desenvolvimento com zero defeito. Prolongar o desenvolvimento em busca da alta qualidade pode resultar em entrega tardia do produto, quando o nicho de
oportunidade j desapareceu. Essa mudana de paradigma imposta pela concorrncia em situaes
em que se est beira do caos.

Realmente, um processo de software priorizando flexibilidade, extensibilidade e velocidade


de desenvolvimento, acima da alta qualidade, soa assustador. Ainda assim, essa ideia foi proposta por uma srie de renomados especialistas em engenharia de software (como, por exemplo, [You95], [Bac97]).
O objetivo dos modelos evolucionrios desenvolver software de alta qualidade14 de
modo iterativo ou incremental. Entretanto, possvel usar um processo evolucionrio para
enfatizar a flexibilidade, a extensibilidade e a velocidade do desenvolvimento. O desafio para
as equipes de software e seus gerentes ser estabelecer um equilbrio apropriado entre esses
parmetros crticos de projeto e produto e a satisfao dos clientes (o rbitro final da qualidade de um software).
13 importante notar, entretanto, que ser o primeiro a chegar ao mercado no sinnimo de sucesso. De fato, muitos produtos
de software bem-sucedidos foram o segundo ou at mesmo o terceiro a chegar ao mercado (aprendendo com os erros dos
outros que o antecederam).
14 Nesse contexto, a qualidade de software definida de forma bastante abrangente para englobar no apenas a satisfao dos
clientes, como tambm uma srie de critrios tcnicos, discutidos nos Captulos 14 e 16.

captulo 2 Modelos de Processo

2 .4

Modelos

de

69

Processo Especializado

Os modelos de processo especializado levam em conta muitas das caractersticas de um


ou mais dos modelos tradicionais apresentados nas sees anteriores. Tais modelos tendem a
ser aplicados quando se opta por uma abordagem de engenharia de software especializada ou
definida de forma restrita.15

2.4.1Desenvolvimento baseado em componentes


WebRef
Informaes teis sobre
desenvolvimento baseado em componentes
podem ser encontradas
em: www.cbd-hq.
com.

Componentes de software comercial de prateleira ou COTS (sigla para Commercial Off-TheShelf), desenvolvidos por vendedores que os oferecem como produtos, disponibilizam a funcionalidade almejada juntamente com as bem definidas interfaces, sendo que essas interfaces
permitem que o componente seja integrado ao software a ser desenvolvido. O modelo de desenvolvimento baseado em componentes incorpora muitas das caractersticas do modelo espiral.
evolucionrio em sua natureza [Nie92], demandando uma abordagem iterativa para a criao
de software. O modelo de desenvolvimento baseado em componentes desenvolve aplicaes a
partir de componentes de software pr-empacotados.
As atividades de modelagem e construo comeam com a identificao de possveis candidatos a componentes. Esses componentes podem ser projetados como mdulos de software
convencionais, como classes orientadas a objeto ou pacotes16 de classes. Independentemente da
tecnologia usada para criar os componentes, o modelo de desenvolvimento baseado em componentes incorpora as seguintes etapas (implementadas usando-se uma abordagem evolucionria):
1. Produtos baseados em componentes disponveis so pesquisados e avaliados para o campo
de aplicao em questo.
2. Itens de integrao de componentes so considerados.
3. Uma arquitetura de software projetada para acomodar os componentes.
4. Os componentes so integrados na arquitetura.
5. Testes completos so realizados para assegurar funcionalidade adequada.
O modelo de desenvolvimento baseado em componentes conduz ao reso do software e a
reusabilidade proporciona uma srie de benefcios mensurveis aos engenheiros de software. A
equipe de engenharia de software pode conseguir uma reduo no tempo do ciclo de desenvolvimento, bem como uma reduo no custo do projeto, caso a reutilizao de componentes se
torne parte de sua cultura. O desenvolvimento baseado em componentes discutido de forma
mais detalhada no Captulo 10.

2.4.2O modelo de mtodos formais


O modelo de mtodos formais engloba um conjunto de atividades que conduzem especificao matemtica formal do software. Os mtodos formais possibilitam especificar, desenvolver
e verificar um sistema baseado em computador atravs da aplicao de uma notao matemtica rigorosa. Uma variao dessa abordagem, chamada engenharia de software cleanroom (sala
limpa/leve/ntida) [Mil87, Dye92], aplicada atualmente por algumas organizaes de desenvolvimento de software.
Quando so utilizados mtodos formais (Captulo 21) durante o desenvolvimento, estes oferecem um mecanismo que elimina muitos dos problemas difceis de ser superados com o uso

15 Em alguns casos, esses modelos de processo especializado podem ser mais bem definidos como um conjunto de tcnicas, ou
uma metodologia, para alcanar uma meta de desenvolvimento de software especfica. Entretanto, eles realmente implicam
um processo.
16 Conceitos de orientao a objetos so discutidos no Apndice 2 e so usados ao longo da Parte 2 deste livro. Nesse contexto,
uma classe engloba um conjunto de dados e os procedimentos que processam os mesmos. Pacote de classes um conjunto de
classes relativas que operam juntas para alcanar algum resultado final.

70

PARTE 1O processo de Software

de outros paradigmas de engenharia de software. Ambiguidade, incompletude e inconsistncia


podem ser descobertas e corrigidas mais facilmente no por meio de uma reviso local, mas
devido aplicao de anlise matemtica. Quando so utilizados mtodos formais durante o
projeto, servem como base para verificar a programao e, portanto, possibilitam que se descubra e se corrijam erros que, de outra forma, poderiam passar despercebidos.
Embora no seja uma abordagem predominante, o modelo de mtodos formais oferece a
promessa de software sem defeitos. No entanto, foram mencionados motivos para preocupao
a respeito de sua aplicabilidade em um ambiente de negcios:

? Semtodos

formais so
capazes de
demonstrar
correo de
software, por
que no so
amplamente
utilizados?

Atualmente, o desenvolvimento de modelos formais consome muito tempo e dinheiro.


Pelo fato de poucos desenvolvedores de software possurem formao e experincia necessrias (background) para aplicao dos mtodos formais, necessrio treinamento
extensivo.
difcil usar os modelos como um meio de comunicao com clientes tecnicamente despreparados (no sofisticados tecnicamente).
Apesar de tais preocupaes, a abordagem de mtodos formais tem conquistado adeptos
entre os desenvolvedores de software que precisam desenvolver software com fator crtico de
segurana (como, por exemplo, os desenvolvedores de sistemas avinicos para aeronaves e
equipamentos mdicos), bem como entre desenvolvedores que sofreriam pesadas sanes econmicas se ocorressem erros no software.

2.4.3Desenvolvimento de software orientado a aspectos


WebRef
Uma ampla gama de
recursos e informaes
sobre AOP pode ser
encontrada em:
aosd.net.

A AOSD define
aspectos
representando
restries do cliente
que cruzam vrias
funes, recursos
e informaes do
sistema.

Independentemente do processo de software escolhido, os desenvolvedores de software


complexos, invariavelmente, implementam um conjunto de recursos, funes e contedo localizados. Essas caractersticas de software localizadas so modeladas como componentes (por
exemplo, classes orientadas a objetos) e, em seguida, construdas dentro do contexto da arquitetura do sistema. medida que os modernos sistemas baseados em computadores se tornam
mais sofisticados (e complexos), certas restries propriedades exigidas pelo cliente ou reas
de interesse tcnico se estendem por toda a arquitetura. Algumas restries so propriedades
de alto nvel de um sistema (por exemplo, segurana, tolerncia a falhas). Outras afetam funes
(por exemplo, a aplicao de regras de negcio), sendo que outras so sistmicas (por exemplo,
sincronizao de tarefas ou gerenciamento de memria).
Quando restries cruzam mltiplas funes, recursos e informaes do sistema, elas so,
frequentemente, denominadas restries cruzadas. Os requisitos de aspectos definem as restries cruzadas que tm um impacto por toda a arquitetura de software. O desenvolvimento de
software orientado a aspectos AOSD, Aspect-Oriented Software Development), com frequncia
conhecido como programao orientada a aspectos (AOP, Aspect-Oriented Programming), um
paradigma de engenharia de software relativamente novo que oferece uma abordagem metodolgica e de processos para definir, especificar, projetar e construir aspectos mecanismos
alm das sub-rotinas e herana para localizar a expresso de uma restrio cruzada [Elr01].
Grundy [Gru02] discute ainda mais os aspectos no contexto do que ele denomina engenharia
de componentes orientada a aspectos (AOCE, aspect-oriented component engineering):
A AOCE usa um conceito de fatias horizontais atravs de componentes de software decompostos verticalmente, chamados aspectos, para caracterizar propriedades funcionais ou no funcionais cruzadas
dos componentes. Aspectos sistmicos, comuns, incluem interfaces com o usurio, trabalho colaborativo, distribuio, persistncia, gerenciamento de memria, processamento de transaes, segurana,
integridade e assim por diante. Os componentes podem fornecer ou requerer um ou mais detalhes de
aspecto relativo a um determinado aspecto, tais como um mecanismo de visualizao, exequibilidade
extensvel e gnero de interface (aspectos da interface com o usurio); gerao de eventos, transporte
e recebimento (aspectos de distribuio); armazenamento/recuperao e indexao de dados (aspectos
de persistncia); autenticao, codificao e direitos de acesso (aspectos de segurana); atomicidade

captulo 2

71

MODELOS DE PrOCESSO

de transaes, controle de concorrncia e estratgia de entrada no sistema (aspectos transacionais) e


assim por diante. Cada detalhe de aspecto possui uma srie de propriedades relativas a caractersticas
funcionais e no funcionais do detalhe do aspecto.

Um processo distinto orientado a aspectos ainda no atingiu sua maturao. Entretanto,


provvel que um processo desses ir adotar caractersticas tanto dos modelos de processo
evolucionrio quanto de concorrente. O modelo evolucionrio apropriado quando os aspectos
so identificados e ento construdos. A natureza paralela do desenvolvimento concorrente
essencial, porque os aspectos so criados independentemente de componentes de software localizado e, apesar disso, os aspectos tm um impacto direto sobre esses componentes. Portanto, essencial instanciar comunicao assncrona entre as atividades de processos de software
aplicadas na engenharia e construo de aspectos e componentes.
Uma discusso detalhada sobre desenvolvimento de software orientado a aspectos mais
bem colocada em livros dedicados ao assunto. Se tiver mais interesse, consulte [Saf08], [Cla05],
[Jac04] e [Gra03].

FERRAMENTAS DO SOFTWARE
Gerenciamento de processos
Objetivo: ajudar na definio, execuo e gerenciamento de modelos de processos prescritivos.
Mecnica: as ferramentas de gerenciamento de processo possibilitam que uma organizao ou equipe de software definam
um modelo de processo de software completo (atividades metodolgicas, aes, tarefas, pontos de verificao para garantia da qualidade, pontos de controle (marcos) e artefatos de
software). Alm disso, tais ferramentas acabam fornecendo um
mapeamento (guia), conforme os engenheiros de software realizam o trabalho tcnico, e tambm propiciam um modelo para
os gerentes, os quais tm o dever de acompanhar e controlar o
processo de software.
Ferramentas Representativas: o GDPA, um conjunto de
ferramentas para denio de processos de pesquisa, desen17

2.5

volvido na Universidade de Bremen, na Alemanha (www.


informatik.uni-bremen.de/uniform/gdpa/home.
htm), fornece uma grande quantidade de funes de gerenciamento e modelagem de processos.
O SpeeDev, desenvolvido pela SpeeDev Corporation (www.
speedev.com) engloba um conjunto de ferramentas
para definio de processo, gerenciamento de requisitos,
resoluo de itens, planejamento e acompanhamento de
projetos.
O ProVision BPMx, desenvolvido pela Proforma (www.pro
formacorp.com), representante de muitas ferramentas
que auxiliam na definio de processo e automao de
uxo de trabalho.
Uma lista valiosa de diversas ferramentas diferentes associadas
ao processo de software, pode ser encontrada no endereo
www.processwave.net/Links/tool_links.htm.

o ProCesso unifiCado
No livro que deu origem ao Processo Unificado, Ivar Jacobson, Grady Booch e James Rumbaugh
[Jac99] discutem a necessidade de um processo de software dirigido a casos de uso, centrado
na arquitetura, iterativo e incremental ao afirmarem:
Hoje em dia, a tendncia do software no sentido de sistemas maiores e mais complexos. Isso se deve,
em parte, ao fato de que os computadores tornam-se mais potentes a cada ano, levando os usurios a
ter uma expectativa maior em relao a eles. Essa tendncia tambm foi influenciada pelo uso crescente da Internet para troca de todos os tipos de informao... Nosso apetite por software cada vez mais
sofisticado aumenta medida que tomamos conhecimento de uma verso do produto para a seguinte,
como o produto pode ser aperfeioado. Queremos software que seja mais e mais adaptado a nossas
necessidades, mas isso, por sua vez, simplesmente torna o software mais complexo. Em suma, queremos cada vez mais.

De certa forma, o Processo Unificado uma tentativa de aproveitar os melhores recursos


e caractersticas dos modelos tradicionais de processo de software, mas caracterizando-os
de modo a implementar muitos dos melhores princpios do desenvolvimento gil de software
(Captulo 3). O Processo Unificado reconhece a importncia da comunicao com o cliente e de
mtodos racionalizados (sequencializados) para descrever a viso do cliente sobre um sistema (os

72

PARTE 1O processo de Software

casos de uso17). Ele enfatiza o importante papel da arquitetura de software e ajuda o arquiteto a
manter o foco nas metas corretas, tais como compreensibilidade, confiana em mudanas futuras
e reutilizao [Jac99]. Ele sugere um fluxo de processo iterativo e incremental, proporcionando a
sensao evolucionria que essencial no desenvolvimento de software moderno.

2.5.1 Breve histrico


Durante o incio dos anos 1990, James Rumbaugh [Rum91], Grady Booch [Boo94] e Ivar
Jacobson [Jac92] comearam a trabalhar em um mtodo unificado que combinaria as melhores
caractersticas de cada um de seus mtodos individuais de anlise e projeto orientados a objetos
e adotaram caractersticas adicionais propostas por outros especialistas (por exemplo, [Wir90])
em modelagem orientada a objetos. O resultado foi a UML uma linguagem de modelagem
unificada que contm uma notao robusta para a modelagem e o desenvolvimento de sistemas
orientados a objetos. Por volta de 1997, a UML tornou-se um padro de fato da indstria em
termos de desenvolvimento de software orientado a objetos.
A UML usada ao longo da Parte 2 deste livro para representar tanto modelos de projeto
quanto de requisitos. O Apndice 1 apresenta um tutorial introdutrio para aqueles que no esto familiarizados com as regras bsicas de notaes e de modelagem da UML. Uma apresentao completa da UML fica reservada a livros-texto dedicados ao assunto. Livros recomendados
esto relacionados no Apndice 1.
A UML forneceu a tecnologia necessria para dar suporte prtica de engenharia de software
orientada a objetos, mas no ofereceu a metodologia de processo para orientar as equipes
de projeto na aplicao da tecnologia. Ao longo de poucos anos que se seguiram, Jacobson,
Rumbaugh e Booch desenvolveram o Processo Unificado, uma metodologia para engenharia de
software orientada a objetos usando a UML. Hoje em dia, o Processo Unificado (PU ou UP, Unified Process) e a UML so amplamente utilizados em projetos orientados a objetos de todos os
tipos. O modelo incremental e iterativo proposto pelo PU pode e deve ser adaptado para atender
necessidades de projeto especficas.

2.5.2 Fases do processo unificado18

Em seu intento, as
fases do Processo
Unificado so
similares s atividades
metodolgicas
genricas definidas
neste livro.

No incio deste captulo, foram apresentadas cinco atividades metodolgicas genricas e argumentos afirmando que elas poderiam ser usadas para descrever qualquer modelo de processo
de software. O Processo Unificado no nenhuma exceo. A Figura 2.9 descreve as fases do
PU e as relaciona com as atividades genricas que foram discutidas no Captulo 1 e anteriormente neste captulo.
A fase de concepo (Inception) do PU envolve tanto a atividade de comunicao com o cliente
como a de planejamento. Colaborando com os interessados, identificam-se as necessidades de
negcio para o software; prope-se uma arquitetura rudimentar para o sistema e se desenvolve
um planejamento para a natureza iterativa e incremental do projeto decorrente. Requisitos de negcio fundamentais so descritos por meio de um conjunto de casos prticos preliminares (Captulo 5), descrevendo quais recursos e funes cada categoria principal de usurio deseja. At esse
ponto, a arquitetura nada mais do que um esquema provisrio dos principais subsistemas e da
funo e dos recursos que os compem. Posteriormente, a arquitetura ser refinada e expandida
para um conjunto de modelos que representaro vises diferentes do sistema. O planejamento
identifica recursos, avalia os principais riscos, define um cronograma e estabelece uma base para
as fases que sero aplicadas medida que o incremento de software desenvolvido.
A fase de elaborao envolve atividades de comunicao e modelagem do modelo de processo genrico (Figura 2.9). A elaborao refina e expande os casos prticos preliminares, desenvol17 Um caso de uso (Captulo 5) uma narrativa textual ou modelo que descreve uma funo ou recurso de um sistema do ponto de
vista do usurio. Um caso de uso escrito pelo usurio e serve como base para criao de um modelo de requisitos mais amplo.
18 O Processo Unificado , algumas vezes, chamado de Processo Unificado Racional RUP, Rational Unified Process) em homenagem a Rational Corporation (posteriormente adquirida pela IBM), um dos primeiros contribuidores para o desenvolvimento e
refinamento do PU e um desenvolvedor de ambientes completos (ferramentas e tecnologia) que do suporte ao processo.

73

captulo 2 Modelos de Processo

Figura 2.9
O Processo
Unificado

Elaborao

Concepo
to
jamen
plane

nica

comu

lagem

mode

uo

constr

ego

empr

Verso
incremento
de software

Construo
Transio

Produo

WebRef
Uma interessante
abordagem sobre o
PU, dentro do contexto
de desenvolvimento
gil, poder ser
encontrada em www.
ambysoft.com/
unifiedprocess/
agileUP.html.

vidos como parte da fase de concepo, e amplia a representao da arquitetura, incluindo cinco
vises diferentes do software: modelo de caso prtico, modelo de requisitos, modelo de projeto,
modelo de implementao e modelo de emprego. Em alguns casos, a elaborao gera uma
base de arquitetura executvel [Arl02], consistindo num sistema executvel de degustao.19
Essa base demonstra a viabilidade da arquitetura, mas no oferece todos os recursos e funes
necessrias para usar o sistema. Alm disso, no auge da fase de elaborao, o plano revisado
cuidadosamente para assegurar que escopo, riscos e datas de entrega permaneam razoveis.
Normalmente, as modificaes no planejamento so feitas nesta oportunidade.
A fase de construo do PU idntica atividade de construo definida para o processo de
software genrico. Tendo como entrada (input) o modelo de arquitetura, a fase de construo
desenvolve ou adquire componentes de software; esses componentes faro com que cada caso
prtico (de uso) se torne operacional para os usurios finais. Para tanto, os modelos de requisitos e de projeto, iniciados durante a fase de elaborao, so completados para refletir a verso
final do incremento de software. Ento, implementa-se, no cdigo-fonte, todos os recursos e
funes necessrias e exigidas para o incremento de software (isto , para a verso). medida
que os componentes esto sendo implementados, desenvolve-se e executam-se testes de unidades20 para cada um deles. Alm disso, realizam-se atividades de integrao (montagem de
componentes e testes de integrao). Os casos prticos so usados para obter um pacote de
testes de aceitao, executados antes do incio da fase seguinte do PU.
A fase de transio do PU abarca os ltimos estgios da atividade da construo genrica e a
primeira parte da atividade de emprego genrico: entrega e realimentao (feedback). Entrega-se o software aos usurios finais para testes beta e o feedback dos usurios relata defeitos e
mudanas necessrias. Alm disso, a equipe de software elabora material com as informaes
de apoio (por exemplo, manuais para o usurio, guias para resoluo de problemas, procedimentos de instalao) que so necessrias para lanamento da verso. Na concluso da fase de
transio, o incremento torna-se uma verso do software utilizvel.
A fase de produo do PU coincide com a atividade de emprego do processo genrico. Durante
essa fase, monitora-se o uso contnuo do software, disponibiliza-se suporte para o ambiente (infraestrutura) operacional, realiza-se e avalia-se relatrios de defeitos e solicitaes de mudanas.
19 importante observar que a base da arquitetura no um prottipo, j que ela no descartada. Ao contrrio, a base ganha
corpo durante a fase seguinte do PU.
20 Uma discusso extensiva de testes de software (inclusive testes de unidades) apresentada nos Captulos 17 a 20.

74

PARTE 1O processo de Software

provvel que, ao mesmo tempo em que as fases de construo, transio e produo estejam sendo conduzidas, j se tenha iniciado o incremento de software seguinte. Isso significa que
as cinco fases do PU no ocorrem em sequncia, mas sim de forma concorrente e escalonada.
Um fluxo de trabalho de engenharia de software distribudo ao longo de todas as fases
do PU. Nesse contexto, um fluxo de trabalho anlogo a um conjunto de tarefas (descrito anteriormente neste captulo), isto , identifica as tarefas para realizar uma importante ao de
engenharia de software e os artefatos produzidos como consequncia da finalizao de tarefas
com xito. Deve-se notar que nem toda tarefa identificada para um fluxo de trabalho do PU
conduzida em todos os projetos de software. A equipe adapta o processo (aes, tarefas, subtarefas e artefatos de software) para ficar de acordo com suas necessidades.

2 .6
Pessoas
bem-sucedidas
desenvolveram,
simplesmente, o
hbito de realizar
coisas que as
fracassadas no
iro fazer.
Dexter Yager

Modelos

de

Processo Pessoal

e de

Equipe

O melhor processo de software aquele prximo s pessoas que realizaro o trabalho. Se


um modelo de processo de software for desenvolvido em nvel corporativo ou organizacional,
ele apenas ser efetivo se for aberto a significativas adaptaes a fim de atender s necessidades da equipe de projeto (aquela que est efetivamente realizando o trabalho de engenharia de
software). Num cenrio ideal, voc desenvolveria um processo que melhor se adequasse s suas
necessidades e, simultaneamente, atendesse s necessidades mais amplas da equipe e da organizao. De forma alternativa, a prpria equipe pode criar seu prprio processo e, ao mesmo
tempo, atender s necessidades mais especficas dos indivduos e s necessidades mais amplas
da organizao. Watts Humphrey ([Hum97] e [Hum00]) afirmam que possvel criar um processo de software pessoal e/ou um processo de software da equipe. Ambos requerem trabalho
rduo, treinamento e coordenao, mas so alcanveis.21

2.6.1Processo de Software Pessoal (PSP)

WebRef
Uma grande quantidade
de recursos para PSP
encontrada em www.
ipd.uka.de/PSP/.

? Quais
atividades

metodolgicas so
utilizadas durante
o PSP?

Todo desenvolvedor utiliza algum processo para construir software. Esse processo pode ser
nebuloso ou especfico; pode mudar diariamente; no ser eficiente, efetivo ou bem-sucedido; porm, um processo realmente existe. Watts Humphrey [Hum97] sugere que a fim de modificar
um processo pessoal no efetivo, um indivduo deve passar por quatro fases, cada uma exigindo
treinamento e orquestrao cuidadosa. O Processo de Software Pessoal (sigla PSP, Personal Software Process) enfatiza a medio pessoal, tanto do artefato de software gerado quanto da qualidade resultante dele. Alm disso, responsabiliza o profissional pelo planejamento de projetos (por
exemplo, estimativa de custos e cronograma) e lhe d poder para controlar a qualidade de todos
os artefatos de software desenvolvidos. O modelo PSP define cinco atividades estruturais:
Planejamento. Essa atividade isola os requisitos e desenvolve as estimativas de porte e
de recursos. Alm disso, faz-se uma estimativa dos defeitos (o nmero de defeitos estimado
para o trabalho). Registram-se todas as mtricas em formulrios ou planilhas. Finalmente,
identificam-se as tarefas de desenvolvimento e faz-se um cronograma para o projeto.
Projeto de alto nvel. Desenvolvem-se especificaes externas para cada componente a
ser construdo e elabora-se um projeto de componentes. Quando h incerteza, constroem-se
prottipos. Todos os problemas so registrados e localizados.
Reviso de projeto de alto nvel. Aplicam-se mtodos de verificao formais (Captulo
21) para revelar erros no projeto. Mtricas so mantidas para todos os resultados de trabalho
e tarefas importantes.
Desenvolvimento. O projeto em nvel de componentes refinado e revisado. Cdigo
gerado, revisado, compilado e testado. Mtricas so mantidas para todos os resultados de
trabalho e tarefas importantes.

21 Vale notar que os defensores do desenvolvimento gil de software (Captulo 3) tambm afirmam que o processo deve ficar
prximo equipe. Eles propem um mtodo alternativo para conseguir isso.

captulo 2 Modelos de Processo

75

Autpsia. Usando as medidas e mtricas coletadas (trata-se de um volume de dados substancial que deve ser analisado estatisticamente), determinada a eficcia do processo. Medidas e mtricas devem guiar as mudanas no processo de modo a melhorar sua eficincia.

O PSP enfatiza a
necessidade de
registrar e analisar
tipos de erros
cometidos, para que
se possa elaborar
estratgias para
elimin-los.

O PSP enfatiza a necessidade de identificar erros precocemente e, to importante quanto,


compreender os tipos de erros que provavelmente ocorrero. Isso obtido por meio de uma
rigorosa atividade de avaliao em todos os artefatos de software gerados.
O PSP representa uma abordagem disciplinada e baseada em mtricas para a engenharia
de software que pode causar um choque cultural em muitos profissionais. Entretanto, quando
apresentado de forma apropriada aos engenheiros de software [Hum96], a melhoria resultante
na produtividade da engenharia e na qualidade de software significativa [Fer97]. Apesar disso,
no foi adotado largamente pelo setor. Os motivos, infelizmente, tm mais a ver com a natureza
humana e com a inrcia organizacional do que com os pontos fortes e fracos da abordagem PSP.
Esse processo intelectualmente desafiador e exige um nvel de comprometimento (por parte
dos profissionais e de seus gerentes) que nem sempre possvel alcanar. O perodo de treinamento relativamente longo e os custos de treinamento so altos. O nvel de medio exigido
culturalmente difcil para muitos profissionais da rea de software.
O PSP pode ser utilizado como um processo de software eficaz no nvel pessoal? A resposta
um inequvoco sim. Porm, mesmo se no adotado em sua totalidade, muitos dos conceitos de
aperfeioamento do processo pessoal que introduz so importantes e vale a pena aprend-los.

2.6.2Processo de Software em Equipe (TSP)


WebRef
Informaes sobre a
formao de equipes
com alto desempenho
empregando-se TSP e
PSP podem ser obtidas
em: www.sei.cmu.
edu/tsp/.

AVISO
Para formar uma
equipe autodirigida,
deve haver boa
colaborao
internamente e
boa comunicao
externamente.

Pelo fato de muitos projetos de software para nvel industrial serem tratados por uma equipe
de profissionais, Watts Humphrey estendeu as lies aprendidas com a introduo do PSP e props um Processo de Software em Equipe (TSP, Team Software Process). O objetivo do TSP criar
uma equipe de projetos autodirigida, que se organize por si mesma para produzir software de
alta qualidade. Humphrey [Hum98] define os seguintes objetivos para o TSP:
C
riar equipes autodirigidas que planejem e acompanhem seu prprio trabalho, estabeleam metas e sejam proprietrias de seus processos e planos. As equipes podero ser
puras ou equipes de produto integradas (IPTs, integrated product teams) com cerca de 3
a 20 engenheiros.
Mostrar aos gerentes como treinar e motivar suas equipes e como ajud-las a manter
alto desempenho.
Acelerar o aperfeioamento dos processos de software, tornando o comportamento CMM22 Nvel 5 algo normal e esperado.
Fornecer orientao para melhorias a organizaes com elevado grau de maturidade.
Facilitar o ensino universitrio de habilidades de trabalho em equipe de nvel industrial.
Uma equipe autodirigida possui um entendimento consistente de suas metas e objetivos globais; define papis e responsabilidades para cada um dos membros; monitora dados quantitativos de projeto (produtividade e qualidade); identifica um processo de equipe que seja apropriado
para o projeto em questo e uma estratgia para implementao do processo; define padres
locais que sejam aplicveis ao trabalho de engenharia da equipe; avalia continuamente os riscos
e reage a eles e, finalmente, acompanha, gerencia e gera relatrios sobre a situao do projeto.
O TSP define as seguintes atividades metodolgicas: lanamento do projeto, projeto de
alto nvel, implementao, integrao e testes e autpsia. Assim como seus equivalentes no PSP (note que a terminologia ligeiramente diferente), essas atividades capacitam a
equipe a planejar, projetar e construir software de maneira disciplinada, ao mesmo tempo em

22 O Modelo de Maturidade de Capacidade (CMM, Capability Maturity Model), uma medida da eficincia de um processo de
software, discutido no Captulo 30.

76

paRtE 1

Os roteiros (scripts)
do TSP definem
os elementos e as
atividades realizadas
no transcorrer do
processo.

2.7

o ProCesso De software

que mede quantitativamente o processo e o produto. A autpsia representa o estgio para melhorias dos processos.
Esse processo faz uso de uma grande variedade de roteiros (scripts), formulrios e padres
que servem para orientar os membros da equipe em seu trabalho. Os roteiros definem atividades
de processos especficas (isto , lanamento do projeto, projeto, implementao, integrao e
testes do sistema, autpsia) e outras funes de trabalho mais detalhadas (por exemplo, planejamento do desenvolvimento, desenvolvimento de requisitos, gerenciamento das configuraes
de software, teste de unidade) que fazem parte do processo de equipe.
O TSP reconhece que as melhores equipes de software so autodirigidas.23 Seus membros
estabelecem os objetivos do projeto, adaptam o processo para atender suas necessidades, controlam o cronograma e, atravs de medies e anlise das mtricas coletadas, trabalham continuamente para aperfeioar a abordagem em relao engenharia de software.
Assim como o PSP, o TSP uma rigorosa abordagem da engenharia de software que fornece
benefcios distintos e quantificveis para a produtividade e para a qualidade. A equipe deve se
comprometer totalmente com o processo e deve passar por treinamento consciente para assegurar que a abordagem seja apropriadamente aplicada.

teCnologia

de

ProCessos

Um ou mais dos modelos de processo discutidos nas sees anteriores devem ser adaptados
para ser empregados por uma equipe de software. Para tanto, desenvolveram-se ferramentas
de tecnologia de processos, com o objetivo de auxiliar organizaes de software a analisar seus
processos atuais, organizar tarefas de trabalho, controlar e monitorar o progresso, bem como
administrar a qualidade tcnica.24
As ferramentas de tecnologia de processos permitem a uma organizao de software construir um modelo automatizado da metodologia de processos, conjuntos de tarefas e atividades
de apoio (umbrella activities), discutidos na Seo 2.1. O modelo, normalmente representado
como uma rede, pode, ento, ser analisado para determinar o fluxo de trabalho tpico e exa-

FERRAMENTAS DO SOFTWARE
Ferramentas de modelagem de
processos
Objetivo: quando uma organizao trabalha
para aprimorar um processo de negcio (ou de software),
ela precisa, primeiramente, compreend-lo. As ferramentas
de modelagem de processos (tambm chamadas ferramentas
de tecnologia de processos ou ferramentas de gerenciamento
de processos) so usadas para representar elementos-chave
de um processo para que possa ser mais bem compreendido.
Essas ferramentas podem tambm oferecer links para descries de processos, ajudando os envolvidos no processo a
compreender as aes e tarefas necessrias para realiz-lo. As
ferramentas de modelagem de processos fornecem links para
outras ferramentas que oferecem suporte para atividades de
processos definidas.
Mecnica: as ferramentas nesta categoria permitem a uma
equipe de desenvolvimento definir os elementos de um modelo

nico de processo (aes, tarefas, artefato, pontos de garantia da qualidade de software), dar orientao detalhada sobre
o contedo ou descrio de cada elemento de um processo
e, ento, gerenciar o processo conforme ele for conduzido.
Em alguns casos, as ferramentas de tecnologia de processos
incorporam tarefas padronizadas de gerenciamento de projeto como estimativa de custos, cronograma, acompanhamento
e controle.
Ferramentas Representativas:
Igrafx Process Tools ferramentas que capacitam uma equipe a mapear, medir e modelar o processo de software
(www.micrografx.com)
Adeptia BPM Server projetada para gerenciar, automatizar
e otimizar processos de negcio (www.adeptia.com)
SpeedDev Suite conjunto de seis ferramentas com forte nfase no gerenciamento das atividades de comunicao e
modelagem (www.speedev.com)

23 No Captulo 3 discutiremos a importncia das equipes auto-organizadas como um elemento-chave no desenvolvimento de


software gil.
24 As ferramentas aqui citadas no representam um aval, mas sim uma amostragem de ferramentas nesta categoria. Na maioria dos
casos, os nomes das ferramentas so marcas registradas de seus respectivos desenvolvedores.

captulo 2 Modelos de Processo

77

minar estruturas de processos alternativas que possam levar reduo de custos e tempo de
desenvolvimento.
Uma vez criado um processo aceitvel, outras ferramentas de tecnologia de processo podero ser usadas para alocar, monitorar e at mesmo controlar todas as atividades, aes e
tarefas de engenharia de software definidas como parte do modelo de processo. Cada membro
da equipe poder usar tais ferramentas para desenvolver uma lista de controle das tarefas a ser
realizadas, dos artefatos de software a ser gerados e das atividades de garantia da qualidade a
ser realizadas. A ferramenta de tecnologia de processos tambm pode ser usada para coordenar
o uso de outras ferramentas de engenharia de software que so apropriadas para uma determinada tarefa.

2.8

Processo

do

Produto

Se o processo for fraco, certamente o produto final sofrer consequncias. Porm, uma confiana excessiva e obsessiva no processo igualmente perigosa. Em um breve artigo, escrito
muitos anos atrs, Margaret Davis [Dav95a] tece comentrios atemporais sobre a dualidade
produto e processo:
Aproximadamente a cada dez anos (acrescente ou elimine cinco), a comunidade de software
redefine o problema, mudando seu foco de itens do produto para itens de processo. Assim,
adotamos linguagens de programao estruturada (produto), seguidas por mtodos de anlise estruturada (processo), seguidos pelo encapsulamento de dados (produto), seguido pela
nfase atual no Modelo de Maturao da Capacidade de Desenvolvimento de Software (processo), do Software Engineering Institute [seguido por mtodos orientados a objeto, seguido
pelo desenvolvimento de software gil].
Enquanto a tendncia natural de um pndulo a de vir repousar num ponto intermedirio
entre dois extremos, o foco da comunidade de software muda constantemente, pois nova
fora aplicada quando a ltima oscilao falha. Essas oscilaes causam danos para si
mesmos e para o ambiente externo, confundindo o profissional tpico de software, mudando
radicalmente o que significava desempenhar bem seu trabalho. Essas oscilaes tambm
no resolvem o problema, pois esto fadadas ao insucesso, enquanto produto e processo
forem tratados como formando uma dicotomia (diviso de um conceito em dois elementos,
em geral, contrrios) em vez de uma dualidade (coexistncia de dois princpios).
Na comunidade cientfica, h precedentes da tendncia para adotar noes de dualidade
quando, nas observaes, as contradies no podem ser explicadas completamente nem
por uma nem por outra teoria que competem entre si. A natureza dual da luz, parecendo ser
simultaneamente partcula e onda, foi aceita desde os anos 1920, quando Louis de Broglie
a props. Pelas observaes feitas dos artefatos de software e de seu desenvolvimento, fica
demonstrada a existncia de uma dualidade fundamental entre produto e processo. Jamais
poderemos destrinchar ou compreender o artefato completo, seu contexto, uso, significado
e valor se o enxergarmos apenas ou como um processo ou um produto...
Todas as atividades humanas podem ser um processo, mas todos sentem-se valorizados
quando tais atividades se tornam uma representao ou um exemplo, sendo utilizadas ou
apreciadas por mais de uma pessoa, repetidamente, ou ento utilizadas num contexto no
imaginado. Ou seja, extramos sentimentos de satisfao na reutilizao de nossos produtos,
seja por ns mesmos, seja por outros.
Assim, enquanto a assimilao rpida das metas de reso, no desenvolvimento de software,
aumenta potencialmente a satisfao dos profissionais de software, ela tambm aumenta
a urgncia da aceitao da dualidade produto e processo. Enxergar um artefato reutilizvel
apenas como um produto ou apenas como um processo, obscurece o contexto e as maneiras
de us-lo, ou obscurece o fato de que cada uso resulta em produto que, por sua vez, ser
utilizado como entrada, em alguma outra atividade de desenvolvimento de software. Adotar

78

PARTE 1O processo de Software

uma dessas vises em detrimento da outra reduz dramaticamente as oportunidades de reutilizao e, portanto, perde-se a oportunidade de aumentar a satisfao no trabalho.
As pessoas obtm satisfao tanto do processo criativo quanto do produto final. Um artista
sente prazer tanto de suas pinceladas quanto do resultado geral de seu quadro. Um escritor sente prazer tanto da procura da metfora apropriada quanto do livro finalizado. Como profissional
de software criativo, voc tambm deve extrair tanta satisfao do processo como do produto
final. A dualidade produto e processo um elemento importante para manter pessoas criativas
engajadas medida que a engenharia de software continua a evoluir.

2.9

Resumo
Um modelo de processo genrico para engenharia de software consiste num conjunto de
atividades metodolgicas e de apoio (umbrella activities), aes e tarefas a realizar. Cada modelo
de processo, dentre os vrios existentes, pode ser descrito por um fluxo de processo diferente
descrio de como as atividades metodolgicas, aes e tarefas so organizadas sequencial e
cronologicamente. Padres de processo so utilizados para resolver problemas comuns encontrados como parte do processo de software.
Os modelos de processo prescritivos so aplicados h anos, num esforo para organizar e
estruturar o desenvolvimento de software. Cada um desses modelos sugere um fluxo de processos ligeiramente diferente, mas todos realizam o mesmo conjunto de atividades metodolgicas
genricas: comunicao, planejamento, modelagem, construo e emprego.
Os modelos de processo sequenciais, tais como o de cascata e o modelo V, so os paradigmas da engenharia de software mais antigos. Eles sugerem um fluxo de processos linear que,
frequentemente, inadequado para considerar as caractersticas dos sistemas modernos (por
exemplo, contnuas alteraes, sistemas em evoluo, prazos apertados). Entretanto, eles tm,
realmente, aplicabilidade em situaes em que os requisitos so bem definidos e estveis.
Modelos de processo incremental so iterativos por natureza e produzem rapidamente verses operacionais do software. Modelos de processos evolucionrios reconhecem a natureza
iterativa e incremental da maioria dos projetos de engenharia de software e so projetados
para adequar mudanas. Esses modelos, como prototipao e o modelo espiral, produzem rapidamente artefatos de software incrementais (ou verses operacionais do software). Podem
ser adotados para ser aplicados por todas as atividades de engenharia de software desde o
desenvolvimento de conceitos at a manuteno do sistema a longo prazo.
Modelo de processo concorrente possibilita que uma equipe de software represente elementos iterativos e concorrentes de qualquer modelo de processo. Modelos especializados incluem
o modelo baseado em componentes (que enfatiza a montagem e a reutilizao de componentes); o modelo de mtodos formais (que encoraja uma abordagem matemtica para o desenvolvimento e a verificao de software); e o modelo orientado a aspectos (que considera interesses
cruzados que se estendem por toda a arquitetura do sistema). O Processo Unificado um processo de software dirigido a casos prticos, centrado na arquitetura, iterativo e incremental,
desenvolvido como uma metodologia para os mtodos e ferramentas da UML.
Modelos pessoal e de equipe enfatizam a medio, o planejamento e autodirecionamento
como ingredientes-chave para um processo de software bem-sucedido.

Problemas

Pontos

Ponderar

2.1. Na introduo deste captulo, Baetjer observa: O processo oferece interao entre usurios e projetistas, entre usurios e ferramentas em evoluo e entre projetistas e ferramentas [de tecnologia] em evoluo. Liste cinco perguntas que (a) os projetistas deveriam fazer
aos usurios, (b) os usurios deveriam fazer aos projetistas, (c) os usurios deveriam fazer a
si mesmos sobre o produto de software a ser desenvolvido, (d) os projetistas deveriam fazer

79

captulo 2 Modelos de Processo

a si mesmos sobre o produto de software a ser construdo e sobre o processo que ser usado
para constru-lo.
2.2. Tente desenvolver um conjunto de aes para a atividade de comunicao. Selecione
uma ao e defina um conjunto de tarefas para ela.
2.3. Durante a comunicao, um problema comum ocorre ao encontrarmos dois interessados com ideias conflitantes sobre como o software deveria ser. Isto , h requisitos mutuamente conflitantes. Desenvolva um padro de processo (que seja um padro de estgio)
usando o modelo apresentado na Seo 2.1.3 que se refere a esse problema, e sugira uma
abordagem efetiva para ele.
2.4. Pesquise sobre o PSP e faa uma breve apresentao descrevendo os tipos de medidas
que um engenheiro de software individual deve fazer e como tais medidas podem ser usadas
para aprimorar sua eficcia pessoal.
2.5. O uso de roteiros (scripts um mecanismo exigido no TSP) no universalmente apreciado na comunidade de software. Faa uma lista dos prs e contras referentes aos roteiros
e sugira pelo menos duas situaes nas quais seriam teis e outras duas onde poderiam
oferecer menos benefcio.
2.6. Leia [Nog00] e redija um artigo de duas ou trs pginas que discuta o impacto do caos
na engenharia de software.
2.7. Fornea trs exemplos de projetos de software que seriam suscetveis ao modelo cascata. Seja especfico.
2.8. Fornea trs exemplos de projetos de software que seriam suscetveis ao modelo de
prototipao. Seja especfico.
2.9. Quais adaptaes de processo seriam necessrias caso o prottipo fosse se transformar
em um sistema ou produto a ser entregue?
2.10. Fornea trs exemplos de projetos de software que seriam suscetveis ao modelo incremental. Seja especfico.
2.11. medida que se desloca para fora, ao longo do fluxo de processo em espiral, o que
pode ser dito em relao ao software que est sendo desenvolvido ou sofrendo manuteno?
2.12. possvel combinar modelos de processo? Em caso positivo, d um exemplo.
2.13. O modelo de processo concorrente define um conjunto de estados. Descreva, com
suas prprias palavras, o que esses estados representam e, em seguida, indique como entram
em cena no modelo de processos concorrentes.
2.14. Quais so as vantagens e desvantagens em desenvolver software cuja qualidade boa
o suficiente? Ou seja, o que acontece quando enfatizamos a velocidade de desenvolvimento
em detrimento da qualidade do produto?
2.15. Fornea trs exemplos de projetos de software que seriam suscetveis ao modelo baseado em componentes. Seja especfico.
2.16. possvel provar que um componente de software e at mesmo um programa inteiro
est correto. Ento, por que todo mundo no faz isso?
2.17. Processo Unificado e UML so a mesma coisa? Justifique sua resposta.

Leituras

Fontes

de

I n f o r m a o C o m p l e m e n ta r e s

A maioria dos livros texto sobre engenharia de software considera os modelos de processo
tradicionais com certo nvel de detalhe. Livros como os de Sommerville (Software Engineering,
8. ed., Addison-Wesley, 2006), Pfleeger e Atlee (Software Engineering, 3. ed., Prentice-Hall,
2005) e Schach (Engenharia de Software: Os Paradigmas Clssico e Orientado a Objetos, 7.
ed., McGraw-Hill, 2009) falam sobre os paradigmas tradicionais e discutem seus pontos fortes e fracos. Glass (Facts and Fallacies of Software Engineering, Prentice-Hall, 2002) fornece

80

PARTE 1O processo de Software

uma viso nua e crua, bem como pragmtica, do processo de engenharia de software. Embora no seja especificamente dedicado a processos, Brooks (The Mythical Man-Month, 2. ed.,
Addison-Wesley, 1995) apresenta conhecimentos sbios de projeto antigo que tm tudo a ver
com processos.
Firesmith e Henderson-Sellers (The OPEN Process Framework: An Introduction, Addison-Wesley, 2001) apresenta um quadro geral para a criao de processos de software flexveis
e que, ainda assim, no deixam de ser disciplinados e discute atributos e objetivos dos
processos. Madachy (Software Process Dynamics, Wiley-IEEE, 2008) fala sobre tcnicas de
modelagem que possibilitam a anlise dos elementos tcnicos e sociais inter-relacionados
do processo de software. Sharpe e McDermott (Workflow Modeling: Tools for Process Improvement and Application Development, Artech House, 2001) apresenta ferramentas para modelagem de processos de software, bem como de processos de negcios.
Lim (Managing Software Reuse, Prentice Hall, 2004) discute a reutilizao sob a perspectiva gerencial. Ezran, Morisio e Tully (Practical Software Reuse, 2002) e Jacobson, Griss e
Jonsson (Software Reuse, Addison-Wesley, 1997) apresentam informaes muito teis sobre
desenvolvimento baseado em componentes. Heineman e Council (Component-Based Software
Engineering, Addison-Wesley, 2001) descrevem o processo exigido para implementar sistemas baseados em componentes. Kenett e Baker (Software Process Quality: Management and
Control, Marcel Dekker, 1999) colocam como a gesto da qualidade e o projeto de processos
esto intimamente ligados entre si.
Nygard (Release It!: Design and Deploy Production-Ready Software, Pragmatic Bookshelf,
2007) e Richardson e Gwaltney (Ship it! A Practical Guide to Successful Software Projects,
Pragmatic Bookshelf, 2005) apresentam um amplo conjunto de diretrizes teis aplicveis
atividade de emprego.
Alm do livro seminal de Jacobson, Rumbaugh e Booch sobre o Processo Unificado
[Jac99], livros como os de Arlow e Neustadt (UML 2 and the Unified Process, Addison-Wesley,
2005), Kroll e Kruchten (The Rational Unified Process Made Easy, Addison-Wesley, 2003) e
Farve (UML and the Unified Process, IRM Press, 2003) fornecem excelentes informaes complementares. Gibbs (Project Management with the IBM Rational Unified Process, IBM Press,
2006) fala sobre o gerenciamento de projetos no contexto do PU.
Uma ampla variedade de fontes de informao sobre engenharia de software e o processo de software est disponvel na Internet. Uma lista atualizada de referncias relevantes
para o processo de software pode ser encontrada no site www.mhhe.com/engcs/compsci/
pressman/professional/olc/ser.htm.

captulo

Desenvolvimento gil

Conceitos- Chave
agilidade . . . . . . . . 82
Crystal . . . . . . . . . 97
desenvolvimento
de software
adaptativo . . . . . . . 94
desenvolvimento de
software enxuto
(LSD) . . . . . . . . . . . 99
DSDM . . . . . . . . . . 96
Extreme Programming
XP (programao
extrema) . . . . . . . . 87
FDD . . . . . . . . . . . . 98
histrias . . . . . . . . 89
processo gil . . . . . 85
drocesso unificado
gil . . . . . . . . . . . 101
processo XP . . . . . . 89
programao em
duplas . . . . . . . . . . 88

m 2001, Kent Beck e outros dezesseis renomados desenvolvedores, autores e consultores da rea de software [Bec01a] (batizados de Agile Alliance- Aliana dos
geis) assinaram o Manifesto para o Desenvolvimento gil de Software (Manifesto for Agile Software Development), que se inicia da seguinte maneira:
Desenvolvendo e ajudando outros a desenvolver software, estamos desvendando formas melhores de desenvolvimento. Por meio deste trabalho passamos a valorizar:
Indivduos e interaes acima de processos e ferramentas
Software operacional acima de documentao completa
Colaborao dos clientes acima de negociao contratual
Respostas a mudanas acima de seguir um plano
Ou seja, embora haja valor nos itens direita, valorizaremos os da esquerda mais ainda.

Normalmente, um manifesto associado a um movimento poltico emergente: atacando a velha guarda e sugerindo uma mudana revolucionria (espera-se que para melhor).
De certa forma, exatamente do que trata o desenvolvimento gil.
Embora as ideias bsicas que norteiam o desenvolvimento gil tenham estado conosco
por muitos anos, s h menos de duas dcadas que se consolidaram como um movimento.

O que ? A engenharia de software

Panorama gil combina filosofia com um conjunto

de princpios de desenvolvimento. A filosofia defende a satisfao do cliente e a


entrega de incremental prvio; equipes de projeto
pequenas e altamente motivadas; mtodos informais; artefato de engenharia de software mnimos
e, acima de tudo, simplicidade no desenvolvimento geral. Os princpios de desenvolvimento priorizam a entrega mais que anlise e projeto (embora
essas atividades no sejam desencorajadas); tambm priorizam a comunicao ativa e contnua
entre desenvolvedores e clientes.
Quem realiza? Os engenheiros de software e
outros envolvidos no projeto (gerentes, clientes,
usurios finais) trabalham conjuntamente em uma
equipe gil uma equipe que se auto-organiza
e que controla seu prprio destino. Uma equipe
gil acelera a comunicao e a colaborao entre
todos os participantes (que esto a seu servio).
Por que importante? O moderno ambiente dos
sistemas e dos produtos da rea acelerado e
est em constante mudana. A engenharia de software gil constitui uma razovel alternativa para
a engenharia convencional voltada para certas

classes de software e para certos tipos de projetos,


e tem se mostrado capaz de entregar sistemas
corretos rapidamente.
Quais so as etapas envolvidas? O desenvolvimento gil poderia ser mais bem denominado
engenharia de software flexvel. As atividades
metodolgicas bsicas permanecem: comunicao, planejamento, modelagem, construo e
emprego. Entretanto, estas se transformam em
um conjunto de tarefas mnimas que impulsiona a
equipe para o desenvolvimento e para a entrega
(pode-se levantar a questo de que isso feito em
detrimento da anlise do problema e do projeto
de solues).
Qual o artefato? Tanto o cliente como o engenheiro tm o mesmo parecer: o nico artefato
realmente importante consiste em um incremento
de software operacional que seja entregue, adequadamente, na data combinada.
Como garantir que o trabalho foi realizado
corretamente? Se a equipe gil concordar
que o processo funciona e essa equipe produz
incrementos de software passveis de entrega e
que satisfaam o cliente, ento, o trabalho est
correto.

81

82

PARTE 1O processo de Software

retrabalho . . . .
scrum . . . . . . .
velocidade
de projeto . . . .
XP Industrial . .

87
95
86
91

Agilidade: 1,
todo o resto: 0.
Tom DeMarco

3.1

Em essncia, mtodos geis1 se desenvolveram em um esforo para sanar fraquezas reais e


perceptveis da engenharia de software convencional. O desenvolvimento gil oferece benefcios
importantes, no entanto, no indicado para todos os projetos, produtos, pessoas e situaes.
Tambm no a anttese da prtica de engenharia de software consistente e pode ser aplicado
como uma filosofia geral para todos os trabalhos de software.
Na economia moderna frequentemente difcil ou impossvel prever como um sistema computacional (por exemplo, uma aplicao baseada na Web) ir evoluir com o tempo. As condies
de mercado mudam rapidamente, as necessidades dos usurios finais se alteram e novas ameaas competitivas emergem sem aviso. Em muitas situaes, no se conseguir definir completamente requisitos antes que se inicie o projeto. preciso ser gil o suficiente para dar uma
resposta ao ambiente de fluido negcios.
Fluidez implica mudanas, e mudanas so caras. Particularmente, se forem sem controle e
mal gerenciadas. Uma das caractersticas mais convincentes da abordagem gil sua habilidade
de reduzir os custos da mudana ao longo de todo o processo de software.
Isso significa que o reconhecimento dos desafios apresentados pela moderna realidade faz
com que se descartem valiosos princpios da engenharia de software, conceitos, mtodos e
ferramentas? Absolutamente no! Como todas as disciplinas de engenharia, a engenharia de
software continua a evoluir, podendo ser adaptada facilmente aos desafios apresentados pela
demanda por agilidade.
Em um texto que nos leva reflexo sobre desenvolvimento de software gil, Alistair Cockburn [Coc02] argumenta que o modelo de processo prescritivo, apresentado no Captulo 2, tem
uma falha essencial: esquece das fragilidades das pessoas que desenvolvem o software. Os engenheiros de software no so robs. Eles apresentam grande variao nos estilos de trabalho;
diferenas significativas no nvel de habilidade, criatividade, organizao, consistncia e espontaneidade. Alguns se comunicam bem na forma escrita, outros no. Cockburn afirma que os
modelos de processos podem lidar com as fraquezas comuns das pessoas com disciplina e/ou
tolerncia e que a maioria dos modelos de processos prescritivos opta por disciplina. Segundo
ele: Como a consistncia nas aes uma fraqueza humana, as metodologias com disciplina
elevada so frgeis.
Para que funcionem, os modelos de processos devem fornecer um mecanismo realista que
estimule a disciplina necessria ou, ento, devem ter caractersticas que apresentem tolerncia com as pessoas que realizam trabalhos de engenharia de software. Invariavelmente, prticas tolerantes so mais facilmente adotadas e sustentadas pelas pessoas envolvidas, porm
(como o prprio Cockburn admite) podem ser menos produtivas. Como a maioria das coisas na
vida, deve-se considerar os prs e os contras.

que

Agilidade?

No contexto da engenharia de software, o que agilidade? Ivar Jacobson [Jac02a] apresenta


uma til discusso:
Atualmente, agilidade tornou-se a palavra da moda quando se descreve um moderno processo de software. Todo mundo gil. Uma equipe gil aquela rpida e capaz de responder apropriadamente a mudanas. Mudanas tm muito a ver com desenvolvimento de software. Mudanas no software que est
sendo criado, mudanas nos membros da equipe, mudanas devido a novas tecnologias, mudanas de
todos os tipos que podero ter um impacto no produto que est em construo ou no projeto que cria
o produto. Suporte para mudanas deve ser incorporado em tudo o que fazemos em software, algo
que abraamos porque o corao e a alma do software. Uma equipe gil reconhece que o software
desenvolvido por indivduos trabalhando em equipes e que as habilidades dessas pessoas, suas capacidades em colaborar esto no cerne do sucesso do projeto.

Os mtodos geis so algumas vezes conhecidos como mtodos light ou mtodos enxutos (lean methods).

83

captulo 3 DESENVOLVIMENTO GIL

AVISO
No cometa o erro
de assumir que a
agilidade lhe dar
licena para abreviar
solues. Processo
um requisito e
disciplina essencial.

3.2
A agilidade
dinmica, de
contedo especfico,
abrange mudanas
agressivas e
orientada ao
crescimento.
Steven
Goldman et al.

Segundo Jacobson, a penetrao da mudana o principal condutor para a agilidade. Os


engenheiros de software devem ser rpidos em seus passos caso queiram assimilar as rpidas
mudanas que Jacobson descreve.
Porm, agilidade consiste em algo mais que uma resposta mudana, abrangendo a filosofia
proposta no manifesto citado no incio deste captulo. Ela incentiva a estruturao e as atitudes
em equipe que tornam a comunicao mais fcil (entre membros da equipe, entre o pessoal
ligado tecnologia e o pessoal da rea comercial, entre os engenheiros de software e seus gerentes). Enfatiza a entrega rpida do software operacional e diminui a importncia dos artefatos
intermedirios (nem sempre um bom negcio); assume o cliente como parte da equipe de desenvolvimento e trabalha para eliminar a atitude de ns e eles, que continua a invadir muitos
projetos de software; reconhece que o planejamento em um mundo incerto tem seus limites e
que o plano (roteiro) de projeto deve ser flexvel.
A agilidade pode ser aplicada a qualquer processo de software. Entretanto, para obt-la, essencial que seja projetado para que a equipe possa adaptar e alinhar (racionalizar) tarefas; possa
conduzir o planejamento compreendendo a fluidez de uma abordagem do desenvolvimento gil;
possa eliminar tudo, exceto os artefatos essenciais, conservando-os enxutos; e enfatize a estratgia de entrega incremental, conseguindo entregar ao cliente, o mais rapidamente possvel, o
software operacional para o tipo de produto e ambiente operacional.

Agilidade

e o

Custo

da s

Mudana s

A sabedoria convencional em desenvolvimento de software (baseada em dcadas de experincia) afirma que os custos de mudanas aumentam de forma no linear conforme o projeto
avana (Figura 3.1, curva em preto contnuo). relativamente fcil assimilar uma mudana
quando uma equipe de software est juntando requisitos (no incio de um projeto). Pode-se
ter de alterar um detalhamento do uso, ampliar uma lista de funes ou editar uma especificao por escrito. Os custos de tal trabalho so mnimos e o tempo demandado no afetar
negativamente o resultado do projeto. Mas se adiantarmos alguns meses, o que aconteceria? A
equipe est em meio aos testes de validao (que ocorre relativamente no final do projeto) e um
importante interessado est requisitando uma mudana funcional de vulto. A mudana requer
uma alterao no projeto da arquitetura do software, o projeto e desenvolvimento de trs novos
componentes, modificaes em outros cinco componentes, projeto de novos testes, e assim por
diante. Os custos crescem rapidamente e no sero triviais o tempo e custos necessrios para
assegurar que a mudana seja feita sem efeitos colaterais inesperados.

Custos de
alteraes como
uma funo do
tempo em
desenvolvimento

Custo de desenvolvimento

Figura 3.1

Custo de alteraes
usando-se processos de
software convencionais
Custo de alteraes
usando-se processos geis

Custo ideal de alteraes


usando-se processo gil
Progresso do cronograma de desenvolvimento

84

PARTE 1O processo de Software

Um processo gil reduz


o custo das alteraes
porque o software
entregue (liberado) de
forma incremental e as
alteraes podem ser
mais bem controladas
dentro de incrementais.

3 .3

Os defensores da agilidade (por exemplo, [Bec00], [Amb04]) argumentam que um processo gil bem elaborado achata o custo da curva de mudana (Figura 3.1, curva em linha
verde), permitindo que uma equipe de software assimile as alteraes, realizadas posteriormente em um projeto de software, sem um impacto significativo nos custos ou no tempo. J
foi mencionado que o processo gil envolve entregas incrementais. O custo das mudanas
atenuado quando a entrega incremental associada a outras prticas geis, como testes contnuos de unidades e programao por pares, (discutida adiante neste captulo). H
evidncias [CocO1a] que sugerem que se pode alcanar reduo significativa nos custos
de alteraes, embora haja um debate contnuo sobre qual o nvel em que a curva de custos torna-se achatada.

que

Processo gil?

Qualquer processo gil de software caracterizado de uma forma que se relacione a uma
srie de preceitos-chave [Fow02] acerca da maioria dos projetos de software:
1. difcil afirmar antecipadamente quais requisitos de software iro persistir e quais sofrero
alteraes. igualmente difcil prever de que maneira as prioridades do cliente sofrero alteraes conforme o projeto avana.
WebRef
Uma vasta coleo
de artigos sobre
processo gil pode
ser encontrada em
www.aanpo.org/
articles/index.

Embora processos
geis considerem as
alteraes, examinar
as razes para tais
mudanas ainda
continua sendo
importante.

2. Para muitos tipos de software, o projeto e a construo so interconduzidos. Ou seja, ambas as atividades devem ser realizadas em sequncia (uma atrs da outra), para que os modelos de projeto sejam provados conforme sejam criados. difcil prever quanto de trabalho
de projeto ser necessrio antes que a sua construo (desenvolvimento) seja implementada
para avaliar o projeto.
3. Anlise, projeto, construo (desenvolvimento) e testes no so to previsveis (do ponto de
vista de planejamento) quanto gostaramos que fosse.
Dados esses trs preceitos, surge uma importante questo: Como criar um processo capaz
de administrar a imprevisibilidade? A resposta, conforme j observado, consiste na adaptabilidade de processo (para alterar rapidamente o projeto e as condies tcnicas). Portanto, um
processo gil deve ser adaptvel.
Mas adaptao contnua sem progressos que levem em frente o desenvolvimento realiza
muito pouco. Um processo gil de software deve adaptar incrementalmente. Para conseguir uma
adaptao incremental, a equipe gil precisa de feedback do cliente (de modo que as adaptaes
apropriadas possam ser feitas). Um efetivo catalisador para feedback de cliente um prottipo
operacional ou parte de um sistema operacional. Dessa forma, deve se instituir uma estratgia
de desenvolvimento incremental. Os incrementos de software (prottipos executveis ou partes
de um sistema operacional) devem ser entregues em curtos perodos de tempo, de modo que
as adaptaes acompanhem o mesmo ritmo das mudanas (imprevisibilidade). Essa abordagem
iterativa capacita o cliente a avaliar o incremento de software regularmente, fornecer o feedback
necessrio para a equipe de software e influenciar as adaptaes de processo feitas para incluir
adequadamente o feedback.

3.3.1Princpios da agilidade
A Agile Alliance (veja [Agi03], [Fow01]) estabelece 12 princpios de agilidade para quem quiser ter agilidade:
1. A maior prioridade satisfazer o cliente por meio de entrega adiantada e contnua de software valioso.
2. Acolha bem os pedidos de alteraes, mesmo atrasados no desenvolvimento. Os processos geis se aproveitam das mudanas como uma vantagem competitiva na relao com o
cliente.

captulo 3 DESENVOLVIMENTO GIL

85

3. Entregue software em funcionamento frequentemente, de algumas semanas para alguns


meses, dando preferncia a intervalos mais curtos.
4. O pessoal comercial e os desenvolvedores devem trabalhar em conjunto diariamente ao
longo de todo o projeto.
AVISO
Software ativo
importante, mas no
se deve esquecer
que tambm deve
apresentar uma
srie de atributos de
qualidade, incluindo
confiabilidade,
usabilidade e facilidade
de manuteno.

5. Construa projetos em torno de indivduos motivados. D a eles o ambiente e apoio necessrios e confie neles para ter o trabalho feito.
6. O mtodo mais eficiente e efetivo de transmitir informaes para e dentro de uma equipe
de desenvolvimento uma conversa aberta, de forma presencial
7. Software em funcionamento a principal medida de progresso.
8. Os processos geis promovem desenvolvimento sustentvel. Os proponentes, desenvolvedores e usurios devem estar capacitados para manter um ritmo constante indefinidamente.
9. Ateno contnua para com a excelncia tcnica e para com bons projetos aumenta a agilidade.
10. Simplicidade a arte de maximizar o volume de trabalho no efetuado essencial.
11. As melhores arquiteturas, requisitos e projetos emergem de equipes que se auto-organizam.
12. A intervalos regulares, a equipe se avalia para ver como tornar-se mais eficiente, ento
sintoniza e ajusta seu comportamento de acordo.
Nem todo modelo de processo gil aplica esses 12 princpios atribuindo-lhes pesos iguais, e
alguns modelos preferem ignorar (ou pelo menos relevam) a importncia de um ou mais desses
princpios. Entretanto, os princpios definem um esprito gil mantido em cada um dos modelos
de processo apresentados neste captulo.

3.3.2A poltica do desenvolvimento gil

AVISO
Voc no tem de
escolher entre
agilidade ou
engenharia de
software.
Em vez disso, defina
uma abordagem
de engenharia de
software que seja gil.

H debates considerveis (algumas vezes acirrados) sobre os benefcios e a aplicabilidade


do desenvolvimento de software gil em contraposio a processos de engenharia de software
mais convencionais. Jim Highsmith [Hig02a] (em tom jocoso) estabelece extremos ao caracterizar o sentimento do grupo pr-agilidade (os agilistas). Os metodologistas tradicionais so
um bando de ps na lama que preferem produzir documentao sem falhas em vez de um
sistema que funcione e atenda s necessidades do negcio. Em um contraponto, ele apresenta
(mais uma vez, em tom jocoso) a posio do grupo da engenharia de software tradicional: Os
metodologistas de pouco peso, quer dizer, os metodologistas geis so um bando de hackers
pretensiosos que vo acabar tendo uma grande surpresa ao tentarem transformar seus brinquedinhos em software de porte empresarial.
Como toda argumentao sobre tecnologia de software, o debate sobre metodologia corre o
risco de descambar para uma guerra santa. Se for deflagrada uma guerra, a racionalidade desaparece e crenas, em vez de fatos, orientaro a tomada de deciso.
Ningum contra a agilidade. A verdadeira questo : Qual a melhor maneira de atingi-la? Igualmente importante, como desenvolver software que atenda s necessidades atuais dos
clientes e que apresente caractersticas de qualidade que permitiro que seja estendido e ampliado para responder s necessidades dos clientes no longo prazo?
No h respostas absolutas para nenhuma dessas questes. Mesmo na prpria escola gil, existem vrios modelos de processos propostos (Seo 3.4), cada um com uma abordagem sutilmente
diferente a respeito do problema da agilidade. Em cada modelo existe um conjunto de ideias (os
agilistas relutam em cham-las tarefas de trabalho) que representam um afastamento significativo
da engenharia de software tradicional. E, ainda assim, muitos conceitos geis so apenas adaptaes de bons conceitos da engenharia de software. Concluso: pode-se ganhar muito considerando
o que h de melhor nas duas escolas e praticamente nada denegrindo uma ou outra abordagem.
Caso se interesse mais, veja [Hig01], [Hig02a] e [DeM02], em que apresentado um sumrio
interessante a respeito de outras questes tcnicas e polticas importantes.

86

PARTE 1O processo de Software

3.3.3 Fatores humanos


Muito da agilidade
dos mtodos deriva
do fato de terem
suas bases no
conhecimento tcito
incorporado pela
e na equipe, em
vez de registrar
por escrito tal
conhecimento em
planejamentos.

Os defensores do desenvolvimento de software gil se esmeram para enfatizar a importncia


dos fatores humanos. Como afirmam Cockburn e Highsmith [Coc01a], O desenvolvimento
gil foca talentos e habilidades de indivduos, moldando o processo de acordo com as pessoas
e as equipes especficas. O ponto-chave nessa afirmao que o processo se amolda s necessidades das pessoas e equipes, e no o caminho inverso.2
Se os membros da equipe de software devem orientar as caractersticas do processo que
aplicado para construir software, deve existir um certo nmero de traos-chave entre as pessoas
de uma equipe gil e a equipe em si:
Competncia. No contexto do desenvolvimento gil (assim como no da engenharia de
software), a competncia abrange talento inato, habilidades especficas relacionadas a
software e conhecimento generalizado do processo que a equipe escolheu para aplicar. Habilidade e conhecimento de processo podem e devem ser ensinados para todas as pessoas
que sejam membros de uma equipe gil.

Barry Boehm

? Quais
so as

Foco comum. Embora os membros de uma equipe gil possam realizar diferentes tarefas e
tragam diferentes habilidades para o projeto, todos devem estar focados em um nico objetivo
entregar um incremento de software funcionando ao cliente, dentro do prazo prometido.
Para alcanar essa meta, a equipe tambm ir focar em adaptaes contnuas (pequenas e
grandes) que faro com que o processo se ajuste s necessidades da equipe.

caractersticas-chave que devem


estar presentes
entre as pessoas
integrantes de
uma equipe
de software
eficiente?

Colaborao. Engenharia de software (independentemente do processo) trata de avaliao, anlise e uso de informaes comunicadas equipe de software; criar informaes que
ajudaro todos os envolvidos a compreender o trabalho da equipe e a construir informaes
(software para computadores e bancos de dados relevantes) que forneam valor de negcio
para o cliente. Para realizar essas tarefas, os membros da equipe devem colaborar entre si
e com todos os demais envolvidos.

O que visto como


razoavelmente
suficiente por uma
equipe pode ser
avaliado como mais
do que suficiente
ou insuficiente por
uma outra equipe.

Habilidade na tomada de deciso. Qualquer boa equipe de software (at mesmo as


equipes geis) deve ter liberdade para controlar seu prprio destino. Isso implica que seja
dada autonomia equipe autoridade na tomada de deciso, tanto em assuntos tcnicos
como de projeto.
Habilidade de soluo de problemas confusos. Os gerentes de software devem reconhecer que a equipe gil ter de lidar continuamente com a ambiguidade e que ser continuamente atingida por mudanas. Em alguns casos, a equipe tem de aceitar o fato de
que o problema que eles esto solucionando hoje talvez no seja o problema que necessita
ser solucionado amanh. Entretanto, lies aprendidas de qualquer atividade de soluo
de problemas (inclusive aquelas que resolvem o problema errado) podem ser, futuramente,
benficas para a equipe no projeto.

Alistair
Cockburn

Confiana mtua e respeito. A equipe gil deve tornar-se uma equipe tal qual a que
DeMarco e Lister [DeM98] denominam de equipe consistente (Captulo 24). Uma equipe
consistente demonstra a confiana e o respeito necessrios para torn-la to fortemente
unida que o todo fica maior do que a soma das partes. [DeM98]
Uma equipe auto-organizada est no
controle do trabalho
que realiza. A equipe
estabelece seus
prprios compromissos
e define planos para
cumpri-los.

Auto-organizao. No contexto do desenvolvimento gil, a auto-organizao implica trs


fatores: (1) a equipe gil se organiza para o trabalho a ser feito, (2) a equipe organiza o processo para melhor se adequar ao seu ambiente local, (3) a equipe organiza o cronograma
de trabalho para melhor cumprir a entrega do incremento de software. A auto-organizao
possui uma srie de benefcios tcnicos, porm, mais importante, o fato de servir para
melhorar a colaborao e levantar o moral da equipe. Em essncia, a equipe faz seu prprio
2

As organizaes de engenharia de software bem-sucedidas reconhecem essa realidade independentemente do modelo de


processos por elas escolhido.

captulo 3 DESENVOLVIMENTO GIL

87

gerenciamento. Ken Schwaber [Sch02] menciona tais caractersticas ao escrever: A equipe


seleciona quanto trabalho acredita ser capaz de realizar dentro da iterao e se compromete
com trabalho. Nada desmotiva tanto uma equipe como um terceiro assumir compromissos
por ela. Nada motiva tanto uma equipe quanto aceitar a responsabilidade de cumprir completamente o prometido feito por ela prpria.

3.4

E x t r e m e P r o g r a m m i n g X P (P r o g r a m a o E x t r e m a )
Para ilustrar um processo gil de forma um pouco mais detalhada, segue uma viso geral de
Extreme Programming XP (Programao Extrema), a abordagem mais amplamente utilizada
para desenvolvimento de software gil. Embora os primeiros trabalhos sobre os conceitos e mtodos associados XP tenham ocorrido durante o final dos anos 1980, o trabalho seminal sobre
o tema foi escrito por Kent Beck [Bec04a]. Mais recentemente, foi proposta uma variao da XP,
denominada Industrial XP (IXP) [Ker05]. A IXP refina a XP e visa o processo gil especificamente
para uso em grandes organizaes.

3.4.1Valores da XP

AVISO
Simplifique sempre
que puder, mas
tenha cincia de que
um retrabalho
(refabricao,
redesenvolvimento)
contnuo consegue
absorver tempo e
recursos significativos.
A XP a resposta
para a pergunta:
Qual o mnimo
possvel que se
pode realizar e
mesmo assim
desenvolver
um software
grandioso?.
Annimo

Beck [Bec04a] define um conjunto de cinco valores que estabelecem as bases para todo
trabalho realizado como parte da XP comunicao, simplicidade, feedback (realimentao
ou retorno), coragem e respeito. Cada um desses valores usado como um direcionador das
atividades, aes e tarefas especficas da XP.
Para conseguir a comunicao efetiva entre engenheiros de software e outros envolvidos (por
exemplo, estabelecer os fatores e funes necessrias para o software), a XP enfatiza a colaborao estreita, embora informal (verbal), entre clientes e desenvolvedores, o estabelecimento de
metforas eficazes3 para comunicar conceitos importantes, feedback (realimentao) contnuo
e evitar documentao volumosa como meio de comunicao.
Para alcanar a simplicidade, a XP restringe os desenvolvedores a projetar apenas para as
necessidades imediatas, em vez de considerarem as necessidades futuras. O intuito criar um
projeto simples que possa ser facilmente implementado em cdigo. Se o projeto tiver que ser
melhorado, ele poder ser refabricado4 mais tarde.
O feedback provm de trs fontes: do prprio software implementado, do cliente e de outros
membros da equipe de software. Atravs da elaborao do projeto e da implementao de uma
estratgia de testes eficaz (Captulos 17 a 20), o software (via resultados de testes) propicia um
feedback para a equipe gil. A XP faz uso do teste de unidades como sua ttica de testes primria. medida que cada classe desenvolvida, a equipe desenvolve um teste de unidades para
exercitar cada operao de acordo com sua funcionalidade especificada. medida que um incremento entregue a um cliente, as histrias de usurios ou casos de uso (Captulo 5) implementados pelo incremento so usados como base para testes de aceitao. O grau em que o software
implementa o produto, a funo e o comportamento do caso em uso uma forma de feedback.
Por fim, conforme novas necessidades surgem como parte do planejamento iterativo, a equipe
d ao cliente um rpido feedback referente ao impacto nos custos e no cronograma.
Beck [Bec04a] afirma que a adoo estrita a certas prticas da XP exige coragem. Uma palavra melhor poderia ser disciplina. Por exemplo, frequentemente, h uma presso significativa
para a elaborao do projeto pensando em futuros requisitos. A maioria das equipes de software
sucumbe, argumentando que projetar para amanh poupar tempo e esforo no longo prazo.
Uma equipe XP gil deve ter disciplina (coragem) para projetar para hoje, reconhecendo que as

3
4

No contexto da XP, uma metfora uma histria que todos clientes, programadores e gerentes podem contar sobre
como o sistema funciona [Bec04a].
A refabricao permite a um engenheiro de software aperfeioar a estrutura interna de um projeto (ou cdigo-fonte) sem alterar sua funcionalidade ou comportamento externos. Em essncia, a refabricao pode ser usada para melhorar a eficincia,
a legibilidade ou o desempenho de um projeto ou o cdigo que implementa um projeto.

88

PARTE 1O processo de Software

necessidades futuras podem mudar dramaticamente exigindo, consequentemente, substancial


retrabalho em relao ao projeto e ao cdigo implementado.
Ao seguir cada um desses valores, a equipe gil inculca respeito entre seus membros, entre
outros envolvidos e os membros da equipe, e, indiretamente, para o prprio software. Conforme
conseguem entregar com sucesso incrementos de software, a equipe desenvolve cada vez mais
respeito pelo processo XP.

3.4.2O Processo XP
WebRef
Uma excelente viso
geral das regras
para XP pode ser
encontrada em www.
extremeprogramm
ing.org/rules.html.

? Oumaque

histria XP?

A Extreme Programming (programao extrema) emprega uma abordagem orientada a objetos (Apndice 2) como seu paradigma de desenvolvimento preferido e envolve um conjunto
de regras e prticas constantes no contexto de quatro atividades metodolgicas: planejamento,
projeto, codificao e testes. A Figura 3.2 ilustra o processo XP e destaca alguns conceitos e
tarefas-chave associados a cada uma das atividades metodolgicas. As atividades-chave da XP
so sintetizadas nos pargrafos a seguir.
Planejamento. A atividade de planejamento (tambm denominada o jogo do planejamento) se
inicia com a atividade de ouvir uma atividade de levantamento de requisitos que capacita os membros tcnicos da equipe XP a entender o ambiente de negcios do software e possibilita que se consiga ter uma percepo ampla sobre os resultados solicitados, fatores principais e funcionalidade
A atividade de Ouvir conduz criao de um conjunto de histrias (tambm denominado histrias de usurios) que descreve o resultado, as caractersticas e a funcionalidade requisitados para o software a ser construdo. Cada histria (similar aos casos de uso descritos
no Captulo 5) escrita pelo cliente e colocada em uma ficha. O cliente atribui um valor (uma
prioridade) histria baseando-se no valor de negcio global do recurso ou funo.5 Os membros da equipe XP avaliam ento cada histria e atribuem um custo medido em semanas de
desenvolvimento a ela. Se a histria requerer, por estimativa, mais do que trs semanas de
desenvolvimento, solicitado ao cliente para dividir a histria em histrias menores e a atribuio de valor e custo ocorre novamente. importante notar que podem ser escritas novas
histrias a qualquer momento.

Figura 3.2
O processo da
Extreme
Programming (XP)

solues pontuais
prottipos

projeto simples
cartes CRC

valores das histrias


de usurios
critrios de teste de aceitao
plano de iterao

to

proje

ento

ejam

plan

ao

codific

refabricao
programao em dupla

teste

Verso
incremento de software
velocidade de projeto registrada
(computada)

teste de unidades
integrao contnua
teste de aceitao

O valor de uma histria tambm pode depender da presena de uma outra histria.

captulo 3 DESENVOLVIMENTO GIL

WebRef
Um jogo de
planejamento XP
bastante interessante
pode ser encontrado
em: c2.com/cgi/
wiki?planning
Game.

A velocidade do
projeto uma medida
sutil da produtividade
de uma equipe.

AVISO
A XP tira a nfase da
importncia do projeto.
Nem todos concordam.
De fato, h ocasies
em que o projeto deve
ser enfatizado.
WebRef
Tcnicas de refabricao
e ferramentas podem
ser encontradas em:
www.refactoring.
com.

A refabricao
aprimora a estrutura
interna de um projeto
(ou cdigo-fonte)
sem alterar sua
funcionalidade ou
comportamento
externos.

89

Clientes e desenvolvedores trabalham juntos para decidir como agrupar histrias para a
verso seguinte (o prximo incremento de software) a ser desenvolvida pela equipe XP. Conseguindo chegar a um compromisso bsico (concordncia sobre quais histrias sero includas,
data de entrega e outras questes de projeto) para uma verso, a equipe XP ordena as histrias
a ser desenvolvidas em uma das trs formas: (1) todas sero implementadas imediatamente (em
um prazo de poucas semanas), (2) as histrias de maior valor sero deslocadas para cima no
cronograma e implementadas primeiro ou (3) as histrias de maior risco sero deslocadas para
cima no cronograma e implementadas primeiro.
Depois de a primeira verso do projeto (tambm denominada incremento de software) ter
sido entregue, a equipe XP calcula a velocidade do projeto. De forma simples, a velocidade do
projeto o nmero de histrias de clientes implementadas durante a primeira verso. Assim, a
velocidade do projeto pode ser utilizada para (1) ajudar a estimar as datas de entrega e o cronograma para verses subsequentes e (2) determinar se foi assumido um compromisso exagerado
para todas as histrias ao longo de todo o projeto de desenvolvimento. Se ocorrer um exagero,
o contedo das verses modificado ou as datas finais de entrega so alteradas.
Conforme o trabalho de desenvolvimento prossegue, o cliente pode acrescentar histrias,
mudar o valor de uma existente, dividir algumas ou elimin-las. Em seguida, a equipe XP reconsidera todas as verses remanescentes e modifica seus planos de acordo.
Projeto. O projeto XP segue rigorosamente o princpio KIS (keep it simple, ou seja, preserve a
simplicidade). prefervel sempre um projeto simples do que uma representao mais complexa. Como acrscimo, o projeto oferece um guia de implementao para uma histria medida
que escrita nada mais, nada menos. O projeto de funcionalidade extra (pelo fato de o desenvolvedor supor que ela ser necessria no futuro) desencorajado.6
A XP encoraja o uso de cartes CRC (Captulo 7) como um mecanismo eficaz para pensar
sobre o software em um contexto orientado a objetos. Os cartes CRC (classe-responsabilidadecolaborador) identificam e organizam as classes orientadas a objetos7 relevantes para o incremento de software corrente. A equipe XP conduz o exerccio de projeto usando um processo
similar ao descrito no Captulo 8. Os cartes CRC so o nico artefato de projeto produzidos
como parte do processo XP.
Se um difcil problema de projeto for encontrado como parte do projeto de uma histria, a XP
recomenda a criao imediata de um prottipo operacional dessa parte do projeto. Denominada
soluo pontual, o prottipo do projeto implementado e avaliado. O objetivo reduzir o risco
para quando a verdadeira implementao iniciar e validar as estimativas originais para a histria
contendo o problema de projeto.
Na seo anterior, foi feita a observao de que a XP encoraja a refatorao uma tcnica
de construo que tambm um mtodo para otimizao de projetos. Fowler [Fow00] descreve
a refabricao da seguinte maneira:
Refabricao o processo de alterao de um sistema de software de tal forma que no se altere o
comportamento externo do cdigo, mas se aprimore a estrutura interna. uma forma disciplinada de
organizar cdigo [e modificar/simplificar o projeto interno] que minimiza as chances de introduo de
bugs. Em resumo, ao se refabricar, se est aperfeioando o projeto de codificao depois de este ter
sido feito.

Como o projeto XP no usa praticamente nenhuma notao e produz poucos, se algum,


artefatos, alm dos cartes CRC e solues pontuais, o projeto visto como algo transitrio
que pode e deve ser continuamente modificado conforme a construo prossegue. O objetivo
da refabricao controlar tais modificaes sugerindo pequenas mudanas de projeto capazes de melhor-lo radicalmente [Fow00]. Deve ser observado, no entanto, que o esforo
6
7

Tais diretrizes de projeto deveriam ser seguidas em todos os mtodos de engenharia de software, apesar de ocorrer situaes
em que sofisticadas terminologia e notao possam constituir obstculo para a simplicidade.
As classes orientadas a objetos so discutidas no Apndice 2, no Captulo 8 e ao longo da Parte 2 deste livro.

90

PARTE 1O processo de Software

necessrio para a refabricao pode aumentar dramaticamente medida que o tamanho de


uma aplicao cresa.
Um aspecto central na XP o de que a elaborao do projeto ocorre tanto antes como depois
de se ter iniciado a codificao. Refabricao significa que o projetar realizado continuamente enquanto o sistema estiver em elaborao. Na realidade, a prpria atividade de desenvolvimento guiar a equipe XP quanto aprimorao do projeto.

WebRef
Informaes teis
sobre a XP podem ser
obtidas em www.
xprogramming.
com.

que
? Oprogramao

em dupla?

AVISO
Muitas equipes
de software so
constitudas por
individualistas. Dever
haver empenho
para modificar tal
cultura, para que a
programao em dupla
funcione efetivamente.

so
? Como
usados os

testes de unidade
na XP?

Os testes de aceitao
da XP so elaborados
com base nas histrias
de usurios.

Codificao. Depois de desenvolvidas as histrias e o trabalho preliminar de elaborao do


projeto ter sido feito, a equipe no passa para a codificao, mas sim, desenvolve uma srie de
testes de unidades que exercitaro cada uma das histrias a ser inclusas na verso corrente
(incremento de software).8 Uma vez criado o teste de unidades9, o desenvolvedor poder melhor
focar-se no que deve ser implementado para ser aprovado no teste. Nada estranho adicionado
(KIS). Estando o cdigo completo, este pode ser testado em unidade imediatamente, e, dessa
forma, prover, instantaneamente, feedback para os desenvolvedores.
Um conceito-chave na atividade de codificao (e um dos mais discutidos aspectos da XP)
a programao em dupla. A XP recomenda que duas pessoas trabalhem juntas em uma mesma estao de trabalho para criar cdigo para uma histria. Isso fornece um mecanismo para
resoluo de problemas em tempo real (duas cabeas normalmente funcionam melhor do que
uma) e garantia da qualidade em tempo real (o cdigo revisto medida que criado). Ele
tambm mantm os desenvolvedores focados no problema em questo. Na prtica, cada pessoa assume um papel ligeiramente diferente. Por exemplo, uma pessoa poderia pensar nos detalhes de codificao de determinada parte do projeto, enquanto outra assegura que padres
de codificao (uma parte exigida pela XP) sejam seguidos ou que o cdigo para a histria
passar no teste de unidades desenvolvido para validao do cdigo em relao histria.
Conforme a dupla de programadores completa o trabalho, o cdigo que desenvolveram
integrado ao trabalho de outros. Em alguns casos, isso realizado diariamente por uma
equipe de integrao. Em outros, a dupla de programadores responsvel pela integrao. A
estratgia de integrao contnua ajuda a evitar problemas de compatibilidade e de interfaceamento, alm de criar um ambiente teste da fumaa (Captulo 17) que ajuda a revelar
erros precocemente.
Testes. J foi observado que a criao de testes de unidade, antes de comear a codificao,
um elemento-chave da abordagem XP. Os testes de unidade criados devem ser implementados
usando-se uma metodologia que os capacite a ser automatizados (assim, podero ser executados
fcil e repetidamente). Isso encoraja uma estratgia de testes de regresso (Captulo 17), toda vez
em que o cdigo for modificado (o que frequente, dada a filosofia de refabricao da XP).
Como os testes de unidades individuais so organizados em um conjunto de testes universal [Wel99], os testes de integrao e validao do sistema podem ocorrer diariamente. Isso
d equipe XP uma indicao contnua do progresso e tambm permite lanar alertas logo no
incio, caso as coisas no andem bem. Wells [Wel99] afirma: Corrigir pequenos problemas em
intervalos de poucas horas leva menos tempo do que corrigir problemas enormes prximo ao
prazo de entrega.
Os testes de aceitao da XP, tambm denominados testes de cliente, so especificados pelo
cliente e mantm o foco nas caractersticas e na funcionalidade do sistema total que so visveis
e que podem ser revistas pelo cliente. Os testes de aceitao so obtidos de histrias de usurios implementadas como parte de uma verso de software.

8
9

Essa abordagem como conhecer as perguntas de uma prova antes de comear a estudar. Torna o estudo muito mais fcil,
permitindo que se concentre a ateno apenas nas perguntas que sero feitas.
O teste de unidades, discutido detalhadamente no Captulo 17, concentra-se em um componente de software individual,
exercitando a interface, a estrutura de dados e a funcionalidade do componente, em uma tentativa de que se revelem erros
pertinentes ao componente.

captulo 3 DESENVOLVIMENTO GIL

91

3.4.3Industrial XP
Joshua Kerievsky [Ker05] descreve a Industrial Extreme Programming (IXP) programao
extrema industrial da seguinte maneira: A IXP uma evoluo orgnica da XP. Ela imbuda
do esprito minimalista, centrado no cliente e orientado a testes da XP. Difere principalmente da
XP original por sua maior incluso do gerenciamento, por seu papel expandido para os clientes
e por suas prticas tcnicas atualizadas. A IXP incorpora seis novas prticas desenvolvidas para
ajudar a assegurar que um projeto XP funcione com xito em empreendimentos significativos
em uma grande organizao.
novas
? Que
prticas so

acrescidas XP
para elaborar a
IXP?

Habilidade
consiste no que
se capaz de
fazer. Motivao
determina o que
voc faz. Atitude
determina quo
bem voc faz.
Lou Holtz

Avaliao imediata. Antes do incio de um projeto IXP, a organizao deve realizar uma
avaliao imediata. A avaliao verifica se (1) existe um ambiente de desenvolvimento apropriado para sustentar a IXP, (2) a equipe ser composta por um conjunto apropriado de
interessados, (3) a organizao possui um programa de qualidade diferenciado e suporta
contnuo aperfeioamento, (4) a cultura organizacional apoiar os novos valores de uma
equipe gil e (5) a comunidade de projeto ampliada ser composta apropriadamente.
Comunidade de projeto. A XP clssica sugere que se aloquem as pessoas acertadas para
compor a equipe gil e garantir o sucesso. Isso implica pessoas da equipe bem treinadas,
adaptveis e experientes e que tenham temperamento apropriado para contribuir para uma
equipe auto-organizada. Ao se aplicar a XP em um projeto importante de uma grande empresa, o conceito da equipe deve transformar-se no de comunidade. A comunidade pode
ter um tecnlogo e clientes fundamentais para o sucesso de um projeto, assim como muitos
outros envolvidos (por exemplo, responsveis jurdicos, auditores do controle da qualidade,
representantes da rea de produo ou de categorias de vendas) que frequentemente se
encontram na periferia de um projeto IXP, mas que podem desempenhar importante papel
no projeto [Ker05]. Na IXP, os membros da comunidade devem ter papis explicitamente
definidos e os mecanismos de comunicao e de coordenao relativos aos elementos da
comunidade devem estar determinados.
Mapeamento do projeto. A prpria equipe IXP avalia o projeto para determinar se este se
justifica em termos de negcios e se ir ultrapassar as metas e objetivos globais da organizao. O mapeamento tambm examina o contexto do projeto para estabelecer como este
complementa, amplia ou substitui sistemas ou processos existentes.
Gerenciamento orientado a testes. Um projeto IXP requer critrios mensurveis para
avaliar o estado do projeto e do progresso obtido at ento. O gerenciamento orientado a
testes estabelece uma srie de destinos mensurveis [Ker05] e define mecanismos para
determinar se estes foram atingidos ou no.
Retrospectivas. Uma equipe IXP conduz uma reviso tcnica especializada (Captulo 15) aps
a entrega de um incremento de software. Denominada retrospectiva, a reviso examina itens,
eventos e lies aprendidas [Ker05] ao longo do processo de incremento de software e/ou do
desenvolvimento da verso completa do software. O objetivo aprimorar o processo da IXP.
Aprendizagem contnua. Sendo a aprendizagem uma parte vital para o aperfeioamento contnuo do processo, os membros da equipe XP so encorajados (e possivelmente
incentivados) a aprender novos mtodos e tcnicas que possam conduzir a um produto de
melhor qualidade.
Somando-se s apresentadas, a IXP modifica uma srie de prticas XP existentes. O desenvolvimento orientado por histrias (story-driven development, SDD) insiste que as histrias para
testes de aceitao sejam escritas antes de gerar uma nica linha de cdigo. O projeto orientado
por domnio (domain-driven design, DDD) um aprimoramento do conceito metfora de sistema usado na XP. O DDD [Eva03] sugere a criao evolucionria de um modelo de domnio
que represente acuradamente como pensam os especialistas de determinado domnio dentro
de sua disciplina [Ker05]. O emparelhamento amplia o conceito de programao em dupla da

92

PARTE 1O processo de Software

XP, ao incluir gerentes e outros envolvidos. O intuito ampliar o compartilhamento de conhecimentos entre os membros da equipe XP que possam no estar diretamente envolvidos no desenvolvimento tcnico. A usabilidade iterativa desencoraja o projeto de interfaces de carregamento
frontal (front-loaded interface design), sendo a favor do projeto de usabilidade que evolui conforme os incrementos sejam entregues e a interao entre usurios e o software seja estudada.
A IXP faz modificaes menores para outras prticas XP e redefine certos papis e responsabilidades para torn-los mais harmonizados com projetos importantes de organizaes. Para
uma discusso mais ampla sobre a IXP, visite http://industrialxp.org.

3.4.4O Debate XP
Todos os novos mtodos e modelos de processos estimulam debates teis e, em alguns casos, debates acalorados. A Extreme Programming provocou ambos. Em um livro interessante
que examina a eficcia da XP, Stephens e Rosenberg [Ste03] argumentam que muitas prticas
XP valem a pena, mas outras foram superestimadas e algumas poucas so problemticas. Os
autores sugerem que a codependncia da prtica da XP representa sua fora e sua fraqueza.
Pelo fato de muitas organizaes adotarem apenas um subconjunto de prticas XP, elas enfraquecem a eficcia de todo o processo. Seus defensores rebatem dizendo que a XP aperfeioada continuamente e que muitos dos itens levantados pela crtica tm sido acessados
conforme a prtica da XP ganha maturidade. Entre os itens que continuam a incomodar certos
crticos da XP esto:10
so
? Quais
alguns

dos pontos que


conduzem a um
debate a respeito
da XP?

Volatilidade de requisitos. Pelo fato de o cliente ser um membro ativo da equipe XP, alteraes de requisitos so solicitadas informalmente. Como consequncia, o escopo do
projeto pode mudar e trabalhos anteriores podem ter de vir a ser alterados, a fim de
acomodar as necessidades de ento. Seus defensores argumentam que isso acontece
independentemente do processo aplicado e que a XP oferece mecanismos para controlar
o surgimento incontrolado de novos escopos.
Necessidades conflitantes de clientes. Projetos em quantidade possuem mltiplos clientes, cada um com seu prprio conjunto de necessidades. Na XP, a prpria equipe tem a
tarefa de assimilar as necessidades de diferentes clientes, um trabalho que pode estar
alm de seu escopo de autoridade.
Os requisitos so levantados informalmente. Histrias de usurios e testes de aceitao
so a nica manifestao explcita de requisitos da XP. Seus crticos argumentam que,
frequentemente, torna-se necessrio um modelo ou especificao mais formal para assegurar que omisses, inconsistncias e erros sejam descobertos antes que o sistema
seja construdo. Seus defensores rebatem dizendo que a natureza mutante de requisitos
torna tais modelos e especificaes obsoletos praticamente logo depois de terem sido
desenvolvidos.
Falta de projeto formal. A XP tira a nfase da necessidade do projeto de arquitetura e, em
muitos casos, sugere que todos os tipos de projetos devam ser relativamente informais.
Seus crticos argumentam que em sistemas complexos deve-se enfatizar a elaborao
do projeto para assegurar que a estrutura geral do software apresentar qualidade e
facilidade de manuteno. J os defensores da XP sugerem que a natureza incremental
do processo XP limita a complexidade (a simplicidade um valor fundamental) e, consequentemente, reduz a necessidade de um projeto extenso.
Deve-se observar que todo processo de software tem suas falhas e que muitas organizaes
de software usaram, com xito, a XP. O segredo reconhecer onde um processo pode apresentar
fraquezas e adapt-lo s necessidades especficas de sua organizao.

10 Para uma viso detalhada de algumas crticas ponderadas feitas ao XP, visite www.softwarereality.com/ExtremeProgramming.jsp.

93

captulo 3 DESENVOLVIMENTO GIL

C asa S egura
Considerando o desenvolvimento de
software gil

Jamie: Jesus... Eles solicitaro alteraes a cada cinco minutos.

Cena: de Doug Miller.


Atores: Doug Miller, gerente de engenharia de software; Jamie
Lazar, membro da equipe de software; Vinod Raman, membro
da equipe de software.
Conversa:
(Batendo porta, Jamie e Vinod adentram sala de Doug)
Jamie: Doug, voc tem um minuto?
Doug: Com certeza, Jamie, o que h?
Jamie: Estivemos pensando a respeito da discusso sobre processos, de ontem... Sabe, que processo vamos escolher para
este novo projeto CasaSegura.
Doug: E?
Vinod: Eu estava conversando com um amigo de uma outra
empresa e ele me falou sobre a Extreme Programming. um
modelo de processo gil... J ouviu falar?
Doug: Sim, algumas coisas boas, outras ruins.
Jamie: Bem, pareceu muito bom para ns. Permite que se desenvolva software realmente rpido, usa algo chamado programao em dupla para fazer checagens de qualidade em tempo
real... bem legal, eu acho.
Doug: Realmente, apresenta um monte de ideias muito boas.
Gosto do conceito de programao em dupla, por exemplo, e
da ideia de que os envolvidos devam fazer parte da equipe.
Jamie: O qu? Quer dizer que o pessoal de marketing trabalhar conosco na equipe de projeto?

3 .5
Nossa profisso
passa por
metodologias como
uma garota de 14
anos passa por
roupas.
Stephen
Hawrysh e
Jim Ruprecht

Outros Modelos

Doug (confirmando com a cabea): Eles so envolvidos,


no so?

de

Vinod: No necessariamente. Meu amigo me disse que existem


formas de se abarcar as mudanas durante um projeto XP.
Doug: Portanto, meus amigos, vocs acham que deveramos
usar a XP?
Jamie: Definitivamente, vale considerar.
Doug: Eu concordo. E mesmo que optssemos por um modelo incremental como nossa abordagem, no h nenhuma razo para
no podermos incorporar muito do que a XP tem a oferecer.
Vinod: Doug, mas antes voc disse algumas coisas boas, outras ruins. O que so as coisas ruins?
Doug: O que no me agrada a maneira pela qual a XP d
menos importncia anlise e ao projeto... Dizem algo como: a
codificao resume a ao para construir um software.
(Os membros da equipe se entreolham e sorriem.)
Doug: Ento vocs concordam com a abordagem XP?
Jamie (falando por ambos): Escrever cdigo o que fazemos, chefe!
Doug (rindo): verdade, mas eu gostaria de v-lo perdendo
um pouco menos de tempo codificando para depois recodificar
e dedicando um pouco mais de tempo analisando o que precisa
ser feito e projetando uma soluo que funcione.
Vinod: Talvez possamos ter as duas coisas, agilidade com um
pouco de disciplina.
Doug: Acho que sim, Vinod. Na realidade, tenho certeza disso.

Processos geis

Na histria da engenharia de software h dezenas de metodologias e descries de processos, mtodos e notaes de modelagem, ferramentas e tecnologias obsoletas. Cada um atingiu
grande notoriedade e foi ento ofuscado por algo novo e (supostamente) melhor. Com a introduo de uma ampla gama de modelos de processos geis todos disputando por aceitao
pela comunidade de desenvolvimento de software , o movimento gil est seguindo o mesmo
caminho histrico.11
Conforme citado na ltima seo, o modelo mais amplamente utilizado de todos os modelos
de processos geis o da Extreme Programming (XP). Porm, muitos outros tm sido propostos
e encontram-se em uso no setor. Entre os mais comuns, temos:
Desenvolvimento de software adaptativo (Adaptive Software Development, ASD)
Scrum
Mtodo de desenvolvimento de sistemas dinmicos (Dynamic Systems Development
Method, DSDM)
Crystal
11 Isso no algo ruim. Antes que um ou mais modelos ou mtodos sejam aceitos como um padro de fato, todos devem competir para conquistar os coraes e mentes dos engenheiros de software. Os vencedores evoluem e se transformam nas
melhores prticas, enquanto os perdedores desaparecem ou se fundem aos modelos vencedores.

94

PARTE 1O processo de Software

Desenvolvimento dirigido a Funcionalidades (Feature Drive Development, FDD)


Desenvolvimento de software enxuto (Lean Software Development, LSD)
Modelagem gil (Agile Modeling, AM)
Processo unificado gil (Agile Unified Process, AUP)

Nas sees seguintes, apresenta-se uma viso geral muito breve de cada um desses modelos
de processos geis. importante observar que todos esto em conformidade (em maior ou menor grau) com o Manifesto for Agile Software Development e com os princpios citados na Seo
3.3.1. Para mais detalhes, veja as referncias citadas em cada subseo ou, para uma pesquisa,
examine a entrada agile software development na Wikipedia.12

3.5.1Desenvolvimento de Software Adaptativo (ASD)


WebRef
Recursos teis para ASD
podem ser encontrados
em www.
adaptivesd.com.

AVISO
A colaborao efetiva
com seu cliente
ocorrer somente
se voc extinguir
quaisquer atitudes de
ns e eles.

O desenvolvimento de software adaptativo (Adaptive Software Development) foi proposto por


Jim Highsmith [Hig00] como uma tcnica para construo de software e sistemas complexos.
As bases filosficas do ASD se concentram na colaborao humana e na auto-organizao das
equipes.
Highsmith argumenta que uma abordagem de desenvolvimento gil e adaptativo baseada na
colaborao constitui um recurso para organizar nossas complexas interaes, tanto quanto
disciplina e engenharia o so. Ele define um ciclo de vida ASD (Figura 3.3) que incorpora trs
fases: especulao, colaborao e aprendizagem.
Durante a especulao, o projeto iniciado e conduzido o planejamento de ciclos adaptveis.
O planejamento de ciclos adaptveis usa as informaes do incio de projeto o estabelecimento da misso do cliente, as restries do projeto (por exemplo, datas de entrega ou descries
de usurios) e os requisitos bsicos para definir o conjunto de ciclos de verso (incrementos
de software) que sero requisitados para o projeto.
No importa quo completo e com viso de futuro seja o plano de ciclos, invariavelmente
sofrer mudanas. Baseando-se nas informaes obtidas ao se completar o primeiro ciclo, o
plano revisto e ajustado de modo que o trabalho planejado melhor se ajuste realidade na
qual a equipe ASD est trabalhando.

Figura 3.3
Desenvolvimento de
software adaptvel

Levantamento de necessidades
JAD
miniespecificaes

planejamento de diclos adaptativos


estabelecimento da misso
restries do projeto
requisitos bsicos
plano de entregas com tempo estabelecido

ora

colab

ula

espec

em

dizag

apren

Verso
incremento de software
ajustes para ciclos subsequentes

componentes implementados/testados
grupos focados para feedback
revises tcnicas formais
autpsias

12 Veja http://en.wikipedia.org/wiki/Agile_software_development#Agile_methods.

captulo 3 DESENVOLVIMENTO GIL

O ASD enfatiza o
aprendizado como
elemento-chave para
conseguir uma equipe
auto-organizada.

95

As pessoas motivadas usam a colaborao de uma forma que multiplique seus talentos e produes criativas alm de seus nmeros absolutos. Tal abordagem tema recorrente em todos os
mtodos geis. Porm, colaborao no algo fcil, envolve comunicao e trabalho em equipe,
mas tambm enfatiza o individualismo, pois a criatividade individual desempenha um importante papel no pensamento colaborativo. Trata-se, sobretudo, de uma questo de confiana.
Pessoas que trabalham juntas tm de confiar umas nas outras para (1) criticar sem animosidade,
(2) auxiliar sem ressentimentos, (3) trabalhar to arduamente ou mais do que elas fazem, (4)
possuir o conjunto de habilidades que contribua com o atual trabalho e (5) comunicar problemas ou preocupaes de forma que conduzam a aes efetivas.
Conforme os membros de uma equipe ASD comecem a desenvolver os componentes que
fazem parte de um ciclo adaptvel, a nfase reside no aprendizado tanto quanto reside no
progresso para um ciclo completado. De fato, Highsmith [Hig00] argumenta que os desenvolvedores de software normalmente superestimam seu prprio entendimento (da tecnologia, do
processo e do projeto) e que a aprendizagem ir ajud-los a aumentar seus nveis reais de entendimento. As equipes ASD aprendem de trs maneiras: grupos focados (Captulo 5), revises
tcnicas (Captulo 14) e autpsias de projetos (anlises postmortems).
A filosofia ASD tem seus mritos independentemente do modelo de processos utilizado. A
nfase global da ASD est na dinmica das equipes auto-organizadas, na colaborao interpessoal e na aprendizagem individual e da equipe que levam as equipes de projeto de software a
uma probabilidade muito maior de sucesso.

3.5.2 Scrum
WebRef
Informaes e recursos
teis sobre o Scrum
podem ser encontrados
em www.control
chaos.com.

O Scrum engloba
um conjunto de
padres de processos
enfatizando
prioridades de projeto,
unidades de trabalho
compartimentalizadas,
comunicao e
feedback frequente
por parte dos clientes.

Scrum (o nome provm de uma atividade que ocorre durante a partida de rugby13) um
mtodo de desenvolvimento gil de software concebido por Jeff Sutherland e sua equipe de desenvolvimento no incio dos anos 1990. Mais recentemente, foram realizados desenvolvimentos
adicionais nos mtodos grficos Scrum por Schwaber e Beedle [Sch01a].
Os princpios do Scrum so consistentes com o manifesto gil e so usados para orientar
as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades
estruturais: requisitos, anlise, projeto, evoluo e entrega. Em cada atividade metodolgica,
ocorrem tarefas a realizar dentro de um padro de processo (discutido no pargrafo a seguir)
chamado sprint. O trabalho realizado dentro de um sprint (o nmero de sprints necessrios para
cada atividade metodolgica varia dependendo do tamanho e da complexidade do produto)
adaptado ao problema em questo e definido, e muitas vezes modificado em tempo real, pela
equipe Scrum. O fluxo geral do processo Scrum ilustrado na Figura 3.4.
O Scrum enfatiza o uso de um conjunto de padres de processos de software [Noy02] que provaram ser eficazes para projetos com prazos de entrega apertados, requisitos mutveis e crticos de
negcio. Cada um desses padres de processos define um conjunto de aes de desenvolvimento:
Registro pendente de trabalhos (Backlog) uma lista com prioridades dos requisitos ou
funcionalidades do projeto que fornecem valor comercial ao cliente. Os itens podem ser adicionados a esse registro em qualquer momento ( assim que as alteraes so introduzidas). O
gerente de produto avalia o registro e atualiza as prioridades conforme requisitado.
Urgncias (corridas de curta distncia) sprints consistem de unidades de trabalho solicitadas para atingir um requisito estabelecido no registro de trabalho (backlog) e que precisa ser
ajustado dentro de um prazo j fechado (janela de tempo)14 (tipicamente 30 dias).
Alteraes (por exemplo, itens do registro de trabalho backlog work itens) no so introduzidas durante execuo de urgncias (sprint). Portanto, o sprint permite que os membros de
uma equipe trabalhem em um ambiente de curto prazo, porm estvel.
13 Um grupo de jogadores faz uma formao em torno da bola e seus companheiros de equipe trabalham juntos (s vezes, de
forma violenta!) para avanar com a bola em direo ao fundo do campo.
14 Janela de tempo (time boxing) um termo de gerenciamento de projetos (veja a Parte 4 deste livro) que indica um perodo de
tempo destinado para cumprir alguma tarefa.

96

PARTE 1O processo de Software

Figura 3.4
Fluxo do processo
Scrum
a cada
24 horas

Backlog do Sprint:
Funcionalidade(s)
atribuda(s)
ao sprint

Itens pendentes
do Backlog
expandidos
pela equipe

30 dias

Scrum: Reunies dirias de 15 minutos.


Os membros da equipe respondem s
questes bsicas
1) O que voc realizou desde a ltima Scrum?
2) Voc est tendo alguma dificuldade?
3) O que voc ir fazer antes da prxima reunio?

A nova funcionalidade
demonstrada no
final do sprint

Backlog do Produto:

Priorizao das funcionalidades do produto desejadas pelo cliente

Reunies Scrum so reunies curtas (tipicamente 15 minutos), realizadas diariamente


pela equipe Scrum. So feitas trs perguntas-chave e respondidas por todos os membros da
equipe [Noy02]:
O que voc realizou desde a ltima reunio de equipe?
Quais obstculos est encontrando?
O que planeja realizar at a prxima reunio da equipe?
Um lder de equipe, chamado Scrum master, conduz a reunio e avalia as respostas de cada
integrante. A reunio Scrum, realizada diariamente, ajuda a equipe a revelar problemas potenciais o mais cedo possvel. Ela tambm leva socializao do conhecimento [Bee99] e, portanto, promove uma estrutura de equipe auto-organizada.
Demos entrega do incremento de software ao cliente para que a funcionalidade implementada possa ser demonstrada e avaliada pelo cliente. importante notar que a demo pode
no ter toda a funcionalidade planejada, mas sim funes que possam ser entregues no prazo
estipulado.
Beedle e seus colegas [Bee99] apresentam uma ampla discusso sobre esses padres: O
Scrum pressupe a existncia do caos.... Os padres de processos do Scrum capacitam uma
equipe de software a trabalhar com sucesso em um mundo onde a eliminao da incerteza
impossvel.

3.5.3Mtodo de Desenvolvimento de Sistemas Dinmicos (DSDM)


WebRef
Recursos teis para o
DSSD podem ser encontrados em www.
dsdm.org.

O mtodo de desenvolvimento de sistemas dinmicos (Dynamic Systems Development Method)


[Sta97] uma abordagem de desenvolvimento de software gil que oferece uma metodologia
para construir e manter sistemas que atendem restries de prazo apertado atravs do uso da
prototipagem incremental em um ambiente de projeto controlado [CCS02]. A filosofia DSDM
baseia-se em uma verso modificada do princpio de Pareto 80% de uma aplicao pode ser
entregue em 20% do tempo que levaria para entregar a aplicao completa (100%).

captulo 3 DESENVOLVIMENTO GIL

97

O DSDM um processo de software iterativo em que cada iterao segue a regra dos 80%.
Ou seja, somente o trabalho suficiente requisitado para cada incremento, para facilitar o movimento para o prximo incremento. Os detalhes remanescentes podem ser completados depois,
quando outros requisitos de negcio forem conhecidos ou alteraes tiverem sido solicitadas e
acomodadas.
O DSDM Consortium (www.dsdm.org) um grupo mundial de empresas-membro que
coletivamente assume o papel de mantenedor do mtodo. Esse consrcio definiu um modelo
de processos geis, chamado ciclo de vida DSDM que define trs ciclos iterativos diferentes,
precedidos por duas atividades de ciclo de vida adicionais:

Crystal uma
famlia de modelos
de processos com
o mesmo cdigo
gentico, mas com
diferentes mtodos
para se adaptarem
s caractersticas do
projeto.

Estudo da viabilidade estabelece os requisitos bsicos de negcio e restries associados


aplicao a ser construda e depois avalia se a aplicao ou no um candidato vivel para o
processo DSDM.
Estudo do negcio estabelece os requisitos funcionais e de informao que permitiro
aplicao agregar valor de negcio; define tambm a arquitetura bsica da aplicao e identifica
os requisitos de facilidade de manuteno para a aplicao.
Iterao de modelos funcionais produz um conjunto de prottipos incrementais que demonstram funcionalidade para o cliente. (Nota: Todos os prottipos DSDM so feitos com a inteno de
que evoluam para a aplicao final entregue ao cliente.) Durante esse ciclo iterativo, o objetivo
juntar requisitos adicionais ao se obter feedback dos usurios, conforme testam o prottipo.
Iterao de projeto e desenvolvimento revisita prottipos desenvolvidos durante a iterao
de modelos funcionais para assegurar-se de que cada um tenha passado por um processo de
engenharia para capacit-los a oferecer, aos usurios finais, valor de negcio em termos operacionais. Em alguns casos, a iterao de modelos funcionais e a iterao de projeto e desenvolvimento ocorrem ao mesmo tempo.
Implementao aloca a ltima verso do incremento de software (um prottipo operacionalizado) no ambiente operacional. Deve-se notar que: (1) o incremento pode no estar 100%
completo ou (2) alteraes podem vir a ser solicitadas conforme o incremento seja alocado. Em
qualquer dos casos, o trabalho de desenvolvimento do DSDM continua, retornando-se atividade de iterao do modelo funcional.
O DSDM pode ser combinado com a XP (Seo 3.4) para fornecer uma abordagem combinatria que define um modelo de processos consistente (o ciclo de vida do DSDM) com as prticas
bsicas (XP) necessrias para construir incrementos de software. Alm disso, os conceitos de
colaborao e de equipes auto-organizadas do ASD podem ser adaptados a um modelo de processos combinado.

3.5.4Crystal

O DSDM um uma
metodologia de
processos que pode
adotar a ttica de
uma outra abordagem
gil como a XP.

Alistair Cockburn [Coc05] e Jim Highsmith [Hig02b] criaram a famlia Crystal de mtodos
geis15 visando conseguir elaborar uma abordagem de desenvolvimento de software que priorizasse a adaptabilidade (maneuverability) durante o que Cockburn caracteriza como um jogo
de inveno e comunicao cooperativo e com recursos limitados, tendo como primeiro objetivo entregar software til em funcionamento e como segundo objetivo preparar-se para o jogo
seguinte [Coc02].
Para conseguir adaptabilidade, Cockburn e Highsmith definiram um conjunto de metodologias com elementos essenciais comuns a todas, mas com papis, padres de processos, produtos de trabalho e prtica nicos para cada uma delas. A famlia Crystal , na verdade, um
conjunto de exemplos de processos geis que provaram ser efetivos para diferentes tipos de
projetos. A inteno possibilitar que equipes geis selecionem o membro da famlia Crystal
mais apropriado para seu projeto e seu ambiente.
15 O nome crystal (cristal) derivado das caractersticas dos cristais geolgicos, cada qual com sua cor, forma e dureza prprias.

98

PARTE 1O processo de Software

3.5.5Desenvolvimento Dirigido a Funcionalidades (FDD)

WebRef
Uma ampla variedade
de artigos e apresentaes sobre o FDD pode
ser encontrada em:
www.feature
drivendevelopment.
com/.

O desenvolvimento dirigido a funcionalidades (Feature Driven Development) foi concebido


originalmente por Peter Coad e seus colegas [Coa99] como um modelo de processos prtico
para a engenharia de software orientada a objetos. Stephen Palmer e John Felsing [Pal02] estenderam e aperfeioaram o trabalho de Coad, descrevendo um processo gil adaptativo que pode
ser aplicado a projetos de software de porte moderado e a projetos maiores.
Como outras abordagens geis, o FDD adota uma filosofia que (1) enfatiza a colaborao
entre pessoas da equipe FDD; (2) gerencia problemas e complexidade de projetos utilizando a
decomposio baseada em funcionalidades, seguida pela integrao dos incrementos de software, e (3) comunicao de detalhes tcnicos usando meios verbais, grficos e de texto. O FDD
enfatiza as atividades de garantia da qualidade de software por meio do encorajamento de uma
estratgia de desenvolvimento incremental, o uso inspees do cdigo e do projeto, a aplicao
de auditorias para garantia da qualidade de software (Captulo 16), a coleta de mtricas e o uso
de padres (para anlise, projeto e construo).
No contexto do FDD, funcionalidade uma funo valorizada pelo cliente passvel de ser
implementada em duas semanas ou menos [Coa99]. A nfase na definio de funcionalidades
gera os seguintes benefcios:
Como as funcionalidades formam pequenos blocos que podem ser entregues, os usurios podem descrev-las mais facilmente; compreender como se relacionam entre si mais
prontamente; e revis-las melhor em termos de ambiguidade, erros ou omisses.
As funcionalidades podem ser organizadas em um agrupamento hierrquico relacionado
com o negcio.
Como uma funcionalidade o incremento de software do FDD que pode ser entregue, a
equipe desenvolve funcionalidades operacionais a cada duas semanas.
Pelo fato de o bloco de funcionalidades ser pequeno, seus projeto e representaes de
cdigo so mais fceis de inspecionar efetivamente.
O planejamento, cronograma e acompanhamento do projeto so guiados pela hierarquia
de funcionalidades, em vez de um conjunto de tarefas de engenharia de software arbitrariamente adotado.
Coad e seus colegas [Coa99] sugerem o seguinte modelo para definir uma funcionalidade:
<acao> o <resultado> <por| para quem |de |para que> um <objeto>

em que um <objeto> uma pessoa, local ou coisa (inclusive papis, momentos no tempo ou
intervalos de tempo ou descries parecidas com aquelas encontradas em catlogos). Exemplos de funcionalidades para uma aplicao de comrcio eletrnico poderiam ser:
Adicione o produto ao carrinho
Mostre as especificaes tcnicas do produto
Armazene as informaes de remessa para o cliente

Um conjunto de funcionalidades agrupa funcionalidades em categorias correlacionadas por


negcio e definido [Coa99] com:
<acao> um <objeto>

Por exemplo: Fazer a venda de um produto um conjunto de funcionalidades que abrangeria


os fatores percebidos anteriormente e outros.
A abordagem FDD define cinco atividades metodolgicas colaborativas [Coa99] (no FDD
estas so denominadas processos) conforme mostra a Figura 3.5.
O FDD oferece maior nfase s diretrizes e tcnicas de gerenciamento de projeto do que
muitos outros mtodos geis. Conforme os projetos crescem em tamanho e complexidade, com

99

captulo 3 DESENVOLVIMENTO GIL

Figura 3.5
Desenvolvimento
dirigido a funcionalidades
[Coa99]
(com
permisso)
Desenvolver

um
Modelo
Geral

(mais forma do
que contedo)

Construir
uma
Lista de
Funcionalidades

Uma lista de
funcionalidades
agrupadas em
conjuntos e em
reas com afinidades
temticas

Planejar
por
Funcionalidades

Um plano de
desenvolvimento
Proprietrios de classes
Proprietrios de Conjuntos
de Funcionalidade

Projetar
por
Funcionalidade

Um pacote de
projeto (sequncias)

Desenvolver
por
Funcionalidade

Funo valor-cliente
completada

frequncia o gerenciamento de projeto para finalidade local torna-se inadequado. essencial


para os desenvolvedores, seus gerentes e outros envolvidos compreenderem o posicionamento
do projeto que realizaes foram feitas e que problemas foram encontrados. Se a presso
do prazo de entrega for significativa, crtico determinar se os incrementos de software (funcionalidades) foram agendados apropriadamente. Para tanto, o FDD define seis marcos durante
o projeto e a implementao de uma funcionalidade: desenrolar (walkthroughs) do projeto,
projeto, inspeo de projeto, codificao, inspeo de cdigo, progresso para construo/desenvolvimento [Coa99].

3.5.6Desenvolvimento de Software Enxuto (LSD)


O desenvolvimento de software enxuto (Lean Software Development) adaptou os princpios
da fabricao enxuta para o mundo da engenharia de software. Os princpios enxutos que inspiraram o processo LSD podem ser sintetizados ([Pop03], [Pop06a]) em: eliminar desperdcio,
incorporar qualidade, criar conhecimento, adiar compromissos, entregar rpido, respeitar as pessoas e otimizar o todo.
Cada um dos princpios pode ser adaptado ao processo de software. Por exemplo, eliminar
desperdcio no contexto de um projeto de software gil pode ser interpretado como [Das05]: (1)
no adicionar recursos ou funes estranhas, (2) avaliar o impacto do custo e do cronograma de
qualquer requisito solicitado recentemente, (3) eliminar quaisquer etapas de processo suprfluas, (4) estabelecer mecanismos para aprimorar o modo pelo qual a equipe levanta informaes,
(5) assegurar-se de que os testes encontrem o maior nmero de erros possvel, (6) reduzir o
tempo necessrio para solicitar e obter uma deciso que afete o software ou o processo aplicado para cri-lo e (7) racionalizar a maneira pela qual informaes so transmitidas a todos
envolvidos no processo.
Para uma discusso detalhada do LSD e diretrizes pragmticas para implementao do processo, consulte [Pop06a] e [Pop06b].

3.5.7Modelagem gil (AM)


Existem muitas situaes em que engenheiros de software tm de desenvolver sistemas
grandes, com detalhes crticos em termos de negcio. O escopo e complexidade de tais sistemas devem ser modelados de modo que (1) todas as partes envolvidas possam entender melhor

100

WebRef

Informao
ampla sobre
a modelagem
gil pode ser
encontrada
em: www.
agilemodeling.
com.

Um dia, estava
em uma farmcia
tentando achar
um remdio para
resfriado... No foi
fcil... Havia uma
parede inteira de
produtos. Fica-se l
procurando: Bem,
este tem ao
imediata, mas este
outro tem efeito
mais duradouro....
O que mais
importante, o
presente ou o
futuro?
Jerry Seinfeld

PARTE 1O processo de Software

quais requisitos devero ser atingidos, (2) o problema possa ser subdividido eficientemente
entre as pessoas que tm de solucion-lo e (3) a qualidade possa ser avaliada enquanto se est
projetando e desenvolvendo o sistema.
Ao longo dos ltimos 30 anos, uma ampla variedade de notaes e mtodos de modelagem
de engenharia de software tem sido proposta para anlise e projeto (tanto no nvel de componente como de arquitetura). Esses mtodos tm seus mritos, mas provaram ser difceis de ser
aplicados e desafiadores para ser mantidos (ao longo de vrios projetos). Parte do problema o
peso dos mtodos de modelagem. Com isso quero dizer o volume de notao exigido, o grau
de formalismo sugerido, o puro tamanho dos modelos para grandes projetos e a dificuldade
em manter o(s) modelo(s) medida que ocorrem as mudanas. Contudo, o modelamento de
anlise e projeto tem um benefcio substancial para grandes projetos ainda que seja apenas
para torn-los intelectualmente gerenciveis. Existe uma abordagem gil para a modelagem de
engenharia de software que poderia fornecer uma alternativa?
No The Official Agile Modeling Site, Scott Ambler [Amb02a] descreve modelagem gil (AM)
da seguinte maneira:
Modelagem gil (AM) consiste em uma metodologia baseada na prtica, voltada para o modelamento
e documentao de sistemas com base em software. Simplificando, modelagem gil consiste em um
conjunto de valores, princpios e prticas voltados para a modelagem do software que pode ser aplicados em um projeto de desenvolvimento de software de forma leve e efetiva. Os modelos geis so
mais efetivos do que os tradicionais pelo fato de serem meramente bons, pois no tm a obrigao de
ser perfeitos.

Modelagem gil adota todos os valores consistentes com o manifesto gil. Sua filosofia reconhece que uma equipe gil deve ter a coragem de tomar decises que possam causar a rejeio
de um projeto e sua refabricao. A equipe tambm deve ter humildade para reconhecer que
os profissionais de tecnologia no possuem todas as respostas e que os experts em negcios e
outros envolvidos devem ser respeitados e integrados ao processo.
Embora a AM sugira uma ampla gama de princpios de modelagem essenciais e suplementares, os que tornam a AM nica so [Amb02a]:
Modele com um objetivo. O desenvolvedor que utilizar o AM deve ter um objetivo antes
de criar o modelo (por exemplo, comunicar informaes ao cliente ou ajudar a compreender
melhor algum aspecto do software). Uma vez identificado o objetivo, ficar mais bvio o tipo
de notao a ser utilizado e o nvel de detalhamento necessrio.
Use modelos mltiplos. H muitos modelos e notaes diferentes que podem ser usados
para descrever software. Somente um subconjunto essencial para a maioria dos projetos. AM
sugere que, para propiciar o insight necessrio, cada modelo deve apresentar um aspecto diferente do sistema e somente aqueles que valorizem esses modelos para a audincia pretendida
devem ser usados.

AVISO
Viajar leve uma
filosofia apropriada
para todo o trabalho
de engenharia de
software. Construa
apenas aqueles
modelos que forneam
valor Nem mais,
nem menos.

Viajar leve. Conforme o trabalho de engenharia de software prossegue, conserve apenas


aqueles modelos que tero valor no longo prazo e despache o restante. Todo produto de
trabalho mantido deve sofrer manuteno medida que as mudanas ocorram. Isso representa trabalho que retarda a equipe. Ambler [Amb02a] observa que Toda vez que se opta por
manter um modelo, troca-se a agilidade pela convenincia de ter aquela informao acessvel para a equipe de uma forma abstrata (j que, potencialmente, aumenta a comunicao
dentro da equipe, assim como com os envolvidos no projeto).
Contedo mais importante do que a representao. A modelagem deve transmitir
informao para sua audincia pretendida. Um modelo sintaticamente perfeito que transmita pouco contedo til no possui tanto valor como aquele com notaes falhas que, no
entanto, fornece contedo valioso para seu pblico-alvo.
Tenha conhecimento, domnio dos modelos e das ferramentas que for utilizar.
Compreenda os pontos fortes e fracos de cada modelo e ferramenta usada para cri-lo.

101

captulo 3 DeseNVoLVIMeNto GIL

Adapte localmente. A abordagem de modelagem deve ser adaptada s necessidades da


equipe gil.
Um segmento de vulto da comunidade da engenharia de software adotou a linguagem de
modelagem unificada (Unified Modeling Language, UML)16 como o mtodo preferido para anlise representativa e para modelos de projeto. O Processo unificado (Captulo 2) foi desenvolvido
para fornecer uma metodologia para a aplicao da UML. Scott Ambler [Amb06] desenvolveu
uma verso simplificada do UP que integra sua filosofia de modelagem gil.

3.5.8

processo unificado gil (aup)

O processo unificado gil (Agile Unified Process) adota uma filosofia serial para o que amplo e iterativa para o que particular [Amb06] no desenvolvimento de sistemas computadorizados. Adotando as atividades em fases UP clssicas incio, elaborao, construo e transio
, AUP fornece uma camada serial (isto , uma sequncia linear de atividades de engenharia de
software) que capacita uma equipe a visualizar o fluxo do processo geral de um projeto de software. Entretanto, dentro de cada atividade, a equipe itera ou se repete para alcanar a agilidade
e para entregar incrementos de software significativos para os usurios finais to rapidamente
quanto possvel. Cada iterao AUP dirige-se para as seguintes atividades [Amb06]:
Modelagem. Representaes UML do universo do negcio e do problema so criadas.
Entretanto, para permanecer gil, esses modelos devem ser suficientemente bons e adequados [Amb06] para possibilitar que a equipe prossiga.
Implementao. Os modelos so traduzidos para o cdigo-fonte.
Teste. Como a XP, a equipe projeta e executa uma srie de testes para descobrir erros e
assegurar que o cdigo-fonte se ajuste aos requisitos.
Aplicao. Como a atividade de processo genrica discutida nos Captulos 1 e 2, a aplicao neste contexto enfoca a entrega de um incremento de software e a aquisio de
feedback dos usurios finais.
Configurao e gerenciamento de projeto. No contexto da AUP, gerenciamento de configurao (Captulo 22) refere-se a gerenciamento de alteraes, de riscos e de controle de
qualquer artefato167 persistente que sejam produzidos por uma equipe. Gerenciamento de
projeto traciona e controla o progresso de uma equipe e coordena suas atividades.18

FERRAMENTAS DO SOFTWARE
Engenharia de requisitos
Objetivo: O objetivo das ferramentas de desenvolvimento gil auxiliar em um ou mais aspectos do
desenvolvimento gil com nfase em facilitar a gerao rpida
de software operacional. Essas ferramentas tambm podem ser
usadas quando forem aplicados modelos de processos prescritivos (Captulo 2).
Mecnica: A mecnica das ferramentas varia. Em geral, conjuntos de ferramentas geis englobam suporte automatizado
para o planejamento de projetos, desenvolvimento de caso
prtico, coletnea de requisitos, projeto rpido, gerao de
cdigo e teste.
Ferramentas representativas:18
Nota: Por ser o desenvolvimento gil um tpico importante,
a maioria dos vendedores de ferramentas de software

16
17

tende a vender ferramentas que do suporte para a


abordagem gil. As ferramentas aqui observadas tm
caractersticas que as tornam particularmente teis para
projetos geis.
OnTime, desenvolvida pela Axosoft (www.axosoft.com),
fornece suporte para gerenciamento de processo gil
para uma variedade de atividades tcnicas dentro do
processo.
Ideogramic UML, desenvolvida pela Ideogramic (www.ideo
gramic.com), um conjunto de ferramentas UML desenvolvido para uso em processo gil.
Together Tool Set, distribuda pela Borland (www.borland.
com), fornece uma mala de ferramentas que do suporte
para muitas atividades tcnicas na XP e em outros processos geis.

Um breve tutorial sobre a UML apresentado no Apndice 1.


Artefato persistente um modelo ou documento ou pacote de testes produzido pela equipe que ser mantido por um perodo
de tempo indeterminado. No ser descartado, uma vez que o incremento de software seja entregue.
18 Ferramentas observadas aqui no significam um aval, mas antes, uma amostra de ferramentas nesta categoria. Na maioria
dos casos, os nomes das ferramentas so negociados por seus respectivos desenvolvedores.

102

PARTE 1O processo de Software

Gerenciamento do ambiente. Coordena a infraestrutura de processos que inclui padres,


ferramentas e outras tecnologias de suporte disponveis para a equipe.
Embora o AUP possua conexes histricas e tcnicas com a linguagem de modelagem unificada, importante notar que a modelagem UML pode ser usado em conjunto com quaisquer
modelos de processos geis descritos na Seo 3.5.

3 .6

O conjunto de
ferramentas que
suporta os processos
geis focaliza mais
as questes pessoais
do que as questes
tecnolgicas.

3.7

Um Conjunto

de

F e r r a m e n ta s

pa r a o

Processo gil

Alguns proponentes da filosofia gil argumentam que as ferramentas de software automatizadas (por exemplo, ferramentas para projetos) deveriam ser vistas como um suplemento menor
para as atividades, e no como piv para o sucesso da equipe. Entretanto, Alistair Cockburn
[Coc04] sugere que ferramentas podem gerar um benefcio e que equipes geis enfatizam o
uso de ferramentas que permitam o fluxo rpido de compreenso. Algumas dessas ferramentas
so sociais, iniciando-se at no estgio de contratao de pessoal. Algumas so tecnolgicas,
auxiliando equipes distribudas a simular sua presena fsica. Muitas so fsicas, permitindo sua
manipulao em workshops.
Pelo fato de que contratar as pessoas certas, ter a colaborao da equipe, manter a comunicao com os envolvidos e conseguir gerenciar de forma indireta constiturem elementos-chave
em praticamente todos os modelos de processos geis, Cockburn afirma que ferramentas
destinadas a esses itens so fatores crticos para a agilidade. Por exemplo, uma ferramenta
alugada pode vir a ser um requisito para ter um membro de equipe de prospeco destinado a
despender algumas poucas horas em programao em dupla, com um membro j existente da
equipe. O encaixe pode ser avaliado imediatamente.
Ferramentas voltadas para a comunicao e para a colaborao so, em geral, de tecnologia de base e incorporam qualquer mecanismo (proximidade fsica, quadros brancos, papis
para pster, fichas e lembretes adesivos [Coc04]) que fornece informaes e coordenao entre
desenvolvedores. A comunicao ativa obtida por meio de dinmicas de grupo (por exemplo,
programao em dupla), enquanto a comunicao passiva obtida atravs dos irradiadores
de informaes (por exemplo, um display de um painel fixo que apresente o status geral dos
diferentes componentes de um incremento). As ferramentas de gerenciamento de projeto no
enfatizam tanto o diagrama de Gantt e o realoca com quadros de valores ganhos ou grficos
de testes criados e cruzados com os anteriores... Outras ferramentas geis so utilizadas para
otimizar o ambiente no qual a equipe gil trabalha (por exemplo, mais reas eficientes de encontro), tambm para ampliar a cultura da equipe por meio de incentivos para interaes sociais
(por exemplo, equipes alocadas juntas), para dispositivos fsicos (por exemplo, lousas eletrnicas) e para ampliao (por exemplo, programao em dupla ou janela de tempo) [Coc04].
Quaisquer dessas coisas so ferramentas? Sero, caso facilitem o trabalho desenvolvido por
um membro da equipe gil e venham a aprimorar a qualidade do produto final.

Resumo
Em uma economia moderna, as condies de mercado mudam rapidamente, tanto o cliente quanto o usurio final devem evoluir e novos desafios competitivos surgem sem aviso. Os
desenvolvedores tm de assumir uma abordagem de engenharia de software para permitir que
permaneam geis definindo processos que sejam manipulveis, adaptveis, sem excessos,
somente com o contedo essencial que possa adequar-se s necessidades do moderno mundo
de negcios.
Uma filosofia gil para a engenharia de software enfatiza quatro elementos-chave: a importncia das equipes que se auto-organizam, que tenham controle sobre o trabalho por elas
realizado, sobre a comunicao e sobre a colaborao entre os membros da equipe e entre os

103

captulo 3 DESENVOLVIMENTO GIL

desenvolvedores e seus clientes; o reconhecimento de que as mudanas representam oportunidades e nfase na entrega rpida do software para satisfazer o cliente.
A Extreme Programming (XP) o processo gil mais amplamente utilizado. Organizada em
quatro atividades metodolgicas, planejamento, projeto, codificao e testes, a XP sugere um
nmero de tcnicas poderosas e inovadoras que possibilitam a uma equipe gil criar verses de
software frequentemente, propiciando recursos e funcionalidade estabelecidos anteriormente,
e, ento, priorizando os envolvidos.
Outros modelos de processos geis tambm enfatizam a colaborao humana e a auto-organizao das equipes, mas definem suas prprias atividades metodolgicas e selecionam
diferentes pontos de nfase. Por exemplo, ASD usa um processo iterativo que incorpora um
planejamento cclico iterativo, mtodos de levantamento de requisitos relativamente rigorosos,
e um ciclo de desenvolvimento iterativo que incorpora grupos focados nos clientes e revises
tcnicas formais como mecanismos de feedback em tempo real. O Scrum enfatiza o uso de um
conjunto de padres de software que se mostrou efetivo para projetos com cronogramas apertados, requisitos mutveis e aspectos crticos de negcio. Cada padro de processo define um
conjunto de tarefas de desenvolvimento e permite equipe Scrum construir um processo que
se adapta s necessidades do projeto. O mtodo de desenvolvimento de sistemas dinmicos
(DSDM) defende o uso de um cronograma de tempos definidos (janela de tempo) e sugere que
apenas o trabalho suficiente seja requisitado para cada incremento de software para facilitar o
movimento ao incremento seguinte. Crystal uma famlia de modelos de processos geis que
podem ser desenvolvidos para uma caracterstica especfica de um projeto.
O desenvolvimento dirigido a funcionalidades (FDD) ligeiramente mais formal que os outros mtodos, mas ainda mantm agilidade ao focar a equipe do projeto no desenvolvimento de
funcionalidades validadas pelo cliente que possam ser implementadas em duas semanas ou
menos. O desenvolvimento de software enxuto (LSD) adaptou os princpios de uma fabricao
enxuta para o mundo da engenharia de software. A modelagem gil (AM) afirma que modelagem
essencial para todos os sistemas, mas a complexidade, tipo e tamanhos de um modelo devem
ser balizados pelo software a ser construdo. O processo unificado gil (AUP) adota a filosofia
de serial para o que amplo e iterativa para o que particular para o desenvolvimento de
software.

Problemas

Pontos

Ponderar

3.1. Releia The Manifesto for Agile Software Development no incio deste captulo. Voc
consegue exemplificar uma situao em que um ou mais dos quatro valores poderiam levar
a equipe a ter problemas?
3.2. Descreva agilidade (para projetos de software) com suas prprias palavras.
3.3. Por que um processo iterativo facilita o gerenciamento de mudanas? Todos os processos geis discutidos neste captulo so iterativos? possvel completar um projeto com
apenas uma iterao e ainda assim permanecer gil? Justifique suas respostas.
3.4. Cada um dos processos geis poderia ser descrito usando-se as atividades estruturais
genricas citadas no Captulo 2? Construa uma tabela que associe as atividades genricas s
atividades definidas para cada processo gil.
3.5. Tente elaborar mais um princpio de agilidade que ajudaria uma equipe de engenharia
de software a se tornar mais manobrvel.
3.6. Escolha um princpio de agilidade citado na Seo 3.3.1 e tente determinar se cada um
dos modelos de processos apresentados neste captulo demonstra o princpio. [Nota: Apresentei apenas uma viso geral desses modelos de processos; portanto, talvez no seja possvel determinar se determinado princpio foi ou no tratado por um ou mais dos modelos, a
menos que voc pesquise mais a respeito (o que no exigido para o presente problema).

104

PARTE 1O processo de Software

3.7. Por que os requisitos mudam tanto? Afinal de contas, as pessoas no sabem o que elas
querem?
3.8. A maior parte dos modelos de processos geis recomenda comunicao cara a cara.
Mesmo assim, hoje em dia os membros de uma equipe de software e seus clientes podem
estar geograficamente separados uns dos outros. Voc acredita que isso implique que a separao geogrfica seja algo a ser evitado? Voc capaz de imaginar maneiras para superar
esse problema?
3.9. Escreva uma histria de usurio XP que descreva o recurso sites favoritos ou bookmarks disponvel na maioria dos navegadores para Web.
3.10. O que uma soluo pontual na XP?
3.11. Descreva com suas prprias palavras os conceitos de refabricao e programao em
dupla da XP.
3.12. Leia um pouco mais a respeito e descreva o que uma janela de tempo. Como isso ajuda uma equipe ASD na entrega de incrementos de software em um curto perodo de tempo?
3.13. A regra dos 80% do DSDM e a abordagem de janelas de tempo definida para o ASD
alcanam os mesmos resultados?
3.14. Usando a planilha de padres de processos apresentada no Captulo 2, desenvolva um
padro de processo para qualquer um dos padres Scrum da Seo 3.5.2.
3.15. Por que o Crystal considerado uma famlia de mtodos geis?
3.16. Usando o gabarito de recursos FDD descrito na Seo 3.5.5, defina um conjunto de
recursos para um navegador Web. Agora, desenvolva vrios recursos para o conjunto de recursos.
3.17. Visite The Official Agile Modeling Site e faa uma lista completa de todos os princpios bsicos e complementares do AM.
3.18. O conjunto de ferramentas proposto na Seo 3.6 oferece suporte a muitos dos aspectos menos prioritrios dos mtodos geis. Como a comunicao to importante, recomende um conjunto de ferramentas real que poderia ser usado para melhorar a comunicao
entre os interessados de uma equipe gil.

Leituras

Fontes

de

I n f o r m a o C o m p l e m e n ta r e s

A filosofia geral e os princpios subjacentes do desenvolvimento de software gil so considerados em profundidade em muitos dos livros citados neste captulo. Alm destes, livros
como os de Shaw e Warden (The Art of Agile Development, OReilly Media, Inc., 2008), Hunt
(Agile Software Building, Springer, 2005) e Carmichael e Haywood (Better Software Faster,
Prentice-Hall, 2002) trazem discusses interessantes sobre o tema. Aguanno (Managing Agile
Projects, Multi-Media Publications, 2005), Highsmith (Agile Project Management: Creating
Innovative Products, Addison-Wesley, 2004) e Larman (Agile and Iterative Development: A
Managers Guide, Addison-Wesley, 2003) apresentam uma viso geral sobre gerenciamento
e consideram as questes envolvidas no gerenciamento de projetos. Highsmith (Agile Software Development Ecosystems, Addison-Wesley, 2002) retrata uma pesquisa de princpios,
processos e prticas geis. Uma discusso que vale a pena sobre o delicado equilbrio entre
agilidade e disciplina fornecida por Booch e seus colegas (Balancing Agility and Discipline,
Addison-Wesley, 2004).
Martin (Clean Code: A Handbook of Agile Software Craftsmanship, Prentice-Hall, 2009)
enumera os princpios, padres e prticas necessrios para desenvolver cdigo limpo em
um ambiente de engenharia de software gil. Leffingwell (Scaling Software Agility: Best Practices for Large Enterprises, Addison-Wesley, 2007) discute estratgias para dar maior corpo s
prticas geis para poderem ser usadas em grandes projetos. Lippert e Rook (Refactoring in
Large Software Projects: Performing Complex Restructurings Successfully,Wiley, 2006) discutem o uso da refabricao quando aplicada a sistemas grandes e complexos.

captulo 3 DESENVOLVIMENTO GIL

105

Stamelos e Sfetsos (Agile Software Development Quality Assurance, IGI Global, 2007) trazem tcnicas SQA que esto em conformidade com a filosofia gil.
Foram escritos dezenas de livros sobre Extreme Programming ao longo da ltima dcada. Beck (Extreme Programming Explained: Embrace Change, 2. ed., Addison-Wesley, 2004)
ainda o tratado de maior autoridade sobre o tema. Alm desse, Jeffries e seus colegas
(Extreme Programming Installed, Addison-Wesley, 2000), Succi e Marchesi (Extreme Programming Examined, Addison-Wesley, 2001), Newkirk e Martin (Extreme Programming in Practice, Addison-Wesley, 2001), bem como Auer e seus colegas (Extreme Programming Applied:
Play to Win, Addison-Wesley, 2001), fornecem uma discusso bsica da XP juntamente com
uma orientao sobre como melhor aplic-la. McBreen (Questioning Extreme Programming,
Addison-Wesley, 2003) adota uma viso crtica em relao XP, definindo quando e onde ela
apropriada. Uma anlise aprofundada da programao em dupla apresentada por McBreen
(Pair Programming Illuminated, Addison-Wesley, 2003).
A ASD tratada em profundidade por Highsmith [Hig00]. Schwaber (The Enterprise and
Scrum, Microsoft Press, 2007) discute o uso do Scrum para projetos que possuem um grande
impacto sobre as empresas. Os detalhes prticos do Scrum so debatidos por Schwaber e
Beedle (Agile Software Development with SCRUM, Prentice-Hall, 2001). Tratados teis sobre o
DSDM foram escritos pelo DSDM Consortium (DSDM: Business Focused Development, 2. ed.,
Pearson Education, 2003) e Stapleton (DSDM: The Method in Practice, Addison-Wesley, 1997).
Cockburn (Crystal Clear, Addison-Wesley, 2005) traz uma excelente viso geral da famlia
Crystal de processos. Palmer e Felsing [Pal02] apresentam um tratado detalhado acerca do
FDD. Carmichael e Haywood (Better Software Faster, Prentice-Hall, 2002) mais um tratado
til sobre o FDD que inclui uma jornada passo a passo atravs da mecnica do processo.
Poppendieck e Poppendieck (Lean Development: An Agile Toolkit for Software Development
Managers, Addison-Wesley, 2003) do diretrizes para gerenciar e controlar projetos geis.
Ambler e Jeffries (Agile Modeling, Wiley, 2002) discutem a AM com certa profundidade.
Uma grande variedade de fontes de informao sobre desenvolvimento de software gil
est disponvel na Internet. Uma lista atualizada de referncias na Web relevantes ao processo gil pode ser encontrada no site www.mhhe.com/engcs/compsci/pressman/professional/
olc/ser.htm.

PA

RTE

DOIS

MODELAGEM

esta parte do livro Engenharia de software: uma abordagem profissional, voc


aprender os princpios, conceitos e mtodos usados para criar modelos de necessidades e de projeto de alta qualidade.
As seguintes questes so tratadas nos prximos captulos:
Quais conceitos e princpios orientam a prtica da engenharia de software?
O que engenharia de necessidades e quais os conceitos subjacentes que levam a
uma anlise de necessidades adequada?
Como criado o modelo de necessidades e quais seus elementos?
Quais os elementos de um bom projeto?
Como o desenho da arquitetura estabelece uma estrutura para todas as demais
aes de projeto e quais os modelos utilizados?
Como projetar componentes de software de alta qualidade?
Que conceitos, modelos e mtodos so aplicados quando projetada uma interface
para o usurio?
O que projeto baseado em padres?
Que estratgias e mtodos especializados so usados para projetar WebApps?

Assim que essas perguntas forem respondidas, voc estar mais bem preparado para a
prtica da engenharia de software.

captulo

captulo

Conceitos- Chave
princpios
fundamentais . . . . 109
princpios que governam
a codificao . . . 120
a comunicao . . 112
a disponibilizao . 122
a modelagem . . . 116
o planejamento . 114
o projeto . . . . . . 118
os requisitos . . . 117
os testes . . . . . . 121

Princpios Que
O rientam a Prtica

m um livro que pesquisa o cotidiano e reflexes dos engenheiros de software, Ellen


Ullman [Ull 97] descreve um pouco da experincia de vida, medida que relata os
pensamentos do profissional atuante sob presso:

No tenho ideia de que horas so. No h janelas neste escritrio, nem relgio, somente o LED
vermelho de um micro-ondas piscando 12:00, 12:00, 12:00, 12:00. Joel e eu estamos programando
h dias. Temos um defeito, um demnio teimoso... Da mesma forma, o pisca vemelho no se acerta em temporizao, como se fosse uma representao de nossos crebros, que, de alguma forma,
acabaram sincronizados com a mesma fasca temporal do LED...
Em que estamos trabalhando?... Os detalhes me escapam agora. Podemos estar auxiliando os pobres ou sintonizando uma srie de rotinas de baixo nvel, a fim de verificar os bits de um protocolo
de distribuio de dados. Nem me importo. Deveria me importar; em uma outra poca talvez,
quando sairmos desta sala cheia de computadores , me importarei muitssimo com o porqu,
para quem e para qual finalidade estou desenvolvendo software. Mas neste exato momento: no.
Ultrapassei uma camada na qual o mundo real e seus usurios no mais importam. Sou um engenheiro de software...

Muitos leitores estaro capacitados para lidar com esse lado sombrio da engenharia de
software, com ponderao.

O que ? A prtica da engenharia de

Panorama software consiste em uma srie de prin-

cpios, conceitos, mtodos e ferramentas


que devem ser considerados ao planejar
e desenvolver um software. Princpios que direcionem a ao estabelecem a infraestrutura a partir
da qual a engenharia de software conduzida.
Quem realiza? Praticantes (engenheiros de software)
e seus coordenadores (gerentes) desenvolvem
uma variedade de tarefas de engenharia de
software.
Por que importante? O processo de software
propicia a todos os envolvidos na criao de
um sistema computacional ou produto para computador um roteiro para conseguir chegar a um
destino com sucesso. A prtica fornece o detalhamento necessrio para seguir ao longo da
estrada. Aponta para onde esto as pontes, os
conjuntos de rodovias, as bifurcaes. Auxilia a
compreender os conceitos e princpios que devem
ser compreendidos e seguidos para que se dirija
com rapidez e segurana. Orienta quanto ao
como seguir, onde diminuir e aumentar o ritmo.
No contexto da engenharia de software, a prtica

108

consiste no que se realiza diariamente, medida


que o software evolui de ideia a realidade.
Quais so as etapas envolvidas? Aplicam-se trs
elementos prticos, independentemente do modelo de processo escolhido. So eles: princpios,
conceitos e mtodos. Um quarto elemento de
prtica, ferramentas, sustenta a aplicao dos
mtodos.
Qual o artefato? A prtica engloba as atividades
tcnicas que produzem todos os artefatos definidos
pelo modelo de processo de software escolhido.
Como garantir que o trabalho foi realizado corretamente? Primeiro, compreenda completamente

os princpios aplicados ao trabalho (por exemplo,


projeto) que est sendo realizado no momento. Em
seguida, esteja certo de que escolheu um mtodo
apropriado, certifique-se de ter compreendido
como aplicar o mtodo, use ferramentas automatizadas, quando estas forem apropriadas tarefa,
e seja inflexvel quanto necessidade de tcnicas
para se assegurar da qualidade dos produtos de
trabalho produzidos.

109

captulo 4 Princpios que ORIENTAM A PRTICA

As pessoas que criam software praticam a arte ou ofcio ou disciplina1 em que consiste
a engenharia de software. Mas em que consiste a prtica de engenharia de software? De
forma genrica, prtica um conjunto de conceitos, princpios, mtodos e ferramentas aos
quais um engenheiro de software recorre diariamente. A prtica permite aos coordenadores
(gerentes) administrar os projetos e aos engenheiros de software criar programas computacionais. A prtica preenche um modelo de processo de software com recursos de como fazer
para ter o trabalho realizado em termos de gerenciamento e de tecnologia. Transforma uma
abordagem desfocada e confusa em algo mais organizado, mais efetivo e mais propenso a
obter sucesso.
Diversos aspectos da engenharia de software sero examinados ao longo do livro.
Neste captulo, o foco ser em princpios e conceitos que norteiam a prtica da engenharia
de sofwtare em geral.

4 .1

Conhecimento

da

Engenharia

de

S o f t wa r e

Em um editorial publicado na IEEE Software uma dcada atrs, Steve McConnell [McC99] fez
o seguinte comentrio:
Muitos desenvolvedores (de software) veem o conhecimento da engenharia de software quase que
exclusivamente como um conhecimento de tecnologias especficas: Java, Perl, html, C++, Linux, Windows NT etc. O conhecimento de detalhes especficos de tecnologia necessrio para desenvolver a
programao de computador. Se algum o contrata para desenvolver um programa em C++, voc dever saber algo sobre C++ para fazer seu programa funcionar.
Frequentemente, diz-se que conhecimento sobre desenvolvimento de software tem uns trs anos de
vida: metade do que se precisa saber hoje estar obsoleto daqui a trs anos. No que diz respeito ao
conhecimento de tecnologia, essa afirmao est prxima da verdade. Mas h um outro tipo de conhecimento sobre desenvolvimento de software um tipo visto como princpios da engenharia de software que no possui trs anos de meia-vida. Tais princpios provavelmente serviro ao programador
profissional durante toda a sua carreira.

McConnell continua afirmando que a base do conhecimento em engenharia de software (por


volta do ano 2000) evoluiu para uma essncia estvel que ele estimou representar cerca de
75% do conhecimento necessrio para desenvolver um sistema complexo. No entanto, no que
consiste essa essncia estvel?
Como indica McConnell, princpios essenciais ideias elementares que guiam engenheiros de software em seus trabalhos fornecem, em nossos dias, uma infraestrutura a partir
da qual os modelos de engenharia de software, mtodos e ferramentas podem ser aplicados
e avaliados.

4 .2

Teoricamente,
no h nenhuma
diferena entre a
teoria e a prtica.
Porm, na prtica,
ela existe.
Jan van de
Snepscheut

P r i n c p i o s F u n d a m e n ta i s
A engenharia de software norteada por um conjunto de princpios fundamentais que auxiliam na aplicao de um processo de software significativo e na execuo de mtodos de
engenharia de software efetivos. No nvel relativo a processo, os princpios fundamentais estabelecem uma infraestrutura filosfica que guia uma equipe de software medida que desenvolve atividades de apoio e estruturais, navega no fluxo do processo e cria um conjunto de artefatos
de engenharia de software. Quanto prtica, os princpios fundamentais estabelecem um artefatos e regras que servem como guias conforme se analisa um problema, projeta uma soluo,
implementa e testa uma soluo e, por fim, emprega o software na comunidade de usurios.
No Captulo 1, identificou-se uma srie de princpios fundamentais que abrange o processo
e a prtica da engenharia de software: (1) fornecer valor aos usurios finais, (2) simplificar, (3)
1

Certos autores argumentam que um desses termos exclui outros. Na realidade, a engenharia de software se aplica a todos
os trs.

110

Parte 2 MOdelagem

manter a viso (do produto e do projeto), (4) reconhecer que outros usurios consomem (e devem entender) o que se produz, (5) manter abertura para o futuro, (6) planejar antecipadamente
para o reso, e (7) raciocinar!
Embora tais princpios gerais sejam importantes, so caracterizados em um nvel to elevado de abstrao que, s vezes, torna-se difcil a traduo para a prtica diria da engenharia de
software. Nas subsees seguintes, h um maior detalhamento dos princpios essenciais que
conduzem o processo e a prtica.

4.2.1Princpios que orientam o processo


Na Parte 1 deste livro, discutiu-se a importncia do processo de software e descreveram-se os diferentes modelos de processos propostos para o trabalho de engenharia de software.
No importando se um modelo linear ou iterativo, prescritivo ou gil, pode ser caracterizado
usando-se uma metodologia de processo genrica aplicvel a todos os modelos de processo. O
conjunto de princpios fundamentais apresentados a seguir pode ser aplicado metodologia e,
por extenso, a todos os processos de software.

AVISO
Todo projeto e toda
equipe so nicos. Isso
significa que se deve
adaptar o processo
para que melhor se
ajuste s suas
necessidades.

Princpio 1. Seja gil. No importa se o modelo de processo que voc escolheu prescritivo ou gil, os princpios bsicos do desenvolvimento gil devem comandar sua abordagem.
Todo aspecto do trabalho deve enfatizar a economia de aes mantenha a abordagem
tcnica to simples quanto possvel, mantenha os produtos to concisos quanto possvel e
tome decises localmente sempre que possvel.
Princpio 2. Concentre-se na qualidade em todas as etapas. A condio final para toda
atividade, ao e tarefa do processo deve focar na qualidade do produto produzido.
Princpio 3. Esteja pronto para adaptaes. Processo no uma experincia religiosa e
no h espao para dogma. Quando necessrio, adapte sua abordagem s restries impostas pelo problema, pelas pessoas e pelo prprio projeto.
Princpio 4. Monte uma equipe efetiva. O processo e a prtica de engenharia de software
so importantes, mas o fator mais importante so as pessoas. Forme uma equipe que se
auto-organize, que tenha confiana e respeito mtuos.
Princpio 5. Estabelea mecanismos para comunicao e coordenao. Os projetos
falham devido omisso de informaes importantes nas fendas da estrutura do programa
e/ou devido a indivduos que falham na coordenao de seus esforos para criar um produto
final bem-sucedido. Esses so itens de gerenciamento e devem ser direcionados.

A verdade da
questo que
sempre sabemos
a coisa certa a ser
feita. A parte difcil
faz-la.
General H.
Norman
Schwarzkopf

Princpio 6. Gerencie mudanas. A abordagem pode ser tanto formal quanto informal,
entretanto os mecanismos devem ser estabelecidos para gerenciar a maneira como as mudanas sero solicitadas, avaliadas, aprovadas e implementadas.
Princpio 7. Avalie os riscos. Uma srie de coisas pode dar errada quando um software
desenvolvido. essencial estabelecer planos de contingncia.
Princpio 8. Gere artefatos que forneam valor para outros. Crie apenas artefatos que
proporcionaro valor para outro processo, atividades, aes ou tarefas. Todo artefato produzido como parte da prtica da engenharia de software ser repassado para algum mais.
Uma lista de funes e caractersticas requisitadas ser repassada para a pessoa (ou pessoas) que ir desenvolver um projeto, o projeto ser repassado para aqueles que geraro o
cdigo e assim por diante. Certifique-se de que o artefato contenha a informao necessria
sem ambiguidades ou omisses.
A Parte 4 deste livro enfoca o projeto, os fatores de gerenciamento do processo e aborda os
aspectos variados de cada um desses princpios com certo detalhe.

captulo 4 Princpios que ORIENTAM A PRTICA

111

4.2.2Princpios que orientam a prtica


A prtica da engenharia de software tem um objetivo primordial nico entregar dentro
do prazo, com alta qualidade, o software operacional contendo funes e caractersticas que
satisfaam as necessidades de todos os envolvidos. Para atingir esse objetivo, deve-se adotar
um conjunto de princpios fundamentais que orientem o trabalho tcnico. Tais princpios so
importantes, independentemente do mtodo de anlise ou projeto aplicado, das tcnicas de
desenvolvimento (por exemplo, linguagem de programao, ferramentas de automao) escolhidas, ou da abordagem de verificao e validao utilizada. O cumprimento de princpios fundamentais a seguir essencial para a prtica de engenharia de software:
Princpio 1. Divida e conquiste. De forma mais tcnica, a anlise e o projeto sempre
devem enfatizar a separao por interesses2 ( separation of concerns SoC). Um problema
ter sua resoluo mais fcil se for subdividido em conjuntos de interesses. Na forma ideal,
cada interesse fornece uma funcionalidade distinta a ser desenvolvida, e, em alguns casos,
validada, independentemente de outros negcios.

Os problemas
tornam-se mais fceis
para resolver quando
subdivididos por interesses, cada um distinto, individualmente
solucionvel e passvel
de verificao.

Princpio 2. Compreenda o uso da abstrao. Na essncia, abstrair simplificar algum


elemento complexo de um sistema utilizado para comunicar significado em uma nica frase.
Quando se usa a abstrao planilha, assume-se que se compreende o que vem a ser uma
planilha, a estrutura geral de contedo que uma planilha apresenta e as funes tpicas que
podem ser aplicadas a ela. Na prtica de engenharia de software, usam-se muitos nveis
diferentes de abstrao, cada um incorporando ou implicando um significado que deve ser
comunicado. No trabalho de anlise de projeto, uma equipe de sofware normalmente inicia
com modelos que representam altos nveis de abstrao (por exemplo, planilha) e, aos poucos, refina tais modelos em nveis de abstrao mais baixos (por exemplo, uma coluna ou
uma funo de soma).
Joel Spolsky [Spo02] sugere que todas as abstraes no triviais so, at certo ponto, frgeis. O objetivo de uma abstrao eliminar a necessidade de comunicar detalhes. Algumas
vezes, efeitos problemticos se precipitam em virtude da aresta dos detalhes. Sem a compreenso dos detalhes, a causa de um problema no poder ser facilmente diagnosticada.
Princpio 3. Esforce-se por consistncia. Seja criando um modelo de requisitos, desenvolvendo um projeto de software, gerando cdigo-fonte, seja criando pacotes de teste, o
princpio de consistncia sugere que um contexto familiar facilita o uso do software. Consideremos, por exemplo, o projeto de uma interface para o usurio de uma WebApp. A colocao consistente de menu de opes, o uso consistente de um esquema de cores e de cones
identificveis, tudo colabora para uma interface ergonomicamente forte.
Princpio 4. Foque na transferncia de informao. Software trata a transferncia de
informaes: do banco de dados para um usurio final, de um sistema judicirio para uma
aplicao na Web (WebApp), do usurio final para uma interface grfica (GUI), de um sistema
operacional de um componente de software para outro; a lista quase infinita. Em todos os
casos, a informao flui atravs de uma interface, e, como consequncia, h a possibilidade
de erros, omisses e ambiguidade. A implicao desse princpio que se deve prestar especial ateno para interfaces de anlise, projeto, construo e testes.
Princpio 5. Construa software que apresente modularidade efetiva. A separao por
interesse (Princpio 1) estabelece uma filosofia para software. A modularidade fornece um
mecanismo para colocar a filosofia em prtica. Qualquer sistema complexo pode ser dividido
em mdulos (componentes), porm a boa prtica de engenharia de software demanda mais

N. de T.: A palavra concern foi traduzida como interesse ou afinidade. Dividir uma tcnica utilizada para lidar com complexidade. Uma das estratgias para dividir separar usando critrios como interesses ou afinidade tanto, no domnio do problema
como no domnio da tecnologia do software.

112

Parte 2 MOdelagem

que isso . A modularidade deve ser efetiva. Isto , cada mdulo deve focalizar exclusivamente
um aspecto bem restrito do sistema deve ser coeso em sua funo e/ou apresentar contedo bem preciso. Alm disso, os mdulos devem ser interconectados de uma maneira relativamente simples cada mdulo deve apresentar baixo acoplamento com outros mdulos,
fontes de dados e outros aspectos ambientais.
AVISO
Use padres (Captulo
12) para armazenar
conhecimento e
experincia para
as futuras geraes
de engenheiros de
software.

Princpio 6. Padronize. Brad Appleton [App00] prope que:


O objetivo da padronizao criar uma fonte literria para ajudar os desenvolvedores de software a solucionar problemas recorrentes, encontrados ao longo de todo o desenvolvimento de
software. Os padres ajudam a criar uma linguagem compartilhada para transmitir contedo e
experincia acerca dos problemas e de suas solues. Codificar formalmente tais solues e suas
relaes permite que se armazene com sucesso a base do conhecimento, a qual define nossa
compreenso sobre boas arquiteturas, correspondendo s necessidades de seus usurios.
Princpio 7. Quando possvel, represente o problema e sua soluo sob uma srie de
perspectivas diferentes. Ao analisar um problema e sua soluo sob uma srie de perspectivas diferentes mais provvel que se obtenha uma melhor viso e que os erros e omisses
sejam revelados. Por exemplo, um modelo de requisitos pode ser representado usando um
ponto de vista orientado a dados, um ponto de vista orientado a funes ou um ponto de
vista comportamental (Captulos 6 e 7). Cada um deles fornece uma viso diferente do problema e de seus requisitos.
Princpio 8. Lembre-se de que algum far a manuteno do software. A longo prazo, conforme defeitos so descobertos, o software ser corrigido, adaptado de acordo com
as mudanas de seu ambiente e ampliado conforme solicitao por mais capacidade dos
envolvidos. As atividades de manuteno podem ser facilitadas se for aplicada uma prtica
de engenharia de software consistente ao longo do processo.
Esses princpios no constituem o todo necessrio para a construo de um software de alta
qualidade, mas realmente estabelecem uma base para todo mtodo de engenharia de software
discutido neste livro.

4 .3
O engenheiro
ideal uma
composio: no
um cientista, no
um matemtico,
no um socilogo
ou escritor; mas
pode utilizar o
conhecimento e as
tcnicas de qualquer uma ou de
todas as disciplinas
para resolver os
problemas de
engenharia.
N. W.
Dougherty

Princpios

da s

Atividades Metodolgica s

Nas sees seguintes, sero apresentados princpios que constituem uma forte base para o
sucesso de cada atividade metodolgica genrica, definida como parte do processo de software.
Em muitos casos, so um aprimoramento dos princpios apresentados na Seo 4.2, fundamentais e simplificados, situando-se em um nvel de abstrao mais baixo.

4.3.1Princpios da comunicao
Antes que os requisitos dos clientes sejam analisados, modelados ou especificados, eles
devem ser coletados atravs da atividade de comunicao. Um cliente apresenta um problema
que pode ser amenizado por uma soluo baseada em computador. Responde-se ao pedido de
ajuda e inicia-se a comunicao. Entretanto, o percurso da comunicao ao entendimento ,
frequentemente, acidentado.
A comunicao efetiva (entre parceiros tcnicos com o cliente, com outros parceiros interessados e com gerenciadores de projetos) constitui uma das atividades mais desafiadoras. Nesse
contexto, discutem-se princpios de comunicao aplicados na comunicao com o cliente. Entretanto, muitos se aplicam a todas as formas de comunicao.
Princpio 1. Oua. Concentre-se mais em ouvir do que em se preocupar com respostas.
Solicite esclarecimento caso necessrio, e evite interrupes constantes. Nunca se mostre
contestador tanto em palavras quanto em aes (por exemplo, revirar olhos e menear a cabea) enquanto uma pessoa estiver falando.

captulo 4

AVISO
Antes de se comunicar,
assegure-se de
compreender o ponto
de vista alheio, suas
necessidades, e saiba
ouvir.
Planeje perguntas
e respostas, trace o
caminho mais curto
para a maioria das
perplexidades.
Mark Twain

113

PrINCPIos qUe orIeNtaM a PrtICa

Princpio 2. Prepare-se antes de se comunicar. Dedique tempo para compreender o problema antes de se encontrar com outras pessoas. Se necessrio, realize algumas pesquisas
para entender o jargo da rea de negcios em questo. Caso seja sua a responsabilidade
pela conduo de uma reunio, prepare, com antecedncia, uma agenda.
Princpio 3. Algum deve facilitar a atividade. Toda reunio de comunicao deve ter
um lder (um facilitador) para manter a conversao direcionada e produtiva, (2) para mediar
qualquer conflito que ocorra e (3) para garantir que outros princpios sejam seguidos.
Princpio 4. Comunique-se pessoalmente. No entanto, em geral, comunicar-se pessoalmente mais produtivo tendo um outro representante presente. Por exemplo, um participante pode criar um desenho ou um esboo de documento que servir como foco para a
discusso.
Princpio 5. Anote e documente as decises. As coisas tendem a cair no esquecimento.
Algum participante da comunicao deve servir como um gravador e anotar todos os pontos e decises importantes.
Princpio 6. Esforce-se por colaborao. Colaborao e consenso ocorrem quando o conhecimento coletivo dos membros da equipe for usado para descrever funes e caractersticas do produto ou sistema. Cada pequena colaborao servir para estabelecer confiana
entre os membros e chegar a um objetivo comum.
Princpio 7. Mantenha o foco e crie mdulos para a discusso. Quanto mais pessoas
envolvidas, maior a probabilidade de a discusso seguir de um tpico a outro. O facilitador
deve manter a conversa modular, abandonando um tpico somente depois de este ter sido
resolvido (veja, entretanto, o Princpio 9).
Princpio 8. Faltando clareza, represente graficamente. A comunicao verbal flui at
certo ponto. Um esboo ou uma representao grfica pode permitir maior clareza quando
palavras so insuficientes.

que
? OAcontecer

Princpio 9. (a) Uma vez de acordo, siga em frente. (b) Se no chegar a um acordo, siga
em frente. (c) Se uma caracterstica ou funo estiver obscura e no puder ser elucidada
no momento, siga em frente. A comunicao, assim como qualquer outra atividade da engenharia de software, toma tempo. Em vez de ficar interagindo indefinidamente, os participantes
precisam reconhecer que muitos tpicos exigem discusso (veja o Princpio 2) e que seguir em
frente , algumas vezes, a melhor maneira de alcanar agilidade na comunicao.

caso no consiga
chegar a um
acordo com um
cliente sobre
alguma questo
relativa ao
projeto?

Princpio 10. Negociao no uma contestao nem um jogo. Funciona melhor


quando ambas as partes saem ganhando. H muitas ocasies em que se tm de negociar
funes e caractersticas, prioridades e prazos de entrega. Se a equipe interagiu adequadamente, todas as partes tm um objetivo comum. Mesmo assim, a negociao exigir compromisso de todos.

A diferena entre clientes e usurios nais


Os engenheiros de software se comunicam com muitos interessados diferentes, mas clientes e usurios
finais tm o maior impacto sobre o trabalho tcnico
que vir a seguir. Em alguns casos, cliente e usurio final so a
mesma pessoa, mas, para muitos projetos, so pessoas que trabalham para gerentes diferentes, em organizaes diferentes.
Cliente a pessoa ou grupo que: (1) originalmente, requisita
o software a ser construdo, (2) define os objetivos gerais do
negcio para o software, (3) fornece os requisitos bsicos

INfORMAES

do produto e (4) coordena os recursos financeiros para o projeto. Em uma negociao de sistemas ou de produtos, o cliente,
com frequncia, o departamento de marketing. Em um ambiente de tecnologia da informao (TI), o cliente pode ser um
departamento ou componente de negcio.
Usurio final uma pessoa ou grupo que (1) ir realmente
usar o software que construdo para atingir algum propsito de
negcio e (2) ir definir os detalhes operacionais do software
de modo que o objetivo seja alcanado.

114

Parte 2 MOdelagem

C asa S egura
Erros de comunicao
Cena: rea de trabalho da equipe de engenharia de software
Atores: Jamie Lazar, membro da equipe de software; Vinod
Raman, membro da equipe de software; Ed Robbins, membro
da equipe de software.
Conversa:
Ed: O que voc ouviu falar sobre o projeto CasaSegura?
Vinod: A reunio inicial est marcada para a prxima semana.
Jamie: Eu j andei investigando, mas no deu muito certo.
Ed: O que voc quer dizer com isso?
Jamie: Bem, dei uma ligada para Lisa Perez. Ela a manda-chuva de marketing dessa coisa.
Vinod: E . . . ?
Jamie: Eu queria que ela me desse informaes sobre as
caractersticas e funes do CasaSegura... esse tipo de coisa.

Mas, em vez disso, ela comeou a me fazer perguntas sobre


sistemas de segurana, sistemas de vigilncia... Eu no sou um
especialista na rea.
Vinod: O que isso lhe diz?(Jamie encolhe os ombros.)
Vinod: Isso quer dizer que o marketing precisar de ns como
consultores e que melhor nos prepararmos nesta rea de produto antes da primeira reunio. Doug disse que quer que colaboremos com nosso cliente; portanto, melhor aprendermos
como fazer isso.
Ed: Provavelmente teria sido melhor ter dado uma passada na
sala dela. Telefonemas simplesmente no funcionam bem para
esse tipo de coisa.
Jamie: Vocs dois esto certos. Temos que agir em conjunto
ou nossos primeiros contatos sero difceis.
Vinod: Vi o Doug lendo um livro sobre engenharia de requisitos. Aposto que ele enumera alguns princpios de comunicao
efetiva. Vou pedi-lo emprestado amanh mesmo.
Jamie: Boa ideia... depois voc poder nos ensinar.
Vinod (sorrindo): isso a.

4.3.2Princpios de planejamento

Na preparao
para a batalha
sempre achei
que os planos
fossem inteis, mas
planejamento
indispensvel.
General Dwight
D. Eisenhower
WebRef
Um excelente banco
de informaes sobre
planejamento e gerenciamento de projetos
pode ser encontrado em

A atividade de comunicao ajuda a definir metas gerais e objetivos (sujeitos a mudanas,


claro, medida que o tempo passa). Entretanto, compreender essas metas e objetivos no
o mesmo que definir um plano para alcan-los. A atividade de planejamento engloba um conjunto de prticas tcnicas e gerenciais que permitem equipe de software definir um roteiro
medida que segue na direo de seus objetivos estratgicos e tticos.
Por mais que se tente, impossvel prever com exatido como um projeto de software ir evoluir. No h nenhuma maneira simples para determinar quais problemas tcnicos no previstos
sero encontrados, quais enganos ocorrero ou quais itens de negcio sofrero mudanas. Ainda
assim, uma boa equipe deve planejar sua abordagem.
H muitas filosofias de planejamento.3 Algumas pessoas so minimalistas, afirmando que
alteraes, frequentemente, evidenciam a necessidade de um plano detalhado. Outras so tradicionalistas, afirmando que o plano fornece um roteiro efetivo e que, quanto mais detalhes
apresentar, menos probabilidade ter a equipe de se perder. Outras ainda so agilistas, afirmando que um rpido planejamento do jogo pode ser necessrio, entretanto, o roteiro surgir
como verdadeiro trabalho no incio do software.
O que fazer? Em muitos projetos, planejamento em excesso representa consumo de tempo
sem resultado produtivo (mudanas demais), entretanto, pouco planejamento uma receita
para o caos. Como a maioria das coisas na vida, o planejamento deveria ser conduzido de forma
moderada, o suficiente para servir de guia para a aquipe nem mais, nem menos. No importando o rigor com o qual o planejamento seja feito, os seguintes princpios sempre se aplicam:

www.4pm.
com/repository.
htm.

Princpio 1. Compreenda o escopo do projeto. impossvel usar um roteiro caso no


se saiba para onde se est indo. O escopo indica ao grupo um destino.
Princpio 2. Envolva os interessados na atividade de planejamento. Os interessados
definem prioridades e estabelecem as restries de projeto. Para adequar essas caractersti3

Na Parte 4 do livro apresentada uma discusso detalhada sobre planejamento e gerenciamento de projetos de software.

captulo 4 Princpios que ORIENTAM A PRTICA

115

cas, os engenheiros devem negociar com frequncia a programao de entrega, cronograma


e outras questes relativas ao projeto.
Princpio 3. Reconhea que o planejamento iterativo. Um plano de projeto jamais
gravado na pedra. Conforme se inicia o trabalho, muito provavelmente ocorrero alteraes.
Como consequncia, o plano dever ser ajustado para incluir as alteraes. Alm do mais, os
modelos de processos incremental e iterativo exigem replanejamento aps a entrega de cada
incremento de software baseado em feedbacks recebidos dos usurios.
Princpio 4. Faa estimativas com base no que conhece. O objetivo da estimativa
oferecer indicaes de esforo, custo e prazo para a realizao, com base na compreenso
atual do trabalho a realizar. Se a informao for vaga ou no confivel, as estimativas sero
igualmente no confiveis.

O sucesso deve-se
mais ao bom
senso do que
genialidade.

Princpio 5. Considere os riscos ao definir o plano. Caso tenha identificado riscos de


alto impacto e alta probabilidade, o planejamento de contingncia ser necessrio. Alm
disso, o plano de projeto (inclusive o cronograma) deve ser ajustado para incluir a tendncia
de um ou mais desses riscos ocorrerem.

An Wang

Princpio 6. Seja realista. As pessoas no trabalham 100% de todos os dias. Sempre h


interferncia de rudo em qualquer comunicao humana. Omisses e ambiguidades so fatos da vida. Mudanas ocorrem. At mesmo os melhores engenheiros de software cometem
erros. Essas e outras realidades devem ser consideradas quando se estabelece um plano de
projeto.
Princpio 7. Ajuste particularidades ao definir o plano. Particularidades referem-se ao nvel de detalhamento introduzido conforme o plano de projeto desenvolvido.
Um plano com alto grau de particularidade fornece considervel detalhamento de tarefas
planejadas para incrementos em intervalos relativamente curtos para que o rastreamento
e controle ocorram com frequncia. Um plano com baixo grau de particularidade resulta
em tarefas mais amplas para intervalos maiores. Em geral, particularidades variam de alto
para baixo conforme o cronograma de projeto se distancia da data corrente. Nas semanas
ou meses seguintes, o projeto pode ser planejado com detalhes significativos. As atividades que no sero realizadas por muitos meses no requerem alto grau de particularidade
(muito pode ser alterado).

O termo
particularidade
refere-se a detalhes
por meio dos quais
alguns elementos do
planejamento so
representados ou
conduzidos.

Princpio 8. Defina como se pretende garantir a qualidade. O plano deve determinar


como a equipe pretende garantir a qualidade. Se forem necessrias revises tcnicas4, deve-se agend-las. Se a programao pareada for utilizada (Captulo 3), deve-se definir claramente dentro do plano.
Princpio 9. Descreva como pretende adequar as alteraes. Mesmo o melhor planejamento pode ser prejudicado por alterao sem controle. Deve-se identificar como as
alteraes sero integradas ao longo do trabalho em engenharia. Por exemplo, o cliente
pode solicitar uma alterao a qualquer momento? Se for solicitada uma mudana, a equipe
obrigada a implement-la imediatamente? Como avaliado o impacto e o custo de uma
alterao?
Princpio 10. Verifique o plano frequentemente e faa ajustes necessrios. Os projetos de software atrasam uma vez ou outra. Portanto, de bom senso checar diariamente seu
progresso, procurando por reas ou situaes problemticas nas quais o que foi programado
no est em conformidade com o trabalho real a ser conduzido. Ao surgir um descompasso,
deve-se ajustar o plano adequadamente. Para mxima eficincia, todos da equipe de software
devem participar da atividade de planejamento. S dessa maneira os membros estaro comprometidos (engajados) com o plano.
4

As revises tcnicas so discutidas no Captulo 15.

116

Parte 2 MOdelagem

4.3.3Princpios de modelagem

Os modelos de requisitos representam os


requisitos dos clientes.
Os modelos de
projeto oferecem uma
especificao concreta
para a construo do
software.

Criam-se modelos para uma melhor compreenso do que ser realmente construdo. Quando a entidade for algo fsico (por exemplo, um edifcio, um avio, uma mquina), pode-se construir um modelo que seja idntico na forma e no formato, porm menor em escala. Entretanto,
quando a entidade a ser construda for software, nosso modelo deve assumir uma forma diferente. Deve ser capaz de representar as informaes que o software transforma, a arquitetura
e as funes que possibilitam a transformao, as caractersticas que os usurios desejam e o
comportamento do sistema medida que a transformao ocorra. Os modelos devem cumprir
esses objetivos em diferentes nveis de abstrao primeiro, descrevendo o software do ponto
de vista do cliente e, posteriormente, em um nvel mais tcnico.
No trabalho de engenharia de software, podem ser criadas duas classes de modelos: modelos de requisitos e modelos de projeto. Os modelos de requisitos (tambm denominados modelos de anlise) representam os requisitos dos clientes, descrevendo o software em trs domnios
diferentes: o domnio da informao, o domnio funcional e o domnio comportamental. Os
modelos de projeto representam caractersticas do software que ajudam os desenvolvedores a
constru-lo efetivamente: a arquitetura, a interface para o usurio e os detalhes quanto a componentes.
Em seu livro sobre modelagem gil, Scott Ambler e Ron Jeffries [Amb02b] estabelecem uma
srie de princpios5 de modelagem destinados queles que usam o modelo de processos geis
(Captulo 3), mas so apropriados para todos os engenheiros de software que executam aes
e tarefas de modelagem:
Princpio 1. O objetivo principal da equipe de software construir software, e no
criar modelos. Agilidade significa entregar software ao cliente no menor prazo possvel.
Os modelos que fazem com que isso acontea so criaes valiosas, entretanto, os que retardam o processo oferecem pouca novidade, devem ser evitados.
Princpio 2. Viaje leve no crie mais modelos do que necessita. Todo modelo criado deve ser atualizado quando ocorrem alteraes. E, mais importante, todo modelo novo
demanda tempo que poderia ser dispendido em construo (codificao e testes). Portanto,
crie somente aqueles modelos que facilitem mais e diminuam o tempo para a construo do
software.
Princpio 3. Esforce-se ao mximo para produzir o modelo mais simples possvel. No
exagere no software [Amb02b]. Mantendo modelos simples, o software resultante tambm
ser simples. O resultado ser um software mais fcil de ser integrado, testado e mantido.
Alm disso, modelos simples so mais fceis de compreender e criticar, resultando em uma
forma contnua de feedback que otimiza o resultado final.

AVISO
O objetivo de qualquer
modelo transmitir
informaes. Para
tanto, use um formato
consistente. Considere
o fato de no estar
l para explic-lo. Ele
deve ser autoexplicativo.

Princpio 4. Construa modelos que facilitem alteraes. Considere que os modelos


mudaro, mas, ao considerar tal fato, no seja relapso. Por exemplo, uma vez que os requisitos sero alterados, h uma tendncia a dar pouca ateno a seus modelos. Por qu? Porque
se sabe que mudaro de qualquer forma. O problema dessa atitude que sem um modelo de
requisitos razoavelmente completo, criar-se- um projeto (modelo de projeto) que invariavelmente ir deixar de lado funes e caractersticas importantes.
Princpio 5. Seja capaz de estabelecer um propsito claro para cada modelo. Toda
vez que criar um modelo, pergunte-se o motivo para tanto. Se voc no for capaz de dar justificativas slidas para a existncia do modelo, no desperdice tempo com ele.
Princpio 6. Adapte o modelo desenvolvido ao sistema disposio. Talvez seja necessrio adaptar a notao ou as regras do modelo ao aplicativo; por exemplo, um aplicativo

Os princpios citados nessa seo foram resumidos e reescritos de acordo com os propsitos do livro.

captulo 4 Princpios que ORIENTAM A PRTICA

117

de videogame pode requerer uma tcnica de modelagem diferente daquela utilizada em um


software embutido e de tempo real que controla o motor de um automvel.
Princpio 7. Crie modelos teis, mas esquea a construo de modelos perfeitos. Ao
construir modelos de requisitos e de projetos, um engenheiro de software atinge um ponto
de retornos decrescentes. Isto , o esforo necessrio para fazer o modelo absolutamente
completo e internamente consistente no vale os benefcios resultantes. Estaria eu sugerindo que a modelagem deve ser descuidada ou de baixa qualidade? A resposta no. Porm,
a modelagem deve ser conduzida tendo em vista as etapas de engenharia de software seguintes; iterar indefinidamente para criar um modelo perfeito no atende necessidade
de agilidade.
Princpio 8. No seja dogmtico quanto sintaxe do modelo. Se esta transmite o contedo com sucesso, a representao secundria. Embora todos de uma equipe devam
tentar usar uma notao consistente durante a modelagem, a caracterstica mais importante
do modelo reside em transmitir informaes que possibilitem a prxima tarefa de engenharia. Se um modelo viabilizar isso com xito, a sintaxe incorreta pode ser perdoada.
Princpio 9. Se os instintos indicam que um modelo no est correto, embora parea
correto no papel, provavelmente h motivos com os quais se preocupar. Se voc for
um engenheiro experiente, confie em seus instintos. O trabalho com software nos ensina
muitas lies muitas das quais em um nvel subconsciente. Se algo lhe diz que um modelo
de projeto parece falho, embora no haja provas explcitas, h motivos para dedicar tempo
extra examinando o modelo ou desenvolvendo outro diferente.
Princpio 10. Obtenha feedback o quanto antes. Todo modelo deve ser revisado pelos
membros da equipe de software. O objetivo das revises proporcionar feedback que seja
usado para corrigir erros de modelagem, alterar interpretaes errneas, e adicionar caractersticas ou funes omitidas inadvertidamente.
Princpios de modelagem de requisitos. Ao longo das ltimas trs dcadas, desenvolveu-se um grande nmero de mtodos de modelagem de requisitos. Pesquisadores identificaram
problemas de anlise de requisitos e suas causas e desenvolveram uma srie de notaes de
modelagem e uma srie de heursticascorrespondentes para super-los. Cada um dos mtodos de anlise possui um ponto de vista particular. Entretanto, todos esto inter-relacionados
por uma srie de princpios operacionais:
Princpio 1. O universo de informaes de um problema deve ser representado e
compreendido. O universo de informaes engloba os dados constantes no sistema (do
usurio final, de outros sistemas ou disposivos externos), os dados que fluem para fora do
sistema (via interface do usurio, interfaces de rede, relatrios, grficos e outros meios) e a
armazenagem de dados que coleta e organiza objetos de dados persistentes (isto , dados
que so mantidos permanentemente).

A modelagem de
anlise focaliza trs
atributos de software:
informaes a serem
processadas, funo
a ser entregue e
comportamento a ser
apresentado.

Princpio 2. As funes que o software desempenha devem ser definidas. As funes


de software oferecem benefcio direto aos usurios finais e tambm suporte interno para fatores visveis aos usurios. Algumas funes transformam dados que fluem no sistema. Em
outros casos, as funes exercem certo nvel de controle sobre o processamento interno do
software ou sobre elementos de sistema externo. As funes podem ser descritas em diferentes nveis de abstrao, desde afirmao geral at uma descrio detalhada dos elementos de
processo que devem ser requisitados.
Princpio 3. O comportamento do software (como consequncia de eventos externos) deve ser representado. O comportamento de um software comandado por sua
interao com o ambiente externo. Alimentaes fornecidas pelos usurios finais, informaes referentes a controles provenientes de um sistema externo ou dados de monitoramento

118

O primeiro problema do engenheiro


em qualquer
situao de projeto
descobrir qual
realmente o
problema.
Autor
desconhecido

Parte 2 MOdelagem

coletados de uma rede, todos esses elementos determinam que o software se opere de maneira especfica.
Princpio 4. Os modelos que descrevem informaes, funes e comportamentos devem ser divididos para que revelem detalhes por camadas (ou hierarquicamente). A
modelagem de requisitos a primeira etapa da soluo de um problema de engenharia
de software. Permite que se entenda melhor o problema e se estabeleam bases para a soluo (projeto). Os problemas complexos so difceis de resolver em sua totalidade. Por essa
razo, deve-se usar a estratgia dividir-e-conquistar. Um problema grande e complexo dividido em subproblemas at que cada um seja relativamente fcil de ser compreendido. Esse
conceito denominado fracionamento ou separao por interesse e uma estratgia-chave
na modelagem de requisitos.
Princpio 5. A anlise deve partir da informao essencial para o detalhamento da
implementao. A modelagem de requistos se inicia pela descrio do problema sob
a perspectiva do usurio final. A essncia do problema descrita sem levar em considerao como ser implementada uma soluo. Por exemplo, um jogo de videogame requer
que o jogador instrua seu protagonista sobre qual direo seguir para continuar conforme
se movimenta em situaes perigosas. Essa a essncia do problema. O detalhamento da
implementao (em geral descrito como parte do modelo de projeto) indica como a essncia
ser implementada. No caso do videogame, talvez fosse usada entrada de voz. Outra alternativa seria utilizar o comando por meio do teclado, ou por joystick ou mouse para uma
direo especfica, ou um dispositivo com sensor de movimento poderia ser empregado externamente. Aplicando-se tais princpios, um engenheiro de software aborda um problema
de forma sistemtica. Entretanto, como os princpios so aplicados na prtica? Essa pergunta ser respondida nos Captulos 5 a 7.

Primeiramente,
verifique se o projeto inteligente e
preciso: feito isso,
persista resolutamente. No desista
do seu propsito
por causa de uma
rejeio.
William
Shakespeare
WebRef
Comentrios mais
especficos sobre o
processo dos projetos,
juntamente com um
debate sobre sua
esttica, podero ser
encontrados em

cs.wwc.edu/
~aabyan/
Design/.

Princpios da modelagem de projetos. A modelagem de projetos de software anloga


ao planejamento de uma casa feito por um arquiteto. Ela comea pela representao do todo a
ser construdo (por exemplo, uma representao tridimensional da casa) e, gradualmente, foca
os detalhes, oferecendo um roteiro para a sua construo (por exemplo, a estrutura do encanamento). De modo similar, a modelagem de projeto fornece uma variedade de diferentes focos
do sistema.
No h poucos mtodos para identificar os vrios elementos de um projeto. Alguns so
voltados a dados, permitindo que a estrutura de dados determine a arquitetura do programa e
dos componentes de processamento resultantes. Outros so voltados para padres, usando informaes a respeito do domnio do problema (da modelagem dos requisitos) para desenvolver
os estilos arquitetnicos e os padres de processamento. Outros, ainda, so voltados a objetos,
usando os objetos da rea do problema como determinantes para a criao dos mtodos e das
estruturas de dados que os manipularo. Ainda assim, todos englobam uma srie de princpios
de projeto que podem ser aplicados independentemente do mtodo empregado:
Princpio 1. O projeto deve ser roteirizado para a modelagem de requisitos.
A modelagem de requisitos descreve a rea de informao do problema, funes visveis ao
usurio, desempenho do sistema e um conjunto de classes de requisitos que embala objetos
de negcios juntamente com os mtodos que ele serve. A modelagem de projeto traduz essa
informao em forma de uma arquitetura, um conjunto de subsistemas que implementam
funes mais amplas e um conjunto de componentes que so a concretizao das classes de
requisitos. Os elementos da modelagem de projetos devem ser roteirizados para a modelagem de requisitos.
Princpio 2. Sempre considere a arquitetura do sistema a ser construdo.
A arquitetura de software (Captulo 9) a espinha dorsal do sistema a ser construdo. Afetando interfaces, estruturas de dados, desempenho e fluxo de controle de programas, maneira

captulo 4 Princpios que ORIENTAM A PRTICA

119

pela qual os testes podem ser conduzidos, a manuteno do sistema realizada e muito mais.
Por todas essas razes, o projeto deve comear com as consideraes arquitetnicas. S
depois de a arquitetura ter sido estabelecida devem ser considerados os elementos relativos
a componentes.
Princpio 3. O projeto de dados to importante quanto o projeto das funes de
processamento. O projeto de dados um elemento essencial do projeto da arquitetura. A
forma como os objetos de dados so percebidos no projeto no pode ser deixada ao acaso.
Um projeto de dados bem estruturado ajuda a simplificar o fluxo do programa, torna mais
fcil a elaborao do projeto e a implementao dos componentes de software, tornando
mais eficiente o processamento como um todo.
Princpio 4. As interfaces (tanto internas quanto externas) devem ser projetadas com
cuidado. A forma como os dados fluem entre os componentes de um sistema tem muito
a ver com a eficincia do processamento, com a propagao de erros e com a simplicidade
do projeto. Uma interface bem elaborada facilita a integrao e auxilia o responsvel pelos
testes quanto validao das funes dos componentes.

As diferenas no
so insignificantes so bem
semelhantes s
diferenas entre
Salieri e Mozart.
Estudos aps estudos demonstram
que os melhores
projetistas
produzem
estruturas mais
rpidas, menores,
mais simples, mais
claras e com menos
esforo.

Princpio 5. O projeto de interface do usurio deve ser voltado s necessidades do


usurio final. Entretanto, em todo caso, deve enfatizar a facilidade de uso. A interface do usurio a manifestao visvel do software. No importa quo sofisticadas sejam
as funes internas, quo amplas sejam as estruturas de dados, quo bem projetada seja a
arquitetura; um projeto de interface pobre leva percepo de que um software ruim.
Princpio 6. O projeto no nvel de componentes deve ser funcionalmente independente. Independncia funcional uma medida para a mentalidade simplificada de um componente de software. A funcionalidade entregue por um componente deve ser coesa isto
, focarem uma, e somente uma, funo ou subfuno.6

Frederick P.
Brooks

Princpio 7. Os componentes devem ser relacionados livremente tanto entre componentes quanto com o ambiente externo. O relacionamento obtido de vrias maneiras
via interface de componentes, por meio de mensagens, atravs de dados em geral. Na medida em que o nvel de correlacionamento aumenta, a tendncia para a propagao do erro
tambm aumenta e a manuteno geral do software decresce. Portanto, o relacionamento
entre componentes deve ser mantido to baixo quanto possvel.
Princpio 8. Representaes de projetos (modelos) devem ser de fcil compreenso. A finalidade de projetos transmitir informaes aos desenvolvedores que faro a codificao, queles que iro testar o software e para outros que possam vir a dar manuteno
futuramente. Se o projeto for de difcil compreenso, no servir como meio de comunicao
efetivo.
Princpio 9. O projeto deve ser desenvolvido iterativamente. A cada iterao, o projetista deve se esforar para obter maior grau de simplicidade. Como todas as atividades criativas, a elaborao de um projeto ocorre de forma iterativa. As primeiras iteraes
so realizadas para refinar o projeto e corrigir erros, entretanto, as iteraes finais devem
dirigir esforos para tornar o projeto to simples quanto possvel.
Quando tais princpios so aplicados apropriadamente, elabora-se um projeto com fatores de
qualidade tanto externos quanto internos [Mye78]. Fatores externos de qualidade so as propriedades que podem ser prontamente notadas pelos usurios (por exemplo, velocidade, confiabilidade, correo, usabilidade). Os fatores internos de qualidade so de extrema importncia para
os engenheiros de software. Conduzem a um projeto de alta qualidade do ponto de vista tcnico.
Para obter fatores de qualidade internos, o projetista deve entender sobre conceitos bsicos de
projeto (Captulo 8).
6

Mais informaes a respeito de coeso podem ser encontradas no Captulo 8.

120

Por muito tempo


em minha vida, fui
um observador em
relao ao mundo
do software, espiando furtivamente os
cdigos poludos de
outras pessoas.
Ocasionalmente,
encontro uma joia
verdadeira, um
programa bem
estruturado,
escrito em um
estilo consistente,
livre de gambiarras,
desenvolvido de
modo que cada
componente seja
simples, organizado e projetado
de forma que o
produto possa
ser facilmente
alterado.
David Parnas

AVISO
Evite desenvolver um
programa elegante que
resolva o problema errado. Preste particular
ateno ao primeiro
princpio referente
preparao.

WebRef
Uma ampla variedade
de links para padres
de codificao pode
ser encontrada no site
www. literate

programming.
com/fpstyle
.html.

Parte 2 MOdelagem

4.3.4Princpios de construo
A atividade de construo engloba um conjunto de tarefas de codificao e testes que conduzem ao software operacional pronto para ser entregue ao cliente e ao usurio final. Na atividade
moderna de engenharia de software, a codificao pode ser: (1) a criao direta do cdigo-fonte
da linguagem de programao (por exemplo, Java), (2) a gerao automtica de cdigo-fonte usando uma representao intermediria semelhante a um projeto do componente a ser
construdo ou ento (3) a gerao automtica de cdigo executvel usando uma linguagem de
programao de quarta gerao (por exemplo, Visual C++).
O foco inicial dos testes voltado para componentes, com frequncia denominado teste
de unidade. Outros nveis de testes incluem: (1) teste de integrao (realizado medida que o
sistema construdo), (2) teste de validao que avalia se os requisitos foram atendidos para
o sistema completo (ou incremento de software) e (3) teste de aceitao conduzido pelo cliente
voltado para empregar todos os fatores e funes requisitados. A srie de princpios e conceitos
fundamentais a seguir aplicvel codificao e aos testes:
Princpios de codificao. Os princpios que regem a codificao so intimamente alinhados com o estilo de programao, com as linguagens e com os mtodos de programao. Entretanto, h uma srie de princpios fundamentais que podem ser estabelecidos:
Princpios de preparao: Antes de escrever uma nica linha de cdigo, certifique-se
de que
Compreendeu bem o problema a ser solucionado.
Compreendeu bem os princpios e conceitos bsicos sobre o projeto.
Escolheu uma linguagem de programao adequada s necessidades do software a ser
desenvolvido e ao ambiente em que ele ir operar.
Selecionou um ambiente de programao que fornea ferramentas que tornaro seu trabalho mais fcil.
Elaborou um conjunto de testes de unidades que sero aplicados assim que o componente codificado estiver completo.
Princpios de programao: Ao comear a escrever cdigo
Restrinja seus algoritmos seguindo a prtica de programao estruturada [Boh00].
Considere o emprego de uso de programao pareada.
Selecione estruturas de dados que venham ao encontro das do projeto.
Domine a arquitetura de software e crie interfaces consistentes com ela.
Mantenha a lgica condicional to simples quanto possvel.
Crie loops agrupados de tal forma que testes sejam facilmente aplicveis.
Escolha denominaes de variveis significativas e obedea a outros padres de codificao locais.
Faa uma documentao que seja autodocumentvel.
Crie uma disposio (layout) visual (por exemplo, recorte e linhas em branco) que auxilie
a compreenso.
Princpios de validao: Aps completar a primeira etapa de codificao, certifique-se de
Aplicar uma reviso de cdigo quando for apropriado.
Realizar testes de unidades e corrigir erros ainda no identificados.
Refazer a codificao.
Mais livros foram escritos sobre programao (codificao) e sobre os princpios e os conceitos
que a guiam do que qualquer outro tpico do processo de software. Livros sobre o tema incluem
trabalhos antigos em estilo de programao [Ker78], construo prtica de software [McC04],

captulo 4 Princpios que ORIENTAM A PRTICA

121

prolas da programao [Ben99], a arte de programar [Knu98], elementos da programao pragmtica [Hun99] e muitos, muitos outros assuntos. Um debate amplo sobre esses princpios e
conceitos foge do escopo deste livro. Caso haja maior interesse, examine uma ou mais das referncias indicadas.
Princpios de testes. Em um clssico sobre testes de software, Glen Myers [Mye79] estabelece uma srie de regras que podem servir, bem como objetivos da atividade de testes:
Teste consiste em um processo de executar um programa com o intuito de encontrar um
erro.
Um bom pacote de testes aquele em que h uma alta probabilidade de encontrar um
erro ainda no descoberto.
Um teste bem-sucedido aquele que revela um novo erro.

so
? Quais
os objetivos

dos testes de
software?

AVISO
Em um contexto mais
amplo de projeto de
software, atente para
iniciar no geral,
focalizando a
arquitetura de software, e terminar no
particular, focalizando
os componentes.
Para testes, simplesmente reverta o foco e
teste seu desenvolvimento.

Esses objetivos implicam uma mudana radical de ponto de vista para alguns desenvolvedores.
Vo contra a viso comumente difundida de que um teste bem-sucedido aquele em que nenhum erro encontrado. Seu objetivo o de projetar testes que descubram, sistematicamente,
diferentes classes de erros, consumindo o mnimo de esforo e tempo.
Se testes forem conduzidos com xito (de acordo com os objetivos declarados previamente),
iro encontrar erros no software. Como benefcio secundrio, os testes demonstram que as
funes do software esto funcionando de acordo com as especificaes e que os requisitos
relativos ao desempenho e ao comportamento parecem estar sendo atingidos. Os dados coletados durante os testes fornecem um bom indcio da confiabilidade do software, assim como
fornecem a indicao da qualidade do software como um todo. Entretanto, os testes no so capazes de mostrar a ausncia de erros e defeitos; podendo apenas mostrar que erros e defeitos de
software esto presentes. importante manter isso em mente (do que negligenci-lo) enquanto
os testes esto sendo aplicados.
Davis [Dav95b] sugere um conjunto de princpios de testes7 adaptados para este livro:
Princpio 1. Todos os testes devem estar alinhados com os requisitos do cliente.8
O objetivo dos testes desvendar erros. Constata-se que os efeitos mais crticos do ponto de
vista do cliente so aqueles que conduzem a falhas no programa quanto a seus requisitos.
Princpio 2. Os testes devem ser planejados muito antes de ser iniciados. O planejamento dos testes (Captulo 17) pode comear assim que o modelo de requisitos estiver
completo. A definio detalhada dos pacotes de teste pode comear to logo o modelo de
projeto tenha sido solidificado. Portanto, todos os testes podem ser planejados e projetados
antes que qualquer codificao tenha sido gerada.
Princpio 3. O princpio de Pareto se aplica a testes de software. Neste contexto o
princpio de Pareto implica que 80% de todos os erros revelados durante testes provavelmente estaro alinhados a aproximadamente 20% de todos os componentes de programa.
O problema, evidentemente, consiste em isolar os componentes suspeitos e test-los por
completo.
Princpio 4. Os testes devem comear em particular e progredir rumo ao teste em
geral. Os primeiros testes planejados e executados geralmente focam os componentes
individuais. medida que progridem, o foco muda para tentar encontrar erros em grupos de
componentes integrados e, posteriormente, no sistema inteiro.
Princpio 5. Testes exaustivos so impossveis. A quantidade de trocas de direes,
mesmo para um programa de tamanho moderado, excepcionalmente grande. Por essa
7
8

Apenas um pequeno subconjunto dos princpios de testes de David citado aqui. Para maiores informaes, veja [Dav95b].
Esse princpio refere-se a testes funcionais, por exemplo, testes que se concentram em requisitos. Os testes estruturais (testes
que se concentram nos detalhes lgicos ou arquitetnicos) no podem referir-se a requisitos especficos diretamente.

122

Parte 2 MOdelagem

razo, impossvel executar todas as rotas durante os testes. Sendo possvel, no entanto,
cobrir adequadamente a lgica do programa e garantir que todas as condies referentes ao
projeto no nvel de componentes sejam exercidas.

4.3.5Princpios de disponibilizao

AVISO
Certifique-se de que
seu cliente saiba o que
esperar antes da entrega de um incremento
de software. Caso
contrrio, com certeza
ele contar mais do
que voc poder
entregar.

Como observado anteriormente, na Parte 1 deste livro, a disponibilizao envolve trs aes:
entrega, suporte e feedback. Pelo fato de os modernos modelos de processos de software serem,
em sua natureza, evolucionrios ou incrementais, a disponibilizao no ocorre imediatamente,
mas sim, em muitas vezes, quando o software segue para sua finalizao. Cada ciclo de entrega
propicia ao cliente e ao usurio um incremento de software operacional que fornece fatores e
funes utilizveis. Cada ciclo de suporte fornece assistncia humana e documentao para todas as funes e fatores introduzidos durante todos os ciclos de disponibilizao at o presente.
Cada ciclo de feedback fornece equipe de software importante roteiro que resulta em alterao
de funes, elementos e abordagem adotados para o prximo incremento.
A entrega para um incremento de software representa um marco importante para qualquer
projeto de software. Uma srie de princpios essenciais deve ser seguida enquanto a equipe se
prepara para a entrega de um incremento:
Princpio 1. As expectativas dos clientes para o software devem ser gerenciadas.
Muitas vezes, o cliente espera mais do que a equipe havia prometido entregar e, imediatamente, ocorre o desapontamento. Isso resulta em feedback no produtivo e arruna o moral
da equipe. Em seu livro sobre gerenciamento de expectativas, Naomi Karten [Kar94] afirma:
O ponto de partida para administrar expectativas consiste em se tornar mais consciencioso sobre como e o que vai comunicar. Ela sugere que um engenheiro de software deve ser
cauteloso em relao ao envio de mensagens conflituosas ao cliente (por exemplo, prometer
mais do que pode entregar racionalmente no prazo estabelecido ou entregar mais do que
o prometido para determinado incremento e, em seguida, menos do que prometera para o
prximo).
Princpio 2. Um pacote de entrega completo deve ser auditorado e testado. Um
CD-ROM ou outra mdia (inclusive downloads de Web) contendo todo o software executvel, arquivos de dados de suporte, documentos de suporte e outras informaes relevantes
devem ser completamente checados e testados por meio de uma verso beta com os reais
usurios. Todos os roteiros de instalao e outros itens operacionais devem ser rodados
inteiramente em tantas configuraes computacionais quanto forem possveis (isto , hardware, sistemas operacionais, dispositivos perifricos, disposies de rede).
Princpio 3. Deve-se estabelecer uma estrutura de suporte antes da entrega do
software. Um usurio final conta com recebimento de informaes acuradas e com reponsabilidade caso surja um problema. Se o suporte for local, ou, pior ainda, inexistente,
imediatamente o cliente ficar insatisfeito. O suporte deve ser planejado, e seus materiais
devem estar preparados, e mecanismos para manuteno de registros apropriados devem
estar determinados para que a equipe de software possa oferecer uma avaliao de qualidade das formas de suporte solicitadas.
Princpio 4. Material adequado referente a instrues deve ser fornecido aos usurios finais. A equipe de software deve entregar mais do que o software em si. Auxlio em
treinamento de forma adequada (se solicitado) deve ser desenvolvido; orientaes quanto a
problemas inesperados devem ser oferecidas; quando necessrio, importante editar uma
descrio acerca de diferenas existentes no incremento de software.9
Princpio 5. Software com bugs (erros), primeiro, deve ser corrigido, e, depois, entregue. Sob a presso relativa a prazo, muitas empresas de software entregam incrementos
9

Durante a atividade de comunicao, a equipe de software deve determinar quais materiais de apoio os usurios desejam.

captulo 4 Princpios que ORIENTAM A PRTICA

123

de baixa qualidade, notificando o cliente que os bugs sero corrigidos na prxima verso.
Isso um erro. H um ditado no mercado de software: Os clientes esquecero a entrega de
um produto de alta qualidade em poucos dias, mas jamais esquecero os problemas causados por um produto de baixa qualidade. O software os faz lembrar disso todos os dias.
O software entregue propicia benefcio ao usurio final, mas este tambm fornece feedback proveitoso para a equipe de software. medida que um incremento colocado em uso, os
usurios finais devem ser encorajados a tecer comentrios acerca das caractersticas e funes,
facilidade de uso, confiabilidade e quaisquer outras caractersticas apropriadas.

4.4

Resumo
A prtica de engenharia de software envolve princpios, conceitos, mtodos e ferramentas
aplicados por engenheiros da rea ao longo de todo o processo de desenvolvimento. Cada projeto de engenharia de software diferente. Ainda assim, uma gama de princpios genricos se
aplica ao processo como um todo e prtica de cada atividade metodolgica independentemente do projeto ou do produto.
Um conjunto de princpios essenciais auxilia na aplicao de um processo de software significativo e na execuo de mtodos efetivos de engenharia de software. Quanto ao processo,
os princpios essenciais estabelecem uma base filosfica que orienta a equipe durante essa fase
de desenvolvimento. Quanto ao nvel relativo prtica, os princpios estabelecem uma srie
de valores e regras que servem como guia ao se analisar um problema, projetar uma soluo,
implementar e testar uma soluo e, por fim, diponibilizar o software para a sua comunidade
de usurios.
Princpios de comunicao enfatizam a necessidade de reduzir rudo e aumentar a dimenso
conforme o dilogo entre o desenvolvedor e o cliente progride. Ambas as partes devem colaborar para que ocorra a melhor comunicao.
Princpios de planejamento proporcionam roteiros para a construo do melhor mapa para a
jornada rumo a um sistema ou produto completo. O plano pode ser projetado para um nico incremento de software ou pode ser definido para o projeto inteiro. Independentemente da situao, deve indicar o que ser feito, quem o far e quando o trabalho estar completo.
Modelagem abrange tanto anlise quanto projeto, descrevendo representaes do software
que se tornam progressivamente mais detalhadas. O objetivo dos modelos solidificar a compreenso do trabalho a ser feito e providenciar orientao tcnica aos implementadores do
software. Os princpios de modelagem servem como infraestrutura para os mtodos e para a
notao utilizada para criar representaes do software.
Construo incorpora um ciclo de codificao e testes no qual o cdigo-fonte para um componente gerado e testado. Os princpios de codificao definem aes genricas que devem
ocorrer antes da codificao ser feita, enquanto est sendo criada e aps estar completa. Embora haja muitos princpios de testes, apenas um dominante: teste consiste em um processo de
executao de um programa com o intuito de encontrar um erro.
Disponibilizao ocorre na medida em que cada incremento de software apresentado ao
cliente e engloba a entrega, o suporte e o feedback. Os princpios fundamentais para a entrega
consideram o gerenciamento das expectativas dos clientes e o fornecimento ao cliente de informaes de suporte apropriadas sobre o software. O suporte exige preparao antecipada.
Feedback permite ao cliente sugerir mudanas que tenham valor agregado e fornecer ao desenvolvedor informaes para o prximo ciclo de engenharia de software.

Problemas

Pontos

Ponderar

4.1. Uma vez que o foco em qualidade demanda recursos e tempo, possvel ser gil e ainda
assim manter o foco em qualidade?

124

Parte 2 MOdelagem

4.2. Dos oito princpios bsicos que orientam um processo (discutido na Seo 4.2.1), qual
voc acredita ser o mais importante?
4.3. Descreva o conceito de separao por interesses com suas prprias palavras.
4.4. Um importante princpio de comunicao afirma prepare-se antes de se comunicar .
Como essa preparao se manifesta no trabalho prvio que voc realiza? Quais produtos de
trabalho podem resultar da preparao antecipada?
4.5. Pesquise sobre facilitao para a atividade de comunicao (use as referncias fornecidas ou outras) e prepare um conjunto de passos focados somente em facilitao.
4.6. Em que a comunicao gil difere da tradicional em engenharia de software? Em que
ela similar?
4.7. Por que necessrio seguir em fente?
4.8. Pesquise sobre negociao para a atividade de comunicao e prepare uma srie de
etapas concentrando-se apenas na negociao.
4.9. Descreva o que significa particularidadeno contexto do cronograma de um projeto.
4.10. Por que os modelos so importantes no trabalho de engenharia de software? So eles
sempre necessrios? Existem qualificadores para sua resposta sobre necessidade?
4.11. Quais so os trs domnios considerados durante a modelagem de requisitos?
4.12. Tente acrescentar mais um princpio queles determinados para a codificao na Seo
4.3.4.
4.13. Em que consiste um teste bem-sucedido?
4.14. Voc concorda ou discorda com a seguinte afirmao: Uma vez que vrios incrementos
so entregues ao cliente, por que se preocupar com a qualidade nos incrementos iniciais
pode-se corrigir os problemas em iteraes posteriores. Justifique sua resposta.
4.15. Por que o feedback importante para uma equipe de software?

Leituras

Fontes

de

I n f o r m a o C o m p l e m e n ta r e s

A comunicao com o cliente uma atividade crtica na engenharia de software, embora


poucos profissionais invistam em sua leitura. Withall (Software Requirements Patterns, Microsoft Press, 2007) apresenta uma gama de padres teis que tratam de problemas de comunicao. Sutliff (User-Centred Requirements Engineering, Springer, 2002) se concentra muito nos
desafios relacionados com a comunicao. Livros como os de Weigers (Software Requirements,
2. ed., Microsoft Press, 2003), Pardee (To Satisfy and Delight Your Customer, Dorset House, 1996)
e Karten [Kar94] do uma excelente viso sobre mtodos para interao efetiva com os clientes. Embora a obra no se concentre em software, Hooks e Farry (Customer Centered Products,
American Management Association, 2000) apresentam teis diretrizes genricas para a comunicao com os clientes. Young (Effective Requirements Practices, Addison-Wesley, 2001) enfatiza
uma equipe conjunta entre clientes e desenvolvedores que desenvolvem requisitos de forma
colaborativa. Somerville e Kotonya (Requirements Engineering: Processes and Techniques, Wiley,
1998) discutem tcnicas e conceitos de suscitao, bem como outros princpios de engenharia
de requisitos.
Conceitos e princpios de comunicao e planejamento so considerados em vrios livros de
gerenciamento de projetos. Entre eles podemos citar: Bechtold (Essentials of Software Project
Management, 2. ed., Management Concepts, 2007), Wysocki (Effective Project Management:
Traditional, Adaptive, Extreme, 4. ed., Wiley, 2006), Leach (Lean Project Management: Eight
Principless for Success, BookSurge Publishing, 2006), Hughes (Software Project Management,
McGraw-Hill, 2005) e Stellman e Greene (Applied Software Project Management, OReilly Media,
Inc., 2005).
Davis [Dav95] compilou um excelente conjunto de princpios de engenharia de software.
Alm disso, praticamente todo livro sobre engenharia de software contm uma discusso

captulo 4 Princpios que ORIENTAM A PRTICA

125

proveitosa sobre conceitos e princpios para anlise, projeto e testes. Entre os livros mais largamente usados (alm deste livro, claro!), temos:
Abran, A. e J. Moore, SWEBOK: Guide to the Software Engineering Body of Knowledge, IEEE, 2002.
Christensen, M. e R. Thayer, A Project Managers Guide to Software Engineering Best Practices, IEEE-CS
Press (Wiley), 2002.
Jalote, P., An Integrated Approach to Software Engineering, Springer, 2006.
Pfleeger, S., Software Engineering: Theory and Practice, 3. ed., Prentice-Hall, 2005.
Schach, S., Engenharia de Software: Os Paradigmas Clssico e Orientado a Objetos, McGraw-Hill, 7. ed.,
2008.
Sommerville, I., Software Engineering, 8. ed., Addison-Wesley, 2006.

Esses livros tambm apresentam uma discusso detalhada sobre princpios de modelagem
e construo.
Princpios de modelagem so considerados em muitos textos dedicados anlise de requisitos e/ou projeto de software. Livros como os de Lieberman (The Art of Software Modeling,
Auerbach, 2007), Rosenberg e Stephens (Use Case Driven Object Modeling with UML: Theory
and Practice, Apress, 2007), Roques (UML in Practice, Wiley, 2004), Penker e Eriksson (Business
Modeling with UML: Business Patterns at Work, Wiley, 2001) discutem os princpios e mtodos
de modelagem.
A obra de Norman (The Design of Everyday Things, Currency/Doubleday, 1990) uma leitura
obrigatria para todo engenheiro de software que pretenda realizar trabalhos de projeto. Winograd e seus colegas (Bringing Design to Software, Addison-Wesley, 1996) editaram um excelente
conjunto de artigos que tratam das questes prticas no projeto de software. Constantine e
Lockwood (Software for Use, Addison-Wesley, 1999) apresentam os conceitos associados ao
projeto centrado no usurio. Tognazzini (Tog on Software Design, Addison-Wesley, 1995) traz
uma discusso filosfica proveitosa sobre a natureza do projeto e o impacto das decises na
qualidade e na habilidade de a equipe produzir software que fornea grande valor a seu cliente.
Stahl e seus colegas (Model-Driven Software Development: Technology, Engineering, Wiley, 2006)
discutem os princpios do desenvolvimento dirigido por modelos.
Centenas de livros tratam um ou mais elementos da atividade de construo. Kernighan e Plauger [Ker78] escreveram um clssico sobre estilo de programao, McConnell [McC93] apresenta
diretrizes pragmticas para a construo prtica de software, Bentley [Ben99] sugere uma ampla
gama de prolas da programao, Knuth [Knu99] escreveu uma srie clssica de trs volumes sobre a arte de programar e Hunt [Hun99] sugere diretrizes de programao pragmticas.
Myers e seus colegas (The Art of Software Testing, 2. ed., Wiley, 2004) fizeram uma reviso importante de seu texto clssico e discutem vrios princpios de testes importantes. Livros como os
de Perry (Effective Methods for Software Testing, 3. ed., Wiley, 2006), Whittaker (How to Break
Software, Addison-Wesley, 2002), Kaner e seus colegas (Lessons Learned in Software Testing,
Wiley, 2001) e Marick (The Craft of Software Testing, Prentice-Hall, 1997) introduzem, cada
um deles, importantes conceitos e princpios para testes e muita orientao pragmtica.
Uma ampla gama de fontes de informao sobre a prtica da engenharia de software se encontra disposio na Internet. Uma lista atualizada de referncias na Web, relevantes prtica
da engenharia de software, pode ser encontrada no site www.mhhe.com/engcs/compsci/
pressman/professional/olc/ser.htm.

captulo

Engenharia
R equisitos

Conceitos- Chave

casos de uso . . . . . 137


colaborao . . . . . . 132
concepo . . . . . . . 127
disponibilizao da
funo de qualidade . . 136
elaborao . . . . . . . 128
engenharia de
requisitos . . . . . . . 127
especificao . . . . . 129
gesto dos
requisitos . . . . . . . 130
interessados . . . . . 131
levantamento . . . . . 128
levantamento dos
requisitos . . . . . . . 133
modelo de anlise . 142
negociao . . . . . . . 128
padres de anlise . . 145
pontos de vista . . . 131
produtos resultantes . 137
validao . . . . . . . . 129
validao dos
requisitos . . . . . . . 146

de

ntender os requisitos de um problema est entre as tarefas mais difceis enfrentadas


por um engenheiro de software. Ao pensar nisso pela primeira vez, a engenharia de
requisitos no parece assim to difcil. Afinal de contas, o cliente no sabe o que
necessrio? Os usurios finais no deveriam ter um bom entendimento das caractersticas
e funes que traro benefcios? Surpreendentemente, em muitos casos a resposta a essas
perguntas no. E mesmo se os clientes e usurios finais fossem explcitos quanto s
suas necessidades, essas mudariam ao longo do projeto.
No prefcio de um livro de Ralph Young [You01] sobre prticas de necessidades eficazes,
escrevi:
o seu pior pesadelo. Um cliente entra no seu escritrio, se senta, te olha diretamente nos olhos
e diz: Eu sei que voc imagina que entendeu aquilo que eu lhe disse, mas o que voc no compreende que aquilo que eu lhe disse no era exatamente aquilo que eu quis dizer. Invariavelmente,
isso acontece no final do projeto, aps compromissos de prazos de entrega terem sido estabelecidos, reputaes estarem na mira e muito dinheiro estar em jogo.
Todos que j trabalharam na rea de software e sistemas h alguns anos viveram esse pesadelo
e, mesmo assim, poucos aprenderam a livrar-se dele. Passamos por muitas dificuldades ao tentar
extrair os requisitos de nossos clientes. Temos dificuldades para entender as informaes obtidas.
Normalmente registramos os requisitos de uma forma desorganizada e investimos muito pouco
tempo verificando aquilo que registramos. Deixamos que as mudanas nos controlem, em vez de
estabelecermos mecanismos para controlar as mudanas. Em suma, falhamos ao estabelecer uma
base slida para o sistema ou software. Cada um desses problemas desafiador. Quando combinados, o panorama assustador at mesmo para os gerentes e profissionais mais experientes.
Mas solues de fato existem.

O que ? Antes de iniciar qualquer tra-

Panorama balho tcnico, uma boa ideia aplicar

um conjunto de tarefas de engenharia


de requisitos. Estas levam a um entendimento de qual ser o impacto do software sobre o
negcio, o que o cliente quer e como os usurios
finais iro interagir com o software.
Quem realiza? Engenheiros de software (algumas
vezes conhecidos no mundo da TI como engenheiros de sistemas ou analistas) e outros interessados no projeto (gerentes, clientes, usurios finais),
todos participam da engenharia de requisitos.
Por que importante? Projetar e construir um
programa de computador elegante que resolva o
problema errado no atende s necessidades de
ningum. por isso que importante entender o
que o cliente quer antes de comear a projetar e
construir um sistema baseado em computador.
Quais so as etapas envolvidas? A engenharia
de requisitos comea com a concepo uma
tarefa que define o escopo e a natureza do problema a ser resolvido. Ela prossegue para o levantamento uma tarefa que ajuda os interessados a
definir o que necessrio e, ento, para a elabo-

126

rao onde os requisitos bsicos so refinados


e modificados. medida que os interessados definem o problema, ocorre a negociao quais
so as prioridades, o que essencial, quando
necessrio? Por fim, o problema especificado de
algum modo e, ento, revisado ou validado para
garantir que seu entendimento e o entendimento
dos interessados sobre o problema coincidam.
Qual o artefato? O objetivo da engenharia de
requisitos fornecer a todas as partes um entendimento escrito do problema. Isso pode ser alcanado por meio de uma srie de artefatos: cenrios de
uso, listas de funes e caractersticas, modelos de
anlise ou uma especificao.
Como garantir que o trabalho foi realizado
corretamente? Os artefatos da engenharia de
requisitos so revisados com os interessados para
garantir que aquilo que voc entendeu realmente
aquilo que eles queriam dizer. Um alerta: mesmo
depois de todas as partes terem entrado em acordo, as coisas vo mudar e continuaro mudando
ao longo de todo o projeto.

captulo 5 Engenharia de Requisitos

127

razovel argumentar que as tcnicas que discutiremos neste captulo no so uma verdadeira soluo para os desafios que acabamos de citar. Mas elas fornecem efetivamente uma
abordagem consistente para lidar com tais desafios.

5.1
A parte mais
difcil ao construir
um sistema de
software decidir
o que construir.
Nenhuma parte do
trabalho afeta tanto
o sistema resultante
se for feita a coisa
errada. Nenhuma
outra parte mais
difcil de consertar
depois.
Fred Brooks

A engenharia de
requisitos estabelece
uma base slida
para o projeto e
para a construo.
Sem ela, o software
resultante tem
grande probabilidade
de no atender s
necessidades do
cliente.

AVISO
Espere ter de realizar
um pouco de projeto
durante o trabalho
de levantamento
de requisitos e um
pouco de trabalho
de levantamento de
requisitos durante o
projeto.

Engenharia

de

Requisitos

Projetar e construir software desafiador, criativo e pura diverso. Na realidade, construir software to cativante que muitos desenvolvedores desejam iniciar logo, antes de
terem um claro entendimento daquilo que necessrio. Eles argumentam que as coisas
ficaro mais claras medida que forem construindo o software, que os interessados no
projeto sero capazes de entender a necessidade apenas depois de examinar as primeiras
iteraes do software, que as coisas mudam to rpido que qualquer tentativa de entender
os requisitos de forma detalhada ser uma perda de tempo, que o primordial produzir
um programa que funcione e que todo o resto secundrio. O que torna esses argumentos
tentadores que contm elementos de verdade.1 Porm, cada um apresenta pontos fracos e
pode levar um projeto ao fracasso.
O amplo espectro de tarefas e tcnicas que levam a um entendimento dos requisitos denominado engenharia de requisitos. Na perspectiva do processo de software, a engenharia de
requisitos uma ao de engenharia de software importante que se inicia durante a atividade de
comunicao e continua na de modelagem. Ela deve ser adaptada s necessidades do processo,
do projeto, do produto e das pessoas que esto realizando o trabalho.
A engenharia de requisitos constri uma ponte para o projeto e para a construo. Mas
onde comea essa ponte? Algum pode argumentar que ela comea na base dos interessados no projeto (por exemplo, gerentes, clientes, usurios finais), em que definida a
necessidade do negcio, so descritos cenrios de usurios, delineados funes e recursos
e identificadas restries de projeto. Outros poderiam sugerir que ela se inicia com uma
definio mais abrangente do sistema, em que o software apenas um componente do
domnio de sistema mais abrangente. Porm, independentemente do ponto de partida, a
jornada atravs da ponte nos leva bem frente no projeto, permitindo que examinemos o
contexto do trabalho de software a ser realizado; as necessidades especficas que o projeto
e a construo devem atender; as prioridades que orientam a ordem na qual o trabalho deve
ser completado e as informaes, funes e comportamentos que tero um impacto profundo no projeto resultante.
A engenharia de requisitos fornece o mecanismo apropriado para entender aquilo que o
cliente deseja, analisando as necessidades, avaliando a viabilidade, negociando uma soluo razovel, especificando a soluo sem ambiguidades, validando a especificao e gerenciando as
necessidades medida que so transformadas em um sistema operacional [Tha97]. Ela abrange
sete tarefas distintas: concepo, levantamento, elaborao, negociao, especificao, validao e gesto. importante notar que algumas delas ocorrem em paralelo e todas so adaptadas
s necessidades do projeto.
Concepo. Como um projeto de software iniciado? Existe algum evento nico que se torna
o catalisador para um novo produto ou sistema de computador ou a necessidade evolui ao longo do tempo? No h nenhuma resposta definitiva para tais perguntas. Em alguns casos, uma
conversa informal tudo o que preciso para precipitar um trabalho de engenharia de software.
Porm, em geral, a maioria dos projetos comea quando identificada a necessidade do negcio
ou descoberto um novo servio ou mercado potencial. Interessados da comunidade de negcios (por exemplo, gerentes comerciais, pessoal de marketing, gerentes de produto) definem um
plano de negcio para a ideia, tentam identificar o tamanho do mercado, fazem uma anlise de
1

Isto particularmente verdadeiro para projetos pequenos (menos de um ms) e trabalhos de software menores e relativamente simples. medida que o software cresce em tamanho e complexidade, tais argumentos caem por terra.

128

As sementes
das principais
catstrofes de
software so
normalmente
semeadas nos trs
primeiros meses
do projeto de
software.
Caper Jones

PARte 2 Modelagem

viabilidade aproximada e identificam uma descrio operacional do escopo do projeto. Todas


as informaes esto sujeitas a mudanas, porm suficiente para suscitar discusses com a
organizao de engenharia de software.2
Na concepo3 do projeto, estabelecemos um entendimento bsico do problema, as pessoas
que querem uma soluo, a natureza da soluo desejada e a eficcia da comunicao e colaborao preliminares entre os demais interessados e a equipe de software.
Levantamento. Certamente parece bastante simples pergunte ao cliente, aos usurios
e aos demais interessados quais so os objetivos para o sistema ou produto, o que deve ser
alcanado, como o sistema ou produto atende s necessidades da empresa e, por fim, como
o sistema ou produto deve ser utilizado no dia a dia. Mas isso no simples na verdade,
muito difcil.
Christel e Kang [Cri92] identificaram uma srie de problemas que so encontrados durante
o levantamento:

que
? Por
difcil

Problemas de escopo. Os limites do sistema so definidos de forma precria ou os


clientes/usurios especificam detalhes tcnicos desnecessrios que podem confundir, em
vez de esclarecer, os objetivos globais do sistema.
Problemas de entendimento. Os clientes/usurios no esto completamente certos
do que preciso, tm um entendimento inadequado das capacidades e limitaes de
seus ambientes computacionais, no possuem um entendimento completo do domnio
do problema, tm problemas para transmitir suas necessidades ao engenheiro de sistemas, omitem informaes que acreditam ser bvias, especificam requisitos que conflitam com as necessidades de outros clientes/usurios ou especificam requisitos que so
ambguos ou impossveis de ser testados.
Problemas de volatilidade. Os requisitos mudam com o tempo. Para ajudar a superar esses problemas, devemos abordar o levantamento de requisitos de forma organizada.

AVISO

Elaborao. As informaes obtidas do cliente durante as fases de concepo e levantamento


so expandidas e refinadas durante a elaborao. Essa tarefa concentra-se no desenvolvimento
de um modelo de requisitos refinado (Captulos 6 e 7) que identifique os diversos aspectos da
funo, do comportamento e das informaes do software.
A elaborao guiada pela criao e refinamento de cenrios de usurios que descrevem
como o usurio final (e outros atores) iro interagir com o sistema. Cada cenrio de usurio
analisado sintaticamente para extrair classes de anlise entidades do domnio de negcio
visveis para o usurio final. Os atributos de cada classe de anlise so definidos, e os servios4
exigidos por cada classe so identificados. As relaes e a colaborao entre as classes so identificadas e uma variedade de diagramas suplementares produzida.

conseguir um claro
entendimento
daquilo que o
cliente quer?

A elaborao uma
coisa boa, porm
preciso saber quando
parar. O segredo
descrever o problema
de maneira que
estabelea uma base
slida para o projeto.
Caso passe desse
ponto, voc estar
realizando um projeto.

AVISO
Em uma negociao
efetiva no existem
ganhadores, nem
perdedores. Ambas os
lados ganham, pois
solidificado um trato
que ambas as partes
aceitam.

Negociao. No incomum clientes e usurios pedirem mais do que pode ser alcanado,
dados os recursos limitados do negcio. Tambm relativamente comum diferentes clientes ou
usurios proporem necessidades conflitantes, argumentando que sua verso essencial para
nossas necessidades especiais.
preciso conciliar esses conflitos por meio de um processo de negociao. Devemos solicitar aos clientes, usurios e outros interessados para que ordenem seus requisitos e discutam em
termos de prioridade. Usando uma abordagem iterativa que priorize os requisitos, avalie seus
2
3
4

Se um sistema baseado em computador deve ser desenvolvido, as discusses comeam no contexto de um processo de engenharia de sistemas. Para uma discusso detalhada da engenharia de sistemas, visite o site que acompanha este livro.
Lembre-se de que o Processo Unificado (Captulo 2) define uma fase de concepo mais ampla que engloba as tarefas de
concepo, levantamento e elaborao discutidas neste captulo.
Um servio manipula os dados encapsulados pela classe. Os termos operao e mtodo tambm so usados. Caso no esteja
familiarizado com os conceitos da orientao a objetos, apresentada uma introduo bsica no Apndice 2.

129

captulo 5 eNGeNHarIa De reqUIsItos

custos e riscos, bem como trate dos conflitos internos, requisitos so eliminados, combinados
e/ou modificados, de modo que cada parte atinja certo nvel de satisfao.

A formalidade e o
formato de uma
especificao variam
com o tamanho
e a complexidade
do software a ser
construdo.

Especificao. No contexto de sistemas (e software) baseados em computadores, o termo


especificao assume diferentes significados para pessoas diferentes. Especificao pode ser um
documento por escrito, um conjunto de modelos grficos, um modelo matemtico formal, um
conjunto de cenrios de uso, um prottipo ou qualquer combinao dos fatores citados.
Alguns sugerem que modelo-padro [Som97] deve ser desenvolvido e utilizado para a
especificao, argumentando que isso leva a requisitos que so apresentados de forma consistente e, portanto, mais compreensvel. Entretanto, algumas vezes necessrio permanecer
flexvel quando uma especificao deve ser desenvolvida. Para sistemas grandes, um documento
escrito, combinando descries em linguagem natural e modelos grficos, pode ser a melhor
abordagem. Entretanto, talvez sejam necessrios apenas cenrios de uso para produtos ou sistemas menores que residem em ambientes tcnicos bem entendidos.

Modelo de especicao de requisitos de software


Uma especificao de requisitos de software (software
requirements specication, SrS) um documento
criado quando uma descrio detalhada de todos
os aspectos do software a ser construdo deve ser especificada
antes de o projeto comear. importante notar que uma SrS
formal nem sempre por escrito. Na realidade, h vrias ocasies em que o esforo gasto em uma SrS talvez fosse mais bem
aproveitado em outras atividades de engenharia de software.
Entretanto, quando um software for desenvolvido por terceiros,
quando uma falta de especificao criar graves problemas de
negcio, ou quando um sistema for extremamente complexo ou
crtico para o negcio, ser justificvel uma SrS.

2.3 Classes de usurios e caractersticas


2.4 Ambiente operacional
2.5 restries de projeto e implementao
2.6 Documentao para usurios
2.7 Hipteses e dependncias
3. Caractersticas do sistema
3.1 Caractersticas do sistema 1
3.2 Caractersticas do sistema 2 (e assim por diante)
4. Requisitos de interfaces externas
4.1 Interfaces do usurio

Karl Wiegers [Wie03] da Process Impact Inc. desenvolveu uma


planilha bastante til (disponvel em www.processimpact.
com/process_assets/srs_ template.doc), que pode servir
como diretriz para aqueles que precisam criar uma SrS completa. Uma descrio geral por tpicos apresentada a seguir:

4.2 Interfaces de hardware

Sumrio

5.2 Necessidades de proteo

Histrico de reviso
1. Introduo

INfORMAES

4.3 Interfaces de software


4.4 Interfaces de comunicao
5. Outros requisitos no funcionais
5.1 Necessidades de desempenho
5.3 Necessidades de segurana
5.4 Atributos de qualidade de software

1.1 Propsito
1.2 Convenes do documento
1.3 Pblico-alvo e sugestes de leitura
1.4 Escopo do projeto
1.5 referncias
2. Descrio geral
2.1 Perspectiva do produto
2.2 Caractersticas do Produto

6. Outros requisitos
Apndice A: Glossrio
Apndice B: Modelos de anlise
Apndice C: Lista de problemas
Uma descrio detalhada de cada tpico SrS pode ser obtida
fazendo-se o download da planilha SrS na UrL citada anteriormente neste quadro.

Validao. Os artefatos produzidos como consequncia da engenharia de requisitos so avaliados quanto qualidade durante a etapa de validao. A validao de requisitos examina a
especificao5 para garantir que todos os requisitos de software tenham sido declarados de for5

Lembre-se de que a natureza da especificao ir variar em cada projeto. Em alguns casos, a especificao um conjunto
de cenrios de usurios e pouco mais do que isso. Em outros, a especificao pode ser um documento contendo cenrios,
modelos e descries por escrito.

130

paRtE 2

AVISO
Uma preocupao
fundamental durante a
validao de requisitos
a consistncia. Use o
modelo de anlise para
garantir que os requisitos
foram declarados de
forma consistente.

MoDeLaGeM

ma no ambgua; que as inconsistncias, omisses e erros tenham sido detectados e corrigidos


e que os artefatos estejam de acordo com os padres estabelecidos para o processo, projeto e
produto.
O principal mecanismo de validao de requisitos a reviso tcnica (Captulo 15). A equipe
de reviso que valida os requisitos formada por engenheiros de software, clientes, usurios
e outros interessados que examinam a especificao em busca de erros no contedo ou na interpretao, reas em que talvez sejam necessrios esclarecimentos, de informaes faltantes,
de inconsistncias (um problema grave quando so criados produtos ou sistemas grandes), de
requisitos conflitantes ou de requisitos irreais (inatingveis).

Lista de controle para validao de requisitos


Muitas vezes til examinar cada requisito em relao a um conjunto de perguntas contidas em uma
lista de controle. A seguir, um pequeno subconjunto
daquelas que poderiam ser perguntadas:

Os requisitos esto declaradas de forma clara? Eles podem


ser mal-interpretados?

A fonte (por exemplo, uma pessoa, uma regulamentao, um

documento) do requisito foi identificada? A declarao final


do requisito foi examinada pela fonte original ou com ela?
O requisito est limitado em termos quantitativos?
Que outros requisitos se relacionam a este requisito? Eles
esto claramente indicados por meio de uma matriz de referncia cruzada ou algum outro mecanismo?
O requisito viola quaisquer restries do domnio do sistema?

INfORMAES

O requisito pode ser testado? Em caso positivo, podemos

especificar testes (algumas vezes denominados critrios de


validao) para testar o requisito?
O requisito pode ser associado a qualquer modelo de sistema que tenha sido criado?
O requisito pode ser associado aos objetivos globais do sistema/produto?
A especificao estruturada de forma que leve ao fcil
entendimento, fcil referncia e fcil traduo em artefatos
mais tcnicos?
Criou-se um ndice para a especificao?
Os requisitos associados ao desempenho, ao comportamento e s caractersticas operacionais foram declarados de maneira clara? Quais requisitos parecem estar implcitos?

Gesto de requisitos. Os requisitos para sistemas baseados em computadores mudam, e o


desejo de mudar os requisitos persiste ao longo da vida de um sistema. Gesto de requisitos
um conjunto de atividades que ajuda a equipe de projeto a identificar, controlar e acompanhar
as necessidades e suas mudanas a qualquer momento enquanto o projeto prossegue.6 Muitas
7

FERRAMENTAS DO SOFTWARE
Engenharia de requisitos
Objetivo: As ferramentas de engenharia de requisitos auxiliam no levantamento, na modelagem, na
gesto, bem como na validao de requisitos.
Mecnica: A mecnica das ferramentas varia. Em geral, as
ferramentas de engenharia de requisitos constroem uma grande variedade de modelos grficos (por exemplo, UML) que
representam os aspectos informativos, funcionais e comportamentais de um sistema. Esses modelos formam a base para
todas as demais atividades no processo de software.
Ferramentas representativas:7
Uma lista relativamente abrangente (e atualizada) de ferramentas de engenharia de requisitos pode ser encontrada no site
Volvere requirements em www.volere.co.uk/tools.htm.
As ferramentas de modelagem de requisitos so discutidas nos

6
7

Captulos 6 e 7. As ferramentas citadas a seguir se concentram na gesto de requisitos.


EasyrM, desenvolvida pela Cybernetic Intelligence GmbH
(www.easy-rm.com), constri um dicionrio/glossrio
especfico de projetos contendo atributos e descries detalhadas dos requisitos.
rational requisitePro, desenvolvida pela rational Software
(www-306.ibm.com/software/awdtools/req
pro/), permite aos usurios construir um banco de dados
de requisitos, representar as relaes entre requisitos e organizar, priorizar e rastrear requisitos.
Muitas outras ferramentas de gerenciamento de necessidades
podem ser encontradas no site da Volvere citado anteriormente no seguinte endereo: www.jiludwig.com/Require
ments_Management_Tools.html.

O gerenciamento formal de requisitos iniciado apenas para grandes projetos com centenas de necessidades identificveis.
Para projetos pequenos, essa ao da engenharia de requisitos consideravelmente menos formal.
As ferramentas aqui apresentadas no significam um endosso, mas sim, uma amostra de ferramentas desta categoria. Na
maioria dos casos, os nomes das ferramentas so marcas registradas por seus respectivos desenvolvedores.

131

captulo 5 Engenharia de Requisitos

dessas atividades so idnticas s tcnicas de gerenciamento de configuraes de software (software configuration management, SCM) discutidas no Captulo 22.

5 .2

Interessado
qualquer um que
tenha interesse
direto ou beneficia-se
do sistema a ser
desenvolvido.

Incio

do

Processo

de

Engenharia

de

Requisitos

Em um ambiente ideal, os interessados e os engenheiros de software trabalham juntos na


mesma equipe.8 Em tais casos, a engenharia de requisitos apenas uma questo de conduzir
conversaes proveitosas com colegas que sejam membros bem conhecidos da equipe. Porm,
a realidade muitas vezes bastante diferente.
Cliente(s) ou usurios finais podem estar situados em uma cidade ou pas diferente, podem
ter apenas uma vaga ideia daquilo que necessrio, podem ter opinies conflitantes sobre o
sistema a ser construdo, podem ter conhecimento tcnico limitado ou quem sabe pouco tempo
para interagir com o engenheiro que est fazendo o levantamento dos requisitos. Nenhuma das
situaes anteriores desejvel, contudo, todas so relativamente comuns e muitas vezes voc
forado a trabalhar de acordo com as limitaes impostas pela situao.
Nas sees a seguir, discutiremos as etapas necessrias para estabelecer as bases para um
entendimento dos requisitos de software para que o projeto possa ser iniciado de modo que
avance na direo de uma soluo bem-sucedida.

5.2.1Identificao de interessados
Sommerville e Sawyer [Som97] definem interessados como qualquer um que se beneficia
de forma direta ou indireta do sistema que est sendo desenvolvido. J tivemos a oportunidade
de identificar os envolvidos usuais: gerentes de operaes, gerentes de produto, pessoal de marketing, clientes internos e externos, usurios finais, consultores, engenheiros de produto, engenheiros de software, engenheiros de suporte e manuteno e outros. Cada interessado tem uma
viso diferente do sistema, obtm diferentes benefcios quando o sistema desenvolvido com
xito e est sujeito a diferentes riscos caso o trabalho de desenvolvimento venha a fracassar.
No incio, devemos criar uma lista das pessoas que iro contribuir com sugestes medida
que os requisitos so obtidos (Seo 5.3). A lista inicial crescer medida que os interessados
forem contatados, pois para cada um deles ser feita a pergunta: Com quem mais voc acha
que eu deva falar?.

5.2.2 Reconhecimento de diversos pontos de vista


Coloque trs
interessados
em uma sala
e pergunte a
eles que tipo de
sistema desejam.
Provavelmente
voc obter quatro
ou mais opinies
diferentes.
Autor
desconhecido

Pelo fato de existirem muitos interessados diferentes, os requisitos do sistema sero explorados sob vrios pontos de vista. Por exemplo, o grupo de marketing est interessado nas
funes e recursos que iro suscitar o mercado potencial, facilitando a venda do novo sistema.
Os gerentes comerciais esto interessados em um conjunto de recursos que pode ser construdo
dentro do oramento e que estaro prontos para atender s oportunidades definidas de ingresso
no mercado. Os usurios finais podem querer recursos que sejam familiares a eles e que sejam
fceis de aprender e usar. Os engenheiros de software podem estar preocupados com funes
invisveis aos interessados no tcnicos, mas que possibilitam uma infraestrutura que d suporte a um maior nmero de funes e recursos comercializveis. Os engenheiros de suporte talvez
enfoquem a facilidade de manuteno do software.
Cada uma dessas partes envolvidas (e outras) contribuir com informaes para o processo
de engenharia de requisitos. As informaes dos diversos pontos de vista so coletadas, requisitos emergentes talvez sejam inconsistentes ou entrem em conflito uns com os outros. Deve-se
classificar as informaes de todos os interessados (inclusive os requisitos inconsistentes e
conflitantes) de maneira que permita aos tomadores de deciso escolher um conjunto internamente consistente de requisitos para o sistema.
8

Essa abordagem altamente recomendada para projetos que adotam uma filosofia de desenvolvimento de software gil.

132

paRtE 2

5.2.3

MoDeLaGeM

trabalho na busca da colaborao

Se cinco interessados estiverem envolvidos em um projeto de software, talvez tenhamos cinco (ou mais) opinies diferentes sobre o conjunto de requisitos apropriado. Ao longo dos captulos anteriores, citei que os clientes (e outros interessados) devem colaborar entre si (evitando
insignificantes lutas internas pelo poder) e com os profissionais de engenharia de software, caso
se queira obter um sistema bem-sucedido. Mas como a colaborao atingida?
O trabalho de um engenheiro de requisitos identificar reas em comum (requisitos com os
quais todos os interessados concordam) e reas de conflito ou inconsistncia (requisitos desejados por um interessado, mas que conflitam com os de outro interessado). , obviamente, a
ltima categoria que representa um desafio.

INfORMAES

Utilizao de pontos de prioridade


Um modo de resolver requisitos conitantes e, ao
mesmo tempo, entender a importncia relativa de
todas as necessidades usar um esquema de votao baseado nos pontos de prioridade.
Todos os interessados recebem certo nmero de pontos de
prioridade que podem ser gastos em um nmero qualquer de
requisitos. apresentada uma lista de requisitos, e cada interessado indica a importncia relativa de cada um deles (sob o seu

ponto de vista) gastando um ou mais pontos de prioridade nele.


Pontos gastos no podem ser reutilizados.
Uma vez que os pontos de prioridade de um interessado
tenham se esgotado, nenhuma ao adicional em relao aos
requisitos pode ser feita por essa pessoa. O total de pontos
dados por todos os interessados a cada requisito d uma indicao da importncia global de cada requisito.

Colaborao no significa necessariamente que os requisitos so definidos por um comit.


Em muitos casos, os interessados colaboram dando suas vises dos requisitos, mas um poderoso campeo dos projetos (por exemplo, um gerente comercial ou um tcnico snior) pode
tomar a deciso final sobre quais os requisitos que passam pelo corte.

5.2.4
melhor conhecer
algumas perguntas
do que todas as
respostas.
James Thurber

perguntas iniciais

As perguntas feitas na concepo do projeto devem ser livres de contexto [Gau89]. O primeiro conjunto de perguntas enfoca o cliente e outros interessados, os benefcios e as metas de
projeto globais. Por exemplo, poderamos perguntar:



Quem est por trs da solicitao deste trabalho?


Quem ir usar a soluo?
Qual ser o benefcio econmico de uma soluo bem-sucedida?
H uma outra fonte para a soluo que voc precisa?

Essas perguntas ajudam a identificar todos os interessados no software a ser criado. Alm disso,
identificam o benefcio mensurvel de uma implementao bem-sucedida e possveis alternativas para o desenvolvimento de software personalizado.
O conjunto de perguntas a seguir permite que adquiramos um melhor entendimento do problema e que o cliente expresse suas percepes sobre uma soluo:

? Quais
perguntas

iro ajudlo
a obter um
entendimento
preliminar do
problema?

Como voc caracterizaria uma boa sada, que seria gerada por uma soluo bem-sucedida?
Qual(is) problema(s) esta soluo ir tratar?
Voc poderia me indicar (ou descrever) o ambiente de negcios em que a soluo ser
usada?
Restries ou problemas de desempenho afetam a maneira com que a soluo ser abordada?

captulo 5 Engenharia de Requisitos

133

O conjunto final de perguntas concentra-se na eficcia da atividade de comunicao em si.


Gause e Weinberg [Gau89] chamam esse conjunto de metaperguntas e propem a seguinte
lista (sintetizada):




Aquele que
pergunta tolo
por cinco minutos;
aquele que no
faz tolo para
sempre.
Provrbio chins

5 .3

Voc a pessoa correta para responder estas perguntas? Suas respostas so oficiais?
Minhas perguntas so relevantes para o problema que voc tem?
Estaria eu fazendo perguntas demais?
Alguma outra pessoa poderia me prestar informaes adicionais?
Deveria eu perguntar-lhe algo mais?

Essas (e outras) perguntas iro ajud-lo a quebrar o gelo e iniciar o processo de comunicao essencial para o xito do levantamento. Porm, uma reunio com formato perguntas-e-respostas no uma abordagem que tem obtido um sucesso marcante. Na realidade, a sesso
Q&A (perguntas e respostas) deveria ser usada apenas no primeiro encontro e depois substituda
pelo formato de levantamento de requisitos que combina elementos de resoluo de problemas,
negociao e especificao. Uma abordagem desse tipo apresentada na Seo 5.3.

L e va n ta m e n t o

de

Requisitos

O levantamento de requisitos (tambm chamado elicitao de requisitos) combina elementos de resoluo de problemas, elaborao, negociao e especificao. Para encorajar
uma abordagem colaborativa e orientada s equipes em relao ao levantamento de requisitos, os interessados trabalham juntos para identificar o problema, propor elementos da
soluo, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos
da soluo [Zah90].9

5.3.1Coleta colaborativa de requisitos


Foram propostas vrias abordagens para a coleta colaborativa de requisitos. Cada uma delas
faz uso de um cenrio ligeiramente diferente, porm todas aplicam alguma variao das seguintes diretrizes bsicas:

bsicas para
conduzir uma
reunio de coleta
colaborativa de
requisitos?

As reunies so conduzidas por e com a participao tanto dos engenheiros de software


quanto de outros interessados.
So estabelecidas regras para preparao e participao.
sugerida uma agenda suficientemente formal para cobrir todos os pontos importantes,
porm, suficientemente informal para encorajar o fluxo livre de ideias.
Um facilitador (pode ser um cliente, um desenvolvedor ou uma pessoa de fora) dirige
a reunio.
utilizado um mecanismo de definies (que pode ser planilhas, flip charts, adesivos
de parede ou um boletim eletrnico, salas de bate-papo ou fruns virtuais).

Gastamos um
bom tempo a
maior parte do
esforo de um
projeto no
implementando ou
testando, mas sim
tentando decidir o
que construir.

A meta identificar o problema, propor elementos da soluo, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da soluo em uma atmosfera que
seja propcia para o cumprimento da meta. Para melhor compreender o fluxo de eventos
medida que ocorrem, apresento um breve cenrio que descreve em linhas gerais a sequncia
de eventos que levam reunio para levantamento de requisitos e que acontecem durante e
aps a reunio.
Durante a concepo (Seo 5.2) perguntas e respostas estabelecem o escopo do problema
e a percepo geral de uma soluo. Como resultado dessas reunies iniciais, o desenvolvedor
e os clientes redigem uma solicitao de produto de uma ou duas pginas.

so
? Quais
as diretrizes

Brian Lawrence

Essa abordagem algumas vezes chamada FAST (facilitated application specification technique, ou seja, tcnica de especificao de aplicaes facilitada).

134

WebRef
Joint Application
Development (JAD)
uma popular tcnica
para levantamento de
requisitos. Uma
excelente descrio
sobre ela pode ser
encontrada em

www.carolla.
com/wp-jad.
htm.

AVISO
Se um sistema ou
produto atender
muitos usurios,
esteja absolutamente
certo de que os
requisitos foram
extrados de uma fatia
representativa dos
usurios. Se apenas
um usurio definiu
todas as necessidades,
o risco de no
aceitao grande.
Fatos no cessam
de existir por
serem ignorados.
Aldous Huxley

AVISO
Evite o impulso
de hostilizar uma
sugesto de um
cliente classificando-a
como muito cara
ou pouco prtica.
O objetivo aqui
negociar uma lista que
seja aceitvel para
todos. Para tanto, voc
deve ser receptivo a
novas ideias.

PARte 2 Modelagem

So escolhidos um local, hora e data para a reunio; escolhido um facilitador; e os membros da equipe de software e de outros departamentos interessados so convidados a participar.
A solicitao de produto distribuda a todos os participantes antes da data da reunio.
Como exemplo,10 consideremos um trecho de uma solicitao de produto redigida por uma
pessoa de marketing envolvida no projeto CasaSegura. Esta pessoa escreve a seguinte narrativa
sobre a funo de segurana domiciliar que faz parte do CasaSegura:
Nossa pesquisa indica que o mercado para sistemas de administrao domiciliar est crescendo com
taxas de 40% ao ano. A primeira funo do CasaSegura que lanaramos no mercado seria a funo de
segurana domiciliar. A maioria das pessoas est familiarizada com sistemas de alarme, de modo que
seria algo fcil de vender.
A funo de segurana domiciliar protegeria e/ou reconheceria uma srie de situaes indesejveis
como acesso ilegal, incndios, inundaes, nveis de monxido de carbono e outras. Ela usar nossos
sensores sem fio para detectar cada uma dessas situaes. Poder ser programada pelo proprietrio
da casa e, automaticamente, ligar para uma agncia de monitoramento quando for detectada uma
situao destas.

Na realidade, outras pessoas contribuiriam para essa narrativa durante a reunio para levantamento de requisitos e um nmero consideravelmente maior de informaes ficariam disponveis. Contudo, mesmo com essas informaes adicionais, a ambiguidade estaria presente,
provavelmente existiriam omisses e poderiam ocorrer erros. Por enquanto, a descrio funcional anterior ser suficiente.
Ao rever a solicitao de produto nos dias que antecedem a reunio, pedido a cada
participante uma lista de objetos que fazem parte do ambiente que cerca o sistema, outros
que devem ser produzidos pelo sistema e aqueles usados pelo sistema para desempenhar
suas funes. Alm disso, pede-se a cada participante uma outra lista de servios (processos
ou funes) que manipulam ou interagem com os objetos. Por fim, tambm so desenvolvidas listas de restries (por exemplo, custo, dimenses, regras comerciais) e de critrios
de desempenho (por exemplo, velocidade, preciso). Os participantes so informados que
no se espera que as listas sejam exaustivas, mas que reflitam a percepo do sistema de
cada pessoa.
Entre os objetos descritos para o CasaSegura poderamos ter o painel de controle, detectores de fumaa, sensores para janelas e portas, detectores de movimento, um alarme,
um evento (por exemplo, um sensor foi ativado), um display, um PC, nmeros de telefone,
uma ligao telefnica e assim por diante. A lista de servios poderia incluir configurar o
sistema, acionar o alarme, monitorar os sensores, discar o telefone, programar o painel de
controle e ler o display (note que os servios atuam sobre os objetos). De maneira similar,
cada participante ir criar listas de restries (por exemplo, o sistema tem de reconhecer
quando os sensores no esto operando, ser amigvel, interfacear diretamente com uma
linha telefnica comum) e de critrios de desempenho (por exemplo, um evento de sensor
seria reconhecido em um intervalo de um segundo e seria implementado um esquema de
prioridade para os eventos).
As listas de objetos poderiam ser afixadas nas paredes da sala de reunio utilizando-se grandes folhas de papel, coladas nas paredes por meio de folhas adesivas ou escritas em mural.
Como alternativa, poderiam ser postadas em um boletim eletrnico, em um site interno ou
colocadas em um ambiente de salas de bate-papo para reviso antes da reunio. De modo
ideal, cada entrada deveria ser capaz de ser manipulada separadamente, de modo que as listas
pudessem ser combinadas, as entradas modificadas e adies feitas. Nesse estgio, crticas e
polmicas so estritamente proibidas.

10 Esse exemplo (com extenses e variaes) usado para ilustrar importantes mtodos de engenharia de software em vrios
dos captulos que vm a seguir. Como exerccio, valeria a pena realizar sua prpria reunio para levantamento de requisitos e
desenvolver um conjunto de listas para ela.

135

captulo 5 Engenharia de Requisitos

Depois de as listas individuais terem sido apresentadas, o grupo cria uma lista combinada
eliminando entradas redundantes, acrescentando quaisquer ideias novas que surjam durante
a discusso, mas no se elimina nada. Segue-se ento uma discusso (coordenada pelo facilitador). A lista combinada reduzida, ampliada ou escrita de outra maneira para refletir apropriadamente o produto/sistema a ser desenvolvido. O objetivo criar uma lista consensual de
objetos, servios, restries e desempenho para o sistema a ser construdo.
Em muitos casos, um objeto ou servio descrito em uma lista exigir maiores explicaes.
Para tanto, os interessados desenvolvem miniespecificaes para as entradas das listas.11 Cada
miniespecificao a elaborao de um objeto ou servio. Por exemplo, a miniespecificao
para o objeto Control Panel do CasaSegura poderia ser:
O painel de controle a unidade que pode ser montada na parede com tamanho aproximado de
9 x 5 polegadas. O painel de controle possui conectividade sem fio a sensores e a um PC. A interao
com os usurios ocorre com um teclado numrico contendo 12 teclas. Um display colorido LCD de
3 x 3 polegadas fornece o feedback do usurio. O software fornece prompts interativos, eco e funes
similares.

As miniespecificaes so apresentadas a todos os interessados para discusso. Adies,


supresses e mais detalhamentos so feitos. Em alguns casos, o desenvolvimento de miniespecificaes ir revelar novos objetos, servios, restries, ou requisitos de desempenho acrescentados s listas originais. Durante todas as discusses, a equipe pode levantar um assunto que
no pode ser resolvido durante a reunio. mantida uma lista de questes pendentes para que
essas ideias sejam trabalhadas posteriormente.

C asa S egura
Conduo de uma reunio para levantamento de requisitos
Cena: Uma sala de reunio. A primeira reunio para levantamento de requisitos est em andamento.
Atores: Jamie Lazar, membro da equipe de software; Vinod
Raman, membro da equipe de software; Ed Robbins, membro da
equipe de software; Doug Miller, gerente da engenharia de software; trs membros do Depto. de Marketing; um representante
da Engenharia de Produto e um facilitador.
Conversa:
Facilitador (apontando para uma lousa branca): Portanto, esta a lista atual de objetos e servios para a funo
segurana domiciliar.
Representante do Depto. de Marketing:
Segundo o nosso ponto de vista, esta lista cobre aproximadamente todas as funcionalidades.
Vinod: Algum no mencionou que eles queriam que toda a
funcionalidade do CasaSegura pudesse ser acessada via Internet?
Isso incluiria a funo de segurana domiciliar, no mesmo?
Representante do Depto. de Marketing: Sim, voc est
certo... Teremos de acrescentar essa funcionalidade e os objetos
apropriados.

Facilitador: Isso tambm no acrescentaria algumas restries?


Jamie: Realmente, restries tcnicas e legais.
Representante da Engenharia de Produto: E isso significa o qu?
Jamie: melhor termos certeza de que um intruso no conseguir entrar no sistema, desarm-lo e roubar o local ou coisa
pior. Grande responsabilidade sobre ns.
Doug: Uma grande verdade.
Representante do Depto. de Marketing: Mas ainda assim precisamos que... Apenas ter certeza de impedir que um
intruso entre.
Ed: fcil dizer, o duro fazer...
Facilitador (interrompendo): No gostaria de discutir esta
questo agora. Anotemos a questo para ser trabalhada no futuro e prossigamos.
(Doug, atuando como o secretrio da reunio, faz um apontamento apropriado.)
Facilitador: Tenho a impresso de que ainda h mais coisas a
ser consideradas aqui.
(O grupo gasta os 20 minutos seguintes refinando e expandindo
os detalhes da funo segurana domiciliar.)

11 Em vez de criar uma miniespecificao, muitas equipes de software optam por desenvolver cenrios de usurios denominados casos de uso. Estes so considerados de forma detalhada na Seo 5.4 e no Captulo 6.

136

PARte 2 Modelagem

5.3.2Disponibilizao da funo de qualidade


O QFD define
necessidades
para maximizar a
satisfao do cliente.

A disponibilizao da funo de qualidade (quality function deployment, QFD) uma tcnica de gesto da qualidade que traduz as necessidades do cliente para requisitos tcnicos do
software. O QFD concentra-se em maximizar a satisfao do cliente por meio do processo de
engenharia de software [Zul92]. Para tanto, enfatiza o entendimento daquilo que valioso para
o cliente e emprega esses valores ao longo do processo de engenharia. O QFD identifica trs
tipos de necessidades [Zul92]:
Requisitos normais. Refletem os objetivos e metas estabelecidos para um produto ou
sistema durante reunies com o cliente. Se esses requisitos estiverem presentes, o cliente
fica satisfeito. Exemplos de requisitos normais poderiam ser tipos de displays grficos solicitados, funes de sistema especficas e nveis de desempenho definidos.

AVISO
Todo mundo quer
implementar um
monte de requisitos
fascinantes, porm,
tenha cuidado. assim
que o surgimento
incontrolado de
novos requisitos
se estabelece. Por
outro lado, requisitos
fascinantes levam
a um produto
revolucionrio!
WebRef
teis informaes
sobre o QFD podem ser
obtidas em www.

qfdi.org.

Requisitos esperados. Esses requisitos esto implcitos no produto ou sistema e podem


ser to fundamentais que o cliente no os declara explicitamente. Sua ausncia ser causa de grande insatisfao. Exemplos de requisitos esperados so: facilidade na interao
homemmquina, confiabilidade e correo operacional global e facilidade na instalao do
software.
Requisitos fascinantes. Esses recursos vo alm da expectativa dos clientes e demonstram
ser muito satisfatrios quando presentes. Por exemplo, o software para um novo celular vem
com recursos-padro, mas junto vem um conjunto de capacidades no esperadas (por exemplo, tecla multitoque, correio de voz visual) que deleitam todos os usurios do produto.
Embora os conceitos QFD possam ser aplicados ao longo de todo o processo de software [Par
96a], tcnicas QFD especficas so aplicveis atividade de levantamento de requisitos. O QFD
usa observao e entrevistas com clientes, pesquisas e exame de dados histricos (por exemplo,
relatrios de problemas) como dados brutos para a atividade de levantamento de requisitos.
Esses dados so ento traduzidos em uma tabela de requisitos denominada tabela da voz
do cliente revisada com o cliente e outros interessados. Uma srie de diagramas, matrizes e
mtodos de avaliao ento usada para extrair os requisitos esperados e para tentar obter os
requisitos fascinantes [Aka04].

5.3.3Cenrios de uso
medida que os requisitos so levantados, uma viso geral das funes e caractersticas
comea a se materializar. Entretanto, difcil progredir para atividades de engenharia de software mais tcnicas at que entendamos como tais funes e caractersticas sero usadas por
diferentes classes de usurios. Para tanto, os desenvolvedores e usurios podem criar um conjunto de cenrios que identifique um roteiro de uso para o sistema a ser construdo. Os cenrios,
normalmente chamados casos de uso [Jac92], fornecem uma descrio de como o sistema ser
utilizado. Casos de uso so discutidos de forma mais detalhada na Seo 5.4.

C asa S egura
Desenvolvimento de um cenrio de
uso preliminar
Cena: Sala de reunies, na qual prossegue
a primeira reunio de levantamento de requisitos.
Atores: Jamie Lazar, membro da equipe de software; Vinod
Raman, membro da equipe de software; Ed Robbins, membro da
equipe de software; Doug Miller, gerente da engenharia de soft-

ware; trs membros do Depto. de Marketing; um representante


da Engenharia de Produto e um facilitador.
Conversa:
Facilitador: Andamos conversando sobre segurana de acesso funcionalidade CasaSegura que poder ser acessada via
Internet. Gostaria de tentar algo. Vamos desenvolver um cenrio
de uso para acesso funo segurana domiciliar.
Jamie: Como?

137

captulo 5 Engenharia de Requisitos

Facilitador: Podemos realizar isso de vrias maneiras, mas,


por enquanto, gostaria de manter as coisas realmente informais.
Conte-nos (ele aponta para um representante do Depto. de Marketing) como voc imagina o acesso ao sistema.
Representante do Depto. de Marketing: Huum... Bem,
esse o tipo de coisa que eu faria se estivesse fora e tivesse
que deixar algum em casa, digamos uma empregada ou um
encanador, que no teriam o cdigo de acesso.
Facilitador (sorrindo): Isso que voc falou a razo para
voc faz-lo... Diga-me como realmente faria isso.
Representante do Depto. de Marketing: Huum... A primeira coisa de que precisaria seria um PC. Entraria em um site
que deveramos manter para todos os usurios do CasaSegura.
Forneceria meu nome de usurio e...
Vinod (interrompendo): A pgina teria de ser segura e criptografada para garantir que estamos seguros e...
Facilitador (interrompendo): Essas so informaes adequadas, Vinod, porm so tcnicas. Concentremo-nos apenas
em como o usurio final usar essa capacidade. OK?
Vinod: Sem problemas.
Representante do Depto. de Marketing: Bem, como estava dizendo, entraria em um site e forneceria meu nome de usurio e
dois nveis de senhas.

Jamie: O que acontece se eu esquecer minha senha?


Facilitador (interrompendo): Excelente observao, Jamie,
mas no tratemos disso agora. Faremos um registro de sua observao e a chamaremos de exceo. Tenho certeza de que
existiro outras.
Representante do Depto. de Marketing: Aps eu introduzir as senhas, uma tela representando todas as funes do
CasaSegura aparecer. Eu selecionaria a funo de segurana
domiciliar. O sistema poderia solicitar que eu verificasse quem
sou eu, digamos, perguntando meu endereo ou telefone ou algo
do gnero. Em seguida, ele exibiria uma imagem do painel de
controle do sistema de segurana com uma lista das funes que
eu poderia executar armar o sistema, desarm-lo, desarmar
um ou mais sensores. Suponho que ele tambm me permitiria
reconfigurar zonas de segurana e outros itens similares, mas,
no tenho certeza disso.
(Enquanto o representante do Depto. de Marketing continua falando, Doug faz anotaes de maneira ininterrupta; essas formam a base para o primeiro cenrio de uso informal. Como
alternativa, poderia ser solicitado ao representante do Depto.
de Marketing que escrevesse o cenrio, mas isso seria feito fora
da reunio.)

5.3.4Artefatos do levantamento de requisitos


Os artefatos produzidos como consequncia do levantamento de requisitos variaro dependendo do tamanho do sistema ou produto a ser construdo. Para a maioria dos sistemas, entre
os artefatos, temos:

? Quais
informaes

so produzidas
como consequncia
do levantamento
de requisitos?

Uma declarao da necessidade e viabilidade.


Uma declarao restrita do escopo para o sistema ou produto.
Uma lista de clientes, usurios e outros interessados que participaram do levantamento
de requisitos.
Uma descrio do ambiente tcnico do sistema.
Uma lista de requisitos (preferencialmente organizada por funo) e as restries de domnio que se aplicam a cada uma delas.
Um conjunto de cenrios de uso que esclarecem o uso do sistema ou produto sob diferentes condies operacionais.
Quaisquer prottipos desenvolvidos para melhor definio dos requisitos.
Cada um desses artefatos revisado por todas as pessoas que participaram do levantamento
de requisitos.

5 .4

D e s e n v o lv i m e n t o

de

Casos

de

Uso

Em um livro que discute como redigir casos de uso eficazes, Alistair Cockburn [Coc01b] observa que um caso de uso captura um contrato... [que] descreve o comportamento do sistema
sob vrias condies medida que o sistema responde a uma solicitao de um de seus interessados.... Essencialmente, um caso de uso conta uma histria estilizada sobre como um usurio
final (desempenhando um de uma srie de papis possveis) interage com o sistema sob um

138

Os casos de uso so
definidos sob o ponto
de vista de um ator.
Ator um papel que
as pessoas (usurios)
ou dispositivos
desempenham
medida que interagem
com o software.

WebRef
Um excelente artigo
sobre casos de uso
pode ser baixado de
www.ibm.com/
developerworks/
webservices/
library/codesign7.
html.

que
? Opreciso
saber

para desenvolver
um caso de uso
efetivo?

PARte 2 Modelagem

conjunto de circunstncias especficas. A histria poderia ser um texto narrativo, uma descrio
geral das tarefas ou interaes, uma descrio baseada em gabaritos ou uma representao
esquemtica. Independentemente de sua forma, um caso de uso representa o software ou o
sistema do ponto de vista do usurio final.
O primeiro passo ao escrever um caso de uso definir o conjunto de atores envolvidos na
histria. Atores so as diferentes pessoas (ou dispositivos) que usam o sistema ou produto no
contexto da funo e comportamento a ser descritos. Os atores representam os papis que pessoas (ou dispositivos) desempenham enquanto o sistema opera. Definido de maneira um pouco
mais formal, ator qualquer coisa que se comunica com o sistema ou o produto e que externa
ao sistema em si. Todo ator possui uma ou mais metas ao usar o sistema.
importante notar que o ator e o usurio final no so necessariamente a mesma coisa.
O usurio tpico poderia desempenhar uma srie de papis diferentes ao usar um sistema, ao
passo que o ator representa uma classe de entidades externas (normalmente, mas no sempre,
pessoas) que desempenham apenas um papel no contexto do caso de uso. Como exemplo, consideremos um operador de mquina (um usurio) que interage com o computador de controle
de uma clula de fabricao contendo uma srie de robs e mquinas comandada por controle
numrico. Aps uma reviso cuidadosa dos requisitos, o software para o computador de controle requer quatro modos (papis) diferentes para interao: modo de programao, modo de
teste, modo de monitoramento e modo de diagnstico. Portanto, podem ser definidos quatro
atores: programador, testador, monitorador e diagnosticador. Em alguns casos, o operador de
mquina pode desempenhar todos esses papis. Em outros, pessoas diferentes poderiam desempenhar o papel de cada ator.
Pelo fato de o levantamento de requisitos ser uma atividade evolucionria, nem todos os atores so identificados durante a primeira iterao. possvel identificar atores primrios [Jac92]
durante a primeira iterao e atores secundrios quando mais fatos so aprendidos sobre o
sistema. Os primrios interagem para atingir a funo necessria do sistema e obter o benefcio
desejado do sistema. Eles trabalham direta e frequentemente com o software. Os secundrios
do suporte ao sistema, de modo que os primrios possam realizar seu trabalho.
Uma vez que os atores tenham sido identificados, os casos de uso podem ser desenvolvidos.
Jacobson [Jac92] sugere uma srie de perguntas12 que devem ser respondidas por um caso de
uso:









Quem (so) o(s) ator(es) primrio(s) e o(s) ator(es) secundrio(s)?


Quais so as metas do ator?
Que precondies devem existir antes de uma histria comear?
Que tarefas ou funes principais so realizadas pelo ator?
Que excees deveriam ser consideradas medida que uma histria descrita?
Quais so as variaes possveis na interao do ator?
Que informaes de sistema o ator adquire, produz ou modifica?
O ator ter de informar o sistema sobre mudanas no ambiente externo?
Que informaes o ator deseja do sistema?
O ator gostaria de ser informado sobre mudanas inesperadas?

Relembrando as necessidades bsicas do CasaSegura, definimos quatro atores: proprietrio (um usurio), gerente de ativao (provavelmente a mesma pessoa que o proprietrio,
porm desempenhando um papel diferente), sensores (dispositivos conectados ao sistema) e
o subsistema de monitoramento e resposta (a estao central que monitora a funo segurana domiciliar do CasaSegura). Para o propsito deste exemplo, consideraremos apenas o
ator proprietrio, que interage com a funo segurana domiciliar de uma de vrias maneiras
diferentes usando o painel de controle de alarme ou um PC:
12 As perguntas de Jacobson foram estendidas para dar uma viso mais completa do contedo dos casos de uso.

139

captulo 5 Engenharia de Requisitos

Digita uma senha para permitir todas as demais interaes.


Consulta o estado de uma zona de segurana.
Consulta o estado de um sensor.
Pressiona o boto de alarme em caso de emergncia.
Ativa/desativa o sistema de segurana.

Considerando-se a situao em que o proprietrio do imvel usa o painel de controle, o caso de


uso bsico para ativao do sistema o seguinte:13
1. O proprietrio observa o painel de controle do CasaSegura (Figure 5.1) para determinar se o sistema
est pronto para entrada. Se o sistema no estiver pronto, ser mostrada uma mensagem no disponvel no display LCD e o proprietrio ter de fechar manualmente as janelas ou portas para que a
mensagem no disponvel desaparea. [Uma mensagem no disponvel implica que um sensor est
aberto; isto , que uma porta ou janela est aberta.]
2. O proprietrio usa o teclado numrico para introduzir uma senha de quatro dgitos. A senha comparada com a senha vlida armazenada no sistema. Se estiver incorreta, o painel de controle emitir
um bipe uma vez e se autorreiniciar na espera de entrada adicional. Se a senha estiver correta, o
painel de controle aguarda por novas aes.
3. O proprietrio seleciona e digita em casa ou fora de casa (veja a Figura 5.1) para ativar o sistema.
Em casa ativa apenas sensores perifricos (os sensores para deteco de movimento interno so
desativados). Fora de casa ativa todos os sensores.
4. Quando ocorre a ativao, uma luz de alarme vermelha pode ser observada pelo proprietrio.

AVISO
Os casos de uso so
normalmente escritos
de forma informal.
Entretanto, use o
modelo aqui mostrado
para garantir que
voc tratou todas as
questes-chave.

O caso de uso bsico apresenta uma histria detalhada que descreve a interao entre o ator
e o sistema.
Em muitas ocasies, os casos de uso so mais elaborados para dar um nvel de detalhes
consideravelmente maior sobre a interao. Por exemplo, Cockburn [Coc01b] sugere o seguinte
modelo para descries detalhadas de casos de uso:
Caso de uso:

IniciarMonitoramento

Ator primrio:

Proprietrio.

Meta do contexto:

Ativar o sistema para monitoramento dos sensores quando o


proprietrio deixa a casa ou nela permanece.

Figura 5.1
Painel de controle
do CasaSegura

CASASEGURA

alarme
verificao
incndio

fora de
desligado casa em casa
fora de casa
em casa
instantneo
bypass
no disponvel

armado

fora

mximo teste
4

3
bypass
6

instantneo cdigo campainha


7

disponvel
*

boto
de alarme

13 Note que esse caso de uso difere da situao em que o sistema acessado via Internet. Nessa situao, a interao ocorre
atravs do painel de controle e no da interface grfica do usurio (GUI) fornecida quando utilizado um PC.

140

PARte 2 Modelagem

Precondies:

O sistema foi programado para uma senha e para reconhecer


vrios sensores.

Disparador:

O proprietrio decide acionar o sistema, isto , ativar as funes


de alarme.

Cenrio:
1. Proprietrio: observa o painel de controle
2. Proprietrio: introduz a senha
3. Proprietrio: seleciona em casa ou fora de casa
4. Proprietrio: observa a luz de alarme vermelha para indicar que o CasaSegura foi armado

Excees:
1. O painel de controle encontra-se no estado no disponvel: o proprietrio verifica todos os sensores
para determinar quais esto abertos; fechando-os.
2. A senha incorreta (o painel de controle emite um bipe): o proprietrio introduz novamente a senha,
desta vez correta.
3. Senha no reconhecida: o subsistema de monitoramento e resposta deve ser contatado para reprogramar a senha.
4. selecionado em casa: o painel de controle emite dois bipes e uma luz de em casa acesa; os sensores perifricos so ativados.
5. selecionado fora de casa: o painel de controle emite trs bipes e uma luz fora de casa acesa;
todos os sensores so ativados.
Prioridade:

Essencial, deve ser implementada

Quando disponvel:

Primeiro incremento

Frequncia de uso:

Vrias vezes por dia

Canal com o ator:

Via interface do painel de controle

Atores secundrios:

Tcnico de suporte, sensores

Canais com os atores secundrios:

Tcnico de suporte: linha telefnica

Sensores: interfaces hardwired e de radiofrequncia

Questes em aberto:
1. Existiria um modo de ativar o sistema sem o uso de uma senha ou com uma senha abreviada?
2. Deveria o painel de controle exibir outras mensagens de texto?
3. Quanto tempo o proprietrio tem para introduzir a senha a partir do instante em que a primeira
tecla pressionada?
4. Existe alguma maneira de desativar o sistema antes de ser realmente ativado?

Casos de uso para outras interaes do proprietrio seriam desenvolvidos de maneira


similar. importante revisar cada caso com cuidado. Se algum elemento da interao for ambguo, provvel que uma reviso do caso de uso ir indicar um problema.

C asa S egura
Desenvolvimento de um diagrama
de caso de uso detalhado
Cena: Sala de reunies, na qual prossegue
a reunio para levantamento de necessidades.
Atores: Jamie Lazar, membro da equipe de software; Vinod
Raman, membro da equipe de software; Ed Robbins, membro da

equipe de software; Doug Miller, gerente da engenharia de software; trs membros do Depto. de Marketing; um representante
da Engenharia de Produto e um facilitador.
Conversa:
Facilitador: Investimos um tempo razovel falando sobre a funcionalidade de segurana domiciliar do CasaSegura. Durante o
intervalo esbocei um diagrama de caso de uso para sintetizar

141

captulo 5 eNGeNHarIa De reqUIsItos

os cenrios importantes que fazem parte desta funo. Deem


uma olhada.
(Todos os participantes observam a Figura 5.2.)
Jamie: Estou apenas comeando a aprender a notao UML.14
Portanto, a funo de segurana domiciliar representada pelo
retngulo grande com as elipses em seu interior? E as elipses
representam os casos de uso que redigimos?

Facilitador: Permisso no o problema. O ponto comunicar a informao. Eu vejo o uso de uma figura de boneco para
representar um dispositivo enganoso. Portanto, adaptei um pouco as coisas. No acho que isso ir criar problemas.
Vinod: OK, temos narrativas de casos de uso para cada uma
das elipses. Precisamos desenvolver narrativas baseadas nos
modelos detalhados sobre os quais li a respeito?

Facilitador: Certo. E as figuras de bonecos representam atores


as pessoas ou coisas que interagem com o sistema conforme
descrito pelo caso de uso... Oh, eu uso o quadrado legendado
para representar um ator que no uma pessoa... Neste caso,
sensores.

Facilitador: Provavelmente, mas isso pode esperar at que tenhamos considerado outras funes do CasaSegura.

Doug: Isso permitido na UML?

Facilitador: Ah ? Diga-me o que deixamos passar.

Representante do Depto. de Marketing: Espere um pouco. Fiquei observando este diagrama e de repente me dei conta
de que deixamos passar algo.
(A reunio continua.)

Figura 5.2
Arma/
desarma
sistema

diagrama de caso
de uso em uml para
a funo de segurana
domiciliar do casaSegura
Proprietrio

Acessa o
sistema
via Internet

Sensores

Responde
ao evento
de alarme

Administrador
do sistema

Encontra
uma condio
de erro
Reconfigura
os sensores e
caractersticas
relacionadas
ao sistema

FERRAMENTAS DO SOFTWARE
Desenvolvimento de caso de uso
Objetivo: Auxiliar no desenvolvimento de casos
de uso atravs de modelos e mecanismos automatizados para avaliar a clareza e a consistncia.
Mecnica: A mecnica das ferramentas varia. Em geral, as
ferramentas de caso de uso fornecem modelos em que se pode
preencher os espaos em branco para criar casos de uso efetivos. A maior parte da funcionalidade de caso de uso est embutida em um conjunto de funes de engenharia de requisitos
mais abrangentes.

Ferramentas representativas:15
A grande maioria das ferramentas de modelagem de anlise
baseadas em UML oferece recursos de texto como grficos
para o desenvolvimento e a modelagem de casos de uso.
Objects by Design
(www.objectsbydesign.com/tools/umltools_byCom
pany.html) oferece um grande nmero de links para ferramentas desse tipo.

1415

14 Um breve tutorial sobre a UML apresentado no Apndice 1 para aqueles que no esto familiarizados com sua notao.
15 As ferramentas aqui apresentadas no significam um aval, mas sim, uma amostra de ferramentas nessa categoria. Na maioria
dos casos, seus nomes so marcas registradas pelos respectivos desenvolvedores.

142

PARte 2 Modelagem

5.5

Construo

d o m o d e l o d e a n l i s e 16

O intuito do modelo de anlise fornecer uma descrio dos domnios de informao, funcional e comportamental necessrios para um sistema baseado em computadores. O modelo
se modifica dinamicamente medida que voc aprende mais sobre o sistema a ser construdo
e outros interessados adquirem um melhor entendimento sobre aquilo que eles realmente querem. Por essa razo, o modelo de anlise uma reproduo das necessidades em determinado
momento. Voc deve esperar que ele sofra mudanas.
medida que o modelo de requisitos evolui, certos elementos se tornaro relativamente
estveis, fornecendo uma slida base para as tarefas posteriores do projeto. Entretanto, outros
elementos do modelo podem ser mais volteis, indicando que os interessados ainda no tm
um entendimento completo das necessidades para o sistema. O modelo de anlise e os mtodos
usados para constru-lo so apresentados em detalhe nos Captulos 6 e 7. Apresento uma breve
viso geral nas sees a seguir.

5.5.1 Elementos do modelo de anlise


H vrias maneiras de examinar os requisitos para um sistema baseado em computador. Alguns profissionais de software argumentam que melhor selecionar um modo de representao
(por exemplo, o caso de uso) e aplic-lo em detrimento de todos os demais. Outros profissionais
acreditam que vale a pena usar uma srie de modos de representao para representar o modelo
de requisitos. Modos de representao diferentes nos foram a considerar as necessidades de
diferentes pontos de vista uma abordagem com maior probabilidade de revelar omisses,
inconsistncias e ambiguidades.
Os elementos especficos do modelo de anlise so ditados pelo mtodo de modelagem de
anlise (Captulos 6 e 7) que ser usado. Entretanto, um conjunto de elementos genricos comum maioria dos modelos de anlise.
AVISO
sempre uma boa
ideia fazer com que
os interessados se
envolvam. Uma das
melhores formas
para tal pedir a
cada interessado que
escreva casos de uso
que descrevam como o
software ser utilizado.

AVISO
Uma maneira de isolar
classes procurar
substantivos descritivos
em um texto de
caso de uso. Pelo
menos alguns dos
substantivos sero
candidatos a classes.
Mais sobre isso no
Captulo 8.

Elementos baseados em cenrios. O sistema descrito sob o ponto de vista do usurio


usando uma abordagem baseada em cenrios. Por exemplo, casos de uso bsicos (Seo 5.4)
e seus diagramas de casos de uso correspondentes (Figura 5.2) evolui para casos de uso mais
elaborados baseados em modelos. Elementos do modelo de requisitos baseado em cenrios so
em geral a primeira parte do modelo a ser desenvolvida. Como tal, servem como entrada para
a criao de outros elementos de modelagem. A Figura 5.3 mostra um diagrama17 de atividades
em UML para o levantamento de requisitos e os representa utilizando casos de uso. So mostrados trs nveis da elaborao, culminando em uma representao baseada em cenrios.
Elementos baseados em classes. Cada cenrio de uso implica um conjunto de objetos
manipulados medida que um ator interage com o sistema. Esses objetos so categorizados em
classes um conjunto de coisas que possuem atributos similares e comportamentos comuns.
Por exemplo, um diagrama de classes UML pode ser utilizado para representar uma classe Sensor para a funo de segurana do CasaSegura (Figura 5.4). Note que o diagrama enumera os
atributos dos sensores (por exemplo, nome, tipo) e as operaes (por exemplo, identificar, habilitar) que podem ser aplicadas para modificar tais atributos. Alm dos diagramas de classes,
outros elementos de modelagem de anlise descrevem o modo pelo qual as classes colaboram
entre si e os relacionamentos e interaes entre as classes. Estes so discutidos de forma mais
detalhada no Captulo 7.
Elementos comportamentais. O comportamento de um sistema baseado em computadores pode ter um efeito profundo sobre o projeto escolhido e a abordagem de implementao

16 Ao longo deste livro, uso os termos modelo de anlise e modelo de requisito como sinnimos. Ambos se referem s representaes dos domnios de informao, funcional e comportamental que descrevem as necessidades dos problemas.
17 Um breve tutorial sobre a UML apresentado no Apndice 1 para aqueles que no esto familiarizados com sua notao.

143

captulo 5 Engenharia de Requisitos

Figura 5.3
Diagramas de atividades
UML para levantamento
de requisitos

Realizar
reunies
Fazer listas de
funes, classes
Fazer listas de
restries etc.

Extrair os requisitos

Priorizao formal?
Sim
Usar o QFD
para priorizar
necessidades

No
Priorizar
necessidades
informalmente

Criar casos
de uso

Um estado
um modo de
comportamento
externamente
observvel. Estmulos
externos provocam
transies entre
estados.

Definir
os atores
Desenhar
diagrama
de caso de uso

Escrever o
cenrio
Completar o
modelo completo

aplicada. Portanto, o modelo de anlise deve fornecer elementos de modelagem que descrevem
comportamento.
O diagrama de estados um mtodo para representar o comportamento de um sistema
atravs da representao de seus estados e dos eventos que fazem com que o sistema mude
de estado. Estado qualquer modo de comportamento externamente observvel. Alm disso, o
diagrama de estados indica aes (por exemplo, ativao de processos) tomadas em decorrncia
de determinado evento.
Para ilustrar o uso de um diagrama de estados, considere o software embutido no painel de
controle do CasaSegura responsvel pela leitura das entradas feitas pelos usurios. A Figura 5.5
mostra um diagrama de estados UML simplificado.
Alm das representaes comportamentais do sistema como um todo, o comportamento de
classes individuais tambm pode ser modelado. Uma discusso mais aprofundada de modelagem comportamental apresentada no Captulo 7.
Elementos orientados a fluxos. Informaes so transformadas medida que fluem atravs
de um sistema baseado em computador. O sistema aceita entrada em uma variedade de formas,
aplica funes para transform-las e gera sada tambm em uma variedade de formas. A entrada
pode ser um sinal de controle transmitido por um transdutor, uma srie de nmeros digitados por
um operador, um pacote de informaes transmitido em um link de rede ou um arquivo de dados
volumoso recuperado de armazenamento secundrio. A(s) transformao(es) pode(m) compreender desde uma nica comparao lgica, um algoritmo numrico complexo at uma abordagem
por inferncia de regras de um sistema especialista. A sada poderia acender um nico LED ou
gerar um relatrio de 200 pginas. Na realidade, podemos criar um modelo de fluxos para qualquer sistema baseado em computadores, indiferentemente de seu tamanho e complexidade. Uma
discusso mais detalhada da modelagem de fluxos apresentada no Captulo 7.

144

PARte 2 Modelagem

Figura 5.4

Sensor

Diagrama de classes
para Sensor

Nome
Tipo
Local
rea
Caractersticas
Identificar()
Habilitar()
Desabilitar()
Reconfigurar()

Figura 5.5
Reading
commands

Notao de um
diagrama de
estados UML

System status = "Ready"


Display msg = "enter cmd"
Display status = steady
Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input

Nome do estado
Variveis de estado

Atividades de estado

C asa S egura
Modelagem comportamental inicial
Cena: Sala de reunies, na qual prossegue
a primeira reunio para levantamento de requisitos.
Atores: Jamie Lazar, membro da equipe de software; Vinod
Raman, membro da equipe de software; Ed Robbins, membro da
equipe de software; Doug Miller, gerente da engenharia de software; trs membros do Depto. de Marketing; um representante
da Engenharia de Produto e um facilitador.

(O facilitador explica os fundamentos da modelagem comportamental equipe de levantamento de requisitos.)


Representante do Depto. de Marketing: Isso me parece um
tanto tcnico. No estou certo se serei de alguma ajuda aqui.
Facilitador: Certamente que voc pode ajudar. Que comportamento voc observa do ponto de vista de usurio?
Representante do Depto. de Marketing: Bem, o sistema
estar monitorando os sensores. Lendo comandos do proprietrio. Mostrando seu estado.

Conversa:

Facilitador: Viu, voc pode faz-lo.

Facilitador: Estamos prestes a finalizar nossa discusso sobre


a funcionalidade segurana domiciliar do CasaSegura. Antes
de faz-lo, gostaria de discutir o comportamento da funo.

Jamie: Ele tambm ir indagar o PC para determinar se h


qualquer entrada dele proveniente, por exemplo, acesso baseado em Internet ou informaes de configurao.

Representante do Depto. de Marketing: No entendi o


que voc quis dizer com comportamento.

Vinod: Sim, de fato, configurar o sistema um estado em si.

Ed (sorrindo): Trata-se de dar ao produto um tempo de espera caso ele se comporte mal.

Pensemos um pouco mais... Existe uma maneira de colocar esta


coisa em um diagrama?

Facilitador: No exatamente. Permita-me explicar.

Facilitador: Existe, mas adiemos para logo depois da reunio.

Doug: Pessoal, vocs esto enrolando.

captulo 5 Engenharia de Requisitos

145

5.5.2Padres de anlise
Qualquer um que tenha feito engenharia de requisitos em mais do que uns poucos projetos
de software comea a perceber a recorrncia de certos problemas ao longo de todos os projetos
em um campo de aplicao especfico.18 Tais padres de anlise [Fow97] sugerem solues (por
exemplo, uma classe, funo ou comportamento) no campo de aplicao que pode ser reutilizado na modelagem de muitas aplicaes.
Geyer-Schulz e Hahsler [Gey01] sugerem dois benefcios que podem estar associados ao uso
de padres de anlise:
Primeiro, os padres de anlise aceleram o desenvolvimento de modelos de anlise abstratos que capturam os principais requisitos do problema concreto, fornecendo modelos de anlise reutilizveis com
exemplos, bem como uma descrio de vantagens e limitaes. Em segundo lugar, os padres de anlise facilitam a transformao do modelo de anlise em um modelo de projeto, sugerindo padres de
projeto e solues confiveis para problemas comuns.

Os padres de anlise so integrados ao modelo de anlise por meio de referncia ao nome


do padro. Eles tambm so armazenados em um repositrio de modo que os engenheiros de
requisitos podem usar recursos de busca para encontr-los e aplic-los. Informaes sobre um
padro de anlise (e outros tipos de padres) so apresentadas em um modelo padro [Gey01]19
discutido de maneira mais detalhada no Captulo 12. Exemplos de padres de anlise e uma
discusso mais ampla deste tpico so apresentados no Captulo 7.

5.6
Compromisso
a arte de dividir
um bolo de tal
forma que cada
um acredite que
ficou com o pedao
maior.
Ludwig Erhard
WebRef
Um breve artigo sobre
negociao para requisitos de software pode
ser baixado de www.
alexanderegyed.
com/publications/
Software_Require
ments_Negotiation
Some_Lessons_
Learned.html.

Negociao

de

Requisitos

Em um contexto de engenharia de requisitos ideal, as tarefas de incio, levantamento e elaborao determinam os requisitos do cliente com detalhes suficientes para prosseguir para atividades de engenharia de software subsequentes. Infelizmente, isso raramente acontece. Na
realidade, talvez voc tenha de iniciar uma negociao com um ou mais interessados. Na maioria dos casos, solicita-se aos interessados contrabalanar funcionalidade, desempenho e outras
caractersticas do produto ou sistema, em funo do custo e tempo para chegar ao mercado. O
intuito da negociao desenvolver um plano de projeto que atenda s necessidades dos interessados e, ao mesmo tempo, reflita as restries do mundo real (por exemplo, tempo, pessoal,
oramento) impostas equipe de software.
As melhores negociaes buscam ao mximo um resultado ganha-ganha.20 Ou seja, os
interessados ganham obtendo um sistema ou produto que satisfaz a maioria de suas necessidades e voc (como membro da equipe de software) ganha trabalhando com prazos de entrega
e oramentos reais e atingveis.
Boehm [Boe98] define um conjunto de atividades de negociao no incio de cada iterao
do processo de software. Mais do que uma simples atividade de comunicao com o cliente, so
definidas as seguintes atividades:
1. Identificao dos principais interessados no sistema ou subsistema.
2. Determinao das condies de ganho dos interessados.
3. Negociao das condies de ganho dos interessados para reconcili-las em um conjunto de
condies ganha-ganha para todos os envolvidos (inclusive a equipe de software).
O xito na concretizao dessas etapas atinge um resultado em que todos saem ganhando,
critrio-chave para prosseguir para atividades de engenharia de software subsequentes.
18 Em alguns casos, essa recorrncia de problemas acontece independentemente do campo de aplicao. Por exemplo, as caractersticas e funes usadas para resolver problemas de interfaces do usurio so comuns independentemente do campo de
aplicao considerado.
19 Uma grande variedade de modelos de padres foi proposta na literatura. Caso tenha interesse, consulte [Fow97], [Gam95],
[Yac03] e [Bus07] entre as muitas fontes.
20 Foram escritos dezenas de livros sobre habilidades de negociao (por exemplo, [Lew06], [Rai06], [Fis06]). uma das mais
importantes habilidades que voc pode aprender. Leia um deles.

146

paRtE 2

MoDeLaGeM

INfORMAES

A arte da negociao
Aprender a negociar eficazmente pode ser bem til
para toda a sua vida tcnica e pessoal. Vale muito
considerar as seguintes diretrizes:

vvel que voc tome conhecimento de algo que ir ajud-lo


a negociar melhor sua posio.
4. Concentrar-se nos interesses da outra parte. No assuma
posies rgidas caso queira evitar conitos.

1. Reconhecer que no se trata de uma competio. Para ser


bem-sucedido, ambas as partes tm de ter a sensao de
que ganharam ou atingiram algum objetivo. Ambas tero
de ceder.

5. No deixar a negociao ir para o lado pessoal. Concentre-se no problema que precisa ser resolvido.
6. Ser criativo. No tenha medo de inovar caso se encontre
em um impasse.

2. Planejar uma estratgia. Decidir o que voc quer atingir; o


que a outra parte quer atingir e como voc ir fazer para
que ambas aconteam.

7. Estar preparado para se comprometer. Uma vez que se tenha chegado a um acordo, seja objetivo; comprometa-se e
v adiante.

3. Ouvir ativamente. No trabalhe na formulao de sua resposta enquanto a outra parte estiver falando. Oua-a. pro-

C asa s egura
O incio de uma negociao
Cena: Sala da Lisa Perez, aps a primeira
reunio para levantamento de requisitos.
Atores: Doug Miller, gerente de engenharia de software e Lisa
Perez, gerente de marketing.
Conversa:
Lisa: Bem, ouvi dizer que a primeira reunio transcorreu muito
bem.
Doug: Na verdade, foi assim mesmo. Voc mandou bons representantes do seu departamento para a reunio... Eles realmente
contriburam.
Lisa (sorrindo): , na verdade eles me contaram que se engajaram no processo e que no foi uma atividade de torrar os
miolos.
Doug (rindo): Tomarei cuidado para me despojar do jargo
tcnico na prxima vez que eu visitar... Veja, Lisa, acho que
vamos ter problemas para entregar toda a funcionalidade para
o sistema de segurana domiciliar nas datas que sua gerncia
est propondo. Eu sei, prematuro, porm j andei fazendo um
planejamento preliminar e...
Lisa (franzindo a testa): Temos de ter isso at aquela data,
Doug. De que funcionalidade voc est falando?

5 .7

validao

dos

Doug: Presumo que consigamos ter a funcionalidade de segurana domiciliar completa at a data-limite, mas teremos de postergar o acesso via Internet para a segunda verso.
Lisa: Doug, o acesso via Internet que d todo o charme ao
CasaSegura. Vamos criar toda a campanha de marketing em
torno disso. Temos de ter esse acesso!
Doug: Entendo sua situao, realmente. O problema que,
para lhes dar o acesso via Internet, teremos de construir e ter
funcionando um site totalmente seguro. Isso demanda tempo e
pessoal. Tambm teremos de agregar um monte de outras funes na primeira verso... No acredito que possamos fazer
isso com os recursos que temos no momento.
Lisa (ainda franzindo a testa): Entendo, mas temos de descobrir uma maneira de ter tudo isso pronto. crtico para as funes de segurana domiciliar e para outras funes tambm...
Estas ltimas podero esperar at a prxima verso... Concordo
com isso.
Lisa e Doug parecem ter chegado a um impasse, mas eles
tm de negociar uma soluo para o problema. Poderiam os
dois ganhar neste caso? Fazendo o papel de mediador, o que
voc sugeriria?

requisitos

medida que cada elemento do modelo de requisitos criado, examinado em termos de


inconsistncia, omisses e ambiguidade. Os requisitos representados pelo modelo so priorizados pelos interessados e agrupados em pacotes de requisitos que sero implementados como
incrementos de software. Uma reviso do modelo de requisitos trata as seguintes questes:
revisar os
? Aorequisitos,

que perguntas
devo fazer?

Cada um dos requisitos consistente com os objetivos globais para o sistema/produto?


Todos os requisitos foram especificados no nvel de abstrao apropriado? Ou seja, algum dos requisitos fornece um nvel de detalhe tcnico inapropriado no atual estgio?

147

captulo 5 Engenharia de Requisitos

O requisito realmente necessrio ou representa um recurso adicional que talvez no


seja essencial para o objetivo do sistema?
Cada um dos requisitos limitado e sem ambiguidade?
Cada um dos requisitos possui atribuio? Ou seja, uma fonte (em geral, um indivduo
especfico) indicada para cada requisito?
Algum dos requisitos conflita com outros requisitos?
Cada um dos requisitos atingvel no ambiente tcnico que ir abrigar o sistema ou
produto?
Cada um dos requisitos pode ser testado, uma vez implementado?
O modelo de requisitos reflete, de forma apropriada, a informao, funo e comportamento do sistema a ser construdo?
O modelo de requisitos foi dividido para expor progressivamente informaes mais
detalhadas sobre o sistema?
Os padres de requisitos foram utilizados para simplificar o modelo de requisitos? Todos
os padres foram validados adequadamente? Todos os padres so consistentes com os
requisitos do cliente?
Essas e outras perguntas devem ser feitas e respondidas para garantir que o modelo de requisitos reflita de maneira precisa as necessidades do interessado e fornea uma base slida para
o projeto.

5 .8

Resumo
As tarefas da engenharia de requisitos so conduzidas para estabelecer uma base slida para
o projeto e a construo. A engenharia de requisitos ocorre durante as atividades de comunicao
com o cliente e de modelagem que so definidas para o processo genrico de software. So conduzidas sete funes distintas de engenharia de requisitos concepo, levantamento, elaborao, negociao, especificao, validao e gesto pelos membros da equipe de software.
Na concepo do projeto, os interessados estabelecem os requisitos bsicos do problema,
definem restries de projeto primordiais e tratam as principais caractersticas e funes que
tm de estar presentes para que o sistema atenda seus objetivos. Essas informaes so refinadas e expandidas durante o levantamento uma atividade de levantamento de requisitos
que faz uso de reunies com a participao de um facilitador, do QFD e do desenvolvimento de
cenrios de uso.
A elaborao expande ainda mais as necessidades em um modelo um conjunto de elementos comportamentais, orientados a fluxos e baseados em cenrios e classes. O modelo
pode fazer referncia a padres de anlise, solues para problemas de anlise recorrentes em
diferentes aplicaes.
medida que os requisitos so identificados e o modelo de anlise criado, a equipe de software e outros interessados no projeto negociam a prioridade, disponibilidade e custo relativo
de cada requisito. O intuito dessa negociao desenvolver um plano de projeto realista. Alm
disso, cada requisito e o modelo de anlise como um todo validado em relao s necessidades do cliente para garantir que ser construdo o sistema correto.

Problemas

Pontos

Ponderar

5.1. Por que um nmero muito grande de desenvolvedores de software no dedica muita ateno engenharia de requisitos? Existiria alguma circunstncia em que poderamos
deix-la de lado?
5.2. Foi lhe dada a responsabilidade de extrair os requisitos de um cliente que lhe diz que
est muito ocupado para poder atend-lo. O que voc deveria fazer?

148

PARte 2 Modelagem

5.3. Discuta alguns dos problemas que ocorrem quando os requisitos tm de ser obtidos de
trs ou quatro clientes diferentes.
5.4. Por que dizemos que o modelo de anlise representa uma reproduo de um sistema em
determinado momento?
5.5. Suponhamos que voc tenha convencido o cliente (voc um excelente vendedor) a
concordar com todas as suas exigncias como desenvolvedor. Isso o torna um mestre da
negociao? Por qu?
5.6. Desenvolva pelo menos trs perguntas livres de contexto que voc faria a um interessado durante a atividade de concepo.
5.7. Desenvolva um kit de levantamento de requisitos. O kit deve incluir um conjunto de
diretrizes para realizar uma reunio para levantamento de requisitos e materiais que podem
ser utilizados para facilitar a criao de listas e quaisquer outros itens que poderiam ajudar
na definio dos requisitos.
5.8. Seu professor ir dividir a classe em grupos de quatro a seis alunos. Metade do grupo ir
desempenhar o papel do departamento de marketing e a outra far o papel da engenharia de
software. Sua tarefa definir os requisitos para a funo de segurana do CasaSegura descrita neste captulo. Realize uma reunio para levantamento de requisitos usando as diretrizes
apresentadas neste captulo.
5.9. Desenvolva um caso de uso completo para uma das atividades a seguir:
a. Fazer um saque em um caixa eletrnico.
b. Usar seu carto de dbito para uma refeio em um restaurante.
c. Comprar aes usando uma conta de corretagem on-line.
d. Procurar livros (sobre um assunto especfico) usando uma livraria on-line.
e. Uma atividade especificada pelo seu professor.
5.10. O que representam as excees nos casos de uso?
5.11. Descreva o que um padro de anlise com suas prprias palavras.
5.12. Usando o modelo apresentado na Seo 5.5.2, sugira um ou mais padres de anlise
para os seguintes campos de aplicao:
a. Software contbil
b. Software de e-mail
c. Navegadores para a Internet
d. Software de processamento de texto
e. Software para criao de sites
f. Um campo de aplicao especificado pelo seu professor
5.13. Qual o significado de ganha-ganha no contexto das negociaes durante uma atividade de engenharia de requisitos?
5.14. O que voc acha que acontece quando uma validao de requisitos revela um erro?
Quem ser envolvido na correo do erro?

Leituras

Fontes

de

I n f o r m a o C o m p l e m e n ta r e s

Pelo fato de ser crucial para o sucesso na criao de qualquer sistema complexo baseado
em computadores, a engenharia de requisitos discutida em uma ampla gama de livros. Hood
e seus colegas (Requirements Management, Springer, 2007) discutem uma srie de questes
da engenharia de requisitos que abrangem tanto sistemas quanto a engenharia de software.
Young (The Requirements Engineering Handbook, Artech House Publishers, 2007) apresenta
uma discusso aprofundada das tarefas da engenharia de requisitos. Wiegers (More About
Software Requirements, Microsoft Press, 2006) aborda vrias tcnicas prticas para o gerenciamento e o levantamento de requisitos. Hull e seus colegas (Requirements Engineering,

captulo 5 Engenharia de Requisitos

149

2. ed., Springer-Verlag, 2004), Bray (An Introduction to Requirements Engineering, Addison-Wesley, 2002), Arlow (Requirements Engineering, Addison-Wesley, 2001), Gilb (Requirements
Engineering, Addison-Wesley, 2000), Graham (Requirements Engineering and Rapid Development, Addison-Wesley, 1999) e Sommerville e Kotonya (Requirements Engineering: Processes
and Techniques, Wiley, 1998) so apenas alguns exemplos dos muitos livros dedicados ao
assunto. Gottesdiener (Requirements by Collaboration: Workshops for Defining Requirements,
Addison-Wesley, 2002) fornece teis orientaes para aqueles que precisam estabelecer um
ambiente colaborativo com seus interessados em termos de levantamento de requisitos.
Lauesen (Software Requirements: Styles and Techniques, Addison-Wesley, 2002) traz uma
abrangente pesquisa sobre notao e mtodos de anlise para levantamento de requisitos.
Weigers (Software Requirements, Microsoft Press, 1999) e Leffingwell e seus colegas (Managing
Software Requirements: A Use Case Approach, 2. ed., Addison-Wesley, 2003) apresentam um
til conjunto das melhores prticas para levantamento de requisitos e sugerem diretrizes
pragmticas para a maioria dos aspectos do processo da engenharia de requisitos.
Uma viso da engenharia de requisitos baseada em padres descrita por Withall (Software Requirement Patterns, Microsoft Press, 2007). Ploesch (Assertions, Scenarios and Prototypes, Springer-Verlag, 2003) discute tcnicas avanadas para desenvolvimento de requisitos
de software. Windle e Abreo (Software Requirements Using the Unified Process, Prentice-Hall,
2002) discutem a engenharia de requisitos no contexto do Processo Unificado e da notao
da UML. Alexander e Steven (Writing Better Requirements, Addison-Wesley, 2002) fornecem
um breve conjunto de diretrizes para redao clara dos requisitos, representando-as como
cenrios e revisando o resultado final.
A modelagem de casos de uso muitas vezes o motor para a criao de todos os demais aspectos do modelo de anlise. O assunto debatido exaustivamente por Rosenberg
e Stephens (Use Case Driven Object Modeling with UML: Theory and Practice, Apress, 2007).
Denny (Succeeding with Use Cases: Working Smart to Deliver Quality, Addison-Wesley, 2005),
Alexander e Maiden (eds.) (Scenarios, Stories, Use Cases: Through the Systems Development
Life-Cycle, Wiley, 2004), Leffingwell e seus colegas (Managing Software Requirements: A
Use Case Approach, 2. ed., Addison-Wesley, 2003) apresentam um proveitoso conjunto das
melhores prticas para levantamento de requisitos. Bittner e Spence (Use Case Modeling,
Addison-Wesley, 2002), Cockburn [Coc01], Armour e Miller (Advanced Use Case Modeling:
Software Sistemas, Addison-Wesley, 2000) e Kulak e seus colegas (Use Cases: Requirements
in Context, Addison-Wesley, 2000) abordam o levantamento de requisitos com nfase na
modelagem de casos de uso.
Uma ampla gama de fontes de informao sobre anlise e engenharia de requisitos se encontra disposio na Internet. Uma lista atualizada de referncias na Web, relevantes para
a anlise e engenharia de requisitos, pode ser encontrada no site www.mhhe.com/engcs/
compsci/pressman/professional/olc/ser.htm.

captulo

Conceitos- Chave
anlise de domnio . 153
anlise sinttica . . . 166
associaes . . . . . . 176
casos de uso . . . . . 157
classes de anlise . . 166
diagrama de
atividades . . . . . . . 161
diagrama de raias . 162
modelagem baseada
em cenrios . . . . . . 155
modelagem baseada
em classes . . . . . . . 166
modelagem de
requisitos . . . . . . . 154
modelagem CRC . . . . 171
modelagem e
dados . . . . . . . 163
modelos UML . . 161
pacotes de
anlise . . . . . . 178

Modelagem de Requisitos:
C enrios, Informaes e
C lasses de Anlise

o nvel tcnico, a engenharia de software comea com uma srie de tarefas de modelagem que levam a especificao dos requisitos e representao do projeto para
o software a ser construdo. O modelo de requisitos1 na verdade, um conjunto
de modelos a primeira representao tcnica de um sistema.
Em um livro seminal sobre mtodos de modelagem de requisitos, Tom DeMarco [DeM79]
descreve o processo da seguinte maneira:
Revendo reconhecidos problemas e falhas anteriores da fase de anlise, sugiro que precisamos
realizar os seguintes acrscimos ao nosso conjunto de metas. Os produtos da anlise devem apresentar grande facilidade em sua manuteno. Isso se aplica particularmente ao Documento-Alvo
[especificao de requisitos de software]. Problemas de tamanho devem ser tratados por meio de
mtodo efetivo de fracionamento. A especificao escrita como se fossem romances vitorianos
est acabada. Elementos grficos tm de ser usados sempre que possvel. Temos de diferenciar as
consideraes lgicas [essenciais] das fsicas [implementao]... No mnimo, precisamos... Algo
que nos ajude a subdividir nossos requisitos e documentar essa subdiviso antes da especificao... Alguns meios de acompanhar e avaliar interfaces... Novas ferramentas para descrever lgica
e poltica, algo melhor do que um texto narrativo.

Embora DeMarco tenha escrito sobre os atributos da modelagem de anlise h mais de


um quarto de sculo, seus comentrios ainda se aplicam a mtodos e notao da modelagem de requisitos moderna.

O que ? A palavra escrita um mara-

Panorama vilhoso veculo para a comunicao,

porm, no necessariamente a melhor


maneira de representar os requisitos de
um software. A modelagem de requisitos usa uma
combinao das formas textual e diagramtica
para representar os requisitos de maneira relativamente fcil de entender e, mais importante ainda,
simples, para fazer a reviso em termos de correo, completude e consistncia.
Quem realiza? Um engenheiro de software (s
vezes chamado de analista) constri o modelo
usando os requisitos extrados do cliente.
Por que importante? Para validar os requisitos
do software, preciso examin-los segundo uma
srie de pontos de vista. Neste captulo consideraremos a modelagem de requisitos sob trs perspectivas: modelos baseados em cenrios, modelos
de dados (informaes) e modelos baseados em
classes. Cada uma deles representa os requisitos em uma dimenso diferente, aumentando,
portanto, a probabilidade de serem encontrados
erros, inconsistncias virem tona e omisses
serem reveladas.

150

Quais so as etapas envolvidas? A modelagem


baseada em cenrios representa o sistema sob o
ponto de vista do usurio. A modelagem de dados
representa o espao de informaes e os objetos
de dados que o software ir manipular e os relacionamentos entre eles. A modelagem baseada em
classes define objetos, atributos e relacionamentos.
Assim que os modelos preliminares forem criados,
eles so refinados e analisados para avaliar sua
clareza, completude e consistncia. No Captulo
7, estendemos as dimenses da modelagem aqui
citadas com representaes adicionais, fornecendo
uma viso mais robusta dos requisitos.
Qual o artefato? Uma ampla gama de formas
textuais e diagramticas podem ser escolhidas
para o modelo de requisitos. Cada uma das representaes d uma viso de um ou mais dos
elementos de modelo.
Como garantir que o trabalho foi realizado corretamente? Os artefatos da modelagem de requisitos tm de ser revisados em termos de correo, completude e consistncia. Devem refletir as necessidades
de todos os interessados e estabelecer uma base a
partir da qual o projeto pode ser conduzido.

Em edies anteriores deste livro, usei o termo modelo de anlise, em vez de modelo de requisitos. Nesta edio, decidi usar ambos os termos para representar a atividade de modelagem que define vrios aspectos do problema a ser
resolvido. Anlise a ao que ocorre medida que requisitos so obtidos.

captulo 6 MODELAgem DE REQUISITOS: CENRIOS, INFORMAES E CLASSES DE ANLISE

6 .1

Qualquer
viso individual
de requisitos
insuficiente
para entender
ou descrever o
comportamento
desejado de um
sistema complexo.
Alan M. Davis

O modelo de anlise
e a especificao de
requisitos fornecem
um meio para avaliar
a qualidade assim
que o software for
construdo.

nalise

de

Requisitos

A anlise de requisitos resulta na especificao de caractersticas operacionais do software,


indica a interface do software com outros elementos do sistema e estabelece restries que o
software deve atender. Permite ainda que voc (independentemente de ser chamado de engenheiro de software, analista ou modelador) elabore mais as necessidades bsicas estabelecidas
durante as tarefas de concepo, levantamento e negociao, que so parte da engenharia de
requisitos (Captulo 5).
A ao da modelagem de requisitos resulta em um ou mais dos seguintes tipos de modelos:
Modelos baseados em cenrios de requisitos do ponto de vista de vrios atores do
sistema.
Modelos de dados que representam o domnio de informaes para o problema.
Modelos orientados a classes que representam classes orientadas a objetos (atributos e
operaes) e a maneira por meio da qual as classes colaboram para atender aos requisitos do sistema.
Modelos orientados a fluxos que representam os elementos funcionais do sistema e como
eles transformam os dados medida que percorrem o sistema.
Modelos comportamentais que representam como o software se comporta em consequncia de eventos externos.
Tais modelos do a um projetista de software informaes que podem ser traduzidas em
projetos de arquitetura, de interfaces e de componentes. Finalmente, o modelo de requisitos (e
a especificao de requisitos de software) fornecem ao desenvolvedor e ao cliente os meios para
verificar a qualidade to logo o software seja construdo.
Neste captulo, nos concentraremos na modelagem baseada em cenrios uma tcnica
que est se tornando cada vez mais popular na comunidade da engenharia de software; na
modelagem de dados tcnica mais especializada que particularmente apropriada quando
uma aplicao tenha de criar ou manipular um espao de informaes complexo; e a modelagem de classes uma representao de classes orientadas a objetos e as colaboraes resultantes que permitem que um sistema funcione. Os modelos orientados a fluxos, os modelos
comportamentais, a modelagem baseada em padres e os modelos WebApp so discutidos no
Captulo 7.

Figura 6.1
O modelo de
requisitos
como uma
ponte entre
a descrio
do sistema
e o modelo
de projeto

151

Descrio
do sistema
Modelo
de anlise
Modelo
de projeto

152

Requisito no
sinnimo de
arquitetura.
Requisito no
sinnimo de
projeto nem
de interface do
usurio. Requisito
sinnimo de
necessidade.
Andrew Hunt e
David Thomas

O modelo de anlise
deve descrever o que
o cliente quer, deve
estabelecer uma base
para o projeto, bem
como definir uma
meta para validao.

PARTE 2 MODELAGEM

6.1.1 Filosofia e objetivos gerais


Na modelagem de requisitos, nosso foco primrio no que e no no como. Que interao
com o usurio ocorre em dada circunstncia, quais objetos o sistema manipula, que funes o
sistema deve executar, quais comportamentos o sistema apresenta, que interfaces so definidas
e quais restries se aplicam?2
Em captulos anteriores, citamos que a especificao de requisitos completa talvez no seja
possvel neste estgio. O cliente pode estar inseguro daquilo que precisamente necessrio para
certos aspectos do sistema. O desenvolvedor pode estar incerto de que determinada abordagem
ir cumprir apropriadamente as funes e o desempenho esperados. Essas realidades atenuam
a favor de uma abordagem iterativa para a anlise e modelagem de requisitos. O analista deve
modelar aquilo que conhecido e usar o modelo como base para o projeto do incremento de
software.3
O modelo de requisitos deve alcanar trs objetivos primrios: (1) descrever o que o cliente solicita, (2) estabelecer uma base para a criao de um projeto de software e (3) definir um
conjunto de requisitos que possa ser validado assim que o software for construdo. O modelo
de anlise preenche a lacuna entre uma descrio sistmica que descreve o sistema como um
todo ou a funcionalidade de negcio que atingida aplicando-se software, hardware, dados,
pessoal e outros elementos de sistema e um projeto de software (Captulos 8 a 13) que descreve
a arquitetura, a interface do usurio e a estrutura em termos de componentes do software. Essa
relao ilustrada na Figura 6.1.
importante notar que todos os elementos do modelo de requisitos esto diretamente associados a partes do modelo do projeto. Nem sempre possvel estabelecer uma clara diviso das tarefas
de anlise e de projeto entre essas duas importantes atividades de modelagem. Algum projeto ocorre
invariavelmente como parte da anlise e alguma anlise ser realizada durante o projeto.

6.1.2 Regras prticas para a anlise


Arlow e Neustadt [Arl02] sugerem uma srie de regras prticas que devem ser seguidas ao se
criar o modelo de anlise:

? Existem
diretrizes

O modelo deve enfocar as necessidades visveis no domnio do problema ou do negcio. O


nvel de abstrao deve ser relativamente elevado. No se perca nos detalhes [Arl02] que
tentam explicar como o sistema ir funcionar.
Cada elemento do modelo de requisitos deve contribuir para o entendimento geral dos
requisitos de software e fornecer uma viso do domnio de informao, funo e comportamento do sistema.
Postergue consideraes de infraestrutura e outros modelos no funcionais at a fase de
projeto. Ou seja, talvez seja preciso um banco de dados, porm as classes necessrias
para sua implementao, as funes necessrias para acessar o banco de dados e o comportamento que ser apresentado medida que ele for usado devem ser considerados
apenas depois da anlise do domnio do problema ter sido completada.
Minimize o acoplamento do sistema. importante representar os relacionamentos entre
as classes e funes. Entretanto, se o nvel de interconexo for extremamente alto,
deve-se esforar para reduzi-lo.
Certifique-se de que o modelo de requisitos agrega valor a todos os interessados. Cada participante tem um uso prprio para o modelo. Por exemplo, os interessados no negcio devem
usar o modelo para validar os requisitos; os projetistas devem usar o modelo como base para o projeto; o pessoal da Garantia da Qualidade (QA) deve usar o modelo para ajudar no
planejamento de testes de aceitao.

bsicas que
podem nos
ajudar enquanto
realizamos
atividades
de anlise de
requisitos?

Problemas que
valem a pena
ser atacados
demonstram seu
valor contra-atacando.
Piet Hein
2
3

Deve-se notar que medida que os clientes se tornam tecnologicamente mais sofisticados, h uma tendncia no sentido da
especificao do como e tambm do qu. Entretanto, o foco principal deve permanecer no qu.
Como alternativa, a equipe de software poderia optar por criar um prottipo (Captulo 2) em uma tentativa de entender melhor
as necessidades do sistema.

captulo 6 MODELAgem DE REQUISITOS: CENRIOS, INFORMAES E CLASSES DE ANLISE

153

Mantenha o modelo o mais simples possvel. No crie diagramas adicionais quando


no acrescentam nenhuma informao nova. No utilize formas de notao complexas,
quando uma lista simples j bastaria.
WebRef
Vrios recursos teis
para a anlise de
domnio podem ser
encontrados em
www.iturls.com/
English/Software
Engineering/
SE_mod5.asp.

A anlise de domnio
no examina uma
aplicao especfica,
mas sim o domnio
em que a aplicao
reside. O intuito
identificar elementos
comuns para resoluo
de problemas que
sejam aplicveis a
todas as aplicaes no
domnio.

6.1.3Anlise de domnio
Na discusso da engenharia de requisitos (Captulo 5), destaquei que frequentemente ocorre
a recorrncia de padres de anlise em muitas aplicaes em um domnio de aplicao especfico. Se esses padres so definidos e categorizados de maneira que permita seu reconhecimento
e sua aplicao para resolver problemas comuns, a criao do modelo de anlise deve ser acelerada. Mais importante ainda, a probabilidade de aplicao de padres de projeto e de componentes de software executveis cresce dramaticamente. Isso melhora o tempo de colocao do
produto no mercado e reduz custos de desenvolvimento.
Mas como os padres e as classes de anlise so inicialmente reconhecidos? Quem os define,
os classifica e os prepara para uso em projetos subsequentes? As respostas a essas questes caem
na anlise de domnio. Firesmith [Fir93] descreve anlise de domnio da seguinte maneira:
Anlise de domnio de um software a identificao, a anlise e a especificao de requisitos comuns de
um campo de aplicao especfico, tipicamente para reutilizao em vrios projetos dentro deste campo de aplicao... [Anlise de domnio orientada a objetos ] a identificao, anlise e especificao de
capacidades comuns reutilizveis dentro de um campo de aplicao especfico, em termos de objetos,
classes, componentes e frameworks comuns.

O domnio de aplicao especfico pode ir da avinica a sistemas bancrios, de videogames


multimdia a software embutido em equipamentos mdicos. O objeto da anlise de domnio
simples: encontrar ou criar aquelas classes de anlise e/ou padres de anlise largamente aplicveis de modo que possam ser reutilizados.4
Usando a terminologia introduzida anteriormente neste livro, a anlise de domnio pode ser
vista como uma atividade universal para o processo de software. Queremos dizer com isso que
a anlise de domnio uma atividade contnua da engenharia de software que no est ligada a
nenhum projeto de software especfico. De certo modo, o papel de um analista de domnio similar ao papel de um mestre-ferramenteiro em um ambiente de manufatura pesada. O trabalho
do mestre-ferramenteiro projetar e construir ferramentas que possam ser usadas por muitas
pessoas que fazem trabalhos semelhantes, mas no necessariamente iguais. O papel da anlise
de domnio5 descobrir e definir padres de anlise, classes de anlise e informaes relacionadas que possam ser usados por vrias pessoas que trabalham em aplicaes similares, mas
no necessariamente as mesmas.
A Figura 6.2 [Ara89] ilustra entradas e sadas fundamentais para o processo de anlise de domnio. So consultadas fontes de conhecimento de domnio para identificar objetos que possam
ser reutilizados no domnio.

Figura 6.2
Entrada e sada
da anlise de
domnio

Literatura tcnica

Taxonomias de classes

Aplicaes existentes
Fontes de
conhecimento
de domnio

Levantamento dos clientes


Consultoria
Requisitos atuais/futuros

Anlise de
domnio

Padres de reutilizao
Modelos funcionais
Linguagens de domnio

Modelo de
anlise
de domnio

Uma viso complementar da anlise de domnio envolve a modelagem do domnio de forma que os engenheiros de software
e outros interessados possam entender melhor sobre ela... Nem todas as classes de domnio resultam necessariamente no
desenvolvimento de classes reutilizveis... [Let03a].
No parta do pressuposto que pelo fato de um analista de domnio estar envolvido no trabalho, um engenheiro de software
no precise entender o domnio de aplicao. Todos os membros da equipe de software precisam ter algum conhecimento do
domnio em que o software ser inserido.

154

PARTE 2 MODELAGEM

C asa S egura
Anlise de domnio
Cena: Sala do Doug Miller, aps uma reunio com o pessoal de marketing.
Atores: Doug Miller, gerente de engenharia de software e
Vinod Raman, membro da equipe de engenharia de software.
Conversa:
Doug: Preciso de voc para um projeto especial, Vinod. Vou
ter de tir-lo das reunies para levantamento de requisitos.
Vinod (franzindo a testa): Que pena. Aquele formato funciona realmente... Eu estava conseguindo extrair algo dessas
reunies. O que acontece?
Doug: Jamie e Ed te substituiro. De qualquer forma, o Marketing insiste que liberemos a capacidade de acesso Internet
com a funo de segurana domiciliar na primeira verso do
CasaSegura. Estamos com a corda no pescoo nesta... No
temos tempo ou gente suficiente; portanto, temos de resolver
ambos os problemas a interface PC e a interface Web de
uma s vez.
Vinod (parecendo confuso): No sabia que o plano havia
sido estabelecido... Ns ainda nem terminamos de fazer o levantamento de requisitos.
Doug (com um sorriso amarelo): Eu sei, mas os prazos
so to apertados que decidi comear a traar uma estratgia
com o Marketing agora mesmo... De qualquer maneira, revisaremos qualquer plano provisrio assim que tivermos todas as
informaes obtidas nas reunies de necessidades.
Vinod: OK, o que acontece? O que voc quer que eu faa?
Doug: Voc sabe o que anlise de domnio?

anlise
frustrante, cheia
de complexos
relacionamentos
interpessoais,
indefinida e difcil.
Resumindo:
fascinante. Uma
vez fisgado por
ela, os antigos e
fceis prazeres
da construo de
um sistema jamais
sero suficientes
para satisfaz-lo
novamente.
Tom DeMarco

Vinod: Mais ou menos. Primeiramente, devo procurar padres


similares nas aplicaes que fazem os mesmos tipos de coisas
do que a que estou construindo. Se possvel, voc rouba ento os padres e os reutiliza em seu trabalho.
Doug: No estou certo da palavra roubar, mas basicamente
voc entendeu a questo. O que eu gostaria que voc fizesse
que comeasse a pesquisar interfaces do usurio existentes
de sistemas que controlam algo como o CasaSegura. Quero que
voc proponha um conjunto de padres e classes de anlise
que possam ser comuns tanto para a interface baseada em
PCs que ficaro instalados nos domiclios quanto a interface baseada em navegadores que pode ser acessada via
Internet.
Vinod: Podemos poupar tempo fazendo com que eles sejam
os mesmos... Por que no fazemos simplesmente isso?
Doug: Ah... bom ter pessoas que pensem como voc. Esse
o ponto podemos poupar tempo e esforo se ambas as
interfaces forem praticamente idnticas, implementadas com o
mesmo cdigo, bl, bl, bl, que o Marketing tanto insiste.
Vinod: Ento, voc quer o qu? Classes, padres de anlise,
padres de projeto?
Doug: Todos eles. Nada formal neste momento. Quero apenas
ter alguma vantagem inicial em nossa anlise interna e trabalho de projeto.
Vinod: Pesquisarei nossa biblioteca de classes e verei o que
conseguimos. Tambm usarei um modelo de padres que vi em
um livro alguns meses atrs.
Doug: Muito bom. Mos obra!

6.1.4Abordagens modelagem de requisitos


Uma viso da modelagem de requisitos, chamada anlise estruturada, considera os dados e
os processos que transformam os dados em entidades separadas. Os objetos de dados so modelados de maneira que definam seus atributos e relacionamentos. Processos que manipulam
objetos de dados so modelados de maneira que mostrem como transformam dados medida
que os objetos de dados trafegam pelo sistema.
Uma segunda abordagem modelagem de anlise, denominada anlise orientada a objetos,
se concentra na definio de classes e na maneira pela qual colaboram entre si para atender s
necessidades dos clientes. A UML e o Processo Unificado (Captulo 2) so predominantemente
orientados a objetos.
Embora o modelo de anlise de requisitos proposto neste livro combine ambas as abordagens, as equipes de software em geral optam por uma abordagem e excluem todas as representaes da outra. A questo no qual a melhor, mas sim, que combinao de representaes
dar aos interessados o melhor modelo de requisitos de software e a ponte mais efetiva com o
projeto de software.
Cada elemento do modelo de requisitos (Figura 6.3) apresenta o problema segundo um
ponto de vista. Os elementos baseados em cenrios representam como o usurio interage
com o sistema e a sequncia especfica de atividades que ocorre medida que o software

captulo 6 MODELAgem DE REQUISITOS: CENRIOS, INFORMAES E CLASSES DE ANLISE

155

Figura 6.3
Elementos do
modelo de
anlise

Modelos baseados
em cenrios
por exemplo,
casos de uso
histrias de usurios

? Quais
pontos de

vista diferentes
podem ser usados
para descrever
o modelo de
requisitos?

Por que devemos


construir modelos?
Por que no
construir apenas o
sistema? A resposta
que podemos
construir modelos
para destacar, ou
enfatizar, certas
caractersticas crticas
de um sistema
e, ao mesmo
tempo, diminuir
a importncia de
outros aspectos do
sistema.
Ed Yourdon

6 .2

[Casos de uso]
so apenas uma
ferramenta para
definir o que existe
fora do sistema
(atores) e o que
deve ser realizado
pelo sistema (casos
de uso).
Ivar Jacobson

Modelos de
classes
por exemplo,
diagramas de classes
diagramas de colaborao

Requisitos
de software

Modelos
comportamentais
por exemplo,
diagramas de estados
diagramas de sequncia

Modelos
de fluxo
por exemplo,
DFDs
modelos de dados

utilizado. Os elementos baseados em classes modelam os objetos que o sistema ir manipular,


as operaes que sero aplicadas aos objetos para efetuar a manipulao, os relacionamentos
(alguns hierrquicos) entre os objetos e as colaboraes que ocorrem entre as classes definidas. Os elementos comportamentais representam como eventos externos mudam o estado do
sistema ou as classes que nele residem. Por fim, elementos orientados a fluxos representam o
sistema como uma transformao de informaes, indicando como os objetos de dados so
transformados medida que fluem pelas vrias funes do sistema.
A modelagem de anlise leva obteno de cada um desses elementos. Entretanto, o contedo especfico de cada elemento (os diagramas usados para construir o elemento e o modelo)
pode diferir de projeto para projeto. Como j citado vrias vezes neste livro, a equipe de software
tem de se esforar para mant-lo o mais simples possvel. Devem ser utilizados apenas aqueles
elementos da modelagem que agregam valor ao modelo.

Modelagem Ba seada

em

Cenrios

Embora o sucesso de um sistema ou produto baseado em computadores seja medido de


muitas formas, a satisfao do usurio encontra-se no topo da lista. Se voc entender como os
usurios finais (e outros atores) querem interagir com um sistema, sua equipe de software estar mais capacitada a caracterizar, de maneira apropriada, os requisitos e a construir modelos
de anlise e projeto proveitosos.
Portanto, a modelagem de requisitos com UML6 comea com a criao de cenrios na forma
de casos de uso, diagramas de atividades e diagramas de raias.

6.2.1Criao de um caso de uso preliminar


Alistair Cockburn caracteriza um caso de uso como um contrato de comportamento
[Coc01b]. Conforme discutido no Captulo 5, o contrato define a maneira atravs da qual um
ator7 usa um sistema baseado em computadores para atingir alguma meta. Em essncia, um
caso de uso captura as interaes que ocorrem entre produtores e consumidores de informao
6
7

A UML ser usada como notao para modelagem ao longo deste livro. O Apndice 1 apresenta um breve tutorial para aqueles
que talvez no estejam familiarizados com a notao bsica da UML.
Ator no uma pessoa especfica, mas sim um papel que uma pessoa (ou dispositivo) desempenha em um contexto especfico.
Um ator invoca o sistema para que este realize um de seus servios [Coc01b].

156

PARTE 2 MODELAGEM

AVISO
Em algumas
situaes, os casos
de uso se tornam o
mecanismo dominante
de engenharia de
requisitos. Entretanto,
isso no significa que
devamos descartar
outros mtodos de
modelagem quando
forem apropriados.

e o sistema em si. Nesta seo, examinaremos como os casos de uso so desenvolvidos como
parte da atividade da modelagem de requisitos.8
No Captulo 5, citei que um caso de uso descreve um cenrio de uso especfico em uma
linguagem simples sob o ponto de vista de um ator definido. Mas como saber: (1) sobre o que
escrever, (2) quanto escrever a seu respeito, (3) com que nvel de detalhamento fazer uma descrio e (4) como organizar a descrio? Essas so as questes que devem ser respondidas nas
situaes em que os casos de uso devam fornecer valor como uma ferramenta da modelagem
de requisitos.
Sobre o que escrever? As duas primeiras tarefas da engenharia de requisitos concepo
e levantamento nos fornecem informaes necessrias para comearmos a escrever casos de
uso. As reunies para levantamento de requisitos, o QFD e outros mecanismos de engenharia de
requisitos so utilizados para identificar interessados, definir o escopo do problema, especificar
as metas operacionais globais, estabelecer as prioridades, descrever todos os requisitos funcionais conhecidos e descrever os itens (objetos) manipulados pelo sistema.
Para comear a desenvolver um conjunto de casos de uso, enumere as funes ou atividades
realizadas por um ator especfico. Podemos obt-las de uma lista de funes dos requisitos do

C asa S egura
Desenvolvimento de outro cenrio
preliminar de usurio
Cena: Uma sala de reunies, durante a segunda reunio para levantamento de requisitos.
Atores: Jamie Lazar, membro da equipe de software; Ed Robbins, membro da equipe de software; Doug Miller, gerente da
engenharia de software; trs membros do Depto. de Marketing;
um representante da Engenharia de Produto e um facilitador.
Conversa:

Meredith: Ok, ento basicamente h duas partes para a funo de vigilncia... A primeira configura o sistema inclusive desenhando uma planta precisamos de ferramentas para ajudar
o proprietrio do imvel a fazer isto e a segunda parte
a prpria funo de vigilncia real. Como o layout faz parte
da atividade de configurao, irei me concentrar na funo de
vigilncia.
Facilitador (sorrindo): Voc tirou as palavras de minha
boca.

ltima vez, no mesmo?

Meredith: Eu quero ter acesso funo de vigilncia via PC


ou via Internet. Meu sentimento que o acesso via Internet seria
mais utilizado. De qualquer maneira, quero poder exibir vises
de cmeras em um PC e controlar o deslocamento e ampliao
de imagens de determinada cmera. Especifico a cmera selecionando-a da planta da casa. Quero, de forma seletiva, gravar
imagens geradas por cmeras e reproduzi-las. Tambm quero
ser capaz de bloquear o acesso a uma ou mais cmeras com
uma senha especfica. Tambm quero a opo de ver pequenas
janelas que mostrem vises de todas as cmeras e ento poder
escolher uma que deseje ampliar.

Facilitador: Correto... Da mesma forma.

Jamie: Estas so chamadas de vises em miniatura.

Meredith: Bem, obviamente a razo para a vigilncia permitir ao proprietrio do imvel verificar a casa enquanto ele se
encontra fora, gravar e reproduzir imagens de vdeo que so
capturadas... Esse tipo de coisa.

Meredith: OK, ento eu quero vises em miniatura de todas


as cmeras. Tambm quero que a interface para a funo de
vigilncia tenha o mesmo aspecto de todas as demais do CasaSegura. Quero que ela seja intuitiva, significando que no vou
precisar ler todo o manual para us-la.

Facilitador: hora de comearmos a falar sobre a funo de


vigilncia do CasaSegura. Vamos desenvolver um cenrio de
usurio para acesso funo de vigilncia.
Jamie: Quem desempenha o papel do ator nisto?
Facilitador: Acredito que a Meredith (uma pessoa do Marketing) venha trabalhando nessa funcionalidade. Por que voc no
desempenha o papel?
Meredith: Voc quer fazer da mesma forma que fizemos da

Ed: Usaremos compresso para armazenamento de vdeo?


Facilitador: Boa pergunta, Ed, mas vamos postergar essas
questes de implementao por enquanto. Meredith?

Facilitador: Bom trabalho. Agora, vamos nos aprofundar um


pouco mais nesta funo...

Os casos de uso so uma parte importante da modelagem de anlise para as interfaces do usurio. A anlise de interfaces
discutida em detalhes no Captulo 11.

captulo 6 MODELAgem DE REQUISITOS: CENRIOS, INFORMAES E CLASSES DE ANLISE

157

sistema, por meio de conversaes com interessados ou atravs de uma avaliao de diagramas
de atividades (Seo 6.3.1) desenvolvidas como parte da modelagem de anlise.
A funo de vigilncia domiciliar do CasaSegura (subsistema) discutida no quadro anterior
identifica as seguintes funes (uma lista resumida) realizadas pelo ator proprietrio:






Selecionar cmera a ser vista.


Solicitar imagens em miniatura de todas as cmeras.
Exibir imagens das cmeras em uma janela de um PC.
Controlar deslocamento e ampliao de uma cmera especfica.
Gravar, de forma seletiva, imagens geradas pelas cmeras.
Reproduzir as imagens geradas pelas cmeras.
Acessar a vigilncia por cmeras via Internet.

medida que as conversaes com o interessado (que desempenha o papel de proprietrio


de um imvel) forem avanando, a equipe de levantamento de requisitos desenvolve casos de
uso para cada uma das funes citadas. Em geral, os casos de uso so escritos primeiro de
forma narrativa informal. Caso seja necessria maior formalidade, o mesmo caso de uso reescrito usando um formato estruturado similar quele proposto no Captulo 5 e reproduzido mais
adiante, nesta seo, na forma de um quadro.
Para fins de ilustrao, consideremos a funo acessar a vigilncia por cmeras via Internet
exibir vises das cmeras (AVC-EVC). O interessado que faz o papel do ator proprietrio escreveria a seguinte narrativa:
Caso de uso: Acessar vigilncia por cmeras via Internet exibir vises das cmeras
(AVC-EVC)
Ator: proprietrio
Se eu estiver em um local distante, posso usar qualquer PC com navegador apropriado para entrar no
site Produtos da CasaSegura. Introduzo meu ID de usurio e dois nveis de senhas e, depois de validado,
tenho acesso a toda funcionalidade para o meu sistema CasaSegura instalado. Para acessar a viso de
cmera especfica, seleciono vigilncia dos botes para as principais funes mostradas. Em seguida,
seleciono escolha uma cmera, e a planta da casa mostrada. Depois, seleciono a cmera em que
estou interessado. Como alternativa, posso ver, simultaneamente, imagens em miniatura de todas as
cmeras selecionando todas as cmeras como opo de visualizao. Depois de escolher uma cmera, seleciono visualizao, e uma visualizao com um quadro por segundo aparece em uma janela
de visualizao identificada pelo ID de cmera. Se quiser trocar de cmeras, seleciono escolha uma
cmera, e a janela de visualizao original desaparece e a planta da casa mostrada novamente. Em
seguida, seleciono a cmera em que estou interessado. Surge uma nova janela de visualizao.

Uma variao de um caso de uso narrativo apresenta a interao na forma de uma sequncia
ordenada de aes de usurio. Cada ao representada como uma sentena declarativa. Voltando funo AVC-EVC, poderamos escrever:
Os casos de
uso podem ser
utilizados em
vrios processos
[de software].
Nosso processo
favorito o
iterativo e dirigido
por riscos.
Geri Schneider e
Jason Winters

Caso de uso: Acessar vigilncia por cmeras via Internet exibir vises das cmeras
(AVC-EVC)
Ator: proprietrio
1. O proprietrio do imvel faz o login no site Produtos da CasaSegura.
2. O proprietrio do imvel introduz seu ID de usurio.
3. O proprietrio do imvel introduz duas senhas (cada uma com pelo menos oito caracteres).
4. O sistema mostra os botes de todas as principais funes.
5. O proprietrio do imvel seleciona a vigilncia por meio dos botes das funes principais.
6. O proprietrio do imvel seleciona escolher uma cmera.
7. O sistema mostra a planta da casa.
8. O proprietrio do imvel seleciona um cone de cmera da planta da casa.

158

PARTE 2 MODELAGEM

9. O proprietrio do imvel seleciona o boto visualizao.


10. O sistema mostra uma janela de visualizao identificada pelo ID de cmera.
11. O sistema mostra imagens de vdeo na janela de visualizao a uma velocidade de um quadro por
segundo.

importante notar que essa apresentao sequencial no leva em considerao quaisquer


interaes alternativas (a narrativa flui de forma mais natural e representa um nmero pequeno
de alternativas). Casos de uso desse tipo so algumas vezes conhecidos como cenrios primrios [Sch98a].

6.2.2 Refinamento de um caso de uso preliminar


A descrio de interaes alternativas essencial para um completo entendimento da funo
a ser descrita por um caso de uso. Consequentemente, cada etapa no cenrio primrio avaliado fazendo-se as seguintes perguntas [Sch98a]:

? Como

O ator pode fazer algo diferente neste ponto?


Existe a possibilidade de o ator encontrar alguma condio de erro neste ponto? Em caso
positivo, qual seria ela?
Existe a possibilidade de o ator encontrar algum outro tipo de comportamento neste ponto
(por exemplo, comportamento que acionado por algum evento fora do controle do ator)?
Em caso positivo, qual seria ele?

examinar
sequncias de
aes alternativas
ao desenvolver
um caso de uso?

Respostas a essas perguntas resultam na criao de um conjunto de cenrios secundrios


que fazem parte do caso de uso original, mas representam comportamento alternativo. Consideremos, por exemplo, as etapas 6 e 7 do cenrio primrio apresentado anteriormente:
6. O proprietrio do imvel seleciona escolher uma cmera.
7. O sistema mostra a planta da casa.

Poderia o ator assumir outra atitude neste ponto? A resposta sim. Referindo-se narrativa
que flui naturalmente, o ator poderia optar por ver, simultaneamente, imagens em miniatura de
todas as cmeras. Portanto, um cenrio secundrio poderia ser Visualizar imagens em miniatura para todas as cmeras.
Existe a possibilidade de o ator encontrar alguma condio de erro neste ponto? Qualquer nmero de condies de erro pode ocorrer enquanto um sistema baseado em computadores opera.
Nesse contexto, consideramos condies de erro apenas aquelas que provavelmente so resultado direto para realizar a ao nas etapas 6 ou 7. Enfatizando, a resposta pergunta sim.
Uma planta com cones de cmera talvez jamais tenha sido configurada. Portanto, selecionando
escolher uma cmera resulta em condio de erro: No h nenhuma planta configurada para
este imvel.9 Essa condio de erro se torna um cenrio secundrio.
Existe a possibilidade de o ator encontrar algum outro tipo de comportamento neste ponto?
Mais uma vez a resposta sim. Enquanto as etapas 6 e 7 ocorrem, o sistema pode encontrar
uma condio de alarme. Isso resultaria no sistema exibir uma notificao de alerta especial
(tipo, local, ao do sistema) e dar ao ator uma srie de opes relevantes natureza do alerta.
Pelo fato de o cenrio secundrio poder ocorrer a qualquer momento para praticamente todas
as interaes, ele no far parte do caso de uso AVC-EVC. Em vez disso, seria desenvolvido um
caso de uso distinto Condio de alarme encontrada e referido de outros casos de uso
conforme a necessidade.
Cada uma das situaes descritas nos pargrafos anteriores caracterizada como uma exceo do caso de uso. Uma exceo descreve uma situao (seja ela uma condio de falha, seja
9

Nesse caso, outro ator, o administrador do sistema, teria de configurar a planta da casa, instalar e inicializar (por exemplo,
atribuir um ID de equipamento) todas as cmeras e testar cada uma delas para ter certeza de que ele se encontra acessvel
atravs do sistema e atravs da planta da casa.

captulo 6 MODELAgem DE REQUISITOS: CENRIOS, INFORMAES E CLASSES DE ANLISE

159

uma alternativa escolhida pelo ator) que faz com que o sistema exiba um comportamento um
tanto diferente.
Cockburn [Coc01b] recomenda o uso de uma sesso de brainstorming para obter um conjunto de excees relativamente completo para cada caso de uso. Alm das trs perguntas genricas
sugeridas anteriormente nesta seo, as seguintes questes tambm deveriam ser exploradas:
Existem casos em que ocorre alguma funo de validao durante este caso de uso? Isso
implica que a funo de validao chamada e poderia ocorrer uma condio de erro
potencial.
Existem casos em que uma funo de suporte (ou ator) parar de responder apropriadamente? Por exemplo, uma ao de usurio aguarda uma resposta, porm a funo que
deve responder entra em condio de time-out.
Existe a possibilidade de um fraco desempenho do sistema resultar em aes do usurio
inesperadas ou imprprias? Por exemplo, uma interface baseada na Web responde de
forma muito lenta, fazendo com que um usurio selecione um boto de processamento
vrias vezes seguidas. Essas selees entram em fila de forma inapropriada e, por fim,
geram condio de erro.
A lista de extenses desenvolvidas como consequncia das perguntas e respostas deve ser
racionalizada [Co01b] por meio dos seguintes critrios: deve ser indicada uma exceo no
caso de uso se o software for capaz de detectar a condio descrita e, em seguida, tratar a condio assim que esta for detectada. Em alguns casos, uma exceo ir precipitar o desenvolvimento de um outro caso de uso (para tratar da condio percebida).

6.2.3Criao de um caso de uso formal

WebRef
Quando termina a
atividade de criao
de casos de uso?
Para uma proveitosa
discusso sobre este
tpico, veja ootips.
org/usecases
done.html.

Os casos de uso informais apresentados na Seo 6.2.1 so, algumas vezes, suficientes para
a modelagem de requisitos. Entretanto, quando um caso de uso envolve uma atividade crtica
ou descreve um conjunto complexo de etapas com um nmero significativo de excees, uma
abordagem mais formal talvez seja mais desejvel.
O caso de uso AVC-EVC mostrado no quadro segue uma descrio geral tpica para casos
de uso formais. O objetivo no contexto identifica o escopo geral do caso de uso. A precondio
descreve aquilo que conhecido como verdadeiro antes de o caso de uso ser iniciado. O disparador identifica o evento ou a condio que faz com que o caso de uso seja iniciado [Coc01b].
O cenrio enumera as aes especficas que o ator deve tomar e as respostas apropriadas do
sistema. As excees identificam as situaes reveladas medida que o caso de uso preliminar
refinado (Seo 6.2.2). Cabealhos adicionais podero ou no ser acrescentados e so relativamente autoexplicativos.
Em muitos casos, no h nenhuma necessidade de criar uma representao grfica de um
cenrio de uso. Entretanto, a representao diagramtica pode facilitar a compreenso, particularmente quando o cenrio complexo. Conforme j citado anteriormente neste livro, a UML
oferece recursos de diagramao de casos de uso. A Figura 6.4 representa um diagrama de caso
de uso preliminar para o produto CasaSegura. Cada caso de uso representado por uma elipse.
Nesta seo foi discutido apenas o caso de uso AVC-EVC.
Toda notao de modelagem tem suas limitaes, e o caso de uso no uma exceo. Assim
como qualquer outra forma de descrio escrita, a qualidade de um caso de uso depende de
seu(s) autor(es). Se a descrio no for clara, o caso de uso pode ser enganoso ou ambguo.
Um caso de uso que se concentra nos requisitos funcionais e comportamentais geralmente
inapropriado para requisitos no funcionais. Para situaes em que o modelo de anlise deve
ter muitos detalhes e preciso (por exemplo, sistemas com segurana crtica), um caso de uso
talvez no seja suficiente.
Entretanto, a modelagem baseada em cenrios apropriada para a grande maioria de todas as
situaes com as quais voc ir deparar como engenheiro de software. Se desenvolvido apropriadamente, o caso de uso pode gerar grandes benefcios como ferramenta de modelagem.

160

PARTE 2 MODELAGEM

C asa S egura
Modelo de caso de uso para vigilncia

Excees:

Caso de uso: Acessar a vigilncia por cmeras via Internet exibir vises das
cmeras (AVC-EVC)

1. O ID ou senhas so incorretos ou no foram reconhecidos


veja o de uso Validar ID e senhas.

Iterao:

2, ltima modificao: 14 de janeiro feita por V. Raman.

Ator primrio:

Proprietrio do imvel.

Objetivo no contexto: Visualizar imagens de cmera espalhadas pela casa de qualquer


ponto remoto via Internet.
Precondies:

Disparador:

O sistema deve estar totalmente


configurado; devem ser obtidos ID
de usurio e senhas apropriadas.
O proprietrio do imvel decide fazer uma inspeo na casa enquanto se encontra fora.

Cenrio:
1. O proprietrio do imvel faz o login no site Produtos da
CasaSegura.

2. A funo de vigilncia no est configurada para este sistema o sistema mostra a mensagem de erro apropriada;
veja o caso de uso Configurar funo de vigilncia.
3. O proprietrio seleciona Visualizar as imagens em miniatura
para todas as cmeras veja o caso de uso Visualizar
as imagens em miniatura para todas as cmeras.
4. A planta no est disponvel ou no foi configurada exibir a mensagem de erro apropriada e ver o caso de uso
Configurar planta da casa.
5. encontrada uma condio de alarme veja o caso de
uso Condio de alarme encontrada.
Prioridade:

Prioridade moderada, a ser implementada aps as funes bsicas.

Quando disponvel: Terceiro incremento.


Frequncia de uso: Frequncia moderada.

2. O proprietrio introduz seu ID de usurio.

Canal com o ator: Via navegador instalado em PC e conexo Internet.

3. O proprietrio introduz duas senhas (cada uma com pelo


menos oito caracteres).

Atores secundrios: Administrador do sistema, cmeras.


Canais com os atores secundrios:

4. O sistema mostra os botes de todas as principais funes.

1. Administrador do sistema: sistema baseado em PCs.

5. O proprietrio seleciona a vigilncia por meio dos botes


das funes principais.

2. Cmeras: conectividade sem fio.

6. O proprietrio seleciona escolher uma cmera.


7. O sistema mostra a planta da casa.

1. Quais mecanismos protegem o uso no autorizado deste recurso por parte de funcionrios da Produtos da CasaSegura?

8. O proprietrio seleciona um cone de cmera da planta da


casa.

2. A segurana suficiente? Acessar de forma no autorizada este


recurso representaria uma invaso de privacidade importante.

9. O proprietrio seleciona o boto visualizao.

3. A resposta do sistema via Internet seria aceitvel dada a largura de banda requerida para visualizaes de cmeras?

10. O sistema mostra uma janela de visualizao identificada


pelo ID de cmera.
11. O sistema mostra imagens de vdeo na janela de visualizao a uma velocidade de um quadro por segundo.

Questes abertas:

4. Iremos desenvolver um recurso para fornecer vdeo a uma


velocidade de quadros por segundo maior quando as conexes de banda larga estiverem disponveis?

Figura 6.4
CasaSegura

Diagrama de
caso de uso
preliminar
para o sistema
CasaSegura

Acessar a
vigilncia por cmeras
via Internet

Proprietrio

Configurar
parmetros
do sistema
CasaSegura

Acionar alarme

Cmeras

161

captulo 6 MODELAgem DE REQUISITOS: CENRIOS, INFORMAES E CLASSES DE ANLISE

6.3

Modelos Uml

que

C o m p l e m e n ta m

Caso

de

Uso

Existem muitas situaes de modelagem de requisitos em que um modelo baseado em texto


mesmo um simples como o caso de uso talvez no fornea informaes de maneira clara
e concisa. Em tais casos, pode-se optar por uma ampla gama de modelos grficos da UML.

6.3.1Desenvolvimento de um diagrama de atividade

Um diagrama de
atividades UML
representa as aes e
decises que ocorrem
enquanto uma dada
funo executada.

Um diagrama de atividades UML complementa o caso de uso atravs de uma representao


grfica do fluxo de interao em um cenrio especfico. Similar ao fluxograma, um diagrama de
atividades usa retngulos com cantos arredondados para representar determinada funo do
sistema, setas para representar o fluxo atravs do sistema, losangos de deciso para representar
uma deciso com ramificao (cada seta saindo do losango identificada) e as linhas horizontais cheias indicam as atividades paralelas que esto ocorrendo. Um diagrama de atividades
para o caso de uso AVC-EVC mostrado na Figura 6.5. Deve-se notar que o diagrama de atividades acrescenta outros detalhes no mencionados (mas implcitos) pelo caso de uso.
Por exemplo, um usurio poderia tentar introduzir ID de usurio e senha um nmero limitado de vezes. Isso representado pelo losango de deciso abaixo de Prompt para reintroduo
de dados.

Figura 6.5
Diagrama de
atividades
para a funo
Acessar a
vigilncia
por cmeras
via Internet
exibir vises
das cmeras

Introduza senha
e ID de usurio

Senhas/ID vlidos

Senhas/ID invlidos

Selecione a
funo principal

Outras funes
tambm podem
ser selecionadas

Selecione
vigilncia

Vises em miniatura
Selecione cmera
miniaturas especficas

Prompt para
reintroduo de dados

No restam
tentativas de entrada
Selecione uma cmera
especfica

Selecione um
cone de cmera

Ver imagens geradas pela cmera


em uma janela com identificao

Solicite outra viso


Sair desta funo

Ver outra cmera

Restam tentativas
de entrada

162

PARTE 2 MODELAGEM

6.3.2Diagramas de raias
Um diagrama de
raias UML representa
o fluxo de aes e
decises e indica quais
atores realizam cada
uma delas.

Um bom modelo
orienta nossas
ideias, enquanto
um ruim as
distorce.
Brian Marick

O diagrama de raias UML uma til variao do diagrama de atividades e nos permite representar o fluxo de atividades descrito pelo caso de uso e, ao mesmo tempo, indicar qual ator (se
existirem vrios atores envolvidos em determinado caso de uso) ou classe de anlise (discutida
posteriormente neste captulo) tem a responsabilidade pela ao descrita por um retngulo de
atividade. As responsabilidades so representadas como segmentos paralelos que dividem o
diagrama verticalmente, como as raias de uma piscina.
Trs classes de anlise Proprietrio, Cmera e Interface possuem responsabilidades diretas ou indiretas no contexto do diagrama de atividades representado na Figura 6.5.
Referindo-se Figura 6.6, o diagrama de atividades rearranjado de forma que as atividades
associadas a determinada classe de anlise caiam na raia para a referida classe. Por exemplo, a
classe Interface representa a interface do usurio conforme vista pelo proprietrio. O diagrama de atividades indica dois prompts que so a responsabilidade da interface prompt para
reintroduo de dados e prompt para outra viso. Esses prompts e as decises associadas
a eles caem na raia Interface. Entretanto, as setas saem dessa raia e voltam para a raia do
Proprietrio, onde ocorrem as aes do proprietrio do imvel.

Figura 6.6
Diagrama de
raias para a
funo Acessar
a vigilncia
por cmeras
via Internet
exibir vises
das cmeras

Proprietrio

Cmera

Interface

Introduza senha
e ID de usurio
Senhas vlidas
/ID

Outras funes
tambm podem
ser selecionadas

Selecione a funo
principal

Senhas
invlidas/ID
Prompt para
reintroduo de dados
Restam tentativas
de entrada

Selecione vigilncia

No restam
tentativas de entrada
Vises em miniatura
Selecione cmera
miniaturas especficas

Selecione uma
cmera especfica
Selecione um cone
de cmera

Gerar sada
de vdeo
Ver imagens geradas pela
cmera em uma janela
com identificao

Solicite outra viso


Sair desta funo
Ver outra
cmera

captulo 6 MODELAgem DE REQUISITOS: CENRIOS, INFORMAES E CLASSES DE ANLISE

163

Casos de uso, juntamente com os diagramas de atividades e de raias, so orientados a procedimentos. Eles representam a maneira pela qual vrios atores chamam funes especficas (ou
outras etapas procedurais) para atender aos requisitos do sistema. Porm, uma viso procedural
dos requisitos representa apenas uma nica dimenso de um sistema. Na Seo 6.4, examinamos
o espao de informaes e como os requisitos de dados podem ser representados.

6 .4
WebRef
Informaes teis sobre
a modelagem de dados
podem ser encontradas
em www.data
model.org.

Como um
objeto
de dados se
manifesta no
contexto de uma
aplicao?

Objeto de dados
uma representao de
qualquer informao
composta que
processada pelo
software.

Conceitos

de

Modelagem

de

Dados

Se entre os requisitos de software tivermos a necessidade de criar, estender ou interfacear


com um banco de dados ou se as estruturas de dados complexas tiverem de ser construdas e
manipuladas, a equipe de software poder optar por criar um modelo de dados como parte da
modelagem de requisitos. Um analista ou engenheiro de software define todos os objetos de
dados processados no sistema, os relacionamentos entre os objetos de dados e outras informaes pertinentes aos relacionamentos. O diagrama entidade-relacionamento (entity-relationship
diagram) trata das questes e representa todos os objetos de dados introduzidos, armazenados,
transformados e produzidos em uma aplicao.

6.4.1Objetos de dados
Objeto de dados uma representao das informaes compostas que devem ser compreendidas pelo software. Por informao composta, queremos dizer algo que tenha uma srie
de propriedades ou atributos diferentes. Consequentemente, a largura (um nico valor) no seria um objeto de dados vlido, mas dimenses (incorporando altura, largura e profundidade)
poderia ser definido como um objeto.
Um objeto de dados pode ser uma entidade externa (por exemplo, qualquer item que produza ou consuma informaes), uma coisa (por exemplo, um relatrio ou uma exibio), uma
ocorrncia (por exemplo, uma ligao telefnica) ou evento (por exemplo, um alerta), um papel
(por exemplo, vendedor), uma unidade organizacional (por exemplo, departamento de contabilidade), um local (por exemplo, um armazm) ou uma estrutura (por exemplo, um arquivo). Por
exemplo, uma pessoa ou um carro podem ser vistos como objetos de dados no sentido de que
ambos podem ser definidos em termos de um conjunto de atributos. A descrio do objeto de
dados incorpora o objeto de dados e todos os seus atributos.
Um objeto de dados encapsula apenas dados no h nenhuma referncia em um objeto de
dados a operaes que atuam sobre os dados.10 Consequentemente, o objeto de dados pode ser
representado como uma tabela conforme mostrado na Figura 6.7. Os cabealhos da tabela refletem os atributos do objeto. Nesse caso, um carro definido em termos de sua marca, modelo,
nmero do chassi, tipo de carroceria, cor e proprietrio. O corpo da tabela representa
instncias especficas do objeto de dados. Por exemplo, um Chevy Corvette uma instncia do
objeto de dados carro.

6.4.2Atributos de dados

Os atributos do nome
a um objeto de dados,
descrevem suas
caractersticas e, em
alguns casos, fazem
referncia a um outro
objeto.

Os atributos de dados definem as propriedades de um objeto de dados e assumem uma de


trs caractersticas diferentes. Eles podem ser usados para (1) dar um nome a uma instncia do
objeto de dados, (2) descrever a instncia ou (3) fazer referncia a uma outra instncia em outra
tabela. Alm disso, um ou mais dos atributos devem ser definidos como identificador isto ,
o atributo identificador se torna uma chave quando queremos encontrar uma instncia do
objeto de dados. Em alguns casos, os valores para o(s) identificador(es) so exclusivos, embora
no seja uma exigncia. Fazendo referncia ao objeto de dados carro, um identificador razovel
poderia ser o nmero do chassi.

10 Essa distino separa o objeto de dados da classe ou objeto definido como parte da abordagem orientada a objetos (Apndice 2).

164

paRtE 2

MoDeLaGeM

Figura 6.7

Atributos
nominativos

Representao
tabular de
objetos de dados

Associa um objeto de dados a um outro;


neste caso, proprietrio

Identificador

Atributos
descritivos

Atributos
referenciais

Nmero do Tipo de
Marca Modelo chassi
carroceria Cor
Lexus
Instncia Chevy
BMW
Ford

WebRef
Um conceito chamado
normalizao
importante para aqueles
que pretendem realizar
uma modelagem de
dados completa. Uma
til introduo pode ser
encontrada em www .
datamodel .org.

LS400
Corvette
750iL
Taurus

AB123...
X456...
XZ765...
Q12A45...

Sed
Sport
Cup
Sed

Proprietrio

Branco
Vermelho
Branco
Azul

RSP
CCD
LJL
BLF

O conjunto de atributos apropriado para um objeto de dados determinado por meio do


entendimento do contexto do problema. Os atributos para carro poderiam servir bem para uma
aplicao a ser usada por um departamento de veculos a motor, porm tais atributos seriam
de pouca valia para uma empresa do setor automobilstico que precisasse fabricar software de
controle. Neste ltimo caso, os atributos para carro tambm poderiam incluir o nmero do
chassi, o tipo de carroceria e a cor, porm, muitos outros atributos (por exemplo, cdigo
interno, tipo de acionamento do motor, indicador do conjunto de tapearia, tipo de
transmisso) teriam de ser acrescidos para tornar carro um objeto com significado no contexto de controle de manufatura.11

INfORMAES

Objetos de dados e classes orientadas a objetos so eles a mesma coisa?


Uma pergunta que comumente surge quando o
tema objetos de dados: Um objeto de dados a
mesma coisa que uma classe orientada a objetos11? A resposta
no.
O objeto de dados define um dado composto; ou seja,
ele incorpora um conjunto de dados individuais (atributos) e d um nome ao conjunto de itens (o nome do objeto
de dados).

Uma classe orientada a objetos encapsula atributos de dados, mas tambm incorpora as operaes (mtodos) que manipulam os dados decorrentes desses atributos. Alm disso, a
definio de classes implica uma ampla infraestrutura que faz
parte da abordagem de engenharia de software orientada a
objetos. As classes se comunicam entre si via mensagens, podem ser organizadas em hierarquias e fornecem caractersticas
de herana para objetos que so uma instncia de uma classe.

6.4.3 Relacionamentos

Os relacionamentos
indicam a maneira
por meio da qual os
objetos de dados so
interligados entre si.

Os objetos de dados so interligados de vrias formas. Consideremos os dois objetos de


dados, pessoa e carro. Estes podem ser representados usando-se a notao simples ilustrada
na Figura 6.8a. estabelecida uma conexo entre pessoa e carro, pois os dois objetos esto
interrelacionados. Mas quais so os relacionamentos? Para determinarmos a resposta, devemos
entender o papel das pessoas (proprietrios, neste caso) e dos carros no contexto do software a
ser construdo. Podemos estabelecer um conjunto de pares objeto/relacionamento que definem
os relacionamentos relevantes. Por exemplo,
Uma pessoa possui um carro.
Uma pessoa tem seguro para dirigir um carro.

11 Os leitores que no estiverem familiarizados com os conceitos e a terminologia da orientao a objetos devem consultar o
breve tutorial apresentado no Apndice 2.

captulo 6

165

MoDeLaGeM De reqUIsItos: CeNrIos, INforMaes e CLasses De aNLIse

Figura 6.8
Relacionamentos
entre objetos de dados

pessoa

carro

(a) Uma conexo bsica entre objetos de dados


possui
pessoa

tem seguro
para dirigir

carro

(b) Relacionamentos entre objetos de dados

Os relacionamentos possui e tem seguro para dirigir definem as conexes relevantes entre
pessoa e carro. A Figura 6.8b ilustra graficamente esses pares objeto-relacionamento. As setas
indicadas na Figura 6.8b do uma importante informao sobre a direo do relacionamento e,
normalmente, reduzem a ambiguidade ou interpretaes incorretas.121314
INfORMAES

Diagramas entidade-relacionamento
O par objeto-relacionamento a pedra angular do
modelo de dados. Os pares podem ser representados graficamente por meio do diagrama entidaderelacionamento (DEr).12 O DEr foi originalmente proposto por
Peter Chen [Che77] para o projeto de sistemas de bancos de
dados relacionais e foi estendido por outros. Um conjunto de componentes primordiais identificado para o DEr: objetos de
dados, atributos, relacionamentos e indicadores de vrios tipos.
O principal objetivo do DEr representar objetos de dados e
seus relacionamentos.

J foi feita uma introduo rudimentar sobre a notao do


DEr. Os objetos de dados so representados por um retngulo
identificado. Os relacionamentos so indicados com uma linha
rotulada interligando objetos. Em algumas variantes do DEr, a
linha de conexo contm um losango, rotulado com um relacionamento. As conexes entre objetos de dados e relacionamentos
so estabelecidas usando-se uma variedade de smbolos especiais que indicam a cardinalidade e a modalidade.13 Se desejar
maiores informaes sobre modelagem de dados e o diagrama
entidade-relacionamento, consulte [Hob06] ou [Sim05].

FERRAMENTAS DO SOFTWARE
Modelagem de dados
Objetivo: As ferramentas de modelagem de dados do a um engenheiro de software a capacidade de representar objetos de dados, suas caractersticas e
seus relacionamentos. Usado primariamente para aplicaes
de bancos de dados de grande porte e outros projetos de
sistemas de informao, as ferramentas para modelagem de
dados fornecem um meio automatizado para criar diagramas
entidade-relacionamento completos, dicionrios de objetos de
dados e modelos relacionados.
Mecnica: As ferramentas nesta categoria permitem ao usurio descrever objetos de dados e seus relacionamentos. Em alguns casos, as ferramentas usam a notao DEr. Em outros, as
ferramentas modelam relaes por meio de algum outro mecanismo. As ferramentas nesta categoria so em geral usadas
como parte do projeto de um banco de dados e permitem a
criao de um modelo de banco de dados atravs da gerao

de um esquema de banco de dados para sistemas de gerenciamento de bancos de dados comuns (SGBD).
Ferramentas representativas14:
AllFusion ERWin, desenvolvida pela Computer Associates
(www3.ca.com), auxilia no projeto de objetos de dados, na estrutura apropriada e elementos-chave para bancos de dados.
ER/Studio, desenvolvida pela Embarcadero Software (www.
embarcadero.com), oferece suporte modelagem entidade-relacionamento.
Oracle Designer, desenvolvida pela Oracle Systems (www.
oracle.com), modela processos de negcio, entidades
de dados e relacionamentos [que] so transformados em
projetos a partir dos quais so gerados aplicaes e bancos de dados completos.
Visible Analyst, desenvolvida pela Visible Systems (www.
visible.com), oferece suporte a uma srie de funes de
modelagem de anlise inclusive modelagem de dados.

12 Embora o DER ainda seja utilizado em algumas aplicaes de projeto de bancos de dados, a notao UML (Apndice 1) agora
pode ser usada para projeto de dados.
13 Cardinalidade de um par objeto-relacionamento especifica o nmero de ocorrncias de um [objeto] que pode ser relacionado
ao nmero de ocorrncias de um outro [objeto] [Til93]. A modalidade de um relacionamento 0 se no houver uma necessidade explcita para a ocorrncia do relacionamento ou o relacionamento for opcional. A modalidade 1 se a ocorrncia do
relacionamento for compulsria.
14 As ferramentas aqui apresentadas no significam um aval, mas sim uma amostra de ferramentas nesta categoria. Na maioria
dos casos, os nomes das ferramentas so marcas registradas por seus respectivos desenvolvedores.

166

PARTE 2 MODELAGEM

6.5

Modelagem Ba seada

em

Classes

A modelagem baseado em classes representa os objetos que o sistema ir manipular, as operaes (tambm denominadas mtodos ou servios) que sero aplicadas aos objetos para efetuar a manipulao, os relacionamentos (alguns hierrquicos) entre os objetos e as colaboraes
que ocorrem entre as classes definidas. Os elementos de um modelo baseado em classes so:
classes e objetos, atributos, operaes, modelos CRC (classe-responsabilidade-colaborador),
diagramas de colaborao e pacotes. As sees a seguir apresentam uma srie de diretrizes informais que auxiliaro na identificao e na representao desses elementos.

6.5.1Identificao de classes de anlise

O problema
realmente difcil
descobrir, logo no
incio, quais so os
objetos [classes]
corretos.
Carl Argila

que
? Demaneira
as

classes de anlise
se manifestam
como elementos
do espao de
solues?

Se voc observar em torno de uma sala, existe um conjunto de objetos fsicos que podem ser
facilmente identificados, classificados e definidos (em termos de atributos e operaes). Porm,
quando se observa em torno do espao de problema de uma aplicao de software, as classes
(e objetos) podem ser mais difceis de compreender.
Podemos comear a identificar classes examinando os cenrios de uso desenvolvidos como
parte do modelo de requisitos e realizando uma anlise sinttica [Abb83] dos casos de uso desenvolvidos para o sistema a ser construdo. As classes so determinadas sublinhando-se cada
substantivo ou frase contendo substantivos e introduzindo-a em uma tabela simples. Podem ser
observados sinnimos. Se for preciso que a classe (substantivo) implemente uma soluo, ento
ela faz parte do espao de solues; caso contrrio, se for necessria uma classe apenas para
descrever uma soluo, ela faz parte do espao de problemas.
Mas o que devemos procurar uma vez que todos os substantivos tenham sido isolados? As
classes de anlise se manifestam em uma das seguintes maneiras:
Entidades externas (por exemplo, outros sistemas, dispositivos, pessoas) que produzem
ou consomem informaes a ser usadas por um sistema baseado em computadores.
Coisas (por exemplo, relatrios, exibies, letras, sinais) que fazem parte do domnio de
informaes para o problema.
Ocorrncias ou eventos (por exemplo, uma transferncia de propriedades ou a finalizao
de uma srie de movimentos de rob) que ocorrem no contexto da operao do sistema.
Papis (por exemplo, gerente, engenheiro, vendedor) desempenhados pelas pessoas que
interagem com o sistema.
Unidades organizacionais (por exemplo, diviso, grupo, equipe) que so relevantes para
uma aplicao.
Locais (por exemplo, cho de fbrica ou rea de carga) que estabelecem o contexto do
problema e a funo global do sistema.
Estruturas (por exemplo, sensores, veculos de quatro rodas ou computadores) que definem uma classe de objetos ou classes de objetos relacionadas.
Essa categorizao apenas uma das muitas que foram propostas na literatura.15 Por exemplo, Budd [Bud96] sugere uma taxonomia de classes que inclui produtores (fontes) e consumidores (reservatrios) de dados, gerenciadores de dados, classes de visualizao ou de observao
e classes auxiliares.
Tambm importante notar o que as classes ou objetos no devem ser. Em geral, uma classe
jamais deve ter um nome procedural imperativo [Cas89]. Por exemplo, se os desenvolvedores
de software de um sistema de imagens para aplicao em medicina definiram um objeto com
o nome InverterImagem ou at mesmo InversoDeImagem, eles estariam cometendo um
erro sutil. A Imagem obtida do software poderia, obviamente, ser uma classe ( algo que faz
parte do domnio de informaes). A inverso da imagem uma operao aplicada ao objeto.
15 Outra classificao importante, definindo classes de entidades, de contorno e de controle, discutida na Seo 6.5.4.

captulo 6 MODELAgem DE REQUISITOS: CENRIOS, INFORMAES E CLASSES DE ANLISE

167

provvel que a inverso seja definida como uma operao para o objeto Imagem, mas no
seja definida como uma classe separada com a conotao inverso de imagem. Como afirma
Cashman [Cas89]: o intuito da orientao a objetos encapsular, mas, ainda, manter separados
os dados e as operaes sobre os dados.
Para ilustrarmos como as classes de anlise poderiam ser definidas durante os estgios
iniciais da modelagem, consideremos uma anlise sinttica (os substantivos so sublinhados,
os verbos colocados em itlico) para uma narrativa16 de processamento da funo de segurana
domiciliar do CasaSegura.

AVISO
A anlise sinttica
no infalvel, mas
um excelente salto
inicial, caso voc
esteja em dificuldades
para definir objetos
de dados e as
transformaes que
operam sobre eles.

A funo de segurana domiciliar do CasaSegura permite que o proprietrio do imvel configure o


sistema de segurana quando ele instalado, monitore todos os sensores conectados ao sistema de
segurana e interaja com o proprietrio do imvel atravs da Internet, de um PC ou de um painel de
controle.
Durante a instalao, o PC do CasaSegura usado para programar e configurar o sistema. atribudo um nmero e um tipo a cada sensor, programada uma senha-mestra para armar e desarmar o
sistema e so introduzidos nmero(s) de telefone para discar quando um evento de sensor ocorre.
Quando um evento de sensor reconhecido, o software aciona um alarme audvel agregado ao sistema. Aps um tempo de retardo que especificado pelo proprietrio do imvel durante as atividades
de configurao do sistema, o software disca um nmero de telefone de um servio de monitoramento,
fornece informaes sobre o local, relatando a natureza do evento que foi detectado. O nmero de telefone ser discado novamente a cada 20 segundos at que seja completada a ligao.
O proprietrio do imvel recebe informaes de segurana atravs de um painel de controle, do PC
ou de um navegador, coletivamente denominados interface. A interface mostra mensagens ao operador,
bem como informaes sobre o estado do sistema no painel de controle, no PC ou na janela do navegador. A interao com o proprietrio do imvel acontece da seguinte forma...

Extraindo os substantivos, podemos propor uma srie de possveis classes:


Classe potencial

Classificao geral

proprietrio do imvel

papel ou entidade externa

sensor

entidade externa

painel de controle

entidade externa

instalao

ocorrncia

sistema (tambm conhecido como sistema de segurana)

coisa

nmero, tipo,

no objetos, atributos do sensor

senha-mestra

coisa

nmero de telefone

coisa

evento de sensor

ocorrncia

alarme audvel

entidade externa

servio de monitoramento

unidade organizacional ou entidade externa

Prosseguiramos com a lista at que todos os substantivos contidos na narrativa de processamento tivessem sido considerados. Observe que chamamos cada entrada da lista de possvel
objeto. Temos de considerar cada um deles at que uma deciso final seja feita.

16 Uma narrativa de processamento similar ao caso de uso em termos de estilo, mas ligeiramente diferente em seu propsito.
A narrativa de processamento fornece uma descrio geral da funo a ser desenvolvida. Ela no um cenrio escrito sob o
ponto de vista de um ator. importante observar, entretanto, que uma anlise sinttica tambm pode ser usada para todos os
casos de uso desenvolvidos como parte do levantamento de requisitos (inferncia).

168

PARTE 2 MODELAGEM

Coad e Yourdon [Coa91] sugerem seis caractersticas de seleo que deveriam ser usadas
medida que se considera cada classe potencial para incluso no modelo de anlise:

? Como
podemos

determinar se uma
classe potencial
deve, de fato, se
tornar uma classe
de anlise?

1. Informaes retidas. A classe potencial ser til durante a anlise apenas se as informaes
sobre ela tiverem de ser relembradas para que o sistema possa funcionar.
2. Servios necessrios. A classe potencial deve ter um conjunto de operaes identificveis
capazes de modificar, de alguma forma, o valor de seus atributos.
3. Atributos mltiplos. Durante a anlise de requisitos, o foco deve ser nas informaes importantes; uma classe com um nico atributo poderia, na verdade, ser til durante o projeto,
porm, provavelmente seria mais bem representada na forma de atributo de outra classe
durante a atividade de anlise.
4. Atributos comuns. Um conjunto de atributos pode ser definido para a classe potencial e esses
atributos se aplicam a todas as instncias da classe.
5. Operaes comuns. Um conjunto de operaes pode ser definido para a classe potencial e
tais operaes se aplicam a todas as instncias da classe.
6. Requisitos essenciais. Entidades externas que aparecem no espao do problema e produzem
ou consomem informaes essenciais operao de qualquer soluo para o sistema quase
sempre sero definidas como classes no modelo de requisitos.

As classes
batalham, algumas
delas triunfam,
outras so
eliminadas.
Mao Zedong

Para ser considerada uma classe legtima para incluso no modelo de requisitos, um objeto
potencial deve satisfazer todas (ou quase todas) essas caractersticas. A deciso para incluso
de classes potenciais no modelo de anlise um tanto subjetiva, e uma avaliao posterior
poderia fazer com que um objeto fosse descartado ou reintegrado. Entretanto, a primeira etapa
da modelagem baseada em classes definir as classes e decises (mesmo aquelas subjetivas).
Com isso em mente, devemos aplicar as caractersticas de seleo da lista de classes potenciais
do CasaSegura:
Classe potencial

Nmero caracterstico que se aplica

proprietrio do imvel

rejeitado: 1, 2 falham, embora 6 se aplique

sensor

aceito: todos se aplicam

painel de controle

aceito: todos se aplicam

instalao

rejeitado

sistema (tambm conhecido como sistema de segurana)

aceito: todos se aplicam

nmero, tipo

rejeitado: 3 falha, atributos de sensor

senha-mestra

rejeitado: 3 falha

nmero de telefone

rejeitado: 3 falha

evento de sensor

aceito: todos se aplicam

alarme audvel

aceito: 2, 3, 4, 5, 6 se aplicam

servio de monitoramento

rejeitado: 1, 2 falham, embora 6 se aplique

Deve-se notar o seguinte: (1) a lista anterior no definitiva, outras classes talvez tenham
de ser acrescentadas para completar o modelo; (2) algumas das classes potenciais rejeitadas
se tornaro atributos para as que foram aceitas (por exemplo, nmero e tipo so atributos de
Sensor e senha-mestre e nmero de telefone talvez se tornem atributos de Sistema); (3)
enunciados do problema diferentes talvez provoquem decises aceito ou rejeitado diferentes (por exemplo, se cada proprietrio de um imvel tivesse uma senha individual ou fosse
identificado pelo seu padro de voz, a classe Proprietrio satisfaria as caractersticas 1 e 2
e teriam sido aceitas).

captulo 6 MODELAgem DE REQUISITOS: CENRIOS, INFORMAES E CLASSES DE ANLISE

169

6.5.2 Especificao de atributos

Atributos so o
conjunto de objetos
de dados que definem
completamente a
classe no contexto do
problema.

Os atributos descrevem uma classe selecionada para ser includa no modelo de requisitos. Em
essncia, so os atributos que definem uma classe que esclarecem o que a classe representa
no contexto do espao de problemas. Por exemplo, se fssemos construir um sistema que registrasse estatsticas dos jogadores do campeonato de beisebol profissional, os atributos da classe
Jogador seriam bem diferentes dos atributos da mesma classe quando usados no contexto do
sistema de aposentadoria dos jogadores profissionais de beisebol. No primeiro, atributos como
nome, posio, mdia de rebatidas, porcentagem de voltas completas em torno do campo, nmero
de anos jogados e nmero de jogos podem ser relevantes. No outro caso, alguns desses atributos
seriam relevantes, mas outros substitudos (ou aumentados) por atributos como salrio mdio,
crdito faltante para aposentadoria plena, opes escolhidas para o plano de aposentadoria, endereo
para correspondncia e outros similares.
Para criarmos um conjunto de atributos que fazem sentido para uma classe de anlise, devemos estudar cada caso de uso e escolher aquelas coisas que pertencem de forma razovel
quela classe. Alm disso, a pergunta a seguir deve ser respondida para cada uma das classes:
Quais dados (compostos e/ou elementares) definem completamente esta classe no contexto do
problema em mos?.
A ttulo de ilustrao, consideremos a classe Sistema definida para o CasaSegura. O proprietrio de um imvel pode configurar a funo de segurana para que esta reflita informaes
sobre os sensores, tempo de resposta do alarme, ativao/desativao, de identificao e assim
por diante. Podemos representar estes dados compostos da seguinte maneira:
informaes de identificao = ID do sistema + nmero de telefone de verificao + estado do sistema
informaes sobre a resposta do alarme = tempo de retardo + nmero de telefone
informaes de ativao/desativao = senha-mestre + nmero de tentativas permitidas + senha temporria

Cada um dos dados direita do sinal de igual poderia ser definido de forma mais extensiva
a um nvel elementar, porm, para nossos propsitos, eles constituem uma lista de atributos
razovel para a classe Sistema (a parte sombreada da Figura 6.9).
Os sensores fazem parte do sistema global CasaSegura e ainda no esto listados como
dados ou atributos na Figura 6.9. Sensor j foi definido como uma classe, e mltiplos objetos
Sensor sero associados classe Sistema. Em geral, evitamos definir um item como um atributo, caso mais de um dos itens deva ser associado classe.

Figura 6.9
Diagrama de classes
para a classe Sistema

Sistema
systemID
verificationPhoneNumber
systemStatus
delayTime
telephoneNumber
masterPassword
temporaryPassword
numberTries
program( )
display( )
reset( )
query( )
arm( )
disarm( )

170

PARTE 2 MODELAGEM

AVISO
Ao definir operaes
para uma classe de
anlise, concentre-se
no comportamento
orientado ao problema
em vez de nos
comportamentos
necessrios para a
implementao.

6.5.3Definio das operaes


As operaes definem o comportamento de um objeto. Embora existam muitos tipos diferentes de operaes, em geral podem ser divididas em quatro grandes categorias: (1) operaes que
manipulam dados de alguma forma (por exemplo, adio, eliminao, reformatao, seleo),
(2) operaes que realizam um clculo, (3) operaes que pesquisam o estado de um objeto e
(4) operaes que monitoram um objeto em termos de ocorrncias de um evento de controle.
Tais funes so realizadas operando-se sobre atributos e/ou associaes (Seo 6.5.5). Consequentemente, uma operao deve ter conhecimento da natureza dos atributos e associaes
das classes.
Como primeira iterao na obteno de um conjunto de operaes para uma classe de anlise, podemos estudar novamente uma narrativa de processamento (ou caso de uso) e escolher
aquelas operaes que pertencem de forma razovel classe. Para tanto, a anlise sinttica
mais uma vez estudada e os verbos so isolados. Alguns dos verbos sero as operaes legtimas e podem ser facilmente associadas a uma classe especfica. Por exemplo, da narrativa
de processamento do CasaSegura apresentada anteriormente neste captulo, veremos que
atribudo um nmero e tipo aos sensores ou uma senha-mestre programada para armar e
desarmar o sistema. Essas frases indicam uma srie de coisas:
Que uma operao assign() relevante para a classe Sensor.
Que uma operao program() ser aplicada classe Sistema.
Que arm() e disarm() so operaes que se aplicam classe Sistema.

C asa S egura
Modelos de classes
Cena: Sala do Ed, quando se inicia o modelamento de requisitos.
Atores: Jamie, Vinod e Ed todos os membros da equipe de
engenharia de software do CasaSegura.
Conversa:
[Ed vem trabalhando na extrao de classes do modelo de casos
de uso para o AVC-EVC (apresentado em um quadro anterior
deste captulo) e est mostrando as classes que ele extraiu a
seus colegas.]
Ed: Ento, quando o proprietrio de um imvel quiser escolher
uma cmera, ele ter de selecion-la na planta da casa. Defini
uma classe Planta. Eis o diagrama.
(Eles observam a Figura 6.10.)
Jamie: Portanto, Planta um objeto que colocado com paredes, portas, janelas e cmeras. isso que estas linhas com
identificao significam, certo?
Ed: Isso mesmo, elas so chamadas associaes. Uma classe
est associada a outra de acordo com as associaes que eu
mostrei. [As associaes so discutidas na Seo 6.5.5.]
Vinod: Portanto, a planta real feita de paredes e contm cmeras e sensores colocados nessas paredes. Como a planta da
casa sabe onde colocar esses objetos?
Ed: Ela no sabe, mas as outras classes sim. Veja os atributos
em, digamos, TrechoParede, que usada para construir uma

parede. O trecho de parede tem coordenadas de incio e fim e


a operao draw() faz o resto.
Jamie: E o mesmo acontece com as janelas e portas. Parece-me
que cmera possui alguns atributos extras.
Ed: Exatamente, preciso deles para fornecer informaes sobre
deslocamento e ampliao de imagens.
Vinod: Tenho uma pergunta. Por que a cmera possui um ID,
mas os demais no? Percebi que voc tem um atributo chamado
prximaParede. Como TrechoParede saber qual ser a
parede seguinte?
Ed: Boa pergunta, mas como dizem por a, essa uma deciso
de projeto e, portanto, a postergarei at...
Jamie: D um tempo... Aposto que voc j bolou isso.
Ed (sorrindo timidamente): verdade, vou usar uma estrutura de listas que irei modelar quando chegarmos ao projeto. Se
ficarmos muito presos questo de separar anlise e projeto,
o nvel de detalhe que tenho exatamente aqui poderia ser duvidoso.
Jamie: Para mim parece muito bom, mas tenho algumas outras
perguntas.
(Jamie faz perguntas que resultam em pequenas modificaes.)
Vinod: Voc tem cartes CRC para cada um dos objetos? Em
caso positivo, deveramos simular seus papis, apenas para ter
certeza de que nada tenha escapado.
Ed: No estou bem certo de como faz-lo.
Vinod: No difcil e realmente vale a pena. Vou lhes mostrar.

171

captulo 6 MODELAgem DE REQUISITOS: CENRIOS, INFORMAES E CLASSES DE ANLISE

Um dos propsitos
dos cartes CRC
fazer com
que as falhas
apaream logo,
com frequncia e
de forma barata.
muito mais barato
rasgar um monte
de cartes do que
reorganizar uma
grande quantidade
de cdigo-fonte.
C. Horstmann

Aps uma investigao mais apurada, provvel que a operao program() seja dividida em
uma srie de suboperaes mais especficas exigidas para configurar o sistema. Por exemplo,
program() implica a especificao de nmeros de telefone, a configurao de caractersticas do
sistema (por exemplo, criar a tabela de sensores, introduzir caractersticas do alarme) e a introduo de senha(s). Mas, por enquanto, especificaremos program() como uma nica operao.
Alm da anlise sinttica, pode-se ter uma melhor viso sobre outras operaes considerando-se a comunicao que ocorre entre os objetos. Os objetos se comunicam passando mensagens entre si. Antes de prosseguirmos com a especificao de operaes, exploraremos essa
questo em mais detalhes.

6.5.4Modelagem CRC (Classe-Responsabilidade-Colaborador)


A modelagem CRC (classe-responsabilidade-colaborador) [Wir90] fornece uma maneira simples para identificar e organizar as classes que so relevantes para os requisitos do sistema ou
produto. Ambler [Amb95] descreve a modelagem CRC da seguinte maneira:
Um modelo CRC , na verdade, um conjunto de fichas-padro que representam classes. Os cartes so
divididos em trs sees. Ao longo da parte superior do carto escrevemos o nome da classe. No corpo
do carto enumeramos as responsabilidades da classe do lado esquerdo e os colaboradores do lado
direito.

Na realidade, o modelo CRC pode fazer uso de fichas reais ou virtuais. O intuito desenvolver uma representao organizada das classes. As responsabilidades so os atributos e as

Figura 6.10

Planta

Diagrama de classes
para Planta
(veja o quadro
de discusso)

type
name
outsideDimensions
determineType( )
positionFloorplan( )
scale( )
change color( )

colocada em
Faz parte da

Parede

Cmera
type
ID
location
fieldView
panAngle
ZoomSetting
determineType( )
translateLocation( )
displayID( )
displayView( )
displayZoom( )

type
wallDimensions

determineType( )
computeDimensions ( )

usada
para construir

usada para construir


usada para construir

TrechoParede

Janela

Porta

type
startCoordinates
stopCoordinates
nextWallSement

type
startCoordinates
stopCoordinates
nextWindow

type
startCoordinates
stopCoordinates
nextDoor

determineType( )
draw( )

determineType( )
draw( )

determineType( )
draw( )

172

WebRef
Uma excelente discusso sobre esses tipos
de classes pode ser
encontrada em www.
theumlcafe.com/
a0079.htm.

Os objetos podem
ser classificados
cientificamente
em trs grandes
categorias:
aqueles que no
funcionam, aqueles
que quebram e
aqueles que se
perdem.
Russell Baker

PARTE 2 MODELAGEM

operaes que so relevantes para a classe. Em outras palavras, responsabilidade qualquer


coisa que a classe sabe ou faz [Amb95]. Colaboradores so aquelas classes que so necessrias para fornecer a uma classe as informaes necessrias para completar uma responsabilidade. Em geral, colaborao implica uma solicitao de informaes ou uma solicitao de
alguma ao.
Um carto CRC simples para a classe Planta ilustrado na Figura 6.11. A lista de responsabilidades mostrada no carto CRC preliminar e sujeita a acrscimos ou modificaes. As
classes Parede e Cmera so indicadas ao lado da responsabilidade que ir requerer sua
colaborao.
Classes. Foram apresentadas diretrizes bsicas para a identificao de classes e objetos
no incio deste captulo. A taxonomia dos tipos de classe da Seo 6.5.1 pode ser estendida
considerando-se as seguintes categorias:
Classes de entidades, tambm chamadas classes de modelo ou de negcio, so extradas
diretamente do enunciado do problema (por exemplo, Planta e Sensor). Estas representam, tipicamente, coisas que devem ser armazenadas em um banco de dados e persistem ao longo de toda a existncia da aplicao (a menos que sejam especificamente
eliminadas).
Classes de fronteira so usadas para criar a interface (por exemplo, tela interativa ou
relatrios impressos) que o usurio v e interage medida que o software usado. Os
objetos de entidades contm informaes importantes para os usurios, mas eles no
so exibidos. As classes de fronteira so desenvolvidas com a responsabilidade de gerenciar a forma atravs da qual os objetos de entidades so representados para os usurios.
Por exemplo, uma classe de fronteira chamada JanelaCmera teria a responsabilidade
de exibir imagens de cmeras de vigilncia do sistema CasaSegura.
Classes de controle gerenciam uma unidade de trabalho [UML03] do incio ao fim. Isto
, as classes de controle podem ser desenvolvidas para gerenciar: (1) a criao ou a
atualizao de objetos de entidades, (2) a instanciao de objetos de fronteira medida
que forem obtendo informaes dos objetos de entidades, (3) comunicao complexa
entre conjuntos de objetos, (4) validao de dados transmitidos entre objetos ou entre o
usurio e a aplicao. Em geral, as classes de controle no so consideradas at que a
atividade de projeto tenha sido iniciada.

Figura 6.11
Um modelo de carto CRC
Class:

Class:

Des Class:
De Classe: Planta
D
R e s Descrio

Responsabilidade:

Co llab o r at o r :
Co llab o r at o r :
Co llab o r at o r :

Colaborador:

Incorpora paredes, portas e janelas


Mostra a posio das cmeras de vdeo
Define o nome/tipo da planta
Gerencia o posicionamento na planta
Amplia/reduz a planta para exibio
Incorpora paredes, portas e janelas

Parede

Mostra a posio das cmeras de vdeo

Cmera

captulo 6 MODELAgem DE REQUISITOS: CENRIOS, INFORMAES E CLASSES DE ANLISE

? Quais
diretrizes

podem ser
aplicadas
para alocar
responsabilidades
s classes?

173

Responsabilidades. Diretrizes bsicas para a identificao das responsabilidades (atributos e operaes) foram apresentadas nas Sees 6.5.2 e 6.5.3. Wirfs-Brock e seus colegas
[Wir90] sugerem cinco diretrizes para alocao de responsabilidades s classes:
1. A inteligncia do sistema deve ser distribuda pelas classes para melhor atender
s necessidades do problema. Toda aplicao engloba certo grau de inteligncia; aquilo
que o sistema sabe e aquilo que ele pode fazer. Essa inteligncia pode ser distribuda pelas
classes em uma srie de maneiras. Classes burras (aquelas com poucas responsabilidades)
podem ser modeladas para atuar como serventes para algumas poucas classes inteligentes
(aquelas com muitas responsabilidades). Embora essa abordagem faa com que o fluxo de
controle em um sistema se torne simples, ela apresenta algumas desvantagens: concentra
toda a inteligncia em algumas poucas classes, tornando as mudanas mais difceis e tende
a exigir mais classes e, portanto, um esforo de desenvolvimento maior.
Se a inteligncia do sistema for distribuda de forma mais homognea pelas classes de
uma aplicao, cada objeto conhecer e far apenas algumas poucas coisas (que em geral
so bem focadas), a coeso do sistema aumentar.17 Isso aumenta a facilidade de manuteno do software e reduz o impacto dos efeitos colaterais devido a mudanas.
Para determinar se a inteligncia do sistema est distribuda de maneira apropriada, as
responsabilidades indicadas em cada carto CRC modelo devem ser avaliadas para determinar se alguma classe tem uma lista extraordinariamente longa de responsabilidades. Isso
indica uma concentrao de inteligncia.18 Alm disso, as responsabilidades para cada classe deveriam exibir o mesmo nvel de abstrao. Por exemplo, entre as operaes listadas
para uma classe agregada denominada ContaCorrente um revisor indica duas responsabilidades: verificar-saldo-da-conta e dar-baixa-cheques-compensados. A primeira operao
(responsabilidade) implica um complexo procedimento lgico e matemtico. A segunda
uma atividade administrativa simples. Como essas duas operaes no se encontram no
mesmo nvel de abstrao, dar-baixa-cheques-compensados deve ser colocada dentro das
responsabilidades de EntradaCheques, uma classe que englobada pela classe agregada
ContaCorrente.
2. Cada responsabilidade deve ser declarada da forma mais genrica possvel. Essa
diretriz implica que as responsabilidades gerais (tanto atributos quanto operaes) devem
estar no topo da hierarquia de classes (por elas serem genricas, sero aplicveis a todas as
subclasses).
3. As informaes e o comportamento relativos a elas devem residir na mesma
classe. Isso atende o princpio da orientao a objetos denominado encapsulamento. Os
dados e os processos que manipulam os dados devem ser empacotados como uma unidade
coesiva.
4. As informaes sobre um item devem estar em uma nica classe e no distribuda por vrias classes. Uma nica classe deve assumir a responsabilidade pelo armazenamento e manipulao de um tipo de informao especfico. Tal responsabilidade no deve,
em geral, ser compartilhada por uma srie de classes. Se as informaes forem distribudas,
o software se torna mais difcil de ser mantido e testado.
5. Quando apropriado, as responsabilidades devem ser compartilhadas entre classes
relacionadas. H muitos casos em que uma srie de objetos relacionados deve apresentar o
mesmo comportamento ao mesmo tempo. Como exemplo, consideremos um videogame que
precise exibir as seguintes classes: Jogador, CorpoJogador, BraosJogador, PernasJogador, CabeaJogador. Cada uma dessas classes possui seus prprios atributos (por exemplo,
17 Coeso um conceito de projeto que ser discutido no Captulo 8.
18 Em tais casos, talvez seja necessrio subdividir a classe em vrias classes ou subsistemas completos para distribuir a inteligncia de forma mais eficaz.

174

PARTE 2 MODELAGEM

posio, orientao, cor, velocidade) e todas tm de ser atualizadas e exibidas medida


que o usurio manipula um joystick. Consequentemente, as responsabilidades atualizar() e
exibir() devem ser compartilhadas por cada um dos objetos citados. Jogador sabe quando
algo mudou e atualizar() se faz necessria. Ela colabora com os demais objetos para atingir
uma nova posio ou orientao, porm cada objeto controla sua prpria visualizao.
Colaboraes. As classes cumprem suas responsabilidades de duas formas: (1) Uma classe
pode usar suas prprias operaes para manipular seus prprios atributos, cumprindo, portanto, determinada responsabilidade ou (2) uma classe pode colaborar com outras classes. Wirfs-Brock e seus colegas [Wir90] definem as colaboraes da seguinte forma:
As colaboraes representam solicitaes de um cliente a um servidor no cumprimento de uma responsabilidade do cliente. A colaborao a expresso do contrato entre o cliente e o servidor... Dizemos
que um objeto colabora com outro objeto se, para cumprir uma responsabilidade, ele precisar enviar
ao outro objeto quaisquer mensagens. Uma colaborao simples flui em uma direo representando
uma solicitao do cliente ao servidor. Do ponto de vista do cliente, cada uma de suas colaboraes
est associada a determinada responsabilidade implementada pelo servidor.

As colaboraes so identificadas determinando se uma classe pode ou no cumprir cada


responsabilidade por si s. Caso no possa, ela precisa interagir com outra classe. Da, a colaborao.
Como exemplo, consideremos a funo de segurana domiciliar do CasaSegura. Como parte
do procedimento de ativao, o objeto PaineldeControle deve determinar se algum sensor est
aberto. A responsabilidade chamada determinar-estado-sensor() definida. Se existirem sensores abertos, PaineldeControle tem de ativar um atributo de estado para no preparado. As
informaes dos sensores podem ser adquiridas de cada objeto Sensor. Consequentemente, a
responsabilidade determinar-estado-sensor() pode ser cumprida apenas se PaineldeControle
trabalhar em colaborao com Sensor.
Para ajudarmos na identificao dos colaboradores, podemos examinar trs relacionamentos genricos diferentes entre as classes [Wir90]: (1) o relacionamento -parte-de, (2) o relacionamento tem-conhecimento-de e (3) o relacionamento depende-de. Cada um desses trs
relacionamentos genricos considerado remidamente nos pargrafos a seguir.
Todas as classes que fazem parte de uma classe agregada so interligadas classe agregada por meio de um relacionamento -parte-de. Considerando as classes definidas para o
videogame citado anteriormente, a classe CorpoJogador faz-parte-do Jogador, assim como
BraosJogador, PernasJogador e CabeaJogador. Em UML, tais relacionamentos so representados na forma da agregao mostrada na Figura 6.12.
Figura 6.12
Jogador

Uma classe
composta de
agregao

CabeaJogador

CorpoJogador

BraosJogador

PernasJogador

captulo 6 MODELAgem DE REQUISITOS: CENRIOS, INFORMAES E CLASSES DE ANLISE

175

Quando uma classe tem de adquirir informaes de outra classe, estabelecido o relacionamento tem-conhecimento-de. A responsabilidade determinar-estado-sensor() citada anteriormente um exemplo de um relacionamento tem-conhecimento-de.
A relao depende-de implica que duas classes tm uma dependncia que no conseguida por tem-conhecimento-de ou -parte-de. Por exemplo, CabeaJogador sempre tem
de estar interligado ao CorpoJogador (a menos que o videogame seja particularmente
violento), embora cada objeto pudesse existir sem o conhecimento direto do outro. Um
atributo do objeto CabeaJogador chamado posio-central determinado a partir
da posio central do CorpoJogador. Essa informao obtida atravs de um terceiro
objeto, Jogador, que a adquire de CorpoJogador. Portanto, CabeaJogador dependedo CorpoJogador.
Em todos os casos, o nome da classe colaboradora registrado no carto CRC modelo, prximo responsabilidade que gerou a colaborao. Consequentemente, o carto contm uma
lista de responsabilidades e as colaboraes correspondentes que permitem que as responsabilidades sejam cumpridas (Figura 6.11).
Quando um modelo CRC completo tiver sido desenvolvido, os interessados podero revisar
o modelo usando a seguinte abordagem [Amb95]:
1. Todos os participantes da reviso (do modelo CRC) recebem um subconjunto dos cartes
CRC. Os cartes que colaboram devem ser separados (nenhum revisor deve ter dois cartes
que colaboram).
2. Todos os cenrios de uso (e diagramas de casos de uso correspondentes) devem ser organizados em categorias.
3. O lder da reviso l o caso de uso pausadamente. medida que o lder da reviso chega a um
objeto com nome, ele passa uma ficha para a pessoa que est com o carto da classe correspondente. Por exemplo, um caso de uso para o CasaSegura conteria a seguinte narrativa:
O proprietrio do imvel observa o painel de controle do CasaSegura para determinar se
o sistema est pronto para operar. Se o sistema no estiver pronto, o proprietrio do imvel
deve fechar manualmente as janelas/portas de modo que o indicador pronto esteja presente.
[Um indicador no preparado implica que um sensor est aberto, isto , que uma porta ou
janela est aberta.]
Quando o lder da reviso chega em painel de controle, na narrativa de caso de uso, a
ficha passada para a pessoa que est com o carto PaineldeControle. A frase implica
que um sensor est aberto requer que o carto contenha a responsabilidade que ir validar
esta implicao (a responsabilidade determinar-estado-sensor() realiza isso). Prximo responsabilidade no carto se encontra o colaborador Sensor. A ficha ento passada para o
objeto Sensor.
4. Quando a ficha passada, solicita-se ao portador do carto Sensor que descreva as responsabilidades anotadas no carto. O grupo determina se uma (ou mais) das responsabilidades
satisfaz necessidade do caso de uso.
5. Se as responsabilidades e colaboraes anotadas nos cartes no puderem satisfazer ao caso
de uso, as modificaes so feitas nos cartes. Estas podem incluir a definio das novas
classes (e os cartes CRC correspondentes) ou a especificao das responsabilidades novas
ou revisadas ou das colaboraes em cartes existentes.
Esse modus operandi prossegue at que o caso de uso seja finalizado. Quando todos os casos de uso tiverem sido revistos, a modelagem de requisitos continua.

176

PARTE 2 MODELAGEM

C asa S egura
Modelos CRC

Usemos a classe InterfaceAdministraoDomiciliar.

Cena: Sala do Ed, quando se inicia a modelagem de requisitos.

Ed: OK... Portanto, as responsabilidades so... Os atributos e


as operaes para a classe, e as colaboraes so as classes
para as quais as responsabilidades apontam.

Atores: Jamie, Vinod e Ed todos os membros da equipe de


engenharia de software do CasaSegura.

Vinod: Pensei que voc no entendesse sobre CRC.

Conversa:

Ed: Um pouquinho, mas v em frente.

[Vinod decidiu mostrar a Ed como desenvolver cartes CRC


dando-lhe um exemplo.]

Vinod: Portanto, eis minha definio de classe para InterfaceAdministraoDomiciliar.

Vinod: Enquanto voc trabalhava na funo de vigilncia e


Jamie estava envolvido com a funo de segurana, trabalhei
na funo de administrao domiciliar.

Atributos:
optionsPanel contm informaes sobre os botes que permitem ao usurio escolher a funcionalidade.

Ed: E em que ponto voc se encontra? O Marketing vive mudando de ideia.

situationPanel contm informaes sobre os botes que permitem ao usurio escolher a situao.

Vinod: Eis o caso de uso preliminar para toda a funo... Ns


o refinamos um pouco, mas isso deve lhe dar uma viso geral...

floorplan o mesmo que o objeto de vigilncia, porm este


aqui mostra os dispositivos.

Caso de uso: A funo de administrao domiciliar do CasaSegura.


Narrativa: Queremos usar a interface de administrao domiciliar em um PC ou via Internet para controlar dispositivos eletrnicos que possuem controladores de interface sem fio. O sistema
deve permitir que eu ligue e desligue luzes especficas, controle
aparelhos que estiverem conectados a uma interface sem fio,
configure o meu sistema de aquecimento e ar-condicionado para
as temperaturas que eu desejar. Para tanto, quero escolher os
dispositivos com base na planta da casa. Cada dispositivo tem
de ser identificado na planta da casa. Como recurso opcional,
quero controlar todos os dispositivos audiovisuais udio,
televiso, DVD, gravadores digitais e assim por diante. Com
uma nica seleo, quero ser capaz de configurar a casa inteira
para vrias situaes. Uma delas em casa, a outra fora de
casa, a terceira viagem de fim de semana e a quarta viagem
prolongada. Todas essas situaes tero ajustes de configurao
aplicados a todos os dispositivos. Nos estados viagem de fim de
semana e viagem prolongada, o sistema deve acender e apagar
as luzes da casa em intervalos aleatrios (para parecer que algum est em casa) e controlar o sistema de aquecimento e ar-condicionado. Devo ser capaz de cancelar essas configuraes
via Internet com a proteo de uma senha apropriada...
Ed: O pessoal do hardware j bolou todas as interfaces sem
fio?
Vinod (sorrindo): Eles esto trabalhando nisso; digamos que
no h nenhum problema. De qualquer forma, extra um monte
de classes para a administrao domiciliar e podemos usar uma
delas como exemplo.

deviceIcons informaes sobre os cones representando luzes,


aparelhos, HVAC etc.
devicePanels simulao do painel de controle de dispositivos
ou de aparelhos; possibilita o controle.
Operaes:
displayControl(), selectControl(), displaySituation(), select situation(), accessFloorplan(), selectDeviceIcon(),
displayDevicePanel(), accessDevicePanel()...
Classe: InterfaceAdministraoDomiciliar
Responsabilidade

Colaborador

displayControl()

PaineldeOpo (classe)

selectControl()

PaineldeOpo (classe)

displaySituation()

PaineldeSituao (classe)

selectSituation()

PaineldeSituao (classe)

accessFloorplan()

Planta (classe)...

...
Ed: Portanto, quando a operao accessFloorplan () for chamada, ela colaborar com o objeto FloorPlan exatamente como
aquela que desenvolvemos para a funo de vigilncia. Espere,
tenho uma descrio dela aqui comigo. (Eles observam a Figura
6.10.)
Vinod: Exatamente. E se quisssemos rever o modelo de classes
inteiro, poderamos comear com este carto, depois ir para o
carto do colaborador e a partir deste ponto para um dos colaboradores do colaborador, e assim por diante.
Ed: Uma boa forma de descobrir omisses ou erros.
Vinod: Isso a.

6.5.5Associaes e dependncias
Em muitos casos, duas classes de anlise so relacionadas entre si de alguma maneira, de
modo muito parecido como dois objetos de dados poderiam estar relacionados entre si (Seo
6.4.3). Na UML essas relaes so chamadas associaes. Referindo-se novamente Figura
6.10, a classe Planta definida identificando-se um conjunto de associaes entre Planta e
duas outras classes, Cmera e Parede. A classe Parede associada a trs classes que permitem que uma parede seja construda, TrechoParede, Janela e Porta.

captulo 6 MODELAgem DE REQUISITOS: CENRIOS, INFORMAES E CLASSES DE ANLISE

A associao define
um relacionamento
entre classes. A
multiplicidade define
quantos de uma classe
esto relacionados com
quantos de uma outra
classe.
que um
? Oesteretipo?

177

Em alguns casos, uma associao pode ser mais bem definida indicando-se a multiplicidade.
Referindo-se Figura 6.10, um objeto Parede construdo por meio de um ou mais objetos
TrechoParede. Alm disso, o objeto Parede pode conter nenhum ou alguns objetos Janela e
nenhum ou alguns objetos Porta. Essas restries de multiplicidade so ilustradas na Figura
6.13, em que um ou mais representado usando-se 1. .* e zero ou mais por 0 . .*. Na UML,
o asterisco indica um limite superior infinito no intervalo.19
Em muitos casos, existe um relacionamento cliente/servidor entre duas classes de anlise.
Em tais casos, uma classe cliente depende da classe servidora de alguma forma e se estabelece
um relacionamento relao de dependncia. Dependncias so definidas por um esteretipo.
Esteretipo um mecanismo de extensibilidade [Arl02] dentro da UML que nos permite definir
um elemento de modelagem especial cuja semntica definida de forma personalizada. Na UML
os esteretipos so representados entre << >> (por exemplo, <<stereotype>>).
Como exemplo de uma dependncia simples no sistema de vigilncia CasaSegura, um objeto
Cmera (neste caso, a classe servidora) fornece uma imagem de vdeo para um objeto ExibirJanela (neste caso, a classe cliente). O relacionamento entre esses dois objetos no uma associao simples, embora no exista uma associao de dependncia. Em um caso de uso escrito
para vigilncia (no mostrado), voc toma conhecimento de que uma senha especial tem de
ser fornecida para visualizar posies de cmera especficas. Uma maneira de conseguir isso
fazer com que Cmera solicite uma senha e ento d permisso para ExibirJanela produzir a
exibio de vdeo. Isso pode ser representado como mostra a Figura 6.14 em que <<access>>
implica que o uso da sada de cmera controlado por uma senha especial.

Figura 6.13

Parede

Multiplicidade

1
usado para construir

usado para construir


1..*
TrechoParede

0..*
Janela

usado para
0..*
construir
Porta

Figura 6.14
Dependncias

ExibirJanela

Cmera
<<access>>
{senha}

19 Outros relacionamentos de multiplicidade um para um, um para vrios, vrios para vrios, um para um intervalo especificado com limites inferior e superior e outros podem ser indicadas como parte de uma associao.

178

PARTE 2 MODELAGEM

6.5.6Pacotes de anlise
Um pacote usado
para montar um
conjunto de classes
relacionadas.

Uma importante parte da modelagem de anlise a categorizao. Vrios elementos do modelo de anlise (por exemplo, casos de uso, classes de anlise) so categorizados de modo que
so empacotados como um agrupamento denominado pacote de anlise que recebe um
nome representativo.
Para ilustrarmos o uso de pacotes de anlise, consideremos o videogame introduzido anteriormente. medida que o modelo de anlise para o videogame desenvolvido, um nmero
maior de classes extrado. Algumas focalizam o ambiente do jogo as cenas que o usurio v
medida que o jogo vai se desenrolando. Classes como rvore, Paisagem, Rodovia, Parede,
Ponte, Prdio e EfeitoVisual poderiam cair dentro desta categoria. Outras focalizam os personagens do jogo, descrevendo suas caractersticas fsicas, aes e restries. Classes como
Jogador (descrito anteriormente), Protagonista, Antagonista e PapisApoio poderiam ser
definidas. Outras ainda descrevem as regras do jogo como um jogador navega pelo ambiente.
Classes como RegrasDeMovimentao e RestriesNaAo so candidatas aqui. Poderiam
existir muitas outras categorias. Essas classes podem ser agrupadas em pacotes de anlise conforme mostra a Figura 6.15.
O sinal de mais antes do nome da classe de anlise em cada pacote indica que as classes
tm visibilidade pblica e so, consequentemente, acessveis de outros pacotes. Embora no sejam mostrados na figura, outros smbolos podem anteceder um elemento dentro de um pacote.
Um sinal de menos indica que um elemento est oculto de todos os demais pacotes e um smbolo
# indica que um elemento acessvel apenas para pacotes contidos em determinado pacote.

Figura 6.15
Nome do pacote

Pacotes
Ambiente
+rvore
+Paisagem
+Rodovia
+Parede
+Ponte
+Prdio
+EfeitosVisuais
+Cenrio

RegrasDoJogo
+RegrasDeMovimentao
+RestriesNaAo

Personagens
+Jogador
+Protagonista
+Antagonista
+PapelApoio

6.6

Resumo
O objetivo da modelagem de requisitos criar uma variedade de representaes que descrevem aquilo que o cliente requer, estabelece uma base para a criao de um projeto de software e
define um conjunto de requisitos que podem ser validados assim que o software for construdo.
O modelo de requisitos preenche a lacuna entre uma representao sistmica que descreve o
sistema como um todo ou a funcionalidade de negcio e um projeto de software que descreve
a arquitetura da aplicao de software, a interface do usurio e a estrutura no nvel de componentes.

captulo 6 MODELAgem DE REQUISITOS: CENRIOS, INFORMAES E CLASSES DE ANLISE

179

Os modelos baseados em cenrio representam requisitos de software sob o ponto de vista


do usurio. O caso de uso uma narrativa ou descrio dirigida por modelos de uma interao
entre um ator e o software o principal elemento da modelagem. Obtido durante o levantamento de requisitos, o caso de uso define as etapas fundamentais para uma funo ou interao
especfica. O grau de formalidade dos casos de uso e detalhes varia, porm o resultado final
fornece a entrada necessria para as demais atividades de modelagem de anlise. Os cenrios
tambm podem ser descritos usando-se um diagrama de atividades uma representao grfica do tipo fluxograma que represente o fluxo de processamento dentro de um cenrio especfico. Os diagramas de raia ilustram como o fluxo de processamento alocado a vrios atores
ou classes.
A modelagem de dados usada para descrever o espao de informaes que sero construdas ou manipuladas pelo software. A modelagem de dados comea pela representao dos
objetos de dados informaes compostas que devem ser compreendidas pelo software. Os
atributos de cada objeto de dados so identificados e os relacionamentos entre objetos de dados, descritos.
A modelagem baseada em classes usa informaes extradas dos elementos de modelagem
de dados baseados em cenrios para identificar as classes de anlise. Uma anlise sinttica
pode ser usada para extrair classes, atributos e operaes candidatos com base em narrativas
textuais. So definidos os critrios para a definio de uma classe. Um conjunto de cartes
classe-responsabilidade-colaborador pode ser usado para definir relaes entre classes. Alm
disso, uma variedade de notao da modelagem UML pode ser aplicada para definir hierarquias,
relacionamentos, associaes, agregaes e dependncias entre as classes. Pacotes de anlise
so usados para categorizar e agrupar classes de maneira que as tornem mais administrveis
para grandes sistemas.

Problemas

Pontos

Ponderar

6.1. Existe a possibilidade de comear a codificar logo depois de um modelo de anlise ter
sido criado? Justifique sua resposta e, em seguida, argumente ao contrrio.
6.2. Uma regra prtica para anlise que o modelo deve se concentrar nos requisitos visveis dentro do domnio do negcio ou problema. Que tipos de requisitos no so visveis
nesses domnios? Fornea alguns exemplos.
6.3. Qual o propsito da anlise de domnio? Como est relacionada com o conceito de padres de requisitos?
6.4. possvel desenvolver um modelo de anlise efetivo sem desenvolver todos os quatro
elementos da Figura 6.3? Explique.
6.5. Foi-lhe solicitado construir um dos seguintes sistemas:
a. um sistema de matrcula em cursos baseado em rede para a sua universidade.
b. um sistema de processamento de pedidos baseado na Web para uma loja de informtica.
c. um sistema de faturas simples para um pequeno negcio.
d. um livro de receitas baseado na Internet que embutido em forno eltrico ou micro-ondas.
Escolha o sistema de seu interesse e desenvolva um diagrama entidade-relao que descreva
objetos de dados, relacionametos e atributos.
6.6. O departamento de obras pblicas de uma grande cidade decidiu desenvolver um sistema de tapa-buracos (pothole tracking and repair system, PHTRS) baseado na Web. Segue
uma descrio:
Os cidados podem entrar em um site e relatar o local e a gravidade dos buracos. medida que so
relatados, os buracos so registrados em um sistema de reparos do departamento de obras pblicas e recebem um nmero identificador, armazenado pelo endereo (nome da rua), tamanho (em

180

PARTE 2 MODELAGEM

uma escala de 1 a 10), localizao (no meio da rua, meio-fio etc.), bairro (determinado com base no
endereo) e prioridade para o reparo (determinada segundo o tamanho do buraco). Os dados de solicitao de trabalho so associados a cada buraco e incluem a localizao e o tamanho do buraco, equipe de
obras identificando o nmero, o nmero de operrios da equipe, equipamento alocado, horas usadas
para o reparo, estado do buraco (trabalho em andamento, reparado, reparo temporrio, no reparado),
quantidade de material de preenchimento utilizado e custo do reparo (calculado com base nas horas
utilizadas, no nmero de pessoas, no material e no equipamento usado). Por fim, criado um arquivo
de danos para armazenar informaes sobre o dano relatado devido ao buraco e que inclui o nome,
endereo e telefone do cidado, tipo de dano e custo monetrio do dano. O PHTRS um sistema online; todas as consultas devem ser feitas interativamente.

a. Desenhe um diagrama de caso de uso UML para o sistema PHTRS. Voc ter de fazer
uma srie de suposies sobre a maneira atravs da qual um usurio interage com esse
sistema.
b. Desenvolva um modelo de classes para o sistema PHTRS.
6.7. Escreva um caso de uso baseado em modelo para o sistema de administrao domiciliar
CasaSegura descrito informalmente no quadro aps a Seo 6.5.4.
6.8. Desenvolva um conjunto completo de cartes CRC sobre o produto ou sistema que voc
escolher como parte do Problema 6.5.
6.9. Realize uma reviso dos cartes CRC com seus colegas. Quantas classes, responsabilidades e colaboradores adicionais so acrescidos como consequncia da reviso?
6.10. O que um pacote de anlise e como poderia ser usado?

Leituras

Fontes

de

I n f o r m a o C o m p l e m e n ta r e s

Os casos de uso podem servir como base para todas as abordagens de modelagem de requisitos. O tema discutido de forma abrangente por Rosenberg e Stephens (Use Case Driven
Object Modeling with UML: Theory and Practice, Apress, 2007), Denny (Succeeding with Use
Cases: Working Smart to Deliver Quality, Addison-Wesley, 2005), Alexander e Maiden (eds.)
(Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Wiley, 2004),
Bittner e Spence (Use Case Modeling, Addison-Wesley, 2002), Cockburn [Coc01b] e outras
referncias citadas nos Captulos 5 e 6.
A modelagem de dados apresenta um til mtodo para examinar o espao de informaes. Livros como os de Hoberman [Hob06] e Simsion e Witt [Sim05] so tratados relativamente completos. Alm disso, Allen e Terry (Beginning Relational Data Modeling, 2. ed.,
Apress, 2005), Allen (Data Modeling for Everyone, Wrox Press, 2002), Teorey e seus colegas
(Database Modeling and Design: Logical Design, 4. ed., Morgan Kaufmann, 2005) e Carlis e
Maguire (Mastering Data Modeling, Addison-Wesley, 2000) trazem tutoriais detalhados para
criao de modelos de dados de alta qualidade. Um interessante livro de Hay (Data Modeling
Patterns, Dorset House, 1995) lista padres de modelos de dados tpicos encontrados em diversas reas de aplicao.
As tcnicas de modelagem UML que podem ser aplicadas tanto na anlise quanto no projeto
so discutidos por ODocherty (Object-Oriented Analysis and Design: Understanding System
Development with UML 2.0, Wiley, 2005), Arlow e Neustadt (UML 2 and the Unified Process, 2.
ed., Addison-Wesley, 2005), Roques (UML in Practice, Wiley, 2004), Dennis e seus colegas (Systems
Analysis and Design with UML Version 2.0, Wiley, 2004), Larman (Applying UML and Patterns,
2. ed., Prentice-Hall, 2001) e Rosenberg e Scott (Use Case Driven Object Modeling with UML,
Addison-Wesley, 1999).
Uma ampla gama de fontes de informao sobre modelagem de requisitos se encontra
disposio na Internet. Uma lista atualizada de referncias na Web, relevantes modelagem de
requisitos, pode ser encontrada no site www.mhhe.com/engcs/compsci/pressman/professional/
olc/ser.htm.

captulo

Modelagem de Requisitos: Fluxo,


C omportamento, Padres e Aplicaes
Baseadas na Web (WebApp)
Conceitos- Chave
diagramas de
sequncia . . . . . . . . . . 191
especificao
de processo . . . . . . . . . 186
modelo comportamental . 188
modelo de configurao . . 200
modelo de contedo . . . 198
modelo de controle
de fluxo . . . . . . . . . . . 184
modelo de fluxo
de dados . . . . . . . . . . . 182
modelo de interao . . . 200
modelo de navegao . . 208
modelo funcional . . . . . 200
padres de anlise . . . . 193
WebApps . . . . . . . . . . . 197

ps nossa discusso de casos de uso, modelagem de dados e modelos baseados


em classes no Captulo 6, razovel perguntar: No seriam essas representaes
de modelagem de requisitos suficientes?.
A nica resposta razovel : Depende. Para alguns tipos de software, o caso de uso
poderia ser a nica representao de modelagem de requisitos exigida. Para outros, escolhida uma abordagem orientada a objetos, e modelos baseados em classes poderiam ser
desenvolvidos. Porm, em outras situaes, requisitos de aplicao complexos poderiam
demandar um exame de como os objetos de dados so transformados medida que fluem
por um sistema; como uma aplicao se comporta como consequncia de eventos externos; se o conhecimento do domnio existente pode ser adaptado ao problema atual; ou no
caso de sistemas e aplicaes baseadas na Web (WebApp), como o contedo e a funcionalidade combinados poderiam dar a um usurio final a habilidade de navegar com xito por
uma WebApp para atingir essas metas.

O que ? O modelo de requisitos

Panorama possui vrias dimenses diferentes. No

presente captulo voc aprender modelos orientados a fluxos, modelos comportamentais e consideraes sobre anlise de
requisitos especiais que entram em cena quando
so desenvolvidas aplicaes baseadas na Web
(WebApps). Cada uma dessas representaes
de modelagem complementa os casos de uso, os
modelos de dados e os modelos baseados em
classes discutidos no Captulo 6.
Quem realiza? Um engenheiro de software (s vezes
denominado analista) constri o modelo usando
os requisitos extrados de vrios interessados.
Por que importante? Sua viso sobre os requisitos do software aumenta em proporo direta ao
nmero de diferentes dimenses da modelagem
de requisitos. Embora talvez voc no tenha
tempo, recursos ou inclinao para desenvolver
cada representao sugerida neste captulo e
no Captulo 6, deve reconhecer que cada abordagem de modelagem lhe d uma forma diferente de visualizar o problema. Como consequncia, voc (e outros interessados) estaro mais
bem preparados para avaliar se o que deve ser

cumprido foi ou no especificado de maneira


apropriada.
Quais so as etapas envolvidas? A modelagem
orientada a fluxos d uma indicao de como os
objetos de dados so transformados pelas funes
de processamento. A modelagem comportamental
representa os estados do sistema e suas classes
e o impacto dos eventos sobre esses estados.
A modelagem baseada em padres faz uso do
conhecimento do domnio existente para facilitar
a anlise de requisitos. Os modelos de requisitos
para WebApp so especialmente adaptados para
a representao das necessidades relacionadas
ao contedo, interao, funo e configurao.
Qual o artefato? Uma ampla gama de formas
textuais e esquemticas pode ser escolhida para o
modelo de requisitos. Cada uma dessas representaes d uma viso de um ou mais dos elementos
do modelo.
Como garantir que o trabalho foi realizado corretamente? Os artefatos do modelamento de requisitos

devem ser revisados em termos de correo, completude e consistncia. Devem refletir os requisitos
de todos os interessados e estabelecer uma base a
partir da qual o projeto pode ser conduzido.

181

182

PARTE DOIS MODELAGEM

7.1

E s t r at g i a s

de

Modelagem

de

Requisitos

Uma viso da modelagem de requisitos, denominada anlise estruturada, considera os dados e os processos que os transformam entidades distintas. Os objetos de dados so modelados
de maneira que defina seus atributos e relacionamentos. Processos que manipulam objetos de
dados so modelados para mostrar como transformam os dados medida que objetos de dados fluem atravs do sistema. A segunda abordagem para a modelagem de anlise denominada
anlise orientada a objetos, enfoca a definio de classes e a maneira pela qual colaboram entre
si para atender os requisitos do cliente.
Embora o modelo de anlise que propomos neste livro combina recursos de ambas as abordagens, as equipes de software em geral optam por uma abordagem e excluem todas as representaes da outra. A questo no qual a melhor, mas sim, qual combinao de representaes
ir fornecer aos interessados o melhor modelo de requisitos de software e a ligao mais efetiva
para o projeto de software.

7 .2
AVISO
Alguns podero sugerir
que o DFD seja coisa
do passado e que
no tem mais lugar
na prtica moderna.
Trata-se de uma viso
que exclui um modo
de representao
potencialmente til no
nvel de anlise. Se ele
for til para comunicar
e documentar, use
o DFD.

M o d e l a g e m O r i e n ta d a

F lu x o s

Embora a modelagem orientada a fluxos de dados seja vista como uma tcnica ultrapassada
por alguns engenheiros de software, continua a ser uma das notaes de anlise de requisitos
mais largamente usadas hoje em dia.1 Embora o diagrama de fluxo de dados (data flow diagram,
DFD) e diagramas relacionados no sejam uma parte formal da UML, podem ser usados para
complementar os diagramas UML e darem uma viso adicional sobre o fluxo e os requisitos do
sistema.
O DFD adota uma viso entrada-processo-sada de um sistema. Isto , os objetos de dados
entram no software, so transformados por elementos de processamento e os objetos de dados
resultantes saem do software. Os objetos de dados so representados por setas rotuladas e as
transformaes, por crculos (tambm chamados bolhas). O DFD apresentado de uma forma
hierrquica: o primeiro modelo de fluxo de dados (algumas vezes denominado DFD nvel 0 ou
diagrama de contexto) representa o sistema como um todo. Diagramas de fluxo de dados subsequentes refinam o diagrama de contexto, fornecendo detalhamento progressivo em cada nvel
subsequente.

7.2.1Criao de um modelo de fluxo de dados


O propsito dos
diagramas de
fluxo de dados
fornecer uma
ponte semntica
entre usurios e
desenvolvedores de
sistemas.
Kenneth Kozar

O diagrama de fluxo de dados permite que desenvolvamos modelos do domnio de informaes e domnio funcional. medida que o DFD refinado com nveis de detalhe cada vez
maiores, realizamos uma decomposio funcional implcita do sistema. Ao mesmo tempo, o
refinamento do DFD resulta em um correspondente refinamento dos dados medida que se
avana nos processos que constituem a aplicao.
Algumas diretrizes simples podem ajudar muito durante a obteno do diagrama de fluxo
de dados: (1) o diagrama de fluxo de dados nvel 0 deve representar o software/sistema como
uma nica bolha; (2) as entradas e sadas primrias devem ser cuidadosamente indicadas; (3)
o refinamento deve comear isolando provveis processos, objetos de dados e repositrios
de dados para ser representados no nvel seguinte; (4) todas as setas e bolhas devem ser rotuladas com nomes significativos; (5) deve-se manter a continuidade do fluxo de informaes
de nvel para nvel,2 e (6) deve-se refinar uma bolha por vez. H uma tendncia natural de
se complicar demais o diagrama de fluxo de dados. Isso acontece quando tentamos mostrar
muitos detalhes precocemente ou representar aspectos procedurais do software em vez de
fluxo de informaes.
1
2

A modelagem de fluxo de dados uma atividade de modelagem fundamental na anlise estruturada.


Ou seja, os objetos de dados que fluem para dentro do sistema ou qualquer transformao em um nvel devem ser os mesmos
objetos de dados (ou suas partes constituintes) que fluem para dentro da transformao em um nvel mais refinado.

captulo 7 Modelagem de Requisitos: Fluxo, Comportamento, Padres e Aplicaes Baseadas na Web (WebApp)

183

Figura 7.1
DFD em nvel de
contexto para a
funo de segurana
do CasaSegura

Painel de
controle

Comandos e dados
do usurio

Software do
CasaSegura

Sensores

A continuidade do
fluxo de informaes
deve ser mantida
medida que cada nvel
DFD seja refinado.
Isso significa que
entrada e sada em
um nvel devem ser o
mesmo que entrada
e sada em um nvel
refinado.

AVISO
A anlise sinttica
no infalvel, mas
pode proporcionar
um excelente passo
inicial, caso esteja
havendo dificuldades
para definir objetos
de dados e as
transformaes que
neles operam.

AVISO
Assegure-se de
que a narrativa de
processamento que
voc pretende analisar
sintaticamente esteja
escrita no mesmo nvel
de abstrao por todo
o processo.

Estado do
sensor

Informaes
de exibio
Tipo de
alarme

Tons de nmero
de telefone

Exibio do
painel de
controle

Alarme

Linha
telefnica

Para ilustrarmos o uso do DFD e da notao relacionada, consideremos mais uma vez a funo
de segurana do CasaSegura. Um DFD nvel 0 para a funo de segurana mostrado na Figura
7.1. As entidades externas (retngulos) primrias produzem informaes para uso do sistema e
consomem informaes geradas pelo sistema. As setas rotuladas representam objetos de dados
ou hierarquias de objetos de dados. Por exemplo, dados e comandos de usurio englobam
todos os comandos de configurao, todos os comandos de ativao/desativao, todas as variaes de interaes e todos os dados introduzidos para qualificar ou expandir um comando.
O DFD nvel 0 agora tem de ser expandido para um modelo de fluxo de dados nvel 1. Mas
como prosseguimos? Seguindo uma abordagem sugerida no Captulo 6, deveramos aplicar uma
anlise sinttica [Abb83] narrativa de caso de uso que descreve a bolha no nvel de contexto.
Isolamos todos os substantivos (e locues substantivas) e verbos (e locues verbais) em uma
narrativa de processamento do CasaSegura obtida durante a primeira reunio para levantamento de necessidades. Recapitulando o texto narrativo de processamento com anlise sinttica
apresentado na Seo 6.5.1:
A funo de segurana domiciliar do CasaSegura permite que o proprietrio do imvel configure o sistema
de segurana quando ele instalado, monitora todos os sensores conectados ao sistema de segurana e
interage com o proprietrio do imvel atravs da Internet, de um PC ou de um painel de controle.
Durante a instalao, o PC do CasaSegura utilizado para programar e configurar o sistema. So
atribudos um nmero e um tipo a cada sensor, programada uma senha-mestra para armar e desarmar
o sistema e so introduzidos nmero(s) de telefone para discar quando ocorre um evento de sensor.
Quando um evento de sensor reconhecido, o software aciona um alarme sonoro agregado ao
sistema. Aps um tempo de espera que especificado pelo proprietrio do imvel durante as atividades
de configurao do sistema, o software disca um nmero de telefone de um servio de monitoramento,
fornece informaes sobre o local, relatando a natureza do evento detectado. O nmero de telefone ser
rediscado a cada 20 segundos at que seja completada a ligao telefnica.
O proprietrio do imvel recebe informaes de segurana atravs de um painel de controle, do PC
ou de um navegador, coletivamente denominados de interface. A interface mostra mensagens de aviso
bem como informaes sobre o estado do sistema no painel de controle, no PC ou na janela do navegador. A interao com o proprietrio do imvel assume a seguinte forma...

Referindo-se anlise sinttica, os verbos so processos do CasaSegura e podem ser representados como bolhas em um DFD subsequente. Os substantivos podem ser entidades externas (retngulos), objetos de controle ou de dados (setas) ou ento repositrios de dados (linhas duplas).
Da discusso do Captulo 6, lembre-se de que os substantivos e verbos podem ser associados
entre si (por exemplo, so atribudos um nmero e um tipo a cada sensor; dessa forma, nmero e
tipo so atributos do objeto de dados sensor). Consequentemente, realizando uma anlise sinttica na narrativa de processamento para uma bolha em qualquer nvel DFD, podemos gerar muitas
informaes teis sobre como prosseguir com o refinamento para o prximo nvel. Usando essas
informaes, mostrado um DFD nvel 1 na Figura 7.2. O processo no nvel de contexto mostrado
na Figura 7.1 foi expandido em seis processos obtidos do exame da anlise sinttica. De modo

184

PARTE DOIS MODELAGEM

Figura 7.2

Painel de
controle

DFD nvel 1 para


a funo de
segurana do
CasaSegura

Comandos e dados
do usurio

Pedido de
configurao

Interagir
com o
usurio
Senha

Iniciar
parar

Processar
senha

Sensores

Configurar
sistema

Informaes de configurao

Ativar/
desativar
sistema

Mensagem de
ID vlido
Dados de
configurao

Estado
do sensor

Dados de
configurao

Monitorar
sensores

Informaes
Mensagem de exibio
de Ativ./
Desativ.
Exibir
mensagens
e estado
Informaes
dos sensores
Tipo de alarme

Informaes
de exibio

Exibio do
painel de
controle
Alarme
Linha
telefnica

Toques de telefone

similar, o fluxo de informaes entre processos no nvel 1 foi extrado da anlise sinttica. Alm
disso, a continuidade do fluxo de informaes mantida entre os nveis 0 e 1.
Os processos representados no nvel 1 do DFD podem ser mais refinados em nveis mais
baixos. Por exemplo, o processo monitorar sensores pode ser refinado em um DFD nvel 2, conforme mostra a Figura 7.3. Note mais uma vez que a continuidade do fluxo de informaes foi
mantida entre os nveis.
O refinamento de DFDs prossegue at que cada bolha realize uma simples funo. At que o
processo representado pela bolha realize uma funo que seria facilmente implementada como
componente de um programa. No Captulo 8, discutiremos um conceito, chamado coeso, que
pode ser usado para avaliar o foco do processamento de determinada funo. Por enquanto, nos
esforaremos para refinar os DFDs at que cada bolha tenha um nico objetivo.
Figura 7.3
DFD nvel 2 que
refina o processo
monitorar sensores

Formatar
para exibio
Informaes de configurao
Dados de
configurao

Sensores
de leitura
Estado
do sensor

Identificao,
tipo e
localizao
do sensor
Avaliar com
base na
configurao
ID de sensor,
tipo

Informaes
dos sensores

Gerar sinal
de alarme
Dados de
alarme
Nmero
do telefone
Discar
telefone
Toques
de telefone

Tipo de
alarme

captulo 7 Modelagem de Requisitos: Fluxo, Comportamento, Padres e Aplicaes Baseadas na Web (WebApp)

185

7.2.2Criao de um modelo de fluxo de controle


Para alguns tipos de aplicaes, o modelo de dados e o diagrama de fluxo de dados bastam
para ter uma viso dos requisitos de software. Entretanto, conforme j citado, um grande grupo de aplicaes dirigido por eventos e no por dados, produzem informaes de controle
em vez de relatrios ou telas e processam informaes com grande preocupao com o tempo
e desempenho. Tais aplicaes requerem o uso da modelagem de fluxo de controle, alm da
modelagem de fluxo de dados.
J vimos que um item de evento ou controle implementado como um valor booleano (por
exemplo, verdadeiro ou falso, ligado ou desligado, 1 ou 0) ou como uma lista discreta de condies (por exemplo, vazio, bloqueado, cheio). Para escolher eventos possveis candidatos a
eventos, sugerem-se as seguintes diretrizes:
escolher
? Como
eventos

Listar todos os sensores lidos pelo software.


Listar todas as condies de interrupo.
Listar todas as chaves acionadas por um operador.
Listar todas as condies de dados.
Recapitular a anlise sinttica de substantivos/verbos aplicada narrativa de processamento, revisar todos os itens de controle como possveis entradas/sadas de especificao de controle.
Descrever o comportamento de um sistema por meio da identificao de seus estados, de
como cada estado atingido e definir as transies entre os estados.
Concentrar-se em possveis omisses um erro muito comum na especificao de controles; por exemplo, perguntar: Existe alguma outra maneira de chegarmos ou sairmos
desse estado?.

potenciais para
um diagrama de
fluxo de controle,
um diagrama de
estados ou uma
CSPEC?

Entre os muitos itens de eventos e de controle que fazem parte do software CasaSegura temos evento de sensor (isto , um sensor foi acionado), flag piscante (um sinal para fazer
com que a exibio fique piscando) e iniciar/parar chave (um sinal para ligar ou desligar o
sistema).

7.2.3A especificao de controles


Uma especificao de controle (control specification, CSPEC) representa o comportamento do
sistema (no nvel em que foi referido) de duas maneiras diferentes.3 A CSPEC contm um diagrama de estados que uma especificao de comportamento sequencial. Ela tambm pode conter
uma tabela de ativao de programas uma especificao de comportamento combinatria.
A Figura 7.4 representa um diagrama de estados4 preliminar para o modelo de fluxo de controle nvel 1 para o CasaSegura. O diagrama indica como o sistema responde a eventos medida
que passa pelos quatro estados definidos nesse nvel. Atravs da reviso de diagramas de estados, podemos determinar o comportamento do sistema e, mais importante ainda, determinar se
h furos no comportamento especificado.
Por exemplo, o diagrama de estados (Figura 7.4) indica que as transies do estado Ocioso
podem ocorrer se o sistema for reinicializado, ativado ou desligado. Se o sistema for ativado
(isto , o sistema de alarme for ligado), a transio para o estado MonitorandoEstadoDoSistema ocorre, as mensagens de tela so alteradas como mostrado e o processo monitorarEControlarSistema chamado. Ocorrem duas transies do estado MonitorandoEstadoDoSistema
(1) quando o sistema desativado, ocorre uma transio de volta para o estado Ocioso; (2)

3
4

Outras notaes referentes modelagem comportamental so apresentadas na Seo 7.3.


A notao de diagramas de estados aqui usada est em conformidade com a notao da UML. Um diagrama de transio
de estados se encontra disponvel na anlise estruturada, porm, o formato UML superior em termos de representao e
contedo de informaes.

186

PARTE DOIS MODELAGEM

Figura 7.4
Diagrama de
estados para a
funo de
segurana do
CasaSegura
Reiniciando
Ligar / desligar
chave de fora

NaEntrada / ajustar EstadoDoSistema para inativo


NaEntrada / ajustar a exibio de Msg1 para
Iniciando sistema
NaEntrada / ajustar a exibio de Msg2 para Aguarde
NaEntrada / ajustar a exibio de Estado para
piscandoLentamente
Faa: executar diagnstico

Sistema OK
Reiniciar

Ativar
Falha detectada / ajustar a exibio
de Msg2 para Contatar fornecedor
MonitorandoEstadoDoSistema
NaEntrada / ajustar EstadoDoSistema para monitorando
NaEntrada / ajustar a exibio de Msg1 para Armado
NaEntrada / ajustar a exibio de Msg2 para
NaEntrada / ajustar a exibio de Estado para firme
Faa: monitorarEControlarSistema
TeclaApertada / tratarTecla

senhaParaDesativar

alarmeFalso
tempoEsgotado

sensorDisparado/
iniciarTimer

Ocioso
NaEntrada / ajustar EstadoDoSistema para inativo
NaEntrada / ajustar a exibio de Msg1 para Pronto
NaEntrada / ajustar a exibio de Msg2 para
NaEntrada / ajustar a exibio de Estado para firme
TeclaApertada / tratarTecla
desligue/Desligar

senhaParaDesativar
AgindoEmDecorrnciaDeAlarme
NaEntrada / ajustar EstadoDoSistema para
monitorarESoarAlarme
NaEntrada / ajustar a exibio de Msg1 para ALARME
NaEntrada / ajustar a exibio de Msg2 para
disparandoSensor
NaEntrada / ajustar a exibio de Estado para
piscandoRapidamente
Faa monitorarEControlarSistema
Faa = soarAlarme
Faa: NotificarOsQueRespondemAoAlarme
TeclaApertada / tratarTecla

sensorDisparado/
reiniciarTimer

quando um sensor ativado, uma transio para o estado AgindoEmDecorrenciaDeAlarme.


Todas as transies e o contedo de todos os estados so considerados durante a reviso.
Um modo ligeiramente distinto de representao comportamental a tabela de ativao de
processos (process activation table, PAT). A PAT representa informaes contidas em diagramas
de estados no contexto de processos, e no de estados. A tabela indica quais processos (bolhas)
no modelo de fluxos sero chamados quando um evento ocorrer. A PAT pode ser usada como
guia para um projetista que tem de construir um executvel que controla os processos representados nesse nvel. Uma PAT para o modelo de fluxos nvel 1 do software CasaSegura mostrada
na Figura 7.5.
A CSPEC descreve o comportamento do sistema, mas no nos d nenhuma informao sobre
o funcionamento interno dos processos ativados como resultado desse comportamento. A notao de modelagem que fornece essas informaes discutida na Seo 7.2.4.

7.2.4A especificao de processos


A especificao de processos (process specification, PSPEC) usada para descrever todos
os processos do modelo de fluxo que aparecem no nvel final de refinamento. O contedo da
especificao de processos pode incluir texto narrativo, uma descrio5 em PDL (linguagem de
projeto de programas) do algoritmo de processos, equaes matemticas, tabelas ou diagramas
5

A linguagem de projeto de programas (PDL) mistura sintaxe de linguagem de programao com texto narrativo para oferecer
um projeto procedural detalhado. A PDL discutida rapidamente no Captulo 10.

captulo 7 Modelagem de Requisitos: Fluxo, Comportamento, Padres e Aplicaes Baseadas na Web (WebApp)

187

Figura 7.5
Tabela de ativao
de processos para a
funo de segurana
do CasaSegura

eventos de entrada
evento de sensor
flag piscante
iniciar/parar chave
exibir status de ao completa
em andamento
tempo esgotado

0
0
0
0
0
0

0
0
1
0
0
0

0
1
0
0
1
0

0
1
0
1
0
0

1
0
0
0
0
0

0
0
0
0
0
1

0
0
1
1

1
1
0
0

0
0
1
0

0
0
1
1

1
0
1
0

1
0
1
1

sada
sinal de alarme
ativao de processos
monitorar e controlar sistema
ativar/desativar sistema
exibir mensagens e estado
interagir com o usurio

C asa S egura
Modelagem de fluxo de dados
Cena: Sala do Jamie, aps a ltima reunio
para levantamento de requisitos.
Atores: Jamie, Vinod e Ed todos membros da equipe de
engenharia de software do CasaSegura.
Conversa:
(Jamie esboou os modelos apresentados nas Figuras 7.1 a 7.5
e est mostrando-os para Ed e Vinod.)
Jamie: Tive um curso de engenharia de software na faculdade e eles nos ensinaram essa matria. O professor disse que
um tanto antigo, mas, quer saber, ajuda-me a esclarecer certos
pontos.
Ed: Isso excelente. Mas no estou vendo nenhuma classe ou
objeto a.
Jamie: No... Trata-se apenas de um modelo de fluxos com
algo sobre seu comportamento no meio dele.
Vinod: Ento estes DFDs representam uma viso E-P-S do
software, no mesmo?
Ed: E-P-S?
Vinod: Entrada-processo-sada. Os DFDs so, na verdade,
bastante intuitivos... Se voc examin-los por um momento, eles

PSPEC uma
miniespecificao
para cada
transformao no
nvel mais baixo de
refinamento de um
DFD.

mostram como os objetos de dados fluem atravs do sistema e


so transformados medida que fluem.
Ed: Parece que poderamos converter cada bolha em um componente executvel... Pelo menos no nvel mais baixo do DFD.
Jamie: interessante, podemos fazer isso. De fato, existe uma maneira de transformarmos os DFDs em uma arquitetura de projeto.
Ed: Verdade?
Jamie: Isso mesmo, mas primeiro temos que desenvolver um
modelo de requisitos completo e, no momento, ele no est.
Vinod: Bem, esta a primeira etapa, mas tambm teremos que
tratar os elementos baseados em classes, bem como os aspectos
comportamentais, embora o diagrama de estados e a PAT j
faam uma parte disso.
Ed: Temos muito trabalho pela frente e no muito tempo para
faz-lo. (Doug o gerente de engenharia de software entra
na sala.)
Doug: Portanto, os prximos dias sero gastos no desenvolvimento do modelo de requisitos, no mesmo?
Jamie (expressando orgulho): J comeamos.
Doug: Muito bem, temos muito trabalho pela frente e no muito
tempo para faz-lo.
(Os trs engenheiros de software se entreolham e sorriem.)

de atividades UML. Ao juntarmos uma PSPEC a cada bolha no modelo de fluxos, podemos criar
uma miniespecificao que sirva como guia para o projeto do componente de software que
ir implementar a bolha.
Para ilustrarmos o uso da PSPEC, consideremos a transformao processar senha representada no modelo de fluxos do CasaSegura (Figura 7.2). A PSPEC para essa funo poderia adquirir
a seguinte forma:
PSPEC: processar senha (no painel de controle). A transformao processar senha realiza a validao de senhas no painel de controle para a funo de segurana do CasaSegura. Processar senha re-

188

paRtE doiS

MoDeLaGeM

cebe uma senha de quatro dgitos da funo interagir com o usurio. Primeiro, a senha comparada com a
senha-mestra armazenada no sistema. Se a senha-mestra coincidir, <valid id message = true> passada
para a funo mostrar mensagem e status. Se a senha-mestra no coincidir, os quatro dgitos so comparados com uma tabela de senhas secundrias (essas poderiam ser atribudas a convidados e/ou empregados
que precisam ter acesso casa quando o proprietrio no est presente). Se a senha coincidir com uma
entrada da tabela, <valid id message = true> passado para a funo mostrar mensagem e status. Caso
no coincida, <valid id message = false> passado para a funo mostrar mensagem e status.

Caso sejam necessrios mais detalhes sobre o algoritmo nesse estgio, uma representao
PDL tambm poderia ser includa como parte da PSPEC. Entretanto, muitos acreditam que a
verso PDL deva ser postergada at que se inicie o projeto de componentes.
6

FERRAMENTAS DO SOFTWARE
Anlise estruturada
Objetivo: As ferramentas de anlise estruturada
permitem a um engenheiro de software criar modelos de dados, modelos de uxos e modelos comportamentais
para possibilitar a verificao de consistncia e continuidade,
bem como fcil edio e extenso. Os modelos criados empregando-se tais ferramentas fornecem ao engenheiro de software uma viso da representao de anlise e podem ajudar
a eliminar erros antes que se propaguem pelo projeto ou, pior
ainda, na prpria implementao.
Mecnica: Ferramentas nessa categoria usam um dicionrio
de dados como banco de dados central para a descrio
de todos os objetos de dados. Uma vez que as entradas no
dicionrio tenham sido definidas, os diagramas entidade-relacionamento podem ser criados e as hierarquias de objetos
podem ser desenvolvidas. Os recursos dos diagramas de uxo
de dados permitem criar facilmente esse modelo grfico, bem
como fornecem recursos para a criao de PSPECs e CSPECs.

7.3

? Como
modelar

a reao do
software a algum
evento externo?

Criao

de um

As ferramentas de anlise tambm possibilitam que o engenheiro de software crie modelos comportamentais usando o
diagrama de estados como notao efetiva.
Ferramentas representativas:6
MacA&D, WinA&D, desenvolvidas pela Excel software (www.
excelsoftware.com), oferece um conjunto de ferramentas simples e baratas para anlise e projeto tanto para mquinas Macs quanto Windows.
MetaCASE Workbench, desenvolvida pela MetaCase Consulting (www.metacase.com), uma metaferramenta usada para definir um mtodo de anlise ou projeto (inclusive
anlise estruturada), bem como seus conceitos, regras,
notaes e geradores.
System Architect, desenvolvida pela Popkin Software (www.
popkin.com) oferece uma ampla gama de ferramentas
de anlise e projeto, inclusive ferramentas para modelagem de dados e anlise estruturada.

m o d e l o C o m P o r ta m e n ta l

A notao de modelagem discutida aqui at ento representa elementos estticos do modelo


de requisitos. chegado o momento de fazermos uma transio para o comportamento dinmico do sistema ou produto. Para tanto, precisamos representar o comportamento do sistema
em funo do tempo e eventos especficos.
O modelo comportamental indica como o software ir responder a estmulos ou eventos externos. Para cri-lo, devemos executar as seguintes etapas:
1. Avaliar todos os casos de uso para entender completamente a sequncia de interao dentro
do sistema.
2. Identificar eventos que dirigem a sequncia de interaes e compreender como esses eventos se relacionam com objetos especficos.
3. Criar uma sequncia para cada caso de uso.
4. Construir um diagrama de estados para o sistema.
5. Revisar o modelo comportamental para verificar preciso e consistncia.
Cada uma dessas etapas discutida nas sees a seguir.
6

As ferramentas aqui apresentadas no significam um aval, mas sim uma amostra dessa categoria. Na maioria dos casos, seus
nomes so marcas registradas pelos respectivos desenvolvedores.

captulo 7 Modelagem de Requisitos: Fluxo, Comportamento, Padres e Aplicaes Baseadas na Web (WebApp)

189

7.3.1Identificao de eventos com o caso de uso


No Captulo 6 vimos que o caso de uso representa uma sequncia de atividades que envolve
atores e o sistema. Em geral, um evento ocorre toda vez que o sistema e um ator trocam informaes. Na Seo 7.2.3, indicamos que um evento no a informao que foi trocada, mas sim
o fato de que as informaes foram trocadas.
Um caso de uso examinado para encontrar pontos de troca de informao. Para ilustrarmos, reconsideremos o caso de uso de uma pequena parte da funo de segurana do
CasaSegura.
O proprietrio usa o teclado numrico para digitar uma senha de quatro dgitos. A senha comparada
com a senha vlida armazenada no sistema. Se a senha for incorreta, o painel de controle emitir um
bipe e se reiniciar para receber novas entradas. Se a senha for correta, o painel de controle aguarda
as prximas aes.

Os trechos sublinhados do cenrio do caso de uso indicam eventos. Deve se identificar um


ator para cada evento; as informaes trocadas devem ser indicadas e quaisquer condies ou
restries devem ser enumeradas.
Como um exemplo tpico de evento, consideremos o trecho sublinhado do caso de uso proprietrio usa o teclado numrico para digitar uma senha de quatro dgitos. No contexto do
modelo de requisitos, o objeto, Proprietrio,7 transmite um evento para o objeto PainelDeControle. O evento poderia ser chamado entrada de senha. As informaes transferidas so os
quatro dgitos que constituem a senha, mas essa no parte essencial do modelo comportamental. importante notar que alguns eventos tm um impacto explcito no fluxo de controle
do caso de uso, ao passo que outros no tm impacto direto no fluxo de controle. Por exemplo,
o evento entrada de senha no muda explicitamente o fluxo de controle do caso de uso, mas os
resultados do evento entrada de senha (derivado da interao senha comparada com a senha
vlida armazenada no sistema) ter um impacto explcito no fluxo de controle e informaes
do software CasaSegura.
Uma vez que todos os eventos tenham sido identificados, so alocados aos objetos envolvidos. Os objetos podem ser responsveis pela gerao de eventos (por exemplo, Proprietrio gera um evento entrada de senha) ou reconhece eventos que ocorreram em algum outro
ponto (por exemplo, PainelDeControle reconhece o resultado binrio do evento comparao
de senha).

7.3.2 Representaes de estados

O sistema possui
estados que
representam
comportamento
especfico
externamente
observvel; uma
classe possui estados
que representam seu
comportamento
medida que o sistema
executa suas funes.

No contexto da modelagem comportamental, devem ser consideradas duas caracterizaes


de estados distintas: (1) o estado de cada classe medida que o sistema executa sua funo e (2)
o estado do sistema como observado de fora medida que o sistema executa sua funo.8
O estado de uma classe pode assumir tanto caractersticas passivas quanto ativas [Cha93].
Estado passivo o estado atual de todos os atributos de um objeto. Por exemplo, o estado passivo da classe Jogador (na aplicao de videogame discutida no Captulo 6) incluiria atributos
referentes posio e orientao atual do Jogador, bem como outros recursos do Jogador relevantes ao jogo (por exemplo, um atributo que indique permanncia de desejos mgicos). O estado
ativo de um objeto indica o estado atual do objeto medida que passa por uma transformao
ou processamento contnuo. A classe Jogador poderia ter os seguintes estados ativos: em movimento, em repouso, contundido, recuperando-se no departamento mdico; preso, perdido e
assim por diante. Deve acontecer um evento (algumas vezes denominado gatilho). Para forar
um objeto a fazer uma transio de um estado ativo para outro.
7
8

Neste exemplo, partimos do pressuposto de que cada usurio (proprietrio do imvel) que interage com o CasaSegura possui
uma senha de identificao e , consequentemente, um objeto legtimo.
Os diagramas de estados apresentados no Captulo 6 e na Seo 7.3.2 representam o estado do sistema. Nossa discusso
nessa seo ir se concentrar no estado de cada classe do modelo de anlise.

190

PARTE DOIS MODELAGEM

Nos prximos pargrafos sero discutidas duas representaes comportamentais distintas.


A primeira indica como determinada classe muda de estado baseada em eventos externos e a
segunda mostra o comportamento do software em funo do tempo.
Diagramas de estados para classes de anlise. O componente de um modelo comportamental um diagrama de estados9 UML que representa estados ativos para cada uma das
classes e para os eventos (gatilhos) que provocam mudanas entre esses estados ativos. A Figura
7.6 ilustra um diagrama de estados para o objeto PainelDeControle na funo de segurana
CasaSegura.
Cada seta da Figura 7.6 representa a transio de um estado ativo de um objeto para outro. As
identificaes em cada seta representam o evento que dispara a transio. Embora o modelo de
estados ativos d uma viso proveitosa sobre a histria de vida de um objeto, possvel especificar informaes adicionais para uma maior profundidade no entendimento do comportamento
de um objeto. Alm de especificarmos o evento que faz com que a transio ocorra, podemos especificar um guarda e uma ao [Cha93]. Guarda uma condio booleana que deve ser satisfeita
de modo que a transio ocorra. Por exemplo, o guarda para a transio do estado lendo para o
estado comparando na Figura 7.6 pode ser determinado examinando-se o caso de uso:
if (entrada de senha = 4 digitos) ento compare com a senha armazenada
Em geral, o guarda para uma transio normalmente depende do valor de um ou mais atributos de um objeto. Em outras palavras, o guarda depende do estado passivo do objeto.
Uma ao ocorre concorrentemente com a transio de estado ou como consequncia dele
e geralmente envolve uma ou mais operaes (responsabilidades) do objeto. Por exemplo, a
ao ligada ao evento entrada de senha (Figura 7.6) uma operao chamada validarSenha()
que acessa um objeto senha e realiza uma comparao dgito por dgito para validar a senha
introduzida.

Figura 7.6

Timer Tempo de Bloqueio

Diagrama de estados
para a classe
PainelDeControle

Timer > Tempo de Bloqueio

Bloqueado

Senha = incorreta
& numeroDeTentativas
< maxTentativas
Acionamento
de tecla

Lendo

Comparando
Senha
introduzida Faa: validarSenha

numeroDeTentativas > maxTentativas

Senha = correta
Selecionando

Ativao com sucesso

Caso no esteja familiarizado com a UML, apresentamos uma breve introduo a essa importante notao de modelagem no
Apndice 1.

captulo 7 Modelagem de Requisitos: Fluxo, Comportamento, Padres e Aplicaes Baseadas na Web (WebApp)

Diferentemente de um
diagrama de estados
que representa
comportamento
sem citar as
classes envolvidas,
um diagrama de
sequncia representa
comportamento
descrevendo como as
classes passam de um
estado para outro.

191

Diagramas de sequncia. O segundo tipo de representao comportamental, denominado


diagrama de sequncia em UML, indica como os eventos provocam transies de objeto para
objeto. Uma vez que os eventos tenham sido identificados pelo exame de um caso de uso, o modelador cria um diagrama de sequncia uma representao de como os eventos provocam o
fluxo de um objeto para outro em funo do tempo. Em resumo, o diagrama de sequncia uma
verso abreviada do caso de uso. Ele representa classes-chave e os eventos que fazem com que
o comportamento flua de classe para classe.
A Figura 7.7 ilustra um diagrama de sequncia parcial para a funo de segurana do CasaSegura. Cada uma das setas representa um evento (derivado de um caso de uso) e indica como
o evento canaliza o comportamento entre os objetos do CasaSegura. O tempo medido verticalmente (de cima para baixo), e os retngulos estreitos na vertical representam o tempo gasto
no processamento de uma atividade. Os estados poderiam ser mostrados ao longo de uma linha
do tempo vertical.
O primeiro evento, sistema pronto, derivado do ambiente externo e canaliza comportamento para o objeto Proprietrio. O proprietrio do imvel introduz uma senha. Um evento
de solicitao de busca passado para Sistema, que busca uma senha em um banco de dados
simples e retorna um resultado (encontrada ou no encontrada) para PainelDeControle (agora
no estado comparando). Uma senha vlida resulta em um evento senha=correta para Sistema,
que ativa Sensores com um evento solicitao de ativao. Por fim, o controle retorna ao proprietrio com o evento ativao com sucesso.
Assim que um diagrama de sequncia completo tiver sido desenvolvido, todos os eventos
que provocam transies entre objetos do sistema podem ser reunidos em um conjunto de
eventos de entrada e eventos de sada (de um objeto). Essas informaes so teis na criao
de um projeto efetivo para o sistema a ser construdo.

Figura 7.7
Diagrama de
sequncia
(parcial)
para a
funo de
segurana do
CasaSegura

Sistema
pronto

Sensores

Sistema

Painel de controle

Proprietrio

Lendo

Senha introduzida
Comparando

Resultado
Senha = correta

numeroDeTentativas >
maxTentativas
A

Solicitao de busca

Bloqueando
Timer >
Tempo de bloqueio

Solicitao de ativao

Selecionando
Ativao com sucesso

Ativao com sucesso

192

paRtE doiS

MoDeLaGeM

FERRAMENTAS DO SOFTWARE
Modelagem de anlise generalizada em UML
Objetivo: As ferramentas de modelagem de anlise fornecem a capacidade de desenvolver modelos baseados
em cenrios, modelos baseados em classes e modelos comportamentais usando a notao UML.
Mecnica: As ferramentas nesta categoria suportam todo
o conjunto de diagramas UML necessrios para construir
um modelo de anlise (as ferramentas tambm do suporte
modelagem de projeto). Alm da diagramao, elas (1)
realizam verificao de consistncia e correo para todos
os diagramas UML, (2) fornecem links para projeto e gerao
de cdigo, (3) constroem um banco de dados que permite o
gerenciamento e a avaliao de grandes modelos UML necessrios para sistemas complexos.

Ferramentas representativas:10
As seguintes ferramentas suportam todo o conjunto de diagramas UML necessrio para a modelagem de anlise:
ArgoUML uma ferramenta com cdigo-fonte aberto disponvel em argouml.tigris.org.
Enterprise Architect, desenvolvida pela Sparx Systems
(www.sparxsystems.com.au).
PowerDesigner, desenvolvida pela Sybase
(www.sybase.com).
Rational Rose, desenvolvida pela IBM (rational)
(www01.ibm.com/software/rational/).
System Architect, desenvolvida pela Popkin Software
(www.popkin.com).
UML Studio, desenvolvida pela Pragsoft Corporation
(www.pragsoft.com).
Visio, desenvolvida pela Microsoft (www.microsoft.com).
Visual UML, desenvolvida pela Visual Object Modelers (www.
visualuml.com).

10

7 .4

Padres Para

modelagem

de

requisitos

Padres de software constituem um mecanismo para capturar conhecimento do domnio


acumulado para permitir que seja reaplicado quando um novo problema encontrado. Em alguns casos, o conhecimento do domnio aplicado a um novo problema no mesmo domnio
de aplicao. Em outros casos, o conhecimento do domnio capturado por um padro pode ser
aplicado por analogia a um domnio de aplicao completamente diferente.
O autor original de um padro de anlise no cria o padro, mas sim, o descobre medida
que o fluxo de trabalho de levantamento de requisitos conduzido. Assim que o padro tiver
sido descoberto, documentado descrevendo-se explicitamente o problema geral ao qual o padro se aplica, a soluo recomendada, hipteses e restries do emprego do padro na prtica
e em geral algumas outras informaes sobre o padro, como a motivao e as foras que orientam o uso do padro, discusso das vantagens e desvantagens do padro, bem como referncias
para alguns exemplos conhecidos do uso desse padro em aplicaes prticas. [Dev01].
No Captulo 5, introduzimos o conceito de padres de anlise e indicamos que padres representam uma soluo que frequentemente incorpora uma classe, funo ou comportamento
em um campo de aplicao. O padro pode ser reutilizado ao se realizar a modelagem de requisitos para uma aplicao em um domnio.11 Os padres de anlise so armazenados em um
repositrio de modo que os membros da equipe de software possam usar recursos de pesquisa
para encontr-los e reutiliz-los. Assim que um padro apropriado tiver sido selecionado, integrado ao modelo de requisitos por meio de referncia ao nome do padro.

7.4.1

descoberta de padres de anlise

O modelo de requisitos formado por uma ampla gama de elementos: baseados em cenrios (casos de uso), orientados a dados (o modelo de dados), baseados em classes, orientados
a fluxos e comportamentais. Cada um deles examina o problema segundo uma perspectiva e
cada uma delas proporciona a descoberta de padres que poderiam ocorrer em um domnio de
aplicao, ou por analogia, em domnios de aplicao diferentes.
10 As ferramentas aqui apresentadas no significam um aval, mas sim uma amostra dessa categoria. Na maioria dos casos, seus
nomes so marcas registradas pelos respectivos desenvolvedores.
11 Uma discusso aprofundada do uso de padres durante o projeto de software apresentada no Captulo 12.

captulo 7 Modelagem de Requisitos: Fluxo, Comportamento, Padres e Aplicaes Baseadas na Web (WebApp)

193

O elemento mais bsico na descrio de um modelo de requisitos o caso de uso. No contexto desta discusso, um conjunto coerente de casos de uso poderia servir como base para descobrir um ou mais padres de anlise. Padro de anlise semntica (semantic analysis pattern,
SAP) descreve um pequeno conjunto de casos de uso coerentes que juntos descrevem uma
aplicao genrica bsica [Fer00].
Consideremos o seguinte caso de uso preliminar para um software necessrio para controlar
e monitorar um sensor de proximidade e cmera de visualizao real para um automvel:
Caso de uso: Monitorar deslocamento em marcha a r
Descrio: Quando o veculo colocado em marcha a r, o software de controle habilita um alimentador
de vdeo por meio de uma cmera de vdeo colocada atrs do painel de comandos. O software de controle
sobrepe uma variedade de linhas de orientao e distncias na exibio do painel de comandos de modo
que o condutor do veculo possa ser orientado medida que se desloca em marcha a r. O software de
controle tambm monitora um sensor de proximidade para determinar se um objeto se encontra ou no a
3 m da traseira do veculo. Ele ir frear o veculo automaticamente se o sensor de proximidade indicar um
objeto a x metros da traseira do veculo, em que x determinado com base na velocidade do veculo.

Esse caso de uso implica uma funcionalidade muito variada que poderia ser refinada e elaborada (em um conjunto de casos de uso coerentes) durante o levantamento de requisitos e a modelagem. Independentemente do nvel de elaborao alcanado, os casos de uso sugerem um
SAP simples, porm de larga aplicao o monitoramento e controle de sensores e atuadores
baseado em software em um sistema fsico. Nesse caso, os sensores fornecem informaes
sobre proximidade e informaes de vdeo. O atuador o sistema de frenagem do veculo
(acionado caso um objeto esteja muito prximo do veculo). Porm, em um caso mais genrico,
se descobre um padro de larga aplicao.
Diferentes domnios de aplicao para monitorar sensores e controlar atuadores fsicos necessitam de software. Um padro de anlise que descreva requisitos genricos para essa capacidade poderia ser utilizado largamente. O padro, denominado Atuador-Sensor , seria aplicvel
como parte do modelo de requisitos do CasaSegura e discutido na Seo 7.4.2, a seguir.

7.4.2 Exemplo de padro de requisitos: atuador-sensor12


Um dos requisitos da funo de segurana do CasaSegura a habilidade de monitorar sensores de segurana (por exemplo, sensores contra roubos, sensores de fogo, fumaa ou CO,
sensores de gua).
Extenses para o CasaSegura baseadas na Internet exigiram a capacidade de controlar o movimento (por exemplo, deslocamento horizontal e vertical, ampliao/reduo) de uma cmera
de segurana no interior de uma residncia. A implicao o software CasaSegura deve gerenciar vrios sensores e atuadores (por exemplo, mecanismos de controle de cmera).
Konrad e Cheng [Kon02] sugeriram um padro de requisitos chamado Atuador-Sensor que
fornece uma til orientao para modelar esses requisitos no software CasaSegura. Uma verso
abreviada do padro Atuador-Sensor, originalmente desenvolvido para aplicaes na indstria automobilstica, apresentada a seguir.
Nome do Padro. Atuador-Sensor
Intuito. Especificar vrios tipos de sensores e atuadores em um sistema embutido.
Motivo. Os sistemas embarcados normalmente possuem vrios tipos de sensores e atua
dores. Esses sensores e atuadores esto todos direta ou indiretamente conectados a uma
unidade de controle. Embora muitos sensores e atuadores paream bem diferentes, seu comportamento suficientemente similar para estrutur-los em um padro. O padro mostra
como especificar os sensores e atuadores para um sistema, inclusive atributos e operaes.
O padro Atuador-Sensor usa um mecanismo pull (solicitao explcita de informao)
12 Essa seo foi adaptada de [Kon02] com a permisso dos autores.

194

PARTE DOIS MODELAGEM

para PassiveSensors (SensoresPassivos) e um mecanismo push (difuso de informao) para os ActiveSensors (SensoresAtivos).
Restries
Cada sensor passivo deve ter algum mtodo para ler entrada de sensores e atributos que
representam o valor do sensor.
Cada sensor ativo deve ter capacidades para transmitir mensagens de atualizao quando seu valor muda.
Cada sensor ativo deve enviar um sinal de vida, uma mensagem de estado emitida em
determinado intervalo de tempo, para detectar defeitos.
Cada atuador deve ter algum mtodo para chamar a resposta apropriada determinada por
ComputingComponent (ComponenteDeClculo).
Cada sensor e atuador deve ter uma funo implementada para verificar seu prprio estado de operao.
Cada sensor e atuador deve ser capaz de testar a validade dos valores recebidos ou enviados e estabelecer seu estado de operao caso os valores se encontrem fora das especificaes.
Aplicabilidade. til em qualquer sistema em que vrios sensores e atuadores esto presentes.
Estrutura. Um diagrama de classes UML para o padro Atuador-Sensor mostrado na
Figura 7.8. Atuador, PassiveSensor e ActiveSensor so classes abstratas e grafadas em
itlico. Existem quatro tipos diferentes de sensores e atuadores nesse padro.
As classes Boolean (Booleana), Integer (Inteira) e Real (Real) representam os tipos
mais comuns de sensores e atuadores. As classes complexas so sensores ou atuadores que
usam valores que no podem ser facilmente representados em termos de tipos de dados primitivos, como um dispositivo de radar. No obstante, tais dispositivos ainda deveriam herdar a
interface das classes abstratas j que elas deveriam ter funcionalidades bsicas como consulta
aos estados de operao.

Figura 7.8
Diagrama de
sequncia UML
para o padro
Atuador-Sensor.
Fonte: adaptado de
[Kon02] com permisso

Componente
de clculo

Sensor passivo
inteiro

Sensor passivo
booleano

Sensor
passivo real

Atuador

Atuador
booleano

Atuador real

Atuador
inteiro

Atuador
complexo

Sensor ativo
Sensor passivo
inteiro

Sensor passivo
complexo

Sensor ativo
booleano

Sensor ativo
real

Sensor ativo
inteiro

Sensor ativo
complexo

captulo 7 Modelagem de Requisitos: Fluxo, Comportamento, Padres e Aplicaes Baseadas na Web (WebApp)

195

Comportamento. A Figura 7.9 apresenta um diagrama de sequncia UML para um exemplo


do padro Atuador-Sensor j que ele poderia ser aplicado funo do CasaSegura que controla
o posicionamento (por exemplo, deslocamentos, ampliao/reduo) de uma cmera de segurana. Nesse caso, ControlPanel (PainelControle)13 consulta um sensor (um sensor de posio
passivo) e um atuador (controle de deslocamentos) para verificar o estado de operao para fins
de diagnstico antes de ler ou configurar um valor. As mensagens Set Physical Value (AjustarValorFsico) e Get Physical Value (ObterValorFsico) no so mensagens entre objetos. Em vez disso,
descrevem a interao entre os dispositivos fsicos do sistema e seus equivalentes em software.
Na parte inferior do diagrama, abaixo da linha horizontal, PositionSensor (SensorPosicional)
informa que o estado de operao zero. ComputingComponent (representada por ControlPanel) envia ento o cdigo de erro devido a uma falha no sensor de posio para FaultHandler
(ControleFalhas) que decidir como esse erro afeta o sistema e que medidas so necessrias. Ela
obtm os dados dos sensores e calcula a resposta necessria para os atuadores.
Participantes. Essa seo de descrio dos padres elenca as classes/objetos includos no
padro de requisitos [Kon02] e descreve as responsabilidades de cada classe/objeto (Figura
7.8). A seguir, temos uma lista resumida:






PassiveSensor abstract: Define uma interface para sensores passivos.


PassiveBooleanSensor: Define sensores passivos booleanos.
PassiveIntegerSensor: Define sensores passivos inteiros.
PassiveRealSensor: Define sensores passivos reais.
ActiveSensor abstract: Define uma interface para sensores ativos.
ActiveBooleanSensor: Define sensores ativos booleanos.
ActiveIntegerSensor: Define sensores ativos inteiros.

Figura 7.9
Diagrama
de classes
FaultHandler
UML para o
padro
Atuador-Sensor.
Fonte: reimpresso
de [Kon02]
com permisso

PositionSensor

ControlPanel

PanControl
Actuator

Sensor
InputDevice
PositionSensor

Obtm o estado
de operao
Obtm valor

(PositionSensor.
OpState = 1)

Configura o
valor fsico
Obtm estado
da operao
Configura o valor
Obtm o valor fsico

Obtm o estado
de operao
Armazena o erro

(PositionSensor.
OpState = 0)

13 O padro original usa o termo genrico ComputingComponent.

Actuator
OutputDevice
PanControl

196

PARTE DOIS MODELAGEM

ActiveRealSensor: Define sensores ativos reais.


Actuator abstract: Define uma interface para atuadores.
BooleanActuator: Define atuadores booleanos.
IntegerActuator: Define atuadores inteiros.
RealActuator: Define atuadores reais.
ComputingComponent: A parte principal do controlador; ele obtm os dados dos sensores e calcula a resposta necessria para os atuadores.
ActiveComplexSensor: Os sensores ativos complexos possuem a funcionalidade bsica da classe abstrata ActiveSensor, porm, mtodos e atributos adicionais mais elaborados precisam ser especificados.
PassiveComplexSensor: Os sensores passivos complexos possuem a funcionalidade
bsica da classe abstrata PassiveSensor, porm, mtodos e atributos adicionais mais
elaborados precisam ser especificados.
ComplexActuator: Os atuadores complexos tambm possuem a funcionalidade bsica
da classe abstrata Actuator, porm, mtodos e atributos adicionais mais elaborados
precisam ser especificados.

Colaboraes. Essa seo descreve como os objetos e as classes interagem entre si e como
cada uma delas cumpre suas obrigaes.
Quando ComputingComponent precisar atualizar o valor de um PassiveSensor,
ela consulta os sensores, solicitando o valor por meio do envio de uma mensagem
apropriada.
ActiveSensors no so consultados. Eles iniciam a transmisso de valores de sensor
para a unidade de clculo, usando o mtodo apropriado para configurar o valor no ComputingComponent. Eles enviam um sinal de vida pelo menos uma vez durante um
intervalo de tempo especificado para atualizar seus registros de horas com o horrio do
relgio do sistema.
Quando ComputingComponent precisar configurar o valor de um atuador, ela envia o
valor para o atuador.
ComputingComponent pode consultar e configurar o estado de operao dos sensores
e atuadores usando os mtodos apropriados. Se for constatado que um estado de operao zero, o erro enviado a FaultHandler, uma classe que contm mtodos para tratar
mensagens de erro como, por exemplo, acionar um mecanismo de recuperao mais elaborado ou um dispositivo de backup. Se a recuperao no for possvel, o sistema poder
usar apenas o ltimo valor conhecido do sensor ou o valor default .
ActiveSensors oferece mtodos para acrescentar ou remover os endereos ou intervalos de endereos dos componentes que querem receber as mensagens no caso de mudana de um valor.
Consequncias
1. As classes de sensores e atuadores possuem uma interface comum.
2. Os atributos de classes podem ser acessados apenas atravs de mensagens e a classe decide
se aceita ou no uma mensagem. Por exemplo, se o valor de um atuador estiver configurado
acima de seu valor mximo, a classe do atuador talvez no aceite a mensagem ou ento use
um valor mximo padro.
3. A complexidade do sistema potencialmente reduzida devido uniformidade das interfaces
para atuadores e sensores.
A descrio dos padres de requisitos tambm poderia fornecer referncias a outros padres
de projeto e de requisitos relacionados.

captulo 7 Modelagem de Requisitos: Fluxo, Comportamento, Padres e Aplicaes Baseadas na Web (WebApp)

7 .5

Modelagem

de

Requisitos

pa r a

197

W e b A pp s 14

Os desenvolvedores Web normalmente so cticos quando lhes sugerida a ideia de anlise


de requisitos para WebApps. Afinal de contas, argumentam eles, o processo de desenvolvimento para Web deve ser gil e a anlise toma muito tempo. Ela ir nos retardar quando simplesmente precisamos projetar e construir uma WebApp.
O levantamento de requisitos realmente toma tempo, porm resolver o problema errado
leva mais tempo ainda. A pergunta para cada desenvolvedor de WebApp simples voc tem
certeza de que entendeu os requisitos do problema? Se a resposta for um inequvoco sim,
poderia ser possvel pular a fase de modelagem de requisitos, porm se a resposta for no, a
modelagem de requisitos deve ser realizada.

7.5.1 Que nvel de anlise suficiente?


O grau com o qual a modelagem de requisitos para WebApps enfatizado depende dos seguintes fatores:
Tamanho e complexidade do incremento de WebApp.
Nmero de interessados (a anlise pode ajudar a identificar requisitos conflitantes provenientes de vrias fontes).
Tamanho da equipe de desenvolvimento de WebApps.
Nvel em que os membros da equipe de desenvolvimento de WebApps trabalharam juntos
antes (a anlise pode ajudar a desenvolver um entendimento comum do projeto).
Nvel de xito da organizao diretamente dependente do xito das WebApps.
O contrrio dos pontos anteriores que medida que um projeto se torna menor, que o nmero
de interessados diminui, que a equipe se torne mais coesa e a aplicao seja menos crtica,
razovel aplicar uma abordagem de anlise menos rgida.
Embora seja uma boa ideia analisar o problema antes de comear o projeto, no verdade
que toda anlise deve preceder todo o projeto. De fato, o projeto de uma parte especfica da WebApp exige apenas uma anlise daqueles requisitos que afetam apenas essa parte da WebApp. Um
exemplo para o CasaSegura: poderamos projetar de forma vlida toda a esttica do site (layouts,
esquemas de cores etc.) sem ter analisado as necessidades funcionais para recursos de comrcio eletrnico. Precisaramos analisar apenas aquela parte do problema relevante ao trabalho de
projeto do incremento a ser entregue.

7.5.2 Entrada da modelagem de requisitos


Uma verso gil do processo de software genrico discutido no Captulo 2 pode ser aplicada quando WebApps forem criadas. O processo incorpora uma atividade de comunicao que
identifica interessados e categorias de usurio, o contexto de negcio, metas de aplicao e de
informao definidas, requisitos gerais da WebApp e cenrios de uso as informaes se tornam entrada para a modelagem de requisitos. Estas so representadas na forma de descries
de linguagem natural, descries gerais, esboos e outras representaes de informao.
A anlise captura essas informaes, as estruturam usando um esquema de representao
formalmente definido (onde apropriado) e depois produz modelos mais rigorosos como sada.
O modelo de requisitos fornece uma indicao detalhada da verdadeira estrutura do problema e
d uma viso da forma da soluo.
A funo ACS-EVC (vigilncia atravs de cmeras) do CasaSegura foi introduzida no Captulo 6. Quando foi introduzida, essa funo parecia relativamente clara e foi descrita com
certo nvel de detalhamento como parte de um caso de uso (Seo 6.2.1). Entretanto, um
14 Essa seo foi adaptada de Pressman e Lowe [Pre08] com permisso.

198

PARTE DOIS MODELAGEM

reexame do caso de uso poderia revelar informaes que esto faltando, ambguas ou no
claras. Alguns aspectos de informaes faltantes emergiriam naturalmente durante o projeto.
Exemplos poderiam incluir o layout especfico dos botes de funo, seu aspecto esttico,
o tamanho das vises instantneas, a colocao de vises das cmeras e planta do imvel
ou at mesmo mincias como o comprimento mximo e mnimo das senhas. Alguns desses
aspectos so decises de projeto (como o layout dos botes) e outros so requisitos (como
o tamanho das senhas) que, fundamentalmente, no influenciam os trabalhos iniciais de
projeto.
Porm, algumas informaes faltantes poderiam realmente influenciar o prprio projeto como
um todo e estarem mais relacionadas a um real entendimento dos requisitos. Por exemplo:
P1:
P2:
P3:
P4:

Qual a resoluo de vdeo fornecida pelas cmeras do CasaSegura?


O que acontece se uma condio de alarme for encontrada enquanto a cmera estiver sendo monitorada?
Como o sistema manipula cmeras que possam ser deslocadas e ampliadas/
reduzidas?
Que informaes deveriam ser fornecidas juntamente com a viso das cmeras? (Por
exemplo, posio? hora/data? ltimo acesso anterior?)

Nenhuma dessas perguntas foram identificadas ou consideradas no desenvolvimento inicial do


caso de uso, muito embora as respostas poderiam ter um efeito substancial em diferentes aspectos do projeto.
Consequentemente, razovel concluir que embora a atividade de comunicao fornea
uma boa fundamentao para o entendimento, a anlise de requisitos refina esse entendimento
atravs de interpretaes adicionais. medida que a estrutura do problema delineada como
parte do modelo de requisitos, invariavelmente surgem perguntas. So essas perguntas que
preenchem as lacunas ou, em alguns casos, realmente nos ajudam, em primeiro lugar, a encontrar as lacunas.
Em suma, as entradas para o modelo de requisitos sero as informaes coletadas durante
a atividade de comunicao qualquer uma, desde um e-mail informal at uma descrio de
projeto detalhado contendo cenrios de uso e especificaes de produto completas.

7.5.3 Sada da modelagem de requisitos


A anlise de requisitos fornece um mecanismo disciplinado para representar e avaliar o contedo e funo de uma WebApp, os modos de interao que os usurios iro encontrar e o ambiente e a infraestrutura em que a WebApp reside.
Cada uma dessas caractersticas pode ser representada como um conjunto de modelos que
permitem que os requisitos da WebApp sejam analisados de maneira estruturada. Embora os
modelos especficos dependam em grande parte da natureza da WebApp, h cinco classes principais de modelos:
Modelo de contedo identifica o espectro completo do contedo a ser fornecido
pela WebApp. Contedo pode ser texto, grficos, imagens, vdeo e udio.
Modelo de interaes descreve a maneira atravs da qual os usurios interagem
com a WebApp.
Modelo funcional define as operaes que sero aplicadas ao contedo da WebApp
e descreve outras funes de processamento independentes do contedo, mas necessrias para o usurio final.
Modelo de navegao define a estratgia geral de navegao para a WebApp.
Modelo de configurao descreve o ambiente e a infraestrutura na qual a WebApp
reside.

captulo 7 Modelagem de Requisitos: Fluxo, Comportamento, Padres e Aplicaes Baseadas na Web (WebApp)

199

Podemos desenvolver cada um desses modelos usando um esquema de representao (em


geral chamado linguagem) que permite que seu intuito e estrutura sejam comunicados e avaliados facilmente entre os membros da equipe de engenharia de Web e outros interessados.
Como consequncia, vrias questes fundamentais (por exemplo, erros, omisses, inconsistncias, sugestes para aperfeioamento ou modificaes, pontos a ser esclarecidos) so identificadas e posteriormente trabalhadas.

7.5.4Modelo de contedo para WebApps


O modelo de contedo contm elementos estruturais que do uma viso importante dos requisitos de contedo para uma WebApp. Estes englobam objetos de contedo e todas as classes
de anlise entidades visveis aos usurios criadas ou manipuladas medida que o usurio
interage com a WebApp.15
O contedo pode ser desenvolvido antes da implementao da WebApp, enquanto a WebApp
est sendo construda ou bem depois de estar em funcionamento. Em todos os casos, ela incorporada via referncia navegacional na estrutura geral da WebApp. Um objeto de contedo poderia ser uma descrio textual de um produto, um artigo descrevendo um evento de noticirio,
uma fotografia de ao tirada durante um evento esportivo, a resposta de um usurio em um frum de discusso, uma animao do logotipo de uma empresa, um breve vdeo de apresentao
ou um udio agregado a um conjunto de slides de uma apresentao. Os objetos de contedo
poderiam ser armazenados como arquivos distintos, incorporados diretamente em pginas Web
ou obtidos dinamicamente de um banco de dados. Em outras palavras, um objeto de contedo
qualquer informao coesa que deve ser apresentada a um usurio final.
Os objetos de contedo podem ser determinados diretamente dos casos de uso, examinando-se a descrio do cenrio para referncias diretas e indiretas ao contedo. Por
exemplo, uma WebApp que oferecesse suporte ao CasaSegura seria estabelecida em CasaSeguraGarantida.com. Um caso de uso, Comprando Componentes Especficos do CasaSegura, descreve o cenrio necessrio para adquirir um componente do CasaSegura e contm
a seguinte sentena:
Serei capaz de obter informaes descritivas e de preo para cada componente do produto.

O modelo de contedo deve ser capaz de descrever o objeto de contedo Componente.


Em muitos casos, uma simples lista dos objetos de contedo, com uma breve descrio de cada
objeto, suficiente para definir os requisitos para o contedo a ser projetados e implementados.
Entretanto, em alguns casos, o modelo de contedo pode se beneficiar de uma anlise mais rica
que ilustre graficamente os relacionamentos entre os objetos de contedo e/ou a hierarquia do
contedo mantido por uma WebApp.
Por exemplo, consideremos a rvore de dados [Sri01] criada para um componente de CasaSeguraGarantida.com e ilustrada na Figura 7.10. A rvore representa uma hierarquia de
informaes usadas para descrever um componente. Dados simples ou compostos (um ou mais
valores de dados) so representados com retngulos de fundo branco. Os objetos de contedo
so representados como retngulos chapados. Na figura, a descrio definida por cinco objetos de contedo (os retngulos chapados). Em alguns casos, um ou mais desses objetos seriam
ainda mais refinados medida que a rvore de dados fosse se expandindo.
Uma rvore de dados pode ser criada para qualquer contedo composto de vrios objetos
de contedo e dados. A rvore de dados desenvolvida em uma tentativa de definir relaes
hierrquicas entre os objetos de contedo e de fornecer um meio para revisar o contedo de
modo que omisses e inconsistncias sejam reveladas antes de o projeto comear. Alm disso,
a rvore de dados serve como base para o projeto do contedo.

15 As classes de anlise foram discutidas no Captulo 6.

200

PARTE DOIS MODELAGEM

Figura 7.10
rvore de dados
para um componente
de CasaSeguraGarantida.com

Descrio de marketing
Nmero da pea
Nome da pea

Componente

Tipo de pea
Descrio
Preo

Fotografia
Descrio tcnica
Esquema
Vdeo
Preo no atacado
Preo no varejo

7.5.5Modelo de interaes para WebApps


A grande maioria das WebApps possibilita um dilogo entre o usurio final e a funcionalidade da aplicao, o contedo e o comportamento de uma aplicao. Esse dilogo pode
ser descrito por meio de um modelo de interaes que pode ser composto de um ou mais dos
seguintes elementos: (1) casos de uso, (2) diagramas de sequncia, (3) diagramas de estados,16
e/ou (4) prottipos de interfaces do usurio.
Em muitos casos, um conjunto de casos de uso j basta para descrever a interao em um
nvel de anlise (um maior refinamento e detalhes sero introduzidos durante a fase de projeto).
Entretanto, quando a sequncia de interao for complexa e envolver vrias classes de anlise
ou muitas tarefas, s vezes vale a pena represent-la usando uma forma esquemtica mais rigorosa.
O layout da interface do usurio, o contedo que ela apresenta, os mecanismos de interao que implementa e a esttica geral das conexes de WebApps para usurios tm muito a ver
com a satisfao do usurio e com o xito geral da WebApp. Embora possa se argumentar que a
criao de um prottipo de interface do usurio seja uma atividade de projeto, uma boa ideia
realiz-la durante a criao do modelo de anlise. O quanto antes uma representao fsica de
uma interface do usurio puder ser revisada, maior a probabilidade de que os usurios finais
obtero aquilo que realmente desejam. O projeto de interfaces do usurio discutido em detalhes no Captulo 11.
Pelo fato de as ferramentas para construo de WebApps serem abundantes, relativamente
baratas e funcionalmente poderosas, melhor criar o prottipo de interface usando-as. O prottipo deve implementar os principais links de navegao e representar o layout geral da tela em
grande parte da mesma forma que ser construdo. Por exemplo, se o intuito oferecer cinco
funes principais de sistema para o usurio final, o prottipo deve represent-las j que o usurio ir v-las assim que entrar na WebApp. Sero fornecidos links grficos? Onde ser exibido o
menu de navegao? Que outras informaes o usurio ver? Perguntas como essas devem ser
respondidas pelo prottipo.

7.5.6Modelo funcional para WebApps


Muitas WebApps oferecem uma ampla gama de funes computacionais e manipuladoras
que podem ser associadas diretamente ao contedo (seja usando-o, seja produzindo-o) e que
16 Diagramas de sequncia e diagramas de estados so modelados usando-se a notao da UML. Os diagramas de estados so
descritos na Seo 7.3. Veja o Apndice 1 para mais detalhes.

captulo 7 Modelagem de Requisitos: Fluxo, Comportamento, Padres e Aplicaes Baseadas na Web (WebApp)

201

frequentemente so sua meta principal de interao com o usurio. Por essa razo, os requisitos
funcionais tm de ser analisados e, quando necessrio, modelados.
O modelo funcional lida com dois elementos de processamento da WebApp, cada um dos
quais representando um diferente nvel de abstrao procedural: (1) funcionalidade observvel
pelo usurio fornecida pela WebApp aos usurios finais e (2) as operaes contidas nas classes
de anlise que implementam comportamentos associados classe.
A funcionalidade observvel pelos usurios engloba quaisquer funes de processamento iniciadas diretamente pelo usurio. Uma WebApp financeira poderia implementar uma srie de funes financeiras (por exemplo, uma calculadora de crdito educativo para o ensino superior ou
uma calculadora para planos de aposentadoria). Essas funes poderiam, na verdade, ser implementadas usando-se operaes dentro das classes de anlise, porm, do ponto de vista do usurio final, a funo (mais precisamente, os dados fornecidos pela funo) o resultado visvel.
Em um nvel de abstrao procedural mais baixo, o modelo de requisitos descreve o processamento a ser realizado pelas operaes das classes de anlise. Essas operaes manipulam
atributos de classes e esto envolvidas, j que as classes colaboram entre si para cumprir determinado comportamento exigido.
Independentemente do nvel de abstrao procedural, o diagrama de atividades UML pode
ser utilizado para representar detalhes do processamento. No nvel de anlise, os diagramas de
atividades devem ser usados apenas onde a funcionalidade relativamente complexa. Grande
parte da complexidade de muitas WebApps ocorre no na funcionalidade fornecida, mas sim
na natureza das informaes que podem ser acessadas e nas maneiras pelas quais podem ser
manipuladas.
Um exemplo de funcionalidade relativamente complexa do CasaSeguraGarantida.com
tratado por um caso de uso intitulado Obter recomendaes para a disposio dos sensores
no espao disponvel. O usurio j desenvolveu um layout para o espao a ser monitorado e,
nesse caso de uso, escolhe esse layout e solicita posies recomendadas para os sensores de
acordo com o layout. CasaSeguraGarantida.com responde com uma representao grfica
do layout com informaes adicionais sobre os pontos recomendados para posicionamento dos
sensores. A interao bastante simples, o contedo ligeiramente mais complexo, porm a
funcionalidade subjacente muito sofisticada. O sistema deve empreender uma anlise relativamente complexa do layout do andar para determinar o conjunto timo de sensores. Ele tem
de examinar as dimenses dos ambientes, a posio das portas e janelas e coorden-las com as
capacidades e especificaes dos sensores. Nada trivial! Um conjunto de diagramas de atividades pode ser usado para descrever o processamento para esse caso de uso.
O segundo exemplo o caso de uso Controlar cmeras. Neste, a interao relativamente
simples, porm h grande risco de funcionalidade complexa, dado que essa simples operao requer comunicao complexa com os dispositivos localizados remotamente e acessveis
via Internet. Uma outra possvel complicao est relacionada com a negociao do controle,
quando vrias pessoas autorizadas tentam monitorar e/ou controlar um nico sensor ao mesmo tempo.
A Figura 7.11 ilustra um diagrama de atividades para a operao assumirControleDaCamera()
que faz parte da classe de anlise Camera usada no caso de uso Controlar cameras. Deve-se
notar que duas operaes adicionais so chamadas dentro do fluxo procedural: solicitarBloqueioCamera(), que tenta bloquear a cmera para esse usurio e obterUsuarioCameraAtual(),
que recupera o nome do usurio que est controlando a cmera no momento. Os detalhes construtivos indicando como essas operaes so chamadas, bem como os detalhes da interface
para cada operao, no so considerados at que o projeto da WebApp seja iniciado.

7.5.7Modelos de configurao para WebApps


Em alguns casos, o modelo de configurao nada mais que uma lista de atributos no servidor
e no cliente. Entretanto, para WebApps mais complexas, uma srie de detalhes de configurao

202

PARTE DOIS MODELAGEM

Figra 7.11
Diagrama de
atividades
para a operao
assumirControleDaCamera()

Cmera no est
sendo usada

obterUsuarioAtual
DaCamera ()

solicitarBloqueioCamera()

Bloqueio disponvel

Informar Cmera
que est sendo usada e
o nome do atual usurio

Cmera est sendo


usada no momento

Bloqueio indisponvel

Informar Cmera
indisponvel

Informar Cmera
que est bloqueada no
momento para o usurio

(por exemplo, distribuio da carga entre vrios servidores, arquiteturas de caching, bancos de
dados remotos, vrios servidores atendendo vrios objetos na mesma pgina Web) poderiam ter
um impacto na anlise e no projeto. O diagrama de disponibilizao da UML pode ser utilizado
em situaes em que complexas arquiteturas de configurao tm de ser consideradas.
Para CasaSeguraGarantida.com, a funcionalidade e contedo pblico deveriam ser especificados como acessveis a todos os principais clientes Web (isto , aqueles com mais do que
1% de participao no mercado17). Ao contrrio, pode ser aceitvel restringir a funcionalidade
de monitoramento e controle mais complexa (que poderia ser acessado somente pelos usurios
Proprietrio) para um conjunto de clientes menor. O modelo de configurao para CasaSeguraGarantida.com tambm especificar a interoperabilidade com aplicaes de monitoramento e bancos de dados de produtos existentes.

7.5.8Modelo de navegao
O modelo de navegao considera a maneira como cada categoria de usurio ir navegar de
um elemento da WebApp (por exemplo, objeto de contedo) para outro. A mecnica de navegao definida como parte do projeto. Nesse estgio, devemos nos concentrar nos requisitos
gerais de navegao. As seguintes perguntas devem ser consideradas:
Deveriam certos elementos ser mais fceis de ser acessados (exigir um nmero de passos
de navegao menor) do que outros? Qual a prioridade para a apresentao?
Deveriam certos elementos ser enfatizados para forar os usurios a navegar em sua
direo?
Como os erros de navegao deveriam ser tratados?
Deveria a navegao para grupos de elementos relacionados ter maior prioridade em
relao navegao para um elemento especfico?
A navegao deveria ser obtida via links, via acesso baseado em pesquisa ou por outros
meios?
17 Determinar a participao de mercado para navegadores notoriamente problemtico e varia, dependendo de qual tipo de
pesquisa for utilizada. No obstante, na poca em que este livro foi escrito, o Internet Explorer e o Firefox eram os nicos navegadores que ultrapassavam os 30%, enquanto o Mozilla, o Opera e o Safari eram os nicos consistentemente acima de 1%.

captulo 7 Modelagem de Requisitos: Fluxo, Comportamento, Padres e Aplicaes Baseadas na Web (WebApp)

203

Deveriam certos elementos ser apresentados aos usurios no contexto de aes de navegao prvias?
Deveria o log de navegao ser mantido para os usurios?
Deveria existir um menu ou mapa de navegao completo (em vez de um simples link de
retorno ou ponteiro indicando direo) em qualquer ponto da interao de um usurio?
Deveria o projeto de navegao ser dirigido pelos comportamentos de usurio mais comumente esperados ou pela importncia percebida dos elementos definidos da WebApp?
Poderia um usurio armazenar sua navegao prvia pela WebApp para agilizar seus
uso futuro?
Para qual categoria de usurio a navegao otimizada deveria ser desenvolvida?
Como os links externos WebApp deveriam ser tratados? Sobrepondo a janela do navegador existente? Como uma nova janela do navegador? Como um quadro separado?
Essas e muitas outras perguntas devem ser feitas e respondidas como parte da anlise de
navegao.
Voc e outros interessados tambm devem determinar os requisitos gerais para navegao.
Por exemplo, ser fornecido um mapa do site para dar aos usurios uma viso geral de toda
a estrutura da WebApp? Ser possvel um usurio fazer um tour guiado que destacar os elementos mais importantes (objetos de contedo e funes) disponveis? Um usurio ser capaz
de acessar objetos de contedo ou funes baseadas em atributos definidos daqueles elementos
(por exemplo, um usurio poderia querer ter acesso a todas as fotografias de determinado prdio ou a todas as funes que possibilitam o clculo de peso)?

7.6

Resumo
Os modelos orientados a fluxos se concentram no fluxo de objetos de dados medida que
so transformados por funes de processamento. Extrados da anlise estruturada, os modelos orientados a fluxos usam o diagrama de fluxo de dados, uma notao de modelagem que
representa como a entrada transformada em sada medida que os objetos de dados se deslocam atravs de um sistema. Cada funo de software que transforma dados descrita por uma
narrativa ou especificao de processos. Alm do fluxo de dados, esse elemento de modelagem
tambm representa o fluxo de controle uma representao que ilustra como os eventos afetam o comportamento de um sistema.
A modelagem comportamental representa o comportamento dinmico. O modelo comportamental usa entrada de elementos baseados em cenrios, orientados a fluxos e baseados em
classes para representar os estados das classes de anlise e do sistema como um todo. Para
tanto, so identificados os estados, so definidos os eventos que fazem com que uma classe
(ou o sistema) passe por uma transio de um estado para outro e tambm so identificadas as
aes que ocorrem medida que acontece a transio. Os diagramas de estados e os diagramas
de sequncia so a notao utilizada para modelagem comportamental.
Os padres de anlise possibilitam a um engenheiro de software usar conhecimento do
domnio existente para facilitar a criao de um modelo de requisitos. Um padro de anlise
descreve uma funo ou recurso de software especfico que pode ser descrito por meio de um
conjunto de casos de uso coerente. Ele especifica o intuito do padro, o motivo para seu emprego, restries que limitam seu uso, sua aplicabilidade em vrios domnios de problemas, a
estrutura geral do padro, seu comportamento e colaboraes, bem como outras informaes
complementares.
A modelagem de requisitos para WebApps pode usar a maioria, se no todos, dos elementos de modelagem discutidos neste livro. Entretanto, tais elementos so aplicados em um conjunto de modelos especializados que tratam o contedo, interao, funo, navegao e a
configurao cliente/servidor em que a WebApp reside.

204

PARTE DOIS MODELAGEM

Problemas

Pontos

Ponderar

7.1. Qual a diferena fundamental entre as estratgias de anlise estruturada e orientadas a


objetos para a anlise de requisitos?
7.2. Em um diagrama de fluxo de dados, uma seta representa um fluxo de controle ou algo
mais?
7.3. O que continuidade de fluxo de informaes e como se aplica medida que um diagrama de fluxo de dados refinado?
7.4. Como a anlise sinttica usada na criao de um DFD?
7.5. O que uma especificao de controle?
7.6. Uma PSPEC e um caso de uso so a mesma coisa? Se no forem, explique as diferenas.
7.7. Existem dois tipos de estados que os modelos comportamentais so capazes de representar. Quais so eles?
7.8. Como um diagrama de sequncia difere de um diagrama de estado? Em que so similares?
7.9. Sugira trs padres de requisitos para um celular moderno e redija uma breve descrio
de cada um deles. Poderiam esses padres ser utilizados para outros dispositivos? Cite um
exemplo.
7.10. Escolha um dos padres que voc desenvolveu no Problema 7.9 e faa uma descrio
de padro relativamente completa similar em contedo e estilo quela apresentada na Seo
7.4.2.
7.11. Que nvel de modelagem de anlise voc acredita que seria necessria para CasaSeguraGarantida.com? Seria necessrio cada um dos tipos de modelos descritos na Seo 7.5.3?
7.12. Qual o objetivo do modelo de interaes para uma WebApp?
7.13. Poder-se-ia argumentar que um modelo funcional para WebApp deveria ser postergado
at a fase de projeto. Apresente os prs e os contras desse argumento.
7.14. Qual o objetivo de um modelo de configurao?
7.15. Em que o modelo de navegao difere do modelo de interaes?

Leituras

Fontes

de

I n f o r m a o C o m p l e m e n ta r e s

Foram publicados dezenas de livros sobre anlise estruturada. Todos cobrem o tema de
forma adequada, porm poucos o fazem de maneira realmente excelente. DeMarco e Plauger
(Structured Analysis and System Specification, Pearson, 1985) um clssico que ainda se
mantm como uma boa introduo notao bsica. Livros como os de Kendall e Kendall
(Systems Analysis and Design, 5. ed., Prentice-Hall, 2002), Hoffer et al. (Modern Systems
Analysis and Design, Addison-Wesley, 3. ed., 2001), Davis e Yen (The Information System Consultants Handbook: Systems Analysis and Design, CRC Press, 1998) e Modell (A Professionals
Guide to Systems Analysis, 2. ed., McGraw-Hill, 1996) so referncias proveitosas. O livro de
Yourdon (Modern Structured Analysis, Yourdon-Press, 1989) sobre o tema ainda se encontra
entre os mais completos publicados at hoje.
A modelagem comportamental apresenta uma viso dinmica importante do comportamento de um sistema. Livros como os de Wagner e seus colegas (Modeling Software with Finite State Machines: A Practical Approach, Auerbach, 2006) e Boerger e Staerk (Abstract State
Machines, Springer, 2003) apresentam uma discusso abrangente sobre diagramas de estado
e outras representaes comportamentais.
A maioria dos livros escritos que abordam o tema padres de software enfoca o projeto de
software. Entretanto, livros como os de Evans (Domain-Driven Design, Addison-Wesley, 2003)
e Fowler ([Fow03] e [Fow97]) examinam especificamente os padres de anlise.

captulo 7 Modelagem de Requisitos: Fluxo, Comportamento, Padres e Aplicaes Baseadas na Web (WebApp)

205

Um tratado aprofundado sobre a modelagem de anlise para WebApps apresentado


por Pressman e Lowe [Pre08]. Artigos contidos em uma antologia editada por Murugesan
e Desphande (Web Engineering: Managing Diversity and Complexity of Web Application Development, Springer, 2001) discutem vrios aspectos dos requisitos de uma WebApp. Alm destes, o Proceedings of the International Conference on Web Engineering publicado anualmente
trata regularmente de questes referentes modelagem de requisitos.
Uma ampla gama de fontes de informao sobre modelagem de requisitos se encontra
disposio na Internet. Uma lista atualizada de referncias na Web, relevante para a modelagem de anlise, pode ser encontrada no site www.mhhe.com/engcs/compsci/pressman/
professional/olc/ser.htm.

captulo

Conceitos

Conceitos- Chave
abstrao . . . . . . . . . . 212
arquitetura . . . . . . . . . 213
aspectos . . . . . . . . . . . 217
atributos de qualidade . 210
bom projeto . . . . . . . . . 210
coeso . . . . . . . . . . . . . 216
diretrizes de qualidade . 209
encapsulamento de
informaes . . . . . . . . . 215
independncia funcional 217
modularidade . . . . . . . . 214
padres . . . . . . . . . . . . 214
processo de projeto . . . 209
projeto de dados . . . . . 209
projeto de software . . . 211
projeto orientado
a objetos . . . . . . . . . . . 218
refatorao . . . . . . . . . 218
refinamento gradual . . . 217
separao de
interesses . . . . . . . . . . 214

de

PROJETO

atividade de projeto de software1 engloba o conjunto de princpios, conceitos e


prticas que levam ao desenvolvimento de um sistema ou produto com alta qualidade. Os princpios de projeto estabelecem uma filosofia que prevalece sobre
as atitudes e aes do desenvolvimento, orientando as atividades para realizar o projeto.
Os conceitos de projeto devem ser estabelecidos e entendidos antes de aplicar a prtica de
projeto, que deve levar criao de vrias representaes do software que servem como
um guia para a atividade de construo que se segue.
A atividade projeto crtica para o xito em engenharia de software. No incio dos
anos 1990, Mitch Kapor, o criador do Lotus 1-2-3, apresentou um manifesto de projeto
de software no Dr. Dobbs Journal. Disse ele:

O que projeto? onde voc fica com o p em dois mundos o mundo da tecnologia e o mundo
das pessoas e dos propsitos do ser humano e voc tenta unir os dois...
O crtico de arquitetura romano, Vitruvius, lanou a noo de que prdios bem projetados
eram aqueles que apresentavam solidez, comodidade e deleite. O mesmo poderia ser dito em
relao a software de boa qualidade. Solidez: um programa no deve apresentar nenhum bug que
impea seu funcionamento. Comodidade: um programa deve ser adequado aos propsitos para os
quais foi planejado. Deleite: a experincia de usar o programa deve ser prazerosa. Temos aqui os
princpios de uma teoria de projeto de software.

O que ? Projeto o que quase todo

Panorama engenheiro quer fazer. o lugar onde a

criatividade impera onde os requisitos


dos interessados, as necessidades da
aplicao e consideraes tcnicas se juntam na
formulao de um produto ou sistema. O projeto
cria uma representao ou modelo do software,
mas diferentemente do modelo de requisitos (que
se concentra na descrio do O que para ser
feito: dos dados, funo e comportamento necessrios), o modelo de projeto indica O Como
fazer, fornecendo detalhes sobre a arquitetura de
software, estruturas de dados, interfaces e componentes fundamentais para implementar o sistema.
Quem realiza? Os engenheiros de software conduzem cada uma das tarefas de projeto.
Por que importante? O projeto permite que se
modele o sistema ou produto a ser construdo. O
modelo pode ser avaliado em termos de qualidade e
aperfeioado ANTES de o cdigo ser gerado, ou de
os testes serem realizados, ou de os usurios finais se
envolverem com grandes nmeros. Projeto o lugar
onde a qualidade do software estabelecida.
Quais so as etapas envolvidas? O projeto representa o software de vrias formas diferentes.
1

206

Primeiramente, a arquitetura do sistema ou do


produto tem de ser representada. Em seguida,
so modeladas as interfaces que conectam o
software aos usurios finais a outros sistemas e a
dispositivos, bem como seus prprios componentes
internos. Por fim, os componentes de software usados para construir o sistema so projetados. Cada
uma dessas vises representa uma diferente ao
de projeto, mas todas devem estar de acordo com
um conjunto de conceitos bsicos de projeto que
orientam o trabalho de projeto de software.
Qual o artefato? Um modelo de projeto que engloba representaes de arquitetura, interface, no
nvel de componentes e de utilizao o principal
artefato gerado durante o projeto de software.
Como garantir que o trabalho foi realizado corretamente? O modelo de projeto avaliado pela
equipe de software em um esforo para determinar
se ele contm erros, inconsistncias ou omisses;
se existem alternativas melhores; e se o modelo
pode ser implementado de acordo com as restries, prazo e oramento estabelecidos.

N. de R.T.: o termo em ingls dessa atividade design. Refere-se atividade de engenharia cujo foco definir como
os requisitos estabelecidos do projeto devem ser implementados no software. uma fase que se apresenta de maneira
similar nas diversas especializaes da engenharia como a Civil, Naval, Qumica e Mecnica.

207

captulo 8 CONCEITOS DE PROJETO

O objetivo da atividade projetar gerar um modelo ou representao que apresente solidez,


comodidade e deleite. Para tanto, temos de praticar a diversificao e, depois, a convergncia.
Belady [Bel81] afirma que diversificao a aquisio de um repertrio de alternativas, a matria-prima do projeto: componentes, solues de componentes e conhecimento, todos contidos
em catlogos, livros-textos e na mente. Assim que esse conjunto diversificado de informaes
for montado, temos de escolher elementos do repertrio que atendam os requisitos definidos
pela engenharia de requisitos e pelo modelo de anlise (Captulos 5 ao 7). medida que isso
ocorre, so consideradas e rejeitadas alternativas e convergimos para uma particular configurao de componentes e, portanto, a criao do produto final [Bel81].
Diversificao e convergncia combinam intuio e julgamento baseado na experincia de
construo de entidades similares, um conjunto de princpios e/ou heurstica que orientam a
maneira por meio da qual o modelo evolui, um conjunto de critrios que permitem que a qualidade seja avaliada e um processo de iterao que, ao fim, leva a uma representao final do projeto. O projeto de software muda continuamente medida que novos mtodos, melhor anlise
e entendimento mais abrangente evoluem.2 Mesmo hoje em dia, a maioria das metodologias de
projeto de software carece da profundidade, flexibilidade e natureza quantitativa que normalmente esto associadas s disciplinas mais clssicas de engenharia de projeto. Entretanto, existem efetivamente mtodos para projeto de software, critrios para qualidade de projeto esto
disponveis e notao de projeto pode ser aplicada. Neste captulo, exploraremos os conceitos e
princpios fundamentais aplicveis a todos os projetos de software, os elementos do modelo de
projeto e o impacto dos padres no processo de projeto. Nos Captulos 9 a 13 apresentaremos
uma srie de mtodos de projeto de software medida que so aplicados ao projeto da arquitetura, de interfaces e de componentes, bem como as abordagens de projeto baseada em padres
e orientada para a Web.

8.1
O milagre
mais comum
da engenharia
de software
a transio da
anlise para
o projeto e do
projeto para o
cdigo.
Richard Due

AVISO
O projeto de software
sempre deve
comear levando
em considerao os
dados a base
para todos os demais
elementos do projeto.
Aps estabelecida a
base, a arquitetura
tem de ser extrada.
S ento devem se
realizar outras tarefas
de projeto.

Projeto

no

Contexto

da

Engenharia

de

S o f t wa r e

O projeto de software reside no ncleo tcnico da engenharia de software e aplicado independentemente do modelo de processos de software utilizado. Iniciando assim que os requisitos de software tiverem sido analisados e modelados, o projeto de software a ltima ao
da engenharia de software da atividade de modelagem e prepara a cena para a construo
(gerao de cdigo e testes).
Cada um dos elementos do modelo de requisitos (Captulos 6 e 7) fornece informaes necessrias para criar os quatro modelos de projeto necessrios para uma especificao completa.
O fluxo de informaes durante o projeto de software ilustrado na Figura 8.1. O modelo de
requisitos, manifestado por elementos baseados em cenrios, baseados em classes, orientado a
fluxos e comportamentais, alimenta a tarefa de projeto. Usando a notao de projeto e os mtodos de projeto discutidos em captulos posteriores, o projeto gera um projeto de dados/classes,
um projeto de arquitetura, um projeto de interfaces e um projeto de componentes.
O projeto de dados/classes transforma os modelos de classes (Captulo 6) em realizaes de
classes de projeto e nas estruturas de dados dos requisitos necessrias para implementar o software. Os objetos e os relacionamentos definidos nos cartes CRC e no contedo detalhado dos
dados representados por atributos de classes e outra notao fornecem a base para a realizao
do projeto de dados. Parte do projeto de classes pode ocorrer com o projeto da arquitetura de
software. O projeto de classe mais detalhado ocorre medida que cada componente de software
projetado.
O projeto arquitetural define os relacionamentos entre os principais elementos estruturais
do software, os estilos arquiteturais e padres de projeto que podem ser usados para satisfazer
os requisitos definidos para o sistema e as restries que afetam o modo pelo qual a arquitetura
2

Aqueles leitores com maior interesse na filosofia do projeto de software talvez se interessem pela intrigante discusso de
Philippe Kruchen sobre o projeto ps-moderno [Kru05a].

208

PARTE DOIS MODELAGEM

Figura 8.1
Transformando
o modelo de
requisitos no
modelo de projeto

Elementos baseados
em cenrios
Casos de uso texto
Diagramas de casos de uso
Diagramas de atividades
Diagramas de raias

Diagramas de fluxo
de dados
Diagramas de fluxo de dados
Diagramas de fluxo de controle
Narrativas de processamento
Modelo de anlise

Elementos baseados
em classes

Elementos
comportamentais

Diagramas de classes
Pacotes de anlise
Modelos CRC
Diagramas de colaborao

Diagramas de estados
Diagramas de sequncia

Projeto de
Componentes

Projeto de
interfaces
Projeto arquitetural

Projeto de dados/classes
Modelo de projeto

H duas maneiras
de construir
um projeto de
software. Uma
delas faz-lo
to simples que,
obviamente,
no existiro
deficincias, e a
outra maneira
faz-lo to
complicado que
no h nenhuma
deficincia bvia. O
primeiro mtodo
bem mais difcil.
C. A. R. Hoare

pode ser implementada [Sha96]. A representao do projeto arquitetural a organizao da soluo tcnica de um sistema baseado em computador derivada do modelo de requisitos.
O projeto de interfaces descreve como o software se comunica com sistemas que interromperam com ele e com as pessoas que o utilizam. Uma interface implica fluxo de informaes (por
exemplo, dados e/ou controle) e um tipo de comportamento especfico. Consequentemente,
modelos comportamentais e de cenrios de uso fornecem grande parte das informaes necessrias para o projeto de interfaces.
O projeto de componentes transforma elementos estruturais da arquitetura de software em
uma descrio procedural dos componentes de software. As informaes obtidas dos modelos
baseados em classes, modelos de fluxo e modelos comportamentais servem como base para o
projeto de componentes.
Durante o projeto tomamos decises que, em ltima anlise, afetaro o sucesso da construo do software e, igualmente importante, a facilidade de manuteno do software. Mas por que
o projeto to importante?
A importncia do projeto de software pode ser definida em uma nica palavra qualidade.
Projeto a etapa em que a qualidade incorporada na engenharia de software. O projeto nos
fornece representaes de software que podem ser avaliadas em termos de qualidade. Projeto
a nica maneira em que podemos traduzir precisamente os requisitos dos interessados em um
produto ou sistema de software finalizado. O projeto de software serve como base para todas
as atividades de apoio e da engenharia de software que seguem. Sem um projeto, corremos o
risco de construir um sistema instvel um sistema que falhar quando forem feitas pequenas
alteraes; um sistema que talvez seja difcil de ser testado; um sistema cuja qualidade no pode
ser avaliada at uma fase avanada do processo de software, quando o tempo est se esgotando
e muito dinheiro j foi gasto.

209

captulo 8 CONCEITOS DE PROJETO

C asa S egura
Projeto versus codificao
Cena: Sala do Ed, enquanto a equipe se
prepara para traduzir os requisitos para o
projeto.
Atores: Jamie, Vinod e Ed todos membros da equipe de
engenharia de software do CasaSegura.
Conversa:
Jamie: Voc sabe, Doug [o gerente da equipe] est obcecado
pelo projeto. Tenho que ser honesto; o que eu realmente adoro
fazer programar. D-me o C++ ou Java e ficarei feliz.
Ed: Nada... Voc gosta de projetar.
Jamie: Voc no est me ouvindo; programar o canal.
Vinod: Acredito que aquilo que o Ed quis dizer que voc
realmente no gosta de programar; voc gosta de projetar e
expressar isto na forma de cdigo de programa. Cdigo a
linguagem que voc usa para representar um projeto.
Jamie: E o que h de errado nisso?

8.2

O Processo

de

Vinod: Nvel de abstrao.


Jamie: H?
Ed: Uma linguagem de programao boa para representar
detalhes como estruturas de dados e algoritmos, mas no to
boa para representar a colaborao componente-componente
ou a arquitetura... Coisas do tipo.
Vinod: E uma arquitetura ferrada pode arruinar at mesmo o
melhor cdigo.
Jamie (pensando por um minuto): Portanto, voc est dizendo que no posso representar arquitetura no cdigo... Isso
no verdade.
Vinod: Certamente voc pode envolver arquitetura no cdigo,
mas na maioria das linguagens de programao, bem difcil
ter uma viso geral rpida da arquitetura examinando-se o cdigo.
Ed: E isso que queremos antes de comear a programar.
Jamie: OK, talvez projetar e programar sejam coisas diferentes, mas ainda assim prefiro programar.

Projeto

O projeto de software um processo iterativo atravs do qual os requisitos so traduzidos


em uma planta para construir o software. Inicialmente, a planta representa uma viso holstica do software. O projeto representado em um alto nvel de abstrao um nvel que pode
ser associado diretamente ao objetivo especfico do sistema e aos requisitos mais detalhados
de dados, funcionalidade e comportamento. medida que ocorrem as iteraes do projeto, refinamento subsequente leva a representaes do projeto em nveis de abstrao cada vez mais
baixos. Estes ainda podem ser associados aos requisitos, mas a conexo mais sutil.

8.2.1Diretrizes e atributos da qualidade de software


Escrever um
trecho de cdigo
inteligente que
funcione uma
coisa; projetar
algo que possa dar
suporte a negcios
duradouros
outra totalmente
diferente.
C. Ferguson

Ao longo do processo de projeto, a qualidade do projeto que evolui avaliada com uma srie
de revises tcnicas discutidas no Captulo 15. McGlaughlin [McG91] sugere trs caractersticas
que servem como um guia para a avaliao de um bom projeto:
O projeto deve implementar todos os requisitos explcitos contidos no modelo de requisitos e deve acomodar todos os requisitos implcitos desejados pelos interessados.
O projeto deve ser um guia legvel, compreensvel para aqueles que geram cdigo e para
aqueles que testam e, subsequentemente, do suporte ao software.
O projeto deve dar uma viso completa do software, tratando os domnios de dados, funcional e comportamental sob a perspectiva de implementao.
Cada uma dessas caractersticas , na verdade, uma meta do processo de projeto. Mas como
cada uma alcanada?
Diretrizes de qualidade. Para avaliar a qualidade da representao de um projeto, voc
e outros membros da equipe de software devem estabelecer critrios tcnicos para um bom
projeto. Na Seo 8.3, discutimos conceitos de projeto que tambm servem como critrios de
qualidade de software. Por enquanto, consideremos as seguintes diretrizes:

210

paRtE doiS

so as
? Quais
caractersticas

1. Um projeto deve exibir uma arquitetura que (1) foi criada usando estilos ou padres arquiteturais reconhecveis, (2) seja composta por componentes que apresentam boas caractersticas de projeto (discutidos mais adiante neste captulo) e (3) possa ser implementada de uma
forma evolucionria3 facilitando, portanto, a implementao e os testes.

de um bom
projeto?

MoDeLaGeM

2. Um projeto deve ser modular; o software deve ser logicamente particionado em elementos
ou subsistemas, de modo que seja fcil de testar e manter.
3. Um projeto deve conter representaes distintas de: dados, arquitetura, interfaces e componentes.
4. Um projeto deve levar as estruturas de dados adequadas s classes a ser implementadas e
baseadas em padres de dados reconhecveis.
5. Um projeto deve levar a componentes que apresentem caractersticas funcionais independentes (baixo acoplamento).
6. Um projeto deve levar a interfaces que reduzam a complexidade das conexes entre os componentes e o ambiente externo (encapsulamento).
7. Um projeto deve ser obtido usando-se um mtodo repetvel, isto , dirigido por informaes
obtidas durante a anlise de requisitos de software.
8. Um projeto deve ser representado usando-se uma notao que efetivamente comunique seu
significado.
Essas diretrizes no so atingidas por acaso. Elas so alcanveis por meio da aplicao de
princpios de projeto fundamentais, de metodologia sistemtica e de reviso.
4
5

Qualidade no
algo que se
coloque sobre os
assuntos e objetos
como um enfeite
em uma rvore de
Natal.

Atributos de qualidade. A Hewlett-Packard [Gra87] desenvolveu um conjunto de atributos


de qualidade de software ao qual foi atribudo o acrnimo FURPS functionality (funcionalidade), usability (usabilidade), reliability (confiabilidade), performance (desempenho) e suportability (facilidade de suporte). Os atributos de qualidade FURPS representam uma meta para
todo projeto de software:
A funcionalidade avaliada pela observao do conjunto de caractersticas e capacidades
do programa, a generalidade das funes que so entregues e a segurana do sistema
como um todo.

Robert Pirsig

Avaliao da qualidade do projeto a reviso tcnica


O projeto importante porque permite equipe de
software avaliar a qualidade4 do software antes de
ser implementado em um momento em que os erros, as omisses ou as inconsistncias so fceis e baratas de
ser corrigidos. Mas como avaliar a qualidade durante um projeto? O software no pode ser testado, pois no existe nenhum
software executvel para testar. O que fazer ento?
Durante um projeto, a qualidade avaliada realizando-se uma
srie de revises tcnicas (technical reviews, Trs). As Trs so
discutidas em detalhes no Captulo 155 mas vale fazer um resumo neste momento. A reviso tcnica uma reunio conduzida
por membros da equipe de software. Normalmente duas, trs
ou quatro pessoas participam, dependendo do escopo das informaes de projeto a ser revisadas. Cada pessoa desempe-

3
4
5

INfORMAES

nha um papel: um lder de reviso planeja a reunio, estabelece


uma agenda e conduz a reunio; o registrador toma notas de
modo que nada seja perdido; o produtor a pessoa cujo artefato (por exemplo, o projeto de um componente de software) est
sendo revisado. Antes de uma reunio, cada pessoa da equipe
de reviso recebe uma cpia do artefato do projeto e lhes
solicitada sua leitura, procurando encontrar erros, omisses ou
ambiguidade. Quando a reunio comea, o intuito perceber
todos os problemas com o artefato, de modo que possam ser
corrigidos antes da implementao comear. A Tr dura, tipicamente, entre 90 minutos e 2 horas. Na concluso, a equipe de
reviso determina se outras aes so necessrias por parte
do produtor antes de o artefato do projeto ser aprovado como
parte do modelo de projeto final.

Evolucionria: incremental, com entregas por partes. Para sistemas menores, algumas vezes o projeto pode ser desenvolvido
linearmente.
Os fatores de qualidade discutidos no Captulo 23 podem ajudar a equipe de reviso medida que avalia a qualidade.
Voc deve considerar consulta do Captulo 15 neste momento. As revises tcnicas so parte crtica do processo de projeto e
um importante mecanismo para atingir qualidade em um projeto.

captulo 8 CONCEITOS DE PROJETO

AVISO
Os projetistas de
software tendem
a se concentrar
no problema a ser
resolvido. Apenas no
se esquea de que os
atributos de qualidade
FURPS sempre fazem
parte do problema.
Eles tm de ser
considerados.

211

A usabilidade avaliada considerando-se fatores humanos (Captulo 11), esttica, consistncia e documentao como um todo.
A confiabilidade avaliada medindo-se a frequncia e a severidade das falhas, a preciso
dos resultados gerados, o tempo mdio entre defeitos (mean-time-to-failure, MTTF), a
capacidade de se recuperar de uma falha e a previsibilidade do programa.
O desempenho medido considerando-se a velocidade de processamento, o tempo de
resposta, o consumo de recursos, vazo (throughput) e eficincia.
A facilidade de suporte combina a habilidade de estender o programa (extensibilidade), a adaptabilidade e a reparabilidade esses trs atributos representam um
termo mais comum, facilidade de manuteno e, alm disso, a facilidade de realizar testes, a compatibilidade, a facilidade de configurar (a habilidade de organizar
e controlar elementos da configurao do software, Captulo 22), a facilidade com a
qual um sistema pode ser instalado, bem como a facilidade com a qual os problemas
podem ser localizados.
Nem todo atributo de qualidade de software tem o mesmo peso medida que o projeto
desenvolvido. Uma aplicao poderia enfatizar a funcionalidade com nfase especial na segurana. Outra poderia demandar desempenho com particular nfase na velocidade de processamento. Um terceiro foco poderia ser na confiabilidade. Independentemente do peso dado,
importante notar que esses atributos de qualidade devem ser considerados quando o projeto se
inicia, e no aps o projeto estar completo e a construo tiver comeado.

8.2.2A evoluo de um projeto de software


Um projetista
sabe que seu
projeto atingiu
a perfeio no
quando no resta
mais nada a ser
acrescentado, mas
quando no h
mais nada a ser
eliminado.
Antoine de
St-Exupry

? Quais
caractersticas

so comuns a todos
os mtodos de
projeto?

A evoluo de um projeto de software um processo contnuo que j atinge quase seis


dcadas. Os trabalhos iniciais concentravam-se em critrios para o desenvolvimento de programas modulares [Den73] e de mtodos para refinamento das estruturas de software de uma
forma topdown [Wir71]. Aspectos procedurais da definio de um projeto evoluram e convergiram para uma filosofia denominada programao estruturada [Dah72], [Mil72]. Trabalhos
posteriores propuseram mtodos para a traduo de fluxos de dados [Ste74] ou da estrutura
de dados (por exemplo, [Jac75], [War74]) em uma definio de projeto. Abordagens de projeto mais recentes (por exemplo, [Jac92], [Gam95]) propuseram uma abordagem orientada a
objetos para a derivao do projeto. Atualmente, a nfase em projeto de software tem sido
na arquitetura de software [Kru06] e nos padres de projeto que podem ser utilizados para
implementar arquiteturas de software e nveis de abstrao de projeto mais baixos (por exemplo, [Hol06] [Sha05]). Tem crescido a nfase em mtodos orientados a aspectos (por exemplo,
[Cla05], [Jac04]), no desenvolvimento dirigido a modelos [Sch06] e dirigido a testes [Ast04]
que enfatizam tcnicas para se atingir uma modularidade e estrutura arquitetural mais efetiva
nos projetos criados.
Uma srie de mtodos de projetos, originrios dos trabalhos citados, est sendo aplicada
em toda a indstria. Assim como os mtodos de anlise apresentados nos Captulos 6 e 7, cada
mtodo de projeto de software introduz heurstica e notao nicas, bem como uma viso um
tanto provinciana daquilo que caracteriza a qualidade de um projeto. Mesmo assim, todos os
mtodos possuem uma srie de caractersticas comuns: (1) um mecanismo para a traduo do
modelo de requisitos em uma representao de projeto, (2) uma notao para representar componentes funcionais e suas interfaces, (3) heurstica para refinamento e particionamento e (4)
diretrizes para avaliao da qualidade.
Independentemente do mtodo de projeto utilizado, devemos aplicar um conjunto de conceitos bsicos ao projeto de dados, de arquitetura, de interface e dos componentes. Tais conceitos so considerados nas sees a seguir.

212

paRtE doiS

MoDeLaGeM

Conjunto de tarefas genricas para projeto


1. Examinar o modelo do domnio de informao e
projetar estruturas de dados apropriadas para objetos de dados e seus atributos.
2. Usar o modelo de anlise, selecionar um estilo de arquitetura apropriado ao software.
3. Dividir o modelo de anlise em subsistemas de projeto e
aloc-los na arquitetura:
Certificar-se de que cada subsistema seja funcionalmente
coeso.
Alocar classes ou funes de anlise para cada subsistema.
4. Criar um conjunto de classes ou componentes de projeto:
Traduzir a descrio de classes de anlise em uma classe
de projeto.
Verificar cada classe de projeto em relao aos critrios
de projeto; considerar questes de herana.
Definir mtodos e mensagens associadas a cada classe
de projeto.
Avaliar e selecionar padres de projeto para uma classe
ou um subsistema de projeto.

ConCeitos

de

rever as classes de projeto e revisar quando necessrio.


5. Projetar qualquer interface necessria para sistemas ou dispositivos externos.
6. Projetar a interface do usurio:
revisar os resultados da anlise de tarefas.
Especificar a sequncia de aes baseando-se nos cenrios de usurio.
Criar um modelo comportamental da interface.
Definir objetos de interface, mecanismos de controle.

Projetar interfaces de subsistemas.

8.3

CONJUNTO DE TAREfAS

rever o projeto de interfaces e revisar quando necessrio.


7. Conduzir o projeto de componentes.
Especificar todos os algoritmos em um nvel de abstrao
relativamente baixo.
refinar a interface de cada componente.
Definir estruturas de dados dos componentes.
revisar cada componente e corrigir todos os erros descobertos.
8. Desenvolver um modelo de implantao.

Projeto

Um conjunto de conceitos fundamentais de projeto de software evoluiu ao longo da histria da engenharia de software. Embora o grau de interesse em cada conceito tenha variado ao
longo dos anos, cada um resistiu ao tempo. Esses conceitos fornecem ao projetista de software
uma base a partir da qual mtodos de projeto mais sofisticados podem ser aplicados. Ajudamnos a responder as seguintes questes:
Quais critrios podem ser usados para particionar o software em componentes individuais?
Como os detalhes de funo ou estrutura de dados so separados de uma representao
conceitual do software?
Quais critrios uniformes definem a qualidade tcnica de um projeto de software?

Abstrao uma
das maneiras
fundamentais
como ns,
seres humanos,
lidamos com a
complexidade.
Grady Booch

M. A. Jackson [Jac75] disse uma vez: O princpio da sabedoria para um [engenheiro de software] reconhecer a diferena entre fazer um programa funcionar e fazer com que ele funcione
corretamente. Os conceitos fundamentais de projeto de software fornecem a organizao necessria para estrutur-la e para fazer com que ele funcione corretamente.
Nas sees a seguir, apresentamos uma breve viso de importantes conceitos de projeto de
software que englobam tanto o desenvolvimento de software tradicional quanto o orientado a
objetos.

8.3.1

abstrao

Ao se considerar uma soluo modular para qualquer problema, muitos nveis de abstrao podem se apresentar. No nvel de abstrao mais alto, uma soluo expressa em termos
abrangentes usando a linguagem do domnio do problema. Em nveis de abstrao mais baixos,
uma descrio mais detalhada da soluo fornecida. A terminologia do domnio do problema
associada terminologia de implementao para definir uma soluo. Por fim, no nvel de

captulo 8 CONCEITOS DE PROJETO

AVISO
Como projetista,
trabalhe arduamente
para derivar tanto as
abstraes procedurais
quanto a de dados que
atendam ao problema
em questo. Se elas
puderem atender um
domnio inteiro dos
problemas, tanto
melhor.

213

abstrao mais baixo, a soluo tcnica do software expressa de maneira que pode ser diretamente implementada.
medida que diferentes nveis de abstrao so alcanados, usa-se a combinao de abstraes procedurais e de dados. Uma abstrao procedural refere-se a uma sequncia de instrues
que possuem uma funo especfica e limitada. O nome de uma abstrao procedural implica
sua funo, porm os detalhes especficos so omitidos. Um exemplo de abstrao procedural
tem como nome abrir para uma porta. Abrir implica uma longa sequncia de etapas procedurais
(por exemplo, dirigir-se at a porta, alcanar e agarrar a maaneta, girar a maaneta e puxar a
porta, afastar-se da porta em movimento etc.).6
A abstrao de dados um conjunto de dados com nome que descreve um objeto de dados.
No contexto da abstrao procedural abrir, podemos definir uma abstrao de dados chamada
porta. Assim como qualquer objeto de dados, a abstrao de dados para porta englobaria um
conjunto de atributos que descrevem a porta (por exemplo, tipo de porta, mudar de direo,
mecanismo de abertura, peso, dimenses). Da decorre que a abstrao abrir faria uso de informaes contidas nos atributos da abstrao de dados porta.

8.3.2Arquitetura
WebRef
Uma discusso mais
aprofundada de
arquitetura de software
pode ser encontrada
em www.sei.cmu.
edu/ata/ata_init.
html.

Arquitetura
de software
o produto
resultante do
desenvolvimento
que d o maior
retorno sobre
o investimento
em relao
qualidade, prazos e
custo.

A arquitetura de software refere-se organizao geral do software e aos modos pelos quais
disponibiliza integridade conceitual para um sistema [Sha95a]. Em sua forma mais simples,
arquitetura a estrutura ou a organizao de componentes de programa (mdulos), a maneira
atravs da qual esses componentes interagem e a estrutura de dados so usadas pelos componentes. Em um sentido mais amplo, entretanto, os componentes podem ser generalizados para
representar os principais elementos de um sistema e suas interaes.
Uma meta do projeto de software derivar um quadro da arquitetura de um sistema. Esse
quadro representa a organizao a partir da qual atividades mais detalhadas de projeto so conduzidas. Um conjunto de padres de arquitetura permite a um engenheiro de software reusar
solues-padro para problemas similares.
Shaw e Garlan [Sha95a] descrevem um conjunto de propriedades que devem ser especificadas como parte de um projeto de arquitetura:
Propriedades estruturais. Esse aspecto do projeto da representao da arquitetura define os componentes de um sistema (por exemplo, mdulos, objetos, filtros) e a maneira pela qual os componentes
so empacotados e interagem entre si. Por exemplo, objetos so empacotados para encapsularem dados
e processamento que manipula esses dados e interagem por meio da chamada dos mtodos.
Propriedades no funcionais. A descrio do projeto de arquitetura deve tratar a maneira pela
qual o projeto da arquitetura atinge os requisitos de desempenho, capacidade, confiabilidade, segurana, adaptabilidade e outras caractersticas do sistema, que no representam as funcionalidades diretamente acessadas pelos usurios.
Famlias de sistemas. O projeto de arquitetura deve tirar proveito de padres reusveis comumente encontrados no projeto de famlias de sistemas similares. Em essncia, o projeto deve ter a
habilidade de reutilizar os componentes que fazem parte da arquitetura.

Len Bass et al.

AVISO
No deixe que a
arquitetura acontea
ao acaso. Ao fazer
isso, voc consumir
o restante do projeto
adequando-a para
a forma forada
ao projeto. Projete
a arquitetura
explicitamente.

Dada a especificao dessas propriedades, o projeto da arquitetura pode ser representado


usando-se um ou mais modelos diferentes [Gar95]. Os modelos estruturais representam a arquitetura como um conjunto organizado de componentes de programa. Esses modelos aumentam
o nvel de abstrao do projeto tentando identificar projetos arquiteturais reusveis encontrados
em tipos de aplicaes similares. Os modelos dinmicos tratam dos aspectos comportamentais da arquitetura do programa, indicando como a estrutura ou configurao do sistema pode
mudar em funo de eventos externos. Os modelos de processos concentram-se no projeto do

Deve-se notar, entretanto, que um conjunto de operaes pode ser substitudo por outro, desde que a funo implicada pela
abstrao procedural permanea a mesma. Consequentemente, as etapas necessrias para implementar abrir mudariam dramaticamente se a porta fosse automtica e ligada a um sensor.

214

Cada padro
descreve um
problema
que ocorre
repetidamente em
nosso ambiente,
e ento descreve
o ncleo da
soluo para esse
problema, de uma
forma tal que
podemos usar a
soluo milhes de
vezes, sem jamais
faz-lo da mesma
forma.
Christopher
Alexander

PARTE DOIS MODELAGEM

processo tcnico ou do negcio que o sistema deve atender. Por fim, os modelos funcionais podem ser utilizados para representar a hierarquia funcional de um sistema.
Desenvolveu-se uma srie de linguagens de descrio de arquitetura (architectural description
languages, ADLs) diferente para representar esses modelos [Sha95b]. Embora tenham sido propostas diversas ADLs, a maioria fornece mecanismos para descrever componentes de sistema e
a maneira atravs da qual esto conectados entre si.
Voc deve notar que h certo debate em torno do papel da arquitetura no projeto. Alguns pesquisadores argumentam que a obteno da arquitetura de software deve ser separada do projeto e
ocorre entre as aes da engenharia de requisitos e aes de projeto mais convencionais. Outros
acreditam que a obteno da arquitetura parte integrante do processo de projeto. A maneira pela
qual a arquitetura de software caracterizada e seu papel no projeto so discutidos no Captulo 9.

8.3.3Padres
Brad Appleton define padro de projeto da seguinte maneira: Padro parte de um conhecimento consolidado j existente que transmite a essncia de uma soluo comprovada para
um problema recorrente em certo contexto, em meio a preocupaes concorrentes [App00].
Em outras palavras, um padro de projeto descreve uma estrutura de projeto que resolve uma
particular categoria de problemas de projeto em um contexto especfico e entre foras que
direcionam a maneira pela qual o padro aplicado e utilizado.
O intuito de cada padro de projeto fornecer uma descrio que permite a um projetista
determinar (1) se o padro se aplica ou no ao trabalho em questo, (2) se o padro pode ou
no ser reutilizado (e, portanto, poupando tempo) e (3) se o padro pode servir como um guia
para desenvolver um padro similar, mas funcional ou estruturalmente diferente. Os padres de
projeto so discutidos de forma detalhada no Captulo 12.

8.3.4 Separao por interesses (por afinidades)

AVISO
O argumento para
a separao por
interesses pode se
estender muito mais.
Se dividirmos um
problema em um
nmero excessivo
de problemas muito
pequenos, resolver
cada um deles ser
fcil, porm, junt-los
em uma soluo
integrao talvez
seja muito difcil.

A separao por interesses um conceito de projeto [Dij82] que sugere que qualquer problema complexo pode ser tratado mais facilmente se for subdividido em trechos a ser resolvidos e/
ou otimizados independentemente. Interesse se manifesta como uma caracterstica ou comportamento especificados como parte do modelo de requisitos do software. Por meio da separao
por interesses em blocos menores e, portanto, mais administrveis, um problema toma menos
tempo para ser resolvido.
Para dois problemas, p1 e p2, se a complexidade percebida de p1 for maior do que a percebida
para p2, segue que o esforo necessrio para solucionar p1 maior do que o esforo necessrio
para solucionar p2. Como caso geral, esse resultado intuitivamente bvio. Leva mais tempo
para resolver um problema difcil.
Segue tambm que a complexidade percebida de dois problemas, quando estes so combinados, normalmente maior do que soma da complexidade percebida quando cada um deles
tomado separadamente. Isso nos leva a uma estratgia dividir-para-conquistar mais fcil
resolver um problema complexo quando o subdividimos em partes gerenciveis. Isso tem implicaes importantes em relao modularidade do software.
A separao por interesses manifesta-se em outros conceitos relacionados ao projeto: modularidade, aspectos, independncia funcional e refinamento.

8.3.5Modularidade
Modularidade a manifestao mais comum da separao por interesses. O software dividido em componentes separadamente especificados e endereveis, algumas vezes denominados mdulos, que so integrados para satisfazer os requisitos de um problema.
Afirmou-se que modularidade o nico atributo de software que possibilita que um programa seja intelectualmente gerencivel [Mye78]. Software monoltico (um grande programa

215

captulo 8 CONCEITOS DE PROJETO

Figura 8.2
Custo total do software

Modularidade e
custo do software
Custo ou esforo

Custo de integrao
Regio de
custo mnimo
M

Custo/mdulo
Nmero de mdulos

o
? Qual
nmero exato

de mdulos para
um dado sistema?

composto de um nico mdulo) no pode ser facilmente entendido por um engenheiro de software. O nmero de caminhos de controle, abrangncia de referncia, nmero de variveis e
complexidade geral tornaria o entendimento prximo do impossvel. Em quase todos os casos,
devemos dividir o projeto em vrios mdulos, para facilitar a compreenso e, consequentemente, reduzir o custo necessrio para construir o software.
Recapitulando nossa discusso sobre separao por interesses, possvel concluir que, se
subdividirmos o software indefinidamente, o esforo exigido para desenvolv-lo seja pequeno!
Infelizmente, outros fatores entram em jogo, invalidando essa concluso. Referindo-se Figura
8.2, o esforo (custo) para desenvolver um mdulo de software individual realmente diminui
medida que o nmero total de mdulos cresce. Dado o mesmo conjunto de requisitos, tambm
com mais mdulos, significa tamanho individual menor. Entretanto, medida que o nmero de
mdulos aumenta, o esforo (custo) associado integrao dos mdulos tambm cresce. Essas
caractersticas levam a um custo total ou curva de esforo mostrada na figura. Existe um nmero M de mdulos que resultaria em um custo de desenvolvimento mnimo, porm no temos a
sofisticao suficiente para prever M com certeza.
As curvas da Figura 8.2 nos do uma til orientao qualitativa quando a modularidade
considerada. Devemos modularizar, mas tomar cuidado para permanecer nas vizinhanas de
M. Devemos evitar modularizar a menos ou a mais. Mas como saber a vizinhana de M? Quo
modular devemos fazer com que um software seja? As respostas a essas perguntas exigem um
entendimento de outros conceitos de projeto considerados posteriormente neste captulo.
Modularizamos um projeto (e o programa resultante) de modo que o desenvolvimento possa
ser planejado mais facilmente; incrementos de software possam ser definidos e entregues; as
mudanas possam ser mais facilmente acomodadas; os testes e depurao possam ser conduzidos de forma mais eficaz e a manuteno no longo prazo possa ser realizada sem efeitos
colaterais srios.

8.3.6 Encapsulamento7 de informaes


O conceito de modularidade nos leva a uma questo fundamental: Como decompor uma soluo de software para obter o melhor conjunto de mdulos?. O princpio de encapsulamento
de informaes [Par72] sugere que os mdulos sejam caracterizados por decises de projeto
que ocultem (cada uma delas) de todas as demais. Em outras palavras, os mdulos devem ser
especificados e projetados de modo que as informaes (algoritmos e dados) contidas em um
mdulo sejam inacessveis por parte de outros mdulos que no necessitam tais informaes,
disponibilizando apenas os itens que interessam aos outros mdulos.

N. de T.: Encapsular uma tcnica de engenharia largamente usada. Por exemplo, um componente de hardware digital projetado da seguinte forma: esconde aspectos que no interessam aos demais componentes e publica aspectos teis aos demais
componentes.

216

O intuito de
encapsulamento
de informaes
esconder os
detalhes das
estruturas de dados
e de processamento
procedural que
esto por trs da
interface de acesso
a um mdulo. Os
detalhes no precisam
ser conhecidos por
usurios do mdulo.

PARTE DOIS MODELAGEM

Encapsular implica que efetiva modularidade pode ser conseguida por meio da definio
de um conjunto de mdulos independentes que passam entre si apenas as informaes necessrias para realizar determinada funo do software. A abstrao ajuda a definir as entidades
procedurais (ou informativas) que constituem o software. Encapsulamento define e impe restries de acesso tanto a detalhes procedurais em um mdulo quanto em qualquer estrutura de
dados local usada pelo mdulo [Ros75].
O uso de encapsulamento de informaes como critrio de projeto para sistemas modulares
fornece seus maiores benefcios quando so necessrias modificaes durante os testes e, posteriormente, durante a manuteno do software. Como a maioria dos detalhes procedurais e de
dados so ocultos para outras partes do software, erros introduzidos inadvertidamente durante
a modificao em um mdulo tm menor probabilidade de se propagar para outros mdulos ou
locais dentro do software.

8.3.7Independncia funcional
O conceito de independncia funcional um resultado direto da separao por interesses,
da modularidade e dos conceitos de abstrao e encapsulamento de informaes. Em artigos
marcantes sobre projeto de software, Wirth [Wir71] e Parnas [Par72] tratam tcnicas de refinamento que aumentam a independncia entre mdulos. Trabalho posterior de Stevens, Myers e
Constantine [Ste74] solidificaram o conceito.
A independncia funcional atingida desenvolvendo-se mdulos com funo nica e com
averso interao excessiva com outros mdulos. Em outras palavras, devemos projetar software de modo que cada mdulo atenda um subconjunto especfico de requisitos e tenha uma
interface simples quando vista de outras partes da estrutura do programa. razovel perguntar
por que a independncia importante.

que
? Por
devemos

nos esforar para


criar mdulos
independentes?

Coeso uma
indicao qualitativa
do grau com o
qual um mdulo se
concentra em fazer
apenas uma coisa.

Acoplamento uma
indicao qualitativa
do grau com o qual
um mdulo est
conectado a outros
mdulos e com o
mundo externo.

Software com efetiva modularidade, isto , mdulos independentes, mais fcil de ser desenvolvido, pois a funo pode ser compartimentalizada e as interfaces simplificadas (considere
as consequncias quando o desenvolvimento conduzido por uma equipe). Mdulos independentes so mais fceis de ser mantidos (e testados), pois efeitos colaterais provocados por
modificao no cdigo ou projeto so limitados, a propagao de erros reduzida e mdulos
reutilizveis so possveis. Em suma, a independncia funcional a chave para um bom projeto,
e projeto a chave para a qualidade de um software.
A independncia avaliada usando-se dois critrios qualitativos: coeso e acoplamento. A
coeso indica a robustez funcional relativa de um mdulo. O acoplamento indica a interdependncia relativa entre os mdulos.
A coeso uma extenso natural do conceito do encapsulamento de informaes descrito
na Seo 8.3.6. Um mdulo coeso realiza uma nica tarefa, exigindo pouca interao com outros componentes em outras partes de um programa. De forma simples, um mdulo coeso deve
(idealmente) fazer apenas uma coisa. Embora voc sempre deva tentar ao mximo obter uma
alta coeso (funcionalidade nica), muitas vezes necessrio e recomendvel fazer com que
um componente de software realize vrias funes. Entretanto, componentes esquizofrnicos
(mdulos que realizam muitas funes no relacionadas) devem ser evitados caso se queira um
bom projeto.
O acoplamento uma indicao da interconexo entre os mdulos em uma estrutura de software e depende da complexidade da interface entre os mdulos, do ponto onde feito o acesso a um mdulo e dos dados que passam pela interface. Em projeto de software, voc deve
se esforar para obter o menor grau de acoplamento possvel. A conectividade simples entre
mdulos resulta em software mais fcil de ser compreendido e menos sujeito a reao em
cadeia [Ste74], provocada quando ocorrem erros, em um ponto, que se propagam por todo
o sistema.

captulo 8 CONCEITOS DE PROJETO

AVISO
Existe uma tendncia
de ir imediatamente
at o ltimo detalhe,
pulando as etapas
de refinamento.
Isso induz a erros e
omisses e torna o
projeto muito mais
difcil de ser revisado.
Realize o refinamento
gradual.

difcil ler de
cabo a rabo
um livro sobre
princpios de
mgica sem, de
tempos em tempos,
dar uma olhada
na capa para ter
certeza de que
no um livro
sobre projeto de
software.
Bruce Tognazzini

Preocupao em
comum alguma
caracterstica do
sistema que se aplica
a vrios requisitos
diferentes.

217

8.3.8 Refinamento
O refinamento gradual uma estratgia de projeto top-down proposta originalmente por
Niklaus Wirth [Wir71]. Um programa desenvolvido refinando-se sucessivamente nveis de detalhes procedurais. desenvolvida uma hierarquia atravs da decomposio de uma declarao
macroscpica da funo (uma abstrao procedural) de forma gradual at que as declaraes da
linguagem de programao sejam atingidas.
Refinamento , na verdade, um processo de elaborao. Comeamos com um enunciado
da funo (ou descrio de informaes) definida em um alto nvel de abstrao. O enunciado
descreve a funo ou informaes conceitualmente, mas no fornece nenhuma informao sobre o funcionamento interno da funo ou da estrutura interna das informaes. Em seguida,
elaboramos a declarao original, fornecendo cada vez mais detalhes medida que ocorre cada
refinamento (elaborao) sucessivo.
Abstrao e refinamento so conceitos complementares. A abstrao nos permite especificar
procedimento e dados internamente, mas suprimir a necessidade de que estranhos tenham
conhecimento de detalhes de baixo nvel. O refinamento nos ajuda a revelar detalhes menores
medida que o projeto avana. Ambos os conceitos permitem que criemos um modelo de projeto
completo medida que o projeto evolui.

8.3.9Aspectos
medida que ocorre anlise de requisitos, vai sendo revelado um conjunto de interesses
(ou afinidades). Entre tais interesses temos os requisitos, os casos de uso, as caractersticas,
as estruturas de dados, questes de qualidade de servio, variaes, limites de propriedade
intelectual, colaboraes, padres e contratos [AOS07]. Idealmente, um modelo de requisitos
pode ser organizado de forma que lhe permita isolar grupos de interesses (requisitos) para que
possam ser considerados independentemente. Na prtica, entretanto, alguns desses interesses
abrangem o sistema inteiro e no pode ser facilmente dividido em compartimentos.
Quando um projeto se inicia, os requisitos so refinados em uma representao de projeto
modular. Consideremos dois requisitos, A e B. O requisito A intersecciona o requisito B se tiver
sido escolhida uma decomposio [refinamento] de software em que B no pode ser satisfeito
sem levar em conta A [Ros04].
Consideremos, por exemplo, dois requisitos para a WebApp CasaSeguraGarantida.com.
O requisito A descrito por meio do caso de uso AVC-EVC discutido no Captulo 6. O refinamento de um projeto poderia se concentrar naqueles mdulos que permitiriam a um usurio registrado acessar imagens de vdeo de cmeras distribudas em um ambiente. O requisito B um
requisito de segurana genrico que afirma que um usurio registrado tem de ser validado antes
de usar CasaSeguraGarantida.com. Esse requisito se aplica a todas as funes disponveis
para os usurios registrados de CasaSegura. medida que ocorre o refinamento de projeto, A*
uma representao de projeto para o requisito A, e B* uma representao de projeto para o
requisito B. Consequentemente, A* e B* so representaes de interesses, e B* tem interseco
com A*.
Aspecto uma representao de um interesse em comum. Consequentemente, a representao de projeto, B*, do requisito um usurio registrado tem de ser validado antes de poder usar CasaSeguraGarantida.com, um aspecto da WebApp CasaSegura. importante
identificar aspectos de modo que o projeto possa acomod-los apropriadamente medida que
ocorre o refinamento e a modularizao. Em um contexto ideal, um aspecto implementado
como um mdulo (componente) separado, em vez de fragmentos de software que esto espalhados ou emaranhados atravs de vrios componentes [Ban06]. Para tanto, a arquitetura
de projeto deve oferecer suporte a um mecanismo para definio de aspectos um mdulo
que possibilite que um interesse seja implementado e atenda aos demais interesses que ele
interseccione.

218

PARTE DOIS MODELAGEM

WebRef
Excelentes recursos
sobre refabricao
podem ser encontrados
em www.refactor
ing.com.

WebRef
Uma srie de padres
de refatorao podem
ser encontrados em
http://c2.com/
cgi/wiki? Refac
toring Patterns.

8.3.10 Refatorao
Uma importante atividade sugerida por diversos mtodos geis (Captulo 3), a refatorao
uma tcnica de reorganizao que simplifica o projeto (ou cdigo) de um componente sem
mudar sua funo ou comportamento. Fowler [Fow00] define refatorao da seguinte maneira:
Refatorao o processo de mudar um sistema de software de tal forma que no altere o comportamento externo do cdigo [projeto], embora melhore sua estrutura interna.
Quando um software refabricado, o projeto existente examinado em termos de redundncia, elementos de projeto no utilizados, algoritmos ineficientes ou desnecessrios, estruturas de
dados mal construdas ou inapropriadas, ou qualquer outra falha de projeto que possa ser corrigida para produzir um projeto melhor. Por exemplo, uma primeira iterao de projeto poderia gerar
um componente que apresentasse baixa coeso (realizar trs funes que possuem apenas relacionamento limitado entre si). Aps cuidadosa considerao, talvez decidamos que o componente
devesse ser refabricado em trs componentes distintos, cada um apresentando alta coeso.
O resultado ser um software mais fcil de se integrar, testar e manter.

C asa S egura
Conceitos de projeto
Cena: Sala do Vinod, quando comea a
modelagem de projetos.
Atores: Jamie, Vinod e Ed todos membros da equipe de engenharia de software do CasaSegura. Tambm participa Shakira, novo membro da equipe.
Conversa:
[Todos os quatro membros da equipe acabaram de voltar de um
seminrio intitulado Aplicao de Conceitos Bsicos de Projeto, oferecido por um professor de computao.]
Vinod: Vocs tiveram algum proveito do seminrio?
Ed: J conhecia grande parte do que foi falado, mas no uma
m ideia ouvir novamente, suponho.
Jamie: Quando era aluno de Cincias da Computao, nunca
realmente entendi por que o encapsulamento de informaes
era to importante como diziam.
Vinod: Porque... Essencialmente... uma tcnica para reduzir
a propagao de erros em um programa. Na verdade, a independncia funcional tambm realiza a mesma coisa.
Shakira: Eu no fiz Cincias da Computao, portanto, um
monte de coisas que o professor mencionou novidade para
mim. Sou capaz de gerar bom cdigo e rapidamente. No vejo
por que isso to importante.

Jamie: Vi seu trabalho, Shak, e sabe de uma coisa, voc j faz


grande parte do que foi dito naturalmente... por isso que seus
projetos e cdigos funcionam.
Shakira (sorrindo): Bem, sempre realmente tento subdividir
o cdigo, mant-lo concentrado em algo, manter as interfaces
simples e restritas, reutilizar cdigo sempre que posso... Esse
tipo de coisa.
Ed: Modularidade, independncia funcional, encapsulamento,
padres... Sabe.
Jamie: Ainda me lembro do primeiro curso de programao que
fiz... Eles nos ensinaram a refinar o cdigo iterativamente.
Vinod: O mesmo pode ser aplicado ao projeto, sabe.
Vinod: Os nicos conceitos que ainda no havia ouvido falar
foram aspectos e refabricao.
Shakira: Isso usado em Extreme Programming, acho que foi
isso que ele disse.
Ed: Exato. No muito diferente do refinamento, apenas que
voc o faz depois que o projeto ou cdigo esteja completo. Acontece uma espcie de otimizao no software, se voc quer saber.
Jamie: Retornemos ao projeto CasaSegura. Imagino que devamos colocar esses conceitos em nossa lista de controle de reviso medida que desenvolvermos o modelo de projeto para o
CasaSegura.
Vinod: concordo. Mas to importante quanto, vamos todos nos
comprometer a pensar nelas enquanto desenvolvemos o projeto.

8.3.11Conceitos de projeto orientado a objetos


O paradigma orientado a objetos (object oriented, OO) largamente utilizado na engenharia de
software moderna. O Apndice 2 dirigido queles que talvez no estejam familiarizados com conceitos de projeto OO como classes e objetos, herana, mensagens e polimorfismo, entre outros.

8.3.12Classes de projeto
O modelo de requisitos define um conjunto de classes de anlise (Captulo 6). Cada um descreve algum elemento do domnio do problema, concentrando-se nos aspectos do problema

captulo 8 CONCEITOS DE PROJETO

219

visveis ao usurio. O nvel de abstrao de uma classe de anlise relativamente alto. medida
que o modelo de projeto evoluir, definiremos um conjunto de classes de projeto que refinem as
classes de anlise, fornecendo detalhes de projeto que permitiro que as classes sejam implementadas, e implementem uma infraestrutura de software que suporte a soluo do negcio.
Podem ser desenvolvidos cinco tipos diferentes de classes de projeto, cada um deles representando uma camada diferente da arquitetura de projeto [Amb01]:
tipos
? Quais
de classes o

projetista cria?

Classes de interfaces do usurio definem todas as abstraes necessrias para a interao


humano-computador (human-computer interaction, HCI). Em muitos casos, a HCI acontece no contexto de uma metfora (por exemplo, um talo de cheques, um formulrio de
pedidos, uma mquina de fax) e as classes de projeto para uma interface poderiam ser
representaes visuais dos elementos da metfora.
Classes de domnio de negcio normalmente so refinamentos das classes de anlise definidas anteriormente. As classes identificam os atributos e servios (mtodos) necessrios
para implementar algum elemento do domnio de negcio.
Classes de processos implementam as abstraes de aplicao de baixo nvel necessrias
para a completa gesto das classes de domnio de negcio.
Classes persistentes representam repositrios de dados (por exemplo, um banco de dados) que persistir depois da execuo do software.
Classes de sistema implementam funes de gerenciamento e controle de software que
permitam ao sistema operar e comunicar em seu ambiente computacional e com o mundo exterior.
medida que a arquitetura se forma, o nvel de abstrao reduzido enquanto cada classe
de anlise transformada em uma representao de projeto. As classes de anlise representam
objetos de dados (e servios associados aplicados a eles) usando o jargo do domnio de negcio. As classes de projeto apresentam significativamente mais detalhes tcnicos como um guia
para a implementao.
Arlow e Neustadt [Arl02] sugerem que cada classe de projeto seja revista para garantir que seja
bem formada. Eles definem quatro caractersticas de uma classe de projeto bem formada:

? Oumaqueclasse

de projeto bem
formada?

Completa e suficiente. Uma classe de projeto deve ser o encapsulamento completo de


todos os atributos e mtodos que podem ser razoavelmente esperados (baseado em uma
interpretao inteligente do nome da classe) para a classe. Por exemplo, a classe Cena definida para software de edio de vdeo completa apenas se contiver todos os atributos e
mtodos que podem ser razoavelmente associados com a criao de uma cena de vdeo. Suficincia garante que a classe de projeto contenha apenas os mtodos suficientes para atingir
o objetivo da classe, nem mais nem menos.
Primitivismo. Os mtodos associados a uma classe de projeto deveriam se concentrar na
realizao de um servio para a classe. Assim que o servio tivesse sido implementado com
um mtodo, a classe no deveria realizar de outra maneira a mesma coisa. Por exemplo,
a classe VideoClipe para um software de edio de vdeo poderia ter atributos ponto de
incio e ponto final para indicar os pontos de incio e fim do clipe (note que uma fita virgem
carregada no sistema talvez seja mais longa do que o clipe que usado). Os mtodos, estabelecerPontoIncio() e estabelecerPontoFinal(), fornecem os nicos meios para estabelecer os
pontos de incio e fim do clipe.
Alta coeso. Uma classe de projeto coesa tem um conjunto de responsabilidades pequeno
e focado e de forma resoluta aplica atributos e mtodos para implementar essas responsabilidades. Por exemplo, a classe VideoClipe poderia conter um conjunto de mtodos para
editar o videoclipe. Desde que cada mtodo se concentra exclusivamente nos atributos associados ao videoclipe, a coeso mantida.
Baixo acoplamento. No modelo de projeto, necessrio para as classes colaborarem entre
si. Entretanto, a colaborao deveria ser mantida em um mnimo aceitvel. Se um modelo de

220

PARTE DOIS MODELAGEM

projeto for altamente acoplado (todas as classes de projeto colaboram com todas as demais
classes de projeto), o sistema difcil de implementar, testar e manter ao longo do tempo.
Em geral, as classes de projeto em um subsistema deveriam ter apenas um conhecimento
limitado das demais classes. Essa restrio, chamada Lei de Demeter [Lie03], sugere que um
mtodo deveria enviar mensagens apenas para mtodos em classes vizinhas.8

C asa S egura
Refinamento de uma classe de anlise em uma classe de projeto
Cena: Sala do Ed, quando comea o modelamento de projetos.
Atores: Vinod e Ed membros da equipe de engenharia de
software do CasaSegura.
Conversa:
[Ed est trabalhando na classe Planta (veja discusso no quadro da Seo 6.5.3 e na Figura 6.10) e a refinou para o modelo
de projeto.]
Ed: Ento, voc se lembra da classe Planta, certo? Ela usada
como parte das funes de vigilncia e gesto da casa.
Vinod (confirmando com a cabea): isso mesmo, parece
que ns a usamos como parte de nossas discusses CRC para
gesto da casa.
Ed: Usamos. De qualquer maneira, estou refinando-a para o
projeto. Gostaria de mostrar como realmente implementaremos
a classe Planta. Minha ideia implement-la como um conjunto de listas ligadas [uma estrutura de dados especfica] Portanto... Eu tinha de refinar a classe de anlise
Planta (Figura 6.10) e, na verdade, simplific-la.

Vinod: A classe de anlise mostrava coisas apenas no domnio


do problema, bem, na verdade na tela do computador, o que
era visvel para o usurio final, certo?
Ed: Isso, mas para a classe de projeto Planta, tive que acrescentar algumas coisas especficas da implementao. Precisava
mostrar que Planta uma agregao de segmentos da a
classe Segmento e que a classe Segmento composta
por listas de segmentos de parede, janelas, portas e assim por
diante. A classe Cmera colabora com Planta e, obviamente,
podem existir muitas cmeras na planta.
Vinod: Ufa, vejamos uma figura desta nova classe de projeto
Planta. [Ed mostra a Vinod o desenho apresentado na Figura
8.3.]
Vinod: Ok, vejo que voc est tentando fazer. Isso lhe permite modificar facilmente a planta, pois novos itens podem ser
acrescentados ou eliminados da lista a agregao sem
quaisquer problemas.
Ed (meneando a cabea): isso a, acho que vai funcionar.
Vinod: Eu tambm.

Figura 8.3
Classe de projeto
para a Planta
e agregao composta
para a classe
(veja no quadro
de discusso)

Planta
tipo
dimensesExternas
adicionarCmera( )
adicionarParede( )
adicionarJanela( )
removerSegmento( )
desenhar( )
1

Cmera
tipo
id
campoDeViso
nguloPan
ajusteDeZoom

*
Segmento
coordenadaInicial
coordenadaFinal
obterTipo( )
desenhar( )

SegmentoDeParede

Janela

Uma maneira menos formal de expressar a Lei de Demeter seria: Cada unidade deve conversar apenas com seus amigos; no
converse com estranhos.

221

captulo 8 CONCEITOS DE PROJETO

8 .4

O modelo de projeto
possui quatro
elementos principais:
dados, arquitetura,
componentes e
interface.
Questes como
se o projeto
necessrio ou
acessvel no vm
ao caso: o projeto
inevitvel. A
alternativa para
um bom projeto
um projeto ruim,
e no nenhum
projeto em
absoluto.
Douglas Martin

O Modelo

de

Projeto

O modelo de projeto pode ser visto em duas dimenses diferentes conforme ilustrado na
Figura 8.4. A dimenso processo indica uma evoluo do modelo de projeto medida que as
tarefas de projeto so executadas como parte do processo do software. A dimenso da abstrao
representa o nvel de detalhe medida que cada elemento do modelo de anlise transformado
em um equivalente de projeto e ento refinado iterativamente. Referindo-se Figura 8.4, a linha
tracejada indica o limite entre os modelos de anlise e de projeto. Em alguns casos, possvel
ter uma clara distino entre os modelos de anlise e de projeto. Em outros, o modelo de anlise
vai lentamente se misturando ao de projeto e essa distino clara menos evidente.
Os elementos do modelo de projeto usam vrios dos diagramas9 UML utilizados no modelo
de anlise. A diferena que esses diagramas so refinados e elaborados como parte do projeto;
so fornecidos detalhes mais especficos implementao e enfatizados a estrutura e o estilo
da arquitetura, os componentes que residem nessa arquitetura, bem como as interfaces entre os
componentes e com o mundo exterior.
Deve-se notar, entretanto, que os elementos de modelo indicados ao longo do eixo horizontal nem sempre so desenvolvidos de maneira sequencial. Na maioria dos casos, um projeto
de arquitetura preliminar prepara o terreno e seguido pelos projetos de interfaces e projeto
de componentes, que normalmente ocorrem em paralelo. O modelo de implantao em geral
retardado at que o projeto tenha sido completamente desenvolvido.
Podemos aplicar padres de projeto (Captulo 12) em qualquer ponto durante o projeto. Estes possibilitam a utilizao de conhecimentos adquiridos em projetos anteriores a problemas
de domnios especficos encontrados e solucionados por outros.

Figura 8.4
Dimenses do
modelo de projeto
Alto

Dimenso de abstrao

Modelo de Anlise
Diagramas de classes
Pacotes de anlise
Modelos CRC
Diagramas de colaborao
Diagramas de fluxo de
dados
Diagramas de fluxo de
controle
Narrativas de processamento

Realizaes das classes


de projeto
Subsistemas
Diagramas de
colaborao

Modelo de projeto

Baixo

Diagramas de classes
Pacotes de anlise
Casos de uso texto
Modelos CRC
Diagramas de casos
Diagramas de colaborao
Requisitos:
de uso
Diagramas de fluxo
Restries
Diagramas de atividade
de dados
Interoperabilidade
Diagramas de raias
Diagramas de fluxo de
Metas e
Diagramas de
controle
colaborao
configurao
Narrativas
de
processamento
Diagramas de estados
Diagramas
de
estados
Diagramas de sequncia
Diagramas de sequncia

Projeto tcnico da
interface
Projeto de navegao
Projeto da interface
grfica do usurio

Refinamentos para:
Realizaes
das classes de projetos
Subsistemas
Diagramas de
colaborao
Elementos da
arquitetura

Elementos da
interface

Diagramas de componentes
Classes de projeto
Diagramas de atividade
Diagramas de sequncia

Realizaes das classes


de projeto
Subsistemas
Diagramas de colaborao
Diagramas de componentes
Classes de projeto
Refinamentos para:
Diagramas de atividade
Diagramas de componentes Diagramas de sequncia
Classes de projetos
Diagramas de atividades
Diagramas de sequncia
Diagramas de implantao
Elementos de
componentes

Dimenso de processo

O Apndice 1 apresenta um tutorial sobre conceitos bsicos e notao da UML.

Elementos de
implantao

222

PARTE DOIS MODELAGEM

8.4.1 Elementos de projeto de dados

No nvel da arquitetura
(aplicao), o
projeto de dados
se concentra em
arquivos ou bancos
de dados; no nvel
dos componentes,
o projeto de dados
considera as estruturas
de dados necessrias
para implementar
os objetos de dados
locais.

Assim como ocorre com outras atividades da engenharia de software, o projeto de dados
(tambm conhecido como arquitetura de dados) cria um modelo de dados e/ou informaes
que representado em um nvel de abstrao elevado (a viso do cliente/usurio dos dados).
Esse modelo ento refinado em representaes cada vez mais especficas da implementao
que podem ser processadas pelo sistema baseado em computador. Em muitas aplicaes de
software, a arquitetura dos dados ter uma profunda influncia na arquitetura do software que
deve process-los.
A estrutura de dados sempre foi uma importante parte do projeto de software. No nvel
dos componentes de programa, o projeto das estruturas de dados e os algoritmos associados
necessrios para manipul-los essencial para a criao de aplicaes de alta qualidade. No
nvel da aplicao, a transformao de um modelo de dados (obtido como parte da engenharia
de necessidades) em um banco de dados fundamental para atingir os objetivos de negcio
de um sistema. No nvel de negcio, o conjunto de informaes armazenadas em bancos de
dados diferentes e reorganizadas em um depsito de dados possibilita o data mining ou descoberta de conhecimento que pode ter um impacto no sucesso do negcio em si. Em qualquer
caso, o projeto de dados desempenha um importante papel e discutido com mais detalhes
no Captulo 9.

8.4.2 Elementos de projeto de arquitetura


Voc pode usar
uma borracha
enquanto ainda
estiver na
prancheta ou uma
marreta na obra
depois.
Frank Lloyd
Wright

O pblico est
mais acostumado
com projetos
ruins do que
bons projetos.
Ele est, de fato,
condicionado a
preferir projetos
ruins, pois
com isso que ele
convive. O novo
representa uma
ameaa, o antigo,
um sentimento de
tranquilidade.
Paul Rand

O projeto de arquitetura para software o equivalente planta baixa para uma casa. A planta
baixa representa a distribuio dos cmodos; seus tamanhos, formas e relacionamentos entre si
e as portas e janelas que possibilitam o deslocamento para dentro e fora dos cmodos. A planta
baixa nos d uma viso geral da casa. Os elementos de projeto de arquitetura nos do uma viso
geral do software.
O modelo de arquitetura [Sha96] obtido de trs fontes: (1) informaes sobre o domnio de
aplicao do software a ser construdo; (2) elementos especficos de modelo de requisitos como
os diagramas de fluxo de dados ou as classes de anlise, seus relacionamentos e colaboraes
para o problema em questo; e (3) a disponibilidade de estilos de arquitetura (Captulo 9) e padres (Captulo 12).
O projeto dos elementos de arquitetura normalmente representado como um conjunto de
subsistemas interligados, em geral derivados dos pacotes de anlise contidos no modelo de requisitos. Cada subsistema pode ter sua prpria arquitetura (por exemplo, uma interface grfica
do usurio poderia ser estruturada de acordo com um estilo de arquitetura preexistente para
interfaces do usurio). Tcnicas para obteno de elementos especficos do modelo de arquitetura so apresentadas no Captulo 9.

8.4.3 Elementos de projeto de interfaces


O projeto de interfaces para software anlogo a um conjunto de desenhos detalhados (e
especificaes) para portas, janelas e ligaes externas de uma casa. Esses desenhos representam o tamanho e a forma das portas e janelas, a maneira por meio da qual funcionam, a
maneira pela qual as ligaes de servios pblicos (por exemplo, gua, energia eltrica, gs,
telefone) entram na casa e so distribudas entre os cmodos representados na planta. Eles nos
informam onde se encontra a campainha, se deve ser usado ou no um porteiro eletrnico para
anunciar a presena de um visitante e como um sistema de segurana deve ser instalado. Em
essncia, os desenhos detalhados (e especificaes) para portas, janelas e ligaes externas nos
notificam como as coisas e as informaes fluem para dentro e para fora da casa e no interior
dos cmodos que fazem parte da planta. Os elementos de projeto de interfaces para software
representam fluxos de informao que entram e saem do sistema e como so transmitidos entre
os componentes definidos como parte da arquitetura.

captulo 8 CONCEITOS DE PROJETO

H trs partes para o


elemento de projeto
de interfaces: a
interface do usurio,
interfaces com os
sistemas externos
aplicao e interfaces
com componentes
internos aplicao.
De tempos em
tempos d uma
volta, relaxe um
pouco, de modo
que ao voltar
para o trabalho
seu julgamento
seja mais seguro.
Afaste-se um
pouco; o trabalho
parecer menor e
grande parte dele
poder ser vista
com um pequeno
exame, e a falta
de harmonia e
proporo sero
visualizadas mais
facilmente.
Leonardo
DaVinci

WebRef
Informaes
extremamente valiosas
no projeto da UI podem
ser encontradas em
www.useit.com.

Um erro
comum que as
pessoas cometem
ao tentarem
projetar algo
completamente
infalvel
subestimar a
criatividade de
completos idiotas.
Douglas Adams

223

H trs importantes elementos de projeto de interfaces: (1) a interface do usurio (user interface, UI); (2) interfaces externas para outros sistemas, dispositivos, redes ou outros produtores ou consumidores de informao; e (3) interfaces internas entre vrios componentes de
projeto. Esses elementos de projeto de interfaces possibilitam que o software se comunique
externamente e que a comunicao interna e a colaborao entre os componentes preencham
a arquitetura de software.
O projeto da UI (cada vez mais chamado projeto de usabilidade) uma importante ao da
engenharia de software e considerado em detalhes no Captulo 11. O projeto de usabilidade
incorpora elementos estticos (por exemplo, layout, cor, imagens, mecanismos de interao),
elementos ergonmicos (por exemplo, o layout e a colocao de informaes, metforas, navegao da UI) e elementos tcnicos (por exemplo, padres UI, componentes reutilizveis). Em
geral, a UI um subsistema exclusivo da arquitetura da aplicao geral.
O projeto de interfaces externas requer informaes definitivas sobre a entidade para as
quais as informaes so enviadas ou recebidas. Em todos os casos, essas informaes devem
ser coletadas durante a engenharia de requisitos (Captulo 5) e verificadas assim que o projeto
de interface for iniciado.10 O projeto de interfaces externas deve incorporar a verificao de erros
e (quando necessrio) caractersticas de segurana apropriadas.
O projeto de interfaces internas est intimamente ligado ao projeto dos componentes (Captulo 10). As realizaes de projeto das classes de anlise representam todas as operaes e
os esquemas de troca de mensagens necessrios para habilitar a comunicao e a colaborao
entre as operaes em vrias classes. Cada mensagem deve ser desenvolvida para acomodar
a transferncia de informaes requeridas e os requisitos funcionais especficos da operao
solicitada. Se for escolhida a abordagem clssica de entrada-processo-sada para o projeto, a
interface de cada componente de software projetada tomando como base as representaes
do fluxo de dados e a funcionalidade descrita em uma narrativa de processamento.
Em alguns casos, uma interface modelada de forma bastante parecida com a de uma classe. Na UML, a interface definida da seguinte maneira [OMG03a]: Interface um especificador
para as operaes [pblicas] visveis externamente de uma classe, componente ou outro classificador (incluindo subsistemas), sem a especificao da estrutura interna. De maneira mais
simples, interface um conjunto de operaes que descreve alguma parte do comportamento
de uma classe e d acesso a essas operaes.
Por exemplo, a funo de segurana do CasaSegura faz uso de um painel de controle que
possibilita a um proprietrio de imvel controlar certos aspectos da funo de segurana. Em
uma verso mais avanada do sistema, as funes do painel de controle poderiam ser implementadas por meio de um PDA sem fio ou telefone celular.
A classe PainelControle (Figura 8.5) fornece o comportamento associado com um teclado e, consequentemente, deve implementar as operaes lerTeclaPressionada () e decodificarTecla(). Se essas operaes tiverem de ser fornecidas para outras classes (no caso,
PDASemFio e TelefoneMvel), til definir uma interface conforme mostra a figura. A
interface, chamada Teclado, apresentada como um esteretipo <<interface>> ou como
um pequeno crculo identificado ligado classe por meio de uma linha. A interface definida sem nenhum atributo e conjunto de operaes necessrios para atingir o comportamento
de um teclado.
A linha tracejada com um tringulo com fundo branco em sua ponta (Figura 8.5) indica que
a classe PainelControle fornece operaes de Teclado como parte de seu comportamento.
Na UML, isso caracterizado como uma realizao. Ou seja, parte do comportamento de PainelControle ser implementada realizando as operaes de Teclado. Essas operaes sero
fornecidas a outras classes que acessam a interface.

10 As caractersticas das interfaces podem mudar ao longo do tempo. Consequentemente, um projetista deve assegurar que a
especificao para uma interface seja precisa e completa.

224

PARTE DOIS MODELAGEM

Figura 8.5
TelefoneMvel

Representao da
interface para
PainelControle

PDASemFio

PainelControle
mostradorLCD
indicadoresLED
caractersticasDeTeclado
microfone
interfaceSemFio
lerTeclaPressionada( )
decodificarTecla( )
exibirEstado( )
acenderLED( )
enviarMsgDeControle( )

Teclado

<<Interface>>
Teclado
lerTeclaPressionada( )
decodificarTecla( )

8.4.4 Elementos de projeto de componentes

Os detalhes no
so detalhes. Eles
fazem o projeto.
Charles Eames

O projeto de componentes para o software equivale a um conjunto de desenhos detalhados (e


especificaes) para cada cmodo de uma casa. Esses desenhos representam a fiao e o encanamento dentro de cada cmodo, a localizao das tomadas e interruptores, torneiras, pias, chuveiros,
banheiras, ralos, armrios e banheiros. Eles tambm descrevem o piso a ser usado, as molduras a
ser aplicadas e qualquer outro detalhe associado a um cmodo. O projeto de componentes para
software descreve completamente os detalhes internos de cada componente de software. Para tanto,
o projeto no nvel de componente define estruturas de dados para todos os objetos de dados locais
e detalhes algortmicos para todo o processamento que ocorre em um componente e uma interface
que d acesso a todas as operaes de componentes (comportamentos).
No contexto da engenharia de software orientada a objetos, um componente representado
em forma esquemtica em UML conforme mostra a Figura 8.6. Nessa figura, representado um
componente chamado GestoDeSensor (parte da funo de segurana do CasaSegura). Uma
seta pontilhada conecta o componente a uma classe chamada Sensor que atribuda a ele.
O componente GestoDeSensor realiza todas as funes associadas aos sensores do CasaSegura, incluindo seu monitoramento e configurao. Uma discusso mais abrangente sobre
diagramas de componentes apresentada no Captulo 10.
Os detalhes de projeto de um componente no podem ser modelados em muitos nveis de
abstrao diferentes. Um diagrama de atividades UML pode ser utilizado para representar processamento lgico. O fluxo procedural detalhado para um componente pode ser representado
usando pseudocdigo (uma representao similar a uma linguagem de programao descrita
no Captulo 10) ou alguma outra forma esquemtica (por exemplo, fluxograma ou diagrama de
blocos). A estrutura algortmica segue as regras estabelecidas para a programao estruturada
(um conjunto de construes procedurais restritas). As estruturas de dados escolhidas tomando
como base a natureza dos objetos de dados a ser processados normalmente so modeladas
usando pseudocdigo ou a linguagem de programao para implementao.

8.4.5 Elementos de projeto de implantao


Os elementos de projeto de implantao indicam como os subsistemas e a funcionalidade
de software sero alocados no ambiente computacional fsico que ir suportar o software. Por

225

captulo 8 CONCEITOS DE PROJETO

Figura 8.6
Um diagrama de
componentes
UML

Os diagramas de
disponibilizao
comeam na forma
de descritores, em
que o ambiente
de disponibilizao
descrito em
termos gerais.
Posteriormente,
usada a forma
de instncia, e
os elementos
da configurao
so descritos
explicitamente.

GestoDeSensor

Sensor

exemplo, os elementos do produto CasaSegura so configurados para operar dentro de trs ambientes computacionais principais um PC localizado na casa, o painel de controle CasaSegura
e um servidor localizado na CPI Corp. (fornecendo acesso ao sistema via Internet).
Durante o projeto, um diagrama de implantao UML desenvolvido e refinado conforme
mostra a Figura 8.7. Na figura, so apresentados trs ambientes computacionais (na verdade,
existiriam outros com a incluso de sensores, cmeras e outros dispositivos). Os subsistemas
(funcionalidade) abrigados em cada elemento computacional so indicados. Por exemplo, o PC
abriga subsistemas que implementam funes de segurana, vigilncia, gesto residencial e de
comunicao. Alm disso, um subsistema de acesso externo foi projetado para gerenciar todas
as tentativas para acessar o sistema CasaSegura de uma fonte externa. Cada subsistema seria
elaborado para indicar os componentes que ele implementa.
O diagrama apresentado na Figura 8.7 se encontra na forma de descritores. Isso significa
que o diagrama de disponibilizao mostra o ambiente computacional, mas no indica explicitamente detalhes de configurao. Por exemplo, o computador pessoal no tem uma identificao adicional. Ele poderia ser um Mac ou um PC com Windows, uma estao de trabalho da
Sun ou um computador com Linux. Esses detalhes so fornecidos quando o diagrama de implantao revisitado na forma de instncia durante os ltimos estgios do projeto ou quando
comea a construo. Cada instncia da disponibilizao (uma configurao de hardware com
nome e especfica) identificada.

Figura 8.7
Um diagrama de
implantao
UML

Painel de controle

Servidor na CPI

Segurana

AcessoProprietrio

Computador pessoal
AcessoExterno

Segurana

Vigilncia

GestoResidencial

Comunicao

226

PARTE DOIS MODELAGEM

8.5

Resumo
O projeto de software comea quando a primeira iterao da engenharia de requisitos chega
a uma concluso. O intuito do projeto de software aplicar um conjunto de princpios, conceitos e prticas que levam ao desenvolvimento de um sistema ou produto de alta qualidade. O
objetivo do projeto criar um modelo de software que ir implementar corretamente todos os
requisitos do cliente e trazer satisfao queles que o usarem. Os projetistas de software devem
examinar completamente muitas alternativas de projeto e convergir para uma soluo que melhor atenda s necessidades dos interessados no projeto.
O processo de projeto passa de uma viso macro do software para uma viso mais estreita
que define os detalhes necessrios para implementar um sistema. O processo comea concentrando-se na arquitetura. So definidos subsistemas; so estabelecidos mecanismos de comunicao entre os subsistemas; so identificados componentes; e desenvolvida uma descrio
detalhada de cada componente. Alm disso, so projetadas interfaces externas, internas e para
o usurio.
Os conceitos de projeto evoluram ao longo dos primeiros 60 anos do trabalho da engenharia de software. Eles descrevem atributos de software que devem estar presentes independentemente do processo de engenharia de software escolhido, dos mtodos de projeto aplicados
ou das linguagens de programao usadas. Em essncia, os conceitos de projeto enfatizam a
necessidade da abstrao como um mecanismo para a criao de componentes de software
reutilizveis; a importncia da arquitetura como forma para melhor entender a estrutura geral
de um sistema; os benefcios da engenharia baseada em padres como tcnica para desenvolvimento de software com capacidades j comprovadas; o valor da separao de preocupaes e
da modularidade eficaz como forma de tornar o software mais compreensvel, mais fcil de ser
testado e mantido; as consequncias do encapsulamento de informaes como um mecanismo
para reduzir a propagao de efeitos colaterais quando da real ocorrncia de erros; o impacto
da independncia funcional como critrio para a construo de mdulos eficazes; o uso do
refinamento como mecanismo de projeto; a considerao de aspectos que interseccionem as
necessidades do sistema; a aplicao da refabricao na otimizao do projeto que obtido; e a
importncia das classes orientadas a objetos e as caractersticas a elas relacionadas.
O modelo de projeto engloba quatro elementos distintos; medida que cada um desenvolvido, evolui uma viso mais completa do projeto. O elemento de arquitetura usa informaes extradas do domnio de aplicao, do modelo de requisitos e de catlogos disponveis
para padres e estilos para obter uma representao estrutural completa do software, seus
subsistemas e componentes. Elementos de projeto de interfaces modelam interfaces internas
e externas, bem como a interface do usurio. Elementos de componentes definem cada um
dos mdulos (componentes) que preenchem a arquitetura. Por fim, os elementos de disponibilizao alocam a arquitetura, seus componentes e as interfaces para a configurao fsica
que abrigar o software.

Problemas

Pontos

Ponderar

8.1. Voc projeta software ao escrever um programa? O que torna o projeto de software
diferente da codificao?
8.2. Se um projeto de software no um programa (e no mesmo), ento o que ele ?
8.3. Como avaliar a qualidade de um projeto de software?
8.4. Examine o conjunto de tarefas apresentado para o projeto. Em que momento a qualidade avaliada em um conjunto de tarefas? Como se consegue isso? Como os atributos de
qualidade discutidos na Seo 8.2.1 so atingidos?
8.5. D exemplos de trs abstraes de dados e as abstraes procedurais que podem ser
usadas para manipul-las.

227

captulo 8 CONCEITOS DE PROJETO

8.6. Descreva arquitetura de software com suas prprias palavras.


8.7. Sugira um padro de projeto que voc encontra em uma categoria das coisas cotidianas
(por exemplo, eletrnica de consumo, automveis, aparelhos domsticos). Descreva brevemente o padro.
8.8. Descreva a separao de preocupaes com suas prprias palavras. Existe um caso em
que a estratgia dividir-para-conquistar no poderia ser apropriada? Como um caso desses
poderia afetar o argumento da modularidade?
8.9. Quando um projeto modular deve ser implementado como um software monoltico?
Como isso pode ser obtido? O desempenho a nica justificativa para a implementao de
software monoltico?
8.10. Discuta a relao entre o conceito de encapsulamento de informaes como um atributo de modularidade eficaz e o conceito da independncia de mdulos.
8.11. Como os conceitos de acoplamento e portabilidade de software esto relacionados? D
exemplos para apoiar sua discusso.
8.12. Aplique uma abordagem de refinamento gradual para desenvolver trs nveis diferentes de abstraes procedurais para um ou mais dos seguintes programas: (a) desenvolver um preenchedor de cheques que, dada uma quantia numrica, imprimir a quantia por
extenso como exigido no preenchimento de cheques; (b) encontrar iterativamente as razes
de uma equao transcendente; (c) desenvolver um algoritmo de cronograma de tarefas simples para um sistema operacional.
8.13. Considere o software necessrio para implementar um recurso completo de navegao
(usando GPS) em um dispositivo de comunicao mvel porttil. Descreva duas ou trs preocupaes em comum que estariam presentes. Discuta como voc representaria uma dessas
preocupaes na forma de um aspecto.
8.14. Refabricao significa que modificamos todo o projeto iterativamente? Em caso negativo, o que significa?
8.15. Descreva brevemente cada um dos quatro elementos do modelo de projeto.

Leituras

Fontes

de

I n f o r m a o C o m p l e m e n ta r e s

Donald Norman escreveu dois livros (The Design of Everyday Things, Doubleday, 1990 e
The Psychology of Everyday Things, Harpercollins, 1988) que se tornaram clssicos na literatura de projeto e uma leitura obrigatria para qualquer um que projete qualquer coisa que
os seres humanos usam. Adams (Conceptual Blockbusting, 3. ed., Addison-Wesley, 1986) o
autor de um texto essencial para os projetistas que querem alargar sua maneira de pensar.
Por fim, um clssico de Polya (How to Solve It, 2. ed., Princeton University Press, 1988) fornece um processo genrico para resoluo de problemas que podem ajudar os projetistas de
software ao depararem com problemas complexos.
Seguindo a mesma tradio, Winograd et al. (Bringing Design to Software, Addison-Wesley, 1996) discutem projetos de software que funcionam, aqueles que no funcionam e o porqu. Um livro fascinante editado por Wixon e Ramsey (Field Methods Casebook for Software
Design, Wiley, 1996) sugere mtodos de pesquisa de campo (muito parecido com aqueles
usados por antroplogos) para entender como os usurios finais realizam o trabalho deles e
depois projetam software que atenda suas necessidades. Beyer e Holtzblatt (Contextual Design: A Customer-Centered Approach to Systems Designs, Academic Press, 1997) oferece uma
outra viso do projeto de software que integra o cliente/usurio em todos os aspectos do processo de projeto de software. Bain (Emergent Design, Addison-Wesley, 2008) acopla padres,
refabricao e desenvolvimento dirigido por testes em uma abordagem de projeto eficaz.
Um tratado completo de projeto no contexto da engenharia de software apresentado por Fox (Introduction to Software Engineering Design, Addison-Wesley, 2006) e Zhu (Software
Design Methodology, Butterworth-Heinemann, 2005). McConnell (Code Complete, 2. ed.,

228

PARTE DOIS MODELAGEM

Microsoft Press, 2004) traz uma excelente discusso dos aspectos prticos para projetar software de alta qualidade. Robertson (Simple Program Design, 3. ed., Boyd and Fraser Publishing,
1999) apresenta uma discusso introdutria do projeto de software que til para aqueles que
esto iniciando seus estudos do assunto. Budgen (Software Design, 2. ed., Addison-Wesley,
2004) introduz uma srie de mtodos de projeto populares, comparando e contrastando cada
um deles. Fowler e seus colegas (Refactoring: Improving the Design of Existing Code, Addison-Wesley, 1999) discutem tcnicas para a otimizao incremental de projetos de software.
Rosenberg e Stevens (Use Case Driven Object Modeling with UML, Apress, 2007) abordam o
desenvolvimento de projetos orientados a objetos usando casos de uso como base.
Uma excelente pesquisa histrica de projeto de software est contida em uma antologia editada por Freeman e Wasserman (Software Design Techniques, 4; ed., IEEE, 1983). Esse tutorial
reapresenta diversos artigos clssicos que formaram a base para as tendncias correntes em
projeto de software. Medidas da qualidade de projeto, apresentadas tanto sob as perspectivas
tcnica como de gerenciamento, so consideradas por Card e Glass (Measuring Software Design
Quality, Prentice-Hall, 1990).
Uma ampla gama de fontes de informao sobre projeto de software se encontra disposio na Internet. Uma lista atualizada de referncias na Web, relevante para o projeto
de software, pode ser encontrada no site www.mhhe.com/engcs/compsci/pressman/
professional/olc/ser.htm.

captulo

Projeto de
A rquitetura
Conceitos- Chave
arqutipos . . . . . . . . . 241
arquitetura . . . . . . . . 230
alternativas . . . . . . . 245
centralizada
em dados . . . . . . . . 235
complexidade . . . . . . 247
componentes . . . . . . 243
em camadas . . . . . . . 238
estilos . . . . . . . . . . . 234
fluxo de dados . . . . . 236
gneros . . . . . . . . . . 232
orientada a
objetos . . . . . . . . . . 230
padres . . . . . . . . . . 238
projeto . . . . . . . . . . 239
refinamento . . . . . . . 242
templates . . . . . . . . 233
ATAM . . . . . . . . . . . . 245
fabricao . . . . . . . . . 268
instncia . . . . . . . . . . 243
linguagem de descrio
de arquitetura . . . . . . 247
mapeamento . . . . . . . 248

rojeto foi descrito como um processo em vrias etapas em que as representaes de


dados e a estrutura do programa, as caractersticas de interfaces e os detalhes procedurais so sintetizados com base nos requisitos de informao. Essa descrio
estendida por Freeman [Fre80]:
[P]rojeto uma atividade que trata da tomada de decises importantes, frequentemente de natureza estrutural. Ele divide com a programao a responsabilidade em abstrair a representao de
informao e de sequncias de processamento, porm o nvel de detalhes bastante diverso nos
extremos. Um projeto constri representaes de programas coerentes e bem planejados que se
concentram nas inter-relaes das partes em um alto nvel e nas operaes lgicas envolvidas em
nveis mais baixos.

Conforme citado no Captulo 8, o projeto dirigido por informaes. Os mtodos de


projeto de software so obtidos considerando-se cada um dos trs domnios do modelo de
anlise. Os domnios de dados, funcional e comportamental servem de orientao para a
criao do projeto de software.
Neste captulo sero apresentados os mtodos necessrios para criar representaes
coerentes e bem planejadas das camadas de dados e da arquitetura do modelo de projeto.
O objetivo fornecer uma abordagem sistemtica para a obteno do projeto da arquitetura o esquema preliminar por meio do qual o software construdo.

O que ? O projeto da arquitetura

Panorama representa a estrutura de dados e os

componentes de programa necessrios


para construir um sistema computacional. Ele considera o estilo de arquitetura que o
sistema assumir, a estrutura e as propriedades
dos componentes que constituem o sistema, bem
como as inter-relaes que ocorrem entre todos os
componentes da arquitetura de um sistema.
Quem realiza? Embora um engenheiro de software
possa projetar tanto os dados quanto a arquitetura, essa tarefa frequentemente distribuda a
especialistas ao se construrem sistemas grandes
e complexos. Um projetista de bancos de dados
ou de depsito de dados cria a arquitetura de
dados para um sistema. O arquiteto de sistemas
escolhe um estilo de arquitetura apropriado com
base nos requisitos obtidos durante a anlise de
requisitos.
Por que importante? Voc no tentaria construir
uma casa sem uma planta, no mesmo? Voc
tambm no desenharia as plantas comeando
pela distribuio dos encanamentos da casa.
Deve-se partir do contexto geral a casa em

si antes de se preocupar com os detalhes.


exatamente isso o que faz o projeto da arquitetura
ele d uma viso geral e garante que voc o
entendeu de forma correta.
Quais so as etapas envolvidas? O projeto da
arquitetura comea pelo projeto de dados e ento
prossegue para a derivao de uma ou mais
representaes da estrutura da arquitetura do sistema. So analisados estilos ou padres de arquitetura alternativos para obter uma estrutura mais
adequada aos requisitos do cliente e atributos de
qualidade. Uma vez que tenha se escolhido uma
alternativa, a arquitetura elaborada usando-se
um mtodo de projeto da arquitetura.
Qual o artefato? Durante o projeto da arquitetura
criado um modelo de arquitetura que engloba a
arquitetura de dados e a estrutura de programas.
Alm disso, so descritas as propriedades e as
relaes (interaes) entre os componentes.
Como garantir que o trabalho foi realizado corretamente? A cada estgio, so revisados os produ-

tos resultantes do projeto de software em termos de


clareza, correo, completude e consistncia com
os requisitos e entre si.

229

230

PARTE 2 MODELAGEM

9.1

Arquitetura

de

S o f t wa r e

Em seu famoso livro sobre o tema, Shaw e Garlan [Sha96] discutem a arquitetura de software
da seguinte maneira:
Desde que o primeiro programa foi dividido em mdulos, os sistemas de software passaram a ter arquiteturas e os programadores passaram a ser responsveis pelas interaes entre os mdulos e as propriedades
globais do conjunto. Historicamente, as arquiteturas tm sido implcitas acidentes de implementao
ou sistemas legados do passado. Os bons desenvolvedores de software muitas vezes adotaram um ou
vrios padres de arquitetura como estratgias para organizao de sistemas, porm usam tais padres
informalmente e no possuem nenhum meio para torn-los explcitos no sistema resultante.

Hoje, arquitetura de software efetiva e sua representao explcita tornaram-se temas dominantes em engenharia de software.

9.1.1O que arquitetura?


A arquitetura
de um sistema
constitui uma
definio
abrangente que
descreve sua forma
e estrutura
seus componentes
e como eles se
integram.
Jerrold Grochow

A arquitetura de
software deve
modelar a estrutura
de um sistema, bem
como a maneira por
meio da qual dados
e componentes
procedurais colaboram
entre si.
Case-se
depressa com
sua arquitetura,
arrependa-se
quando quiser.
Barry Boehm

Ao se considerar a arquitetura de um edifcio, vrios atributos diferentes vm mente. No


nvel mais simplista, pensamos na forma geral da estrutura fsica. Mas, na realidade, arquitetura
muito mais do que isso. Ela a maneira pela qual os vrios componentes do edifcio so integrados para formar um todo coeso. o modo pelo qual o edifcio se ajusta em seu ambiente
e integra com outros edifcios da vizinhana. o grau com que o edifcio atende seu propsito
expresso e satisfaz s necessidades de seu proprietrio. o sentido esttico da estrutura o
impacto visual do edifcio e a maneira pela qual as texturas, cores e materiais so combinados para criar a fachada e o ambiente de moradia. Ela engloba tambm os detalhes o projeto dos dispositivos de iluminao, o tipo de piso, o posicionamento de painis, enfim, a lista
interminvel. E, finalmente, ela arte. Mas arquitetura tambm algo mais. constituda por
milhares de decises, tanto as grandes como as pequenas [Tyr05]. Algumas dessas decises
so tomadas logo no incio do projeto e podem ter um impacto profundo sobre todas as aes
subsequentes. Outras so postergadas ao mximo, eliminando, portanto, restries demasiadas
que levariam a uma implementao inadequada do estilo da arquitetura. Mas o que dizer da arquitetura de software? Bass, Clements e Kazman [Bas03] definem esse termo difcil de descrever
da seguinte maneira:
A arquitetura de software de um programa ou sistema computacional a estrutura ou estruturas do
sistema, que abrange os componentes de software, as propriedades externamente visveis desses componentes e as relaes entre eles.

A arquitetura no o software operacional, mas sim, uma representao que nos permite
(1) analisar a efetividade do projeto no atendimento dos requisitos declarados, (2) considerar
alternativas de arquitetura em um estgio quando realizar mudanas de projeto ainda relativamente fcil e (3) reduzir os riscos associados construo do software.
Essa definio enfatiza o papel dos componentes de software em qualquer representao de
arquitetura. No contexto de projeto da arquitetura, um componente de software pode ser algo to
simples quanto um mdulo de programa ou uma classe orientada a objetos, porm ele tambm
pode ser estendido para abranger bancos de dados e middleware que possibilita a configurao
de uma rede de clientes e servidores. As propriedades dos componentes so aquelas caractersticas necessrias para o entendimento de como eles interagem com outros componentes. No nvel
da arquitetura, propriedades internas (por exemplo, detalhes de um algoritmo) no so especificadas. As relaes entre componentes podem ser to simples quanto a chamada procedural de um
mdulo a outro ou to complexo quanto um protocolo de acesso a banco de dados.
Alguns membros da comunidade da engenharia de software (por exemplo, [Kaz03]) fazem
uma distino entre as aes associadas obteno de uma arquitetura de software (aquilo que
denomino projeto da arquitetura) e as aes aplicadas para obter o projeto de software. Conforme observado por um dos revisores desta edio:

captulo 9 PROJETO DA ARQUITETURA

231

H uma distinta diferena entre os termos arquitetura e projeto. Projeto uma instncia de uma arquitetura da mesma forma que um objeto instncia de uma classe. Consideremos, por exemplo, a
arquitetura cliente/servidor. Podemos projetar um sistema de software centralizado em redes de vrias
formas diferentes por meio dessa arquitetura usando a plataforma Java (Java EE) ou a plataforma
Microsoft (.NET framework). Existe uma arquitetura, porm podem ser criados vrios projetos baseados
nessa arquitetura. Consequentemente, no podemos confundir arquitetura com projeto.
WebRef
Links teis para diversos
sites sobre arquitetura
de software podem
ser encontrados em
www2.umassd.
edu/SECenter/
SAResources.html.

A arquitetura
extremamente
importante para ser
deixada a cargo de
uma nica pessoa,
independentemente
de quo brilhante
ela possa ser.
Scott Ambler

O modelo de
arquitetura fornece
uma viso gestltica
do sistema,
permitindo ao
engenheiro de
software examin-lo
como um todo.

AVISO
Seu esforo
deve focalizar as
representaes de
arquitetura que iro
orientar todos os
demais aspectos do
projeto. Invista o
tempo necessrio para
rever cuidadosamente
a arquitetura. Um erro
nessa fase ter um
impacto negativo no
longo prazo.

Embora concorde que um projeto de software seja uma instncia de uma arquitetura de software especfica, os elementos e estruturas definidos como parte de uma arquitetura so a raiz
de qualquer projeto que evolui a partir deles. Um projeto se inicia com uma considerao de
arquitetura.
Neste livro o projeto de arquitetura de software considera dois nveis da pirmide de projeto
(Figura 8.1) projeto de dados e projeto da arquitetura. No contexto da discusso anterior, o
projeto de dados permite que representemos o componente de dados da arquitetura em sistemas convencionais e as definies de classes (englobando atributos e operaes), em sistemas
orientados a objetos. O projeto da arquitetura concentra-se na representao da estrutura dos
componentes de software, suas propriedades e interaes.

9.1.2Por que a arquitetura importante?


Em um livro dedicado arquitetura de software, Bass e seus colegas [Bas03] identificaram
trs razes-chave da importncia da arquitetura de software:
As representaes da arquitetura de software so um facilitador para a comunicao entre todas as partes interessadas no desenvolvimento de um sistema computacional.
A arquitetura evidencia decises de projeto iniciais que tero profundo impacto em todo
o trabalho de engenharia de software que vem a seguir e, to importante quanto, no sucesso final do sistema como uma entidade operacional.
A arquitetura constitui um modelo relativamente pequeno e intelectualmente compreensvel de como o sistema estruturado e como seus componentes trabalham em conjunto [Bas03].
O modelo de projeto da arquitetura e os padres de arquitetura nele contidos so transferveis.
Gneros, estilos e padres de arquitetura (Sees 9.2 a 9.4) podem ser aplicados ao projeto de
outros sistemas e representam um conjunto de abstraes que permitem aos engenheiros de
software descrever arquitetura de modo previsvel.

9.1.3Descries de arquitetura
Cada um de ns possui uma imagem mental daquilo que a palavra arquitetura significa.
Entretanto, na realidade, seu significado diverso para diferentes pessoas. A implicao que
os diferentes interessados vero uma arquitetura sob diversos pontos de vista orientados por
conjuntos de interesses distintos. Isso implica que uma descrio de arquitetura , na verdade,
um conjunto de artefatos que refletem diferentes vises do sistema.
Por exemplo, o arquiteto de um importante conjunto comercial tem de trabalhar com uma
srie de interessados diferentes. O principal interesse do proprietrio do conjunto comercial
(um dos interessados) garantir que ele seja esteticamente agradvel e que fornea espao e
infraestrutura suficientes para garantir sua lucratividade. Consequentemente, o arquiteto tem
de criar uma descrio usando vises de edifcio que atendam os interesses do proprietrio. Os
pontos de vista usados so desenhos tridimensionais do edifcio (para ilustrar a viso esttica)
e um conjunto de plantas bidimensionais para atender necessidade do interessado em termos
de espao e infraestrutura do conjunto comercial.
Porm, o conjunto comercial tem muitos outros interessados, at mesmo o fabricante
de ao de construo especial que fornecer ao para a estrutura do prdio. Esse fabricante
precisa de informaes de arquitetura detalhadas sobre o ao de construo que ir su-

232

PARTE 2 MODELAGEM

portar o edifcio, incluindo tipos de vigas duplo T, suas dimenses, conectividade, materiais e
muitos outros detalhes. Tais interesses so atendidos por diferentes artefatos que representam
diferentes vises da arquitetura. Desenhos especializados (um outro ponto de vista) da estrutura
de ao de construo do edifcio focalizam apenas uma das vrias preocupaes do fabricante.
A descrio de arquitetura de um sistema baseado em software deve apresentar caractersticas anlogas quelas citadas para o conjunto comercial. Tyree e Akerman [Tyr05] citam isso ao
escreverem: Os desenvolvedores desejam orientao clara e determinada sobre como prosseguir com um projeto. Os clientes querem um entendimento claro sobre as mudanas que devem
ocorrer no ambiente e garantias de que a arquitetura atender suas necessidades de negcio.
Outros arquitetos buscam um entendimento claro dos aspectos mais importantes da arquitetura. Cada um desses desejos se reflete em uma viso diferente representada sob um ponto de
vista diferente.
A IEEE Computer Society props o IEEE-Std-1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems, [IEE00], com os seguintes objetivos: (1) estabelecer uma definio conceitual e um vocabulrio para uso durante o projeto da arquitetura
de software, (2) fornecer diretrizes detalhadas para representar uma descrio de arquitetura e
(3) encorajar prticas de projeto de arquitetura consistentes.
O padro IEEE define uma descrio da arquitetura (architectural description, AD) como um
conjunto de produtos para documentar uma arquitetura. Uma descrio por si s representada usando-se vrias vises; cada viso a representao de um sistema como um todo segundo a perspectiva de um conjunto de necessidades [dos interessados] relacionado. A viso
criada de acordo com regras e convenes definidas em um ponto de vista uma especificao das convenes para a construo e uso de uma viso [IEE00]. Uma srie de artefatos
diferentes utilizados para desenvolver diferentes vises da arquitetura de software discutida
posteriormente, ainda neste captulo.

9.1.4Decises de arquitetura
Cada viso desenvolvida como parte da descrio arquitetural trata uma necessidade especfica do interessado. Para desenvolver cada viso (e a descrio arquitetural como um todo), o
arquiteto de sistemas considera uma variedade de alternativas e, por fim, decide sobre as caractersticas de uma arquitetura especfica que melhor atendam necessidade. Consequentemente,
as prprias decises de arquitetura podem ser consideradas uma viso de arquitetura. As razes
pelas quais as decises foram tomadas fornecem uma viso sobre a estrutura de um sistema e
sua adequao s necessidades dos interessados.
Como arquiteto de sistemas, podemos usar o template sugerido no quadro para documentar cada deciso importante. Desse modo, fornecemos os fundamentos para nosso trabalho e
estabelecemos um registro histrico que pode ser til quando mudanas de projeto tiverem de
ser feitas.

9 .2

H uma srie de
estilos de arquitetura
diferentes que
poderiam ser
aplicados a um gnero
especfico (tambm
denominado domnio
de aplicao).

Gneros

de

Arquitetura

Embora os princpios fundamentais do projeto da arquitetura se apliquem a todos os tipos


de arquitetura, o gnero normalmente ditar a abordagem de arquitetura especfica para a estrutura que deve ser construda. No contexto de projeto da arquitetura, gnero implica uma categoria especfica no domnio de software geral. Em cada categoria, pode-se encontrar uma srie
de subcategorias. Por exemplo, dentro do gnero edifcios, poderamos encontrar os seguintes
estilos gerais: casas, condomnios, prdios de apartamentos, conjuntos comerciais, prdios industriais, armazns e assim por diante. Em cada estilo geral, poderiam ser aplicados estilos
mais especficos (Seo 9.3). Cada estilo teria uma estrutura que pode ser descrita usando-se
um conjunto de padres previsveis.

captulo 9

233

ProJeto Da arqUItetUra

Template de descrio de decises de arquitetura


Cada importante deciso de arquitetura pode ser documentada para posterior reviso pelos interessados
que querem entender a descrio da arquitetura proposta. O template apresentado neste quadro uma verso resumida e adaptada de um gabarito proposto por Tyree e Ackerman
[Tyr05].
Problema de projeto:

Descreva os problemas de projeto da


arquitetura que devem ser tratados.

Resoluo:

Informe a abordagem escolhida


para tratar o problema de projeto.

Categoria:

Especifique a categoria de projeto


que o problema e a resoluo tratam
(por exemplo, projeto de dados, estrutura de contedo, estrutura de componentes, integrao, apresentao).

Hipteses:

Indique quaisquer hipteses que


ajudem a dar forma deciso.

Restries:

Especifique quaisquer restries


do ambiente que auxiliaram a dar
forma deciso (por exemplo, padres de tecnologia, padres disponveis, questes relacionadas ao
projeto).

INfORMAES

Alternativas:

Descreva brevemente as alternativas


de projeto de arquitetura consideradas e por que foram rejeitadas.

Argumento:

Afirme por que escolheu a deciso


em relao a outras alternativas.

Implicaes:

Indique as consequncias de projeto ao tomar a deciso. Como a


resoluo afeta outras questes do
projeto da arquitetura? A resoluo
ir restringir o projeto de alguma
forma?

Decises relacionadas: Que outras decises documentadas


esto relacionadas com essa deciso?
Necessidades
relacionadas:

Que outros requisitos esto relacionados com essa deciso?

Artefatos:

Indique onde essa deciso ir se


reetir na descrio da arquitetura.

Notas:

Faa referncia a quaisquer observaes feitas pela equipe ou outra


documentao utilizada para tomar
a deciso.

Em seu manual em constante evoluo, Handbook of Software Architecture [Boo08], Grady


Booch sugere os seguintes gneros de arquitetura para sistemas baseados em software:

Programar sem
uma arquitetura
ou projeto geral
em mente como
explorar uma
caverna portando
apenas uma
lanterna: no
sabemos onde
estivemos, no
sabemos aonde
estamos indo
e mal sabemos
onde estamos no
momento.
Danny Thorpe

Inteligncia artificial Sistemas que simulam ou ampliam a cognio, locomoo ou


outros processos orgnicos humanos.
Comercial e sem fins lucrativos Sistemas que so fundamentais para a operao
de um empreendimento comercial.
Comunicaes Sistemas que fornecem a infraestrutura para a transferncia e o gerenciamento de dados, para conectar usurios desses dados ou para apresentar dados na
periferia de uma infraestrutura.
Autoria de contedo Sistemas que so utilizados para criar ou manipular artefatos
de texto ou multimdia.
Dispositivos Sistemas que interagem com o mundo fsico para fornecer algum servio para um indivduo.
Esportes e entretenimento Sistemas que gerenciam eventos pblicos ou que geram uma experincia de entretenimento a um grande grupo.
Financeiros Sistemas que fornecem a infraestrutura para transferir e administrar
dinheiro e outros valores.
Jogos Sistemas que geram uma experincia de entretenimento para indivduos ou grupos.
Governo Sistemas que do apoio conduta e operaes de uma entidade municipal,
estadual, federal, internacional ou outras entidades polticas.
Industriais Sistemas que simulam ou controlam processos fsicos.
Legais Sistemas que do apoio ao setor judicirio.
Mdicos Sistemas que diagnosticam ou curam ou contribuem para a pesquisa mdica.
Militar Sistemas para consultas, comunicaes, comando, controle e inteligncia
(C4I), bem como armamento de ataque e defesa.

234

PARTE 2 MODELAGEM

Sistemas operacionais Sistemas que se situam logo acima do hardware para fornecer servios bsicos de software.
Plataformas Sistemas que se posicionam logo acima dos sistemas operacionais para
fornecer servios avanados.
Cientficos Sistemas que so utilizados para pesquisa e aplicaes cientficas.
Ferramentas Sistemas que so utilizados para desenvolver outros sistemas.
Transportes Sistemas que controlam veculos de navegao, terrestres, areos ou
espaciais.
Servios pblicos Sistemas que interagem com outros softwares para fornecer algum servio.
Sob o ponto de vista do projeto da arquitetura, cada gnero representa um desafio nico.
Consideremos, por exemplo, a arquitetura de software para um sistema de jogos eletrnicos.
Os sistemas de jogos, algumas vezes chamados aplicaes interativas de imerso, requerem o
clculo de algoritmos intensivos, computao grfica sofisticada, fontes de dados multimdia
streaming, interatividade em tempo real via entradas convencionais e no convencionais e uma
srie de outras necessidades especializadas.
Alexandre Francois [Fra03] sugere uma arquitetura de software para Immersipresence1 que pode
ser aplicada a um ambiente de jogos eletrnicos. Ele descreve a arquitetura da seguinte maneira:
SAI (Software Architecture for Immersipresence) um novo modelo de arquitetura de software para projetar, analisar e implementar aplicaes realizando processamento paralelo assncrono distribudo de
fluxos de dados genricos. O objetivo do SAI fornecer uma estrutura universal para a implementao
distribuda de algoritmos e sua fcil integrao em sistemas complexos... O modelo de dados subjacente e extensvel, bem como o modelo de processamento paralelo assncrono distribudo (repositrio
compartilhado e passagem de mensagens) hbrido, possibilita a manipulao natural e eficiente de
fluxos de dados genricos, usando-se bibliotecas ou cdigo nativo indiferentemente. A modularidade
do estilo facilita o desenvolvimento, testes e reutilizao de cdigo distribudo, bem como o rpido
desenvolvimento, integrao, manuteno e evoluo do sistema.

Uma discusso detalhada do SAI est fora do escopo deste livro. Entretanto, importante reconhecer que o gnero de sistemas para jogos pode ser tratado com um estilo de arquitetura
(Seo 9.3) especificamente desenhado para lidar com as questes de sistemas para jogos eletrnicos. Caso tenha maior interesse, veja [Fra03].

9.3
Por trs da
mente de qualquer
artista existe um
padro ou tipo de
arquitetura.
G. K. Chesterton

que
? Oestilo
de

arquitetura?

Estilos

de

Arquitetura

Quando um construtor usa a frase colonial americano com hall central para descrever uma
casa, a maioria das pessoas familiarizadas com casas nos Estados Unidos ser capaz de evocar
uma imagem geral de como se parecer a casa e como provavelmente ser a sua planta. O construtor usou um estilo arquitetnico como um mecanismo descritivo para diferenciar a casa de
outros estilos (por exemplo, casa pr-fabricada sobre uma estrutura de madeira em forma de A,
rancho montado sobre uma base elevada, Cape Cod). Porm, mais importante ainda, o estilo arquitetnico tambm um template para construo. Devem ser definidos mais detalhes da casa,
suas dimenses finais especificadas, caractersticas personalizadas poderiam ser acrescentadas,
tambm devem ser determinados os materiais de construo, o estilo uma casa colonial
americano com hall central orienta o construtor em seu trabalho.
O software que criado para sistemas computacionais tambm apresenta um de muitos
estilos de arquitetura. Cada estilo descreve uma categoria de sistema que engloba (1) um conjunto de componentes (por exemplo, um banco de dados, mdulos computacionais) que realiza
uma funo exigida por um sistema; (2) um conjunto de conectores que habilitam a comunicao, coordenao e cooperao entre os componentes; (3) restries que definem como os
1

Francois utiliza o termo immersipresence para aplicaes interativas e de imerso.

captulo 9

235

ProJeto Da arqUItetUra

componentes podem ser integrados para formar o sistema; e (4) modelos semnticos que permitem a um projetista compreender as propriedades gerais de um sistema por meio da anlise
das propriedades conhecidas de suas partes constituintes [Bas03].
Um estilo arquitetural uma transformao imposta no projeto do sistema inteiro. O objetivo estabelecer uma estrutura para todos os componentes do sistema. No caso em que uma
arquitetura existente deve sofrer um processo de reengenharia (Captulo 29), a imposio de um
estilo de arquitetura resultar em mudanas fundamentais na estrutura do software, incluindo
uma nova atribuio da funcionalidade dos componentes [Bos00].
Um padro de arquitetura, assim como um estilo arquitetural, impe transformao no projeto
de arquitetura. Entretanto, padro difere de estilo em alguns modos fundamentais: (1) o escopo de
um padro menos abrangente, concentrando-se em um aspecto da arquitetura e no na arquitetura em sua totalidade; (2) um padro impe uma regra sobre a arquitetura, descrevendo como o
software ir tratar algum aspecto de sua funcionalidade em termos de infraestrutura (por exemplo,
concorrncia) [Bos00]; (3) os padres de arquitetura (Seo 9.4) tendem a tratar questes comportamentais especficas no contexto da arquitetura (por exemplo, como as aplicaes em tempo
real tratam a sincronizao ou as interrupes). Os padres podem ser usados com um estilo de
arquitetura para dar forma estrutura global de um sistema. Na Seo 9.3.1, consideraremos os
padres e estilos de arquitetura e padres mais comumente utilizados em software.

WebRef
Estilos de arquitetura
baseados em atributos
(sigla ABAS) podem
ser utilizados como
blocos bsicos para
as arquiteturas de
software. Informaes
sobre isso podem ser
obtidas em www .

sei .cmu .edu/


architecture/
abas .html .

INfORMAES

Estruturas de arquitetura cannicas


Em essncia, a arquitetura de software representa
uma estrutura em que algum conjunto de entidades
(normalmente denominadas componentes) interligado por um conjunto de relacionamentos definidos (normalmente denominados conectores). Tanto os componentes quanto
os conectores esto associados a um conjunto de propriedades
que permitem ao projetista diferenciar os tipos de componentes
e conectores que podem ser usados. Mas que tipos de estruturas
(componentes, conectores e propriedades) podem ser usados
para descrever uma arquitetura? Bass e Kazman [Bas03] sugerem cinco estruturas de arquitetura fundamentais ou cannicas:
Estrutura funcional. Os componentes representam entidades
funcionais ou de processamento. Os conectores representam
interfaces que fornecem a capacidade de usar ou passar
dados para um componente. As propriedades descrevem a
natureza dos componentes e a organizao das interfaces.
Estrutura de implementao. Os componentes podem
ser pacotes, classes, objetos, procedimentos, funes, mtodos
etc., todos os quais so veculos para empacotar funcionalidade em vrios nveis de abstrao [Bas03]. Os conectores incluem a habilidade de passar dados e controle, compartilhar
dados, uso e instncia-de. As propriedades concentram-se
nas caractersticas de qualidade (por exemplo, facilidade de

9.3.1
O uso de padres
e estilos de projeto
universal nas
disciplinas de
engenharia.
Mary Shaw e
David Garlan

manuteno, reusabilidade) resultantes quando implementada


uma estrutura.
Estrutura de concorrncia. Os componentes representam
unidades de concorrncia organizadas como tarefas paralelas ou threads. As relaes [conectores] incluem sincronizaes-com, -de maior prioridade-que, envia-dados-a, no
possvel-executar-sem e no possvel-executar-com. Entre as
propriedades relevantes a essa estrutura temos prioridade, preempo e tempo de execuo [Bas03].
Estrutura fsica. Essa estrutura similar ao modelo de implantao desenvolvido como parte do projeto. Os componentes
so o hardware fsico onde reside o software. Os conectores
so as interfaces entre os componentes de hardware e as propriedades tratam a capacidade, largura de banda, desempenho e outros atributos.
Estrutura de desenvolvimento. Essa estrutura define os
componentes, artefatos e outras fontes de informao necessrias medida que a engenharia de software prossegue. Os conectores representam os relacionamentos entre os artefatos, e as
propriedades identificam as caractersticas de cada item. Cada
uma dessas estruturas apresenta viso diferente da arquitetura
de software, expondo informaes teis para a equipe de software medida que a modelagem e a construo prosseguem.

uma breve taxonomia dos estilos de arquitetura

Embora milhes de sistemas computacionais tenham sido criados ao longo dos ltimos 60
anos, a vasta maioria pode ser classificada em um nmero relativamente pequeno de estilos de
arquitetura:
Arquiteturas centralizadas em dados. Um repositrio de dados (por exemplo, um arquivo
ou banco de dados) reside no centro dessa arquitetura e em geral acessado por outros componentes que atualizam, acrescentam, eliminam ou de alguma outra maneira modificam dados
contidos no repositrio. A Figura 9.1 ilustra um estilo centralizado em dados tpico. O software-

236

PARTE 2 MODELAGEM

Figura 9.1
Arquitetura
centralizada em
dados

Software
cliente

Software
cliente

Software
cliente

Depsito de dados
(repositrio ou
quadro-negro)

Software
cliente

Software
cliente

Software
cliente

Software
cliente

Software
cliente

cliente acessa um repositrio central. Em alguns casos o repositrio de dados passivo. Ou


seja, o software-cliente acessa os dados independentemente de quaisquer alteraes nos dados
ou das aes de outros softwares-clientes. Uma variao dessa abordagem transforma o repositrio em um quadro-negro que envia notificaes ao software-cliente quando os dados de
seu interesse mudam.
As arquiteturas centralizadas em dados promovem a integrabilidade [Bas03]. Isto , componentes existentes podem ser alterados e novos componentes-clientes acrescentados arquitetura
sem se preocupar com outros clientes (pois os componentes-clientes operam independentemente). Alm disso, dados podem ser passados entre os clientes usando o mecanismo de quadro-negro (o componente quadro-negro serve para coordenar a transferncia de informaes entre
os clientes). Os componentes-clientes executam processos de maneira independente.
Arquiteturas de fluxo de dados. Essa arquitetura se aplica quando dados de entrada devem
ser transformados por meio de uma srie de componentes computacionais ou de manipulao
em dados de sada. Um padro tubos-e-filtro (Figura 9.2) tem um conjunto de componentes,
denominado filtros, conectados por tubos que transmitem dados de um componente para o
seguinte. Cada filtro trabalha independentemente dos componentes que se encontram acima
e abaixo deles, projetado para esperar a entrada de dados de determinada forma e produzir
sada de dados (para o filtro seguinte) da forma especificada. Entretanto, o filtro no precisa
conhecer o funcionamento interno de seus filtros vizinhos.
Se o fluxo de dados ocorrer em uma nica linha de transformaes, denominado sequencial por lotes. Essa estrutura aceita um lote de dados e aplica uma srie de componentes sequenciais (filtros) para transform-lo.
Arquiteturas de chamadas e retornos. Esse estilo de arquitetura permite-nos obter uma
estrutura de programa relativamente fcil de modificar e aumentar. Existe uma srie de subestilos [Bas03] dentro desta categoria:
Arquiteturas de programa principal/subprograma. Essa clssica estrutura de programas
decompe a funo em uma hierarquia de controle na qual um programa principal invoca uma srie de componentes de programa que, por sua vez, podem invocar outros. A
Figura 9.3 ilustra uma arquitetura desse tipo.
Arquiteturas de chamadas a procedimentos remotos. Os componentes de uma arquitetura
de programas principal /subprogramas so distribudos ao longo de vrios computadores
em uma rede.

237

captulo 9 PROJETO DA ARQUITETURA

Figura 9.2
Tubos

Arquitetura de
fluxo de dados
Filtro

Filtro

Filtro

Filtro

Filtro

Filtro

Filtro

Filtro

Filtro

Filtro
Tubos e filtros

Figura 9.3
Arquitetura
programa
principal/
subprograma

Programa
principal

Subprograma
controlador

Subprograma
de aplicao

Subprograma
controlador

Subprograma
de aplicao

Subprograma
de aplicao

Subprograma
de aplicao

Subprograma
controlador

Subprograma
de aplicao

Subprograma
de aplicao

Subprograma
de aplicao

Arquiteturas orientadas a objetos. Os componentes de um sistema encapsulam dados e


as operaes que devem ser aplicadas para manipular os dados. A comunicao e a coordenao entre componentes so realizadas atravs da passagem de mensagens.
Arquiteturas em camadas A estrutura bsica de uma arquitetura em camadas ilustrada
na Figura 9.4. So definidas vrias camadas diferentes, cada uma realizando operaes que
progressivamente se tornam mais prximas do conjunto de instrues de mquina. Na camada
mais externa, os componentes atendem operaes de interface do usurio. Na camada mais
interna, os componentes realizam a interface com o sistema operacional. As camadas intermedirias fornecem servios utilitrios e funes de software de aplicao.
Esses estilos de arquitetura so apenas um pequeno subconjunto dos disponveis.2 Assim que
a engenharia de requisitos revelar as caractersticas e restries do sistema a ser construdo, o
estilo e/ou combinao de padres de arquitetura que melhor se encaixa nessas caractersticas
e restries pode ser escolhido. Em muitos casos, mais de um padro poderia ser apropriado, e
estilos de arquitetura alternativos podem ser projetados e avaliados. Por exemplo, um estilo em
camadas (apropriado para a maioria dos sistemas) pode ser combinado com uma arquitetura
centralizada em dados em diversas aplicaes de bancos de dados.
2

Veja [Bus07], [Gor06], [Roz05], [Bas03], [Bos00] ou [Hof00] para uma discusso detalhada sobre padres e estilos de arquitetura.

238

PARTE 2 MODELAGEM

Figura 9.4

Componentes

Arquitetura em
camadas

Camada da interface do usurio

Camada de aplicao

Camada de utilitrios

Camada central

Talvez ele esteja


no poro. Vou subir
e verificar.
M. C. Escher

9.3.2Padres de arquitetura
medida que o modelo de requisitos desenvolvido, poderemos perceber que o software
deve tratar uma srie de problemas mais amplos que envolvem toda a aplicao. Por exemplo,
o modelo de requisitos para praticamente qualquer aplicao de comrcio eletrnico depara
com o seguinte problema: Como oferecer uma ampla gama de produtos para uma ampla gama
de clientes e permitir que esses clientes comprem nossos artigos on-line?
3

C asa S egura
Escolhendo um estilo de arquitetura
Cena: Sala do Jamie, medida que a modelagem de projeto comea.
Atores: Jamie e Ed membros da equipe de engenharia de
software do CasaSegura.
Conversa:
Ed (franzindo a testa): Modelamos a funo de segurana
usando UML... Voc sabe, classes, relaes, esse tipo de coisas.
Portanto, imagino que a arquitetura3 orientada a objetos seja o
caminho a seguirmos.

Ed: Isso mesmo... O que eu quis dizer que no consigo visualizar


uma estrutura real, apenas classes de projeto flutuando no ar.
Jamie: Bem, isso no verdade. Existem hierarquias de classes... Imagine a hierarquia (agregao) que fizemos para o objeto Planta [Figura 8.3]. Uma arquitetura orientada a objetos
uma combinao daquela estrutura e as interconexes sabe,
colaboraes entre as classes. Podemos mostr-la descrevendo completamente os atributos e operaes, a troca de mensagens que ocorre e a estrutura das classes.

Jamie: Mas...?

Ed: Vou gastar uma hora mapeando uma arquitetura de chamadas e retornos; ento voltarei e considerarei uma arquitetura
orientada a objetos.

Ed: Mas... Tenho dificuldade em visualizar o que uma arquitetura


orientada a objetos. Entendo a arquitetura de chamadas e retornos,
uma espcie de hierarquia de processos convencional, mas orientada a objetos... Eu no sei, ela parece um tanto amorfa.

Jamie: Doug no ter nenhum problema com isso. Ele me disse


que deveramos considerar alternativas de arquitetura. Por sinal,
no h absolutamente nenhuma razo para que essas duas arquiteturas no possam ser usadas de forma combinada.

Jamie (sorrindo): Amorfa, uh?

Ed: Bom. Eu concordo.

Pode ser argumentado que a arquitetura do CasaSegura deveria ser considerada em um nvel mais elevado do que a arquitetura citada. O CasaSegura possui uma srie de subsistemas funcionalidade de monitoramento da casa, o site de monitoramento da empresa e o subsistema que roda no PC do proprietrio do imvel. Nos subsistemas, processos concorrentes (por
exemplo, aqueles para monitorar sensores) e tratamento de eventos so frequentes. Algumas decises em relao arquitetura nesse nvel so tomadas durante a engenharia de produto, porm o projeto da arquitetura na engenharia de software deve
considerar muito bem essas questes.

captulo 9 PROJETO DA ARQUITETURA

239

O modelo de requisitos tambm define um contexto no qual essa questo deve ser respondida.
Por exemplo, uma aplicao de comrcio eletrnico que vende equipamento de golfe para clientes
ir operar em um contexto diferente daquele de uma aplicao de comrcio eletrnico que vende
equipamentos industriais de preo elevado para empresas de mdio e grande porte. Alm disso, um
conjunto de limitaes e restries poderia afetar a forma que tratamos o problema a ser resolvido.
Os padres de arquitetura tratam um problema especfico de aplicao em um contexto especfico e sob um conjunto de limitaes e restries. O padro prope uma soluo de arquitetura capaz de servir como base para o projeto da arquitetura.
Citamos anteriormente, neste captulo, que a maioria das aplicaes enquadra-se em um
domnio ou gnero especfico e que um ou mais estilos de arquitetura poderiam ser apropriados
para aquele gnero. Por exemplo, o estilo de arquitetura geral para uma aplicao poderia ser de
chamadas e retornos ou orientado a objetos. Porm, nesse estilo, encontraremos um conjunto
de problemas comuns que poderiam ser mais bem tratados com padres de arquitetura especficos. Alguns desses problemas e uma discusso mais completa de padres de arquitetura so
apresentados no Captulo 12.

9.3.3Organizao e refinamento
Pelo fato de o processo de projeto muitas vezes nos dar uma srie de alternativas de arquitetura, importante estabelecer um conjunto de critrios de projeto que podem ser usados para
avaliar o projeto da arquitetura obtido. As seguintes questes [Bas03] do uma viso mais clara
sobre um estilo de arquitetura:
avaliar
? Como
um estilo

de arquitetura
obtido?

Controle. Como o controle gerenciado na arquitetura? Existe uma hierarquia de controle


distinta e, em caso positivo, qual o papel dos componentes nessa hierarquia de controle?
Como os componentes transferem controle no sistema? Como o controle compartilhado
entre os componentes? Qual a topologia de controle (ou seja, a forma geomtrica que o controle assume)? O controle sincronizado ou os componentes operam de maneira assncrona?
Dados. Como os dados so transmitidos entre os componentes? O fluxo de dados contnuo ou os objetos de dados so passados esporadicamente para o sistema? Qual o modo de
transferncia de dados (ou seja, os dados so passados de um componente para outro ou
os dados esto disponveis globalmente para ser compartilhados entre os componentes de
sistema)? Os componentes de dados (por exemplo, um quadro-negro ou repositrio) existem
e, em caso positivo, qual o seu papel? Como os componentes funcionais interagem com os
componentes de dados? Os componentes de dados so passivos ou ativos (isto , o componente de dados interage ativamente com outros componentes do sistema)? Como os dados
e controle interagem no sistema?
Essas questes do ao projetista uma avaliao prvia da qualidade do projeto e formam a base
para anlise mais detalhada da arquitetura.

9.4
Um mdico pode
enterrar seus erros,
mas um arquiteto
pode apenas
aconselhar seu
cliente a plantar
videiras.
Frank Lloyd
Wright

Projeto

da

Arquitetura

Quando o projeto da arquitetura se inicia, o software a ser desenvolvido deve ser colocado
no contexto o projeto deveria definir as entidades externas (outros sistemas, dispositivos,
pessoas) com as quais o software interage e a natureza da interao. Essas informaes em geral podem ser obtidas do modelo de requisitos e todas as demais coletadas durante a engenharia de requisitos. Uma vez que o contexto modelado e todas as interfaces de software externas
tenham sido descritas, podemos identificar um conjunto de arqutipos arquiteturais. Arqutipo
uma abstrao (similar a uma classe) que representa um elemento do comportamento do
sistema. O conjunto de arqutipos fornece uma coleo de abstraes que deve ser modelada
arquiteturalmente caso o sistema tenha de ser construdo, porm os arqutipos em si no fornecem detalhes de implementao suficientes. Consequentemente, o projetista especifica uma

240

PARTE 2 MODELAGEM

estrutura do sistema por meio da definio e refinamento de componentes de software que


implementam cada arqutipo. Esse processo continua iterativamente at que uma estrutura de
arquitetura completa tenha sido obtida. Nas sees seguintes examinaremos cada uma dessas
tarefas de projeto da arquitetura com um pouco mais de detalhes.

9.4.1 Representao do sistema no contexto

O contexto de
arquitetura representa
como o software
interage com
entidades externas a
seus limites.
os
? Como
sistemas

operam entre si?

No nvel de projeto da arquitetura, um arquiteto de software usa um diagrama de contexto


arquitetural (architectural context diagram, ACD) para modelar a maneira pela qual o software
interage com entidades externas a seus limites. A estrutura genrica do diagrama de contexto
arquitetural ilustrada na Figura 9.5.
Referindo-se figura, os sistemas que interoperam com o sistema-alvo (o sistema para o
qual um projeto da arquitetura deve ser desenvolvido) so representados como
Sistemas superiores aqueles sistemas que usam o sistema-alvo como parte de algum
esquema de processamento de mais alto nvel.
Sistemas subordinados aqueles sistemas que so utilizados pelo sistema-alvo e
fornecem dados ou processamento necessrios para completar a funcionalidade do
sistema-alvo.
Sistemas de mesmo nvel (pares) aqueles sistemas que interagem em uma base para-par (ou seja, as informaes so produzidas ou consumidas pelos pares e sistema-alvo.
Atores entidades (pessoas, dispositivos) que interagem com o sistema-alvo atravs da
produo ou consumo de informaes necessrias para o processamento.
Cada uma dessas entidades externas se comunica com o sistema-alvo por meio de uma interface (os pequenos retngulos sombreados). Para ilustrarmos o uso do ACD, consideremos
a funo de segurana residencial do produto CasaSegura. O controlador geral do produto
CasaSegura e o sistema baseado na Internet so ambos superiores em relao funo de
segurana e so mostrados acima da funo na Figura 9.6. A funo de vigilncia um sistema de mesmo nvel e utiliza ( utilizado por) a funo de segurana residencial em verses
posteriores do produto. O proprietrio do imvel e os painis de controle so os atores que
agem tanto como produtores quanto consumidores de informaes usadas/produzidas pelo
software de segurana. Por fim, so utilizados sensores pelo software de segurana e mostrados como subordinados a ele.

Figura 9.5

Sistemas superiores

Diagrama de
contexto
arquitetural
Fonte: Adaptado
de [Bos00]

Usado por

Sistema-alvo
Usa
Usa
Atores
Depende de

Sistemas subordinados

Pares

241

captulo 9 PROJETO DA ARQUITETURA

Figura 9.6
Produto
CasaSegura

Diagrama de
contexto arquitetural
para a funo de
segurana do
CasaSegura

Painel de
controle
Proprietrio
do imvel

Sistema baseado
na Internet

Sistema-alvo:
funo de segurana

Usa

Funo de
vigilncia
Pares

Usa
Usa
Sensores

Sensores

Como parte do projeto da arquitetura, os detalhes de cada interface da Figura 9.6 teriam de
ser especificados. Todos os dados que fluem para dentro e para fora do sistema-alvo tm de ser
identificados neste estgio.

9.4.2Definio de arqutipos

Arqutipos so
os blocos bsicos
abstratos de um
projeto da arquitetura.

Arqutipo uma classe ou padro que representa uma abstrao central crtica para o projeto de uma arquitetura para o sistema-alvo. Em geral, necessrio um conjunto relativamente
pequeno de arqutipos para projetar at mesmo sistemas relativamente complexos. A arquitetura do sistema-alvo composta desses arqutipos, que representam elementos estveis da
arquitetura, porm podem ser instanciados de vrias maneiras tomando como base o comportamento do sistema.
Em muitos casos, os arqutipos podem ser derivados examinando-se as classes de anlise
definidas como parte do modelo de requisitos. Prosseguindo com a discusso da funo de segurana domiciliar do CasaSegura, poderamos definir os seguintes arqutipos:
N. Representa um conjunto coeso de elementos de entrada e sada da funo de segurana domiciliar. Por exemplo, um n poderia ser composto por (1) vrios sensores e (2)
uma srie de indicadores (de sada) de alarme.
Detector. Abstrao que engloba todos os equipamentos de sensoriamento que alimentam o sistema-alvo com informaes.
Indicador. Abstrao que representa todos os mecanismos (por exemplo, sirene de
alarme, luzes intermitentes, campainha) para indicar a ocorrncia de condio de
alarme.
Controlador. Abstrao que representa o mecanismo que permite armar ou desarmar
um n. Se os controladores residirem em uma rede, eles tm a habilidade de se comunicarem entre si.
Cada um dos arqutipos representado usando-se a notao UML conforme indicado na
Figura 9.7. Recorde-se que os arqutipos formam a base para a arquitetura, mas so as abstraes que devem ser refinadas medida que o projeto da arquitetura prossegue. Por exemplo,
Detector poderia ser refinado em uma hierarquia de classes de sensores.

242

PARTE 2 MODELAGEM

Figura 9.7
Controlador

Relacionamentos
UML para os
arqutipos
da funo de
segurana do
CasaSegura

Comunica-se com

Fonte: Adaptado
de [Bos00]

Detector

Indicador

9.4.3 Refinamento da arquitetura em componentes

A estrutura de
um sistema de
software fornece
o meio no qual
o cdigo nasce,
amadurece e
morre. Um hbitat
bem projetado
possibilita a
evoluo bemsucedida de todos
os componentes
necessrios em
um sistema de
software.
R. Pattis

medida que a arquitetura de software refinada em componentes, a estrutura do sistema comea a emergir. Mas como os componentes so escolhidos? Para podermos responder
a essa pergunta, comeamos pelas classes descritas como parte do modelo de requisitos.4 As
classes de anlise representam entidades no domnio de aplicao que deve ser tratado na
arquitetura de software. Portanto, o domnio de aplicao uma fonte para a derivao e o
refinamento de componentes. Outra fonte o domnio da infraestrutura. A arquitetura deve
acomodar muitos componentes de infraestrutura que possibilitem componentes de aplicao,
mas que no tenham nenhuma ligao de atividade com o domnio de aplicao. Por exemplo,
componentes de gerenciamento de memria, componentes de comunicao, componentes
de bancos de dados e componentes de gerenciamento de tarefas em geral so integrados
arquitetura do software.
As interfaces representadas no diagrama de contexto arquitetural (Seo 9.4.1) implica um
ou mais componentes especializados que processam os dados que fluem pela interface. Em
alguns casos (por exemplo, uma interface grfica do usurio), tem de ser projetada uma arquitetura de subsistemas completa com vrios componentes.
Continuando com o exemplo da funo de segurana domiciliar do CasaSegura, poderamos
definir o conjunto de componentes de alto nvel que atende seguinte funcionalidade:
Gerenciamento da comunicao externa coordena a comunicao da funo de segurana com entidades externas como sistemas baseados na Internet e notificao externa
de alarme.
Processamento de painel de controle gerencia toda a funcionalidade do painel de controle.
Gerenciamento de detectores coordena o acesso a todos os detectores conectados ao
sistema.
Processamento de alarme verifica e atua sobre todas as condies de alarme.
Cada um dos componentes de alto nvel teria de ser elaborado de forma iterativa e posicionado na arquitetura global do CasaSegura. As classes de projeto (com atributos e operaes
4

Se optar-se por uma abordagem convencional (no orientada a objetos), os componentes so obtidos do modelo de fluxo de
dados. Discutiremos brevemente esse mtodo na Seo 9.6.

243

captulo 9 PROJETO DA ARQUITETURA

apropriados) seriam definidas para cada um deles. Entretanto, importante notar que os detalhes de projeto de todos os atributos e operaes no seriam especificados at se atingir o
projeto de componentes (Captulo 10).
A estrutura global de arquitetura (representada na forma de um diagrama de componentes UML) ilustrada na Figura 9.8. As transaes so capturadas por gerenciamento de
comunicao externa medida que se deslocam de componentes que processam a interface
grfica do usurio do CasaSegura e a interface com a Internet. Tais informaes so gerenciadas por um componente executivo do CasaSegura que seleciona a funo do produto
apropriada (no caso, segurana). O componente processamento do painel de controle interage com o proprietrio do imvel para armar/desarmar a funo de segurana. O componente gerenciamento de detectores faz uma sondagem nos sensores para detectar condio
de alarme, e o componente de processamento de alarme gera uma sada quando o alarme
detectado.

9.4.4Descrio das instncias


O projeto da arquitetura modelado at este ponto ainda relativamente de alto nvel. O contexto do sistema foi representado, arqutipos que indicam importantes abstraes contidas no
domnio do problema foram definidos, a estrutura global do sistema est evidente e os principais componentes de software foram identificados. Entretanto, um maior refinamento (recordese que todo projeto iterativo) ainda necessrio.
Para tanto, desenvolvida uma instncia real da arquitetura. Queremos dizer com isso que
a arquitetura aplicada a um problema especfico com o intuito de demonstrar que a estrutura
e os componentes so apropriados.
A Figura 9.9 ilustra uma instncia da arquitetura do CasaSegura para o sistema de segurana. Os componentes da Figura 9.8 so elaborados para indicar mais detalhes. Por exemplo, o componente gerenciamento de detectores interage com o componente de infraestrutura
agendador que implementa a sondagem (pooling) de cada objeto sensor usado pelo sistema
de segurana. Elaborao similar feita para cada um dos componentes representados na
Figura 9.8