Faculdade de ecnologia de Praia Grande

ENGENHARIA DE SOFTWARE II

Simone Maria Viana Romano

Se eu tivesse oito horas para derrubar uma árvore, passaria seis afiando meu machado (Abraham Lincoln).

2º SEMESTRE DE 2013

E N G E N H A R I A D E S O F T W A R E 2

SSuummáárriioo

INFORMAÇÕES IMPORTANTES .................................................................................................................... 7

OBJETIVOS: .................................................................................................................................................. 7 Sugestão de Livros, Revistas e Sites ............................................................................................................... 7 Softwares ......................................................................................................................................................... 7 Quantidade de aulas semanais e Quantidade de faltas permitidas ............................................................... 7 Abono de Faltas .............................................................................................................................................. 8 Contato ............................................................................................................................................................ 8 Avisos .............................................................................................................................................................. 8 Conteúdo das Avaliações ................................................................................................................................ 8 Forma de Avaliação........................................................................................................................................ 8 Disciplinas, Dias e Horários que me encontro na Fatec ............................................................................... 8 Erros da Apostila: ........................................................................................................................................... 8

TRABALHO SEMESTRAL ................................................................................................................................. 9

TAREFA 01 - REVISÃO DE ENGENHARIA DE SOFTWARE I (VALOR : 0,5) ........................................... 10

1º BIMESTRE DESENVOLVIMENTO DE SOFTWARE .................................................................................................. 14

REQUISITOS DE SOFTWARE ................................................................................................................................... 16

IMPORTÂNCIA DOS REQUISITOS ............................................................................................................... 17 QUALIDADE DOS REQUISITOS ................................................................................................................... 18 TIPOS DE REQUISITOS .................................................................................................................................. 19

EXEMPLO DE REQUISITOS FUNCIONAIS ............................................................................................... 20 EXEMPLO DE REQUISITOS NÃO FUNCIONAIS ...................................................................................... 20 EXEMPLO DE REQUISITOS DE DOMINIO ............................................................................................... 20 PROBLEMAS COMUNS NOS REQUISITOS ............................................................................................... 20 CLASSES DE REQUISITOS .......................................................................................................................... 20

ENGENHARIA DE REQUISITOS ............................................................................................................................... 21

OBJETIVOS DA ENGENHARIA DE REQUISITOS ...................................................................................... 22 TAREFA 02 - QUESTÕES DE REQUISITOS (0,5) ...................................................................................... 23

ELICITAÇÃO DE REQUISITOS ................................................................................................................................. 26

OBJETIVOS DA ELICITAÇÃO DE REQUISITOS ........................................................................................ 28 PASSOS PARA A ELICITAÇÃO DE REQUISITOS ....................................................................................... 28 QUESTÕES QUE PRECISAM SER RESPONDIDAS ..................................................................................... 29 DOCUMENTAÇÃO DO ELICITAÇÃO DE REQUISITOS ............................................................................ 29 IDENTIFICAÇÃO E ELICITAÇÃO DE REQUISITOS .................................................................................. 30

IDENTIFICAÇÃO DOS REQUISITOS ......................................................................................................... 30 PROBLEMAS NA IDENTIFICAÇÃO DOS REQUISITOS ............................................................................ 31 EXEMPLO DE DECLARAÇÃO DO PROBLEMA ........................................................................................ 31

CARACTERÍSTICAS DA ELICITAÇÃO DE REQUISITOS.......................................................................... 31 DIFERENÇA ENTRE UMA BOA E UMA MÁ ELICITAÇÃO DE REQUISITOS ......................................... 32 TAREFA 03 – ELICITAÇÃO DE REQUISITOS (0,5) ................................................................................... 33

TÉCNICAS PARA ELICITAÇÃO DE REQUISITOS ................................................................................... 34

ETNOGRAFIA ................................................................................................................................................. 36 ENTREVISTAS ................................................................................................................................................ 37

Etapas ............................................................................................................................................................ 37 Forma de Entrevistar .................................................................................................................................... 37 Perguntas que devem ser respondidas .......................................................................................................... 37

BRAINSTORMING .......................................................................................................................................... 38 BRAINSWRITING ........................................................................................................................................... 39

EXERCÍCIOS ................................................................................................................................................ 40

JAD ....................................................................................................................................................................... 41

E N G E N H A R I A D E S O F T W A R E 3

ETAPAS PARA PREPARAR UMA REUNIÃO JAD..................................................................................................... 41 PREPARAÇÃO .............................................................................................................................................. 42 SESSÃO ......................................................................................................................................................... 46 REVISÃO ....................................................................................................................................................... 51

PAPEIS DE CADA UM DENTRO DA REUNIÃO .......................................................................................... 52 O CLIENTE (PATROCINADOR) .................................................................................................................. 52 ENGENHEIRO DE SOFTWARE ................................................................................................................... 52 EQUIPE ........................................................................................................................................................ 53 OBSERVADOR .............................................................................................................................................. 53 DOCUMENTADOR ...................................................................................................................................... 53 LÍDER DE SESSÃO OU FACILITADOR ...................................................................................................... 53 FIGURINHAS DIFÍCIEIS NA REUNIÃO ..................................................................................................... 54 TAREFA 04 – TECNICA JAD (1,0) ............................................................................................................... 57

ESPECIFICAÇÃO DE REQUISITOS .............................................................................................................. 58

MODELO DE ESPECIFICAÇÃO DE REQUISITOS ...................................................................................................... 58 PASSOS PARA ESPECIFICAR OS REQUISITOS ........................................................................................ 58

VISÃO E ESCOPO ................................................................................................................................................. 60 EXERCÍCIOS ................................................................................................................................................ 60 TAREFA 05 – ESPECIFICAÇÃO DE REQUISITOS (0,5) ........................................................................... 61

VERIFICAÇÃO E VALIDAÇÃO DE REQUISITOS ..................................................................................... 62

TIPOS DE DEFEITO ........................................................................................................................................ 63 OMISSÃO ...................................................................................................................................................... 64 AMBIGUIDADE ............................................................................................................................................ 64 INCONSISTÊNCIA ........................................................................................................................................ 64 FATO INCORRETO ...................................................................................................................................... 64 INFORMAÇÃO ESTRANHA ......................................................................................................................... 64

DOCUMENTO DE REQUISITOS .............................................................................................................................. 64 DEFEITOS NO DOCUMENTO DE REQUISITOS....................................................................................... 65 CONSEQUENCIAS ....................................................................................................................................... 65

PEQUENO CHECKLIST DE REQUISITOS..................................................................................................... 65 TÉCNICAS DE VALIDAÇÃO DE REQUISITOS ........................................................................................... 65

REVISÃO DE REQUISITOS ......................................................................................................................... 65 REVISÕES DE SOFTWARE ............................................................................................................................ 66

TIPOS DE REVISÃO DE SOFTWARE .......................................................................................................... 66 PROCESSO DE INSPEÇÃO DE SOFTWARE .............................................................................................. 67 PROCESSO TRADICIONAL DE INSPEÇÃO ............................................................................................... 68

GERENCIAMENTO DE MUDANÇA DE REQUISITOS .............................................................................. 69

EVOLUÇÃO DOS REQUISITOS .................................................................................................................... 71 REQUISITOS PERMANENTES E VOLÁTEIS ............................................................................................... 71

CLASSIFICAÇÃO DOS REQUISITOS.......................................................................................................... 71 PLANEJAMENTO DO GERENCIAMENTO DE REQUISITOS ................................................................... 72 RASTREABILIDADE ..................................................................................................................................... 72 SUPORTE À FERRAMENTA: ....................................................................................................................... 72 ETAPAS PARA O RASTREAMENTO ............................................................................................................ 73 EXERCÍCIOS ................................................................................................................................................ 74

MATRIZ DE RASTREABILIDADE ................................................................................................................ 76

RASTREABILIDADE ...................................................................................................................................... 76 OBJETIVOS................................................................................................................................................... 76

MATRIZ DE RASTREABILIDADE DEFINIDAS ........................................................................................................ 78 EXERCÍCIOS ................................................................................................................................................ 79

ORIENTAÇÃO A OBJETOS ............................................................................................................................ 80

HISTÓRIA ........................................................................................................................................................ 80 CONCEITOS FUNDAMENTAIS ............................................................................................................................... 81

OBJETO ........................................................................................................................................................ 82 ATRIBUTO .................................................................................................................................................... 83

E N G E N H A R I A D E S O F T W A R E 4

OPERAÇÃO X MÉTODO ............................................................................................................................. 83 CLASSE ......................................................................................................................................................... 84 ESTADO ........................................................................................................................................................ 84 MENSAGEM ................................................................................................................................................. 84 ENCAPSULAMENTO ................................................................................................................................... 84 HERANÇA ..................................................................................................................................................... 85 POLIMORFISMO ......................................................................................................................................... 86

ANÁLISE ORIENTADA A OBJETOS ............................................................................................................ 87 EXERCÍCIOS ................................................................................................................................................ 88

2º BIMESTRE UML ...................................................................................................................................... 91

HISTÓRIA ............................................................................................................................................................ 91 CONCEITO ....................................................................................................................................................... 92 UTILIZAÇÃO ................................................................................................................................................... 93 NOTAÇÃO ....................................................................................................................................................... 94 VANTAGENS ....................................................................................................................................................... 94 FASES DO DESENVOLVIMENTO UML ....................................................................................................... 94 COMPONENTES DA UML ...................................................................................................................................... 95 MODELOS DE ELEMENTOS ......................................................................................................................... 95

CLASSES ....................................................................................................................................................... 95 OBJETOS ...................................................................................................................................................... 95 ESTADOS ...................................................................................................................................................... 96 PACOTES ...................................................................................................................................................... 96 COMPONENTES .......................................................................................................................................... 96 RELACIONAMENTOS .................................................................................................................................. 97 MECANISMOS GERAIS ............................................................................................................................. 101

DIAGRAMAS ..................................................................................................................................................... 101 DIAGRAMAS ESTRUTURAIS (ESTÁTICOS) ............................................................................................. 101 DIAGRAMAS COMPORTAMENTAIS (DINÂMICOS) ............................................................................... 102 EXERCÍCIOS .............................................................................................................................................. 103

DIA PORTABLE ............................................................................................................................................... 105

MICROSOFT VISIO 2003 ............................................................................................................................... 107

DIAGRAMA DE MODELO UML ............................................................................................................................ 107 ATIVIDADE DE UML ................................................................................................................................. 108 COLABORAÇÃO DE UML ......................................................................................................................... 108 COMPONENTE UML ................................................................................................................................. 109 IMPLANTAÇÃO DE UML .......................................................................................................................... 109 SEQUÊNCIA DE UML ................................................................................................................................ 109 GRÁFICO DE ESTADO DE UML .............................................................................................................. 109 ESTRUTURA ESTÁTICA DE UML ............................................................................................................. 110 CASO DE USO ............................................................................................................................................ 110

PROPRIEDADES DA FORMA ...................................................................................................................... 110 OBSERVAÇÕES .......................................................................................................................................... 111

DIAGRAMA DE CASO DE USO .................................................................................................................... 112

CASOS DE USO ............................................................................................................................................. 112 ATOR ................................................................................................................................................................ 113

COMO IDENTIFICAR OS ATORES ........................................................................................................... 113 CASO DE USO .................................................................................................................................................... 113

COMO IDENTIFICAR CASOS DE USO .................................................................................................... 114 CENÁRIO ....................................................................................................................................................... 114 RELACIONAMENTO DE EXTENSÃO ................................................................................................................ 114 RELACIONAMENTO DE INCLUSÃO ................................................................................................................. 115 RELACIONAMENTO DE ESPECIALIZAÇÃO .................................................................................................... 115

RELACIONAMENTO ENTRE CASOS DE USO ......................................................................................... 115 EXEMPLO: ESTUDO DE CASO – LOCADORA DE VEÍCULOS ............................................................. 117

ANÁLISE DE CASOS DE USO ..................................................................................................................... 118 EXERCÍCIOS .............................................................................................................................................. 118 TAREFA 06 – DIAGRAMA DE CASO DE USO (1,0) ................................................................................. 123

E N G E N H A R I A D E S O F T W A R E 5

DIAGRAMA DE CLASSES ............................................................................................................................. 124

CLASSE .......................................................................................................................................................... 124 CONVENÇÕES ........................................................................................................................................... 125

ATRIBUTOS................................................................................................................................................... 125 OPERAÇÕES .................................................................................................................................................. 125 VISIBILIDADE .................................................................................................................................................... 125 RELACIONAMENTOS .................................................................................................................................. 125

ASSOCIAÇÃO ............................................................................................................................................. 126 AGREGAÇÃO ............................................................................................................................................. 126 COMPOSIÇÃO ........................................................................................................................................... 127 CLASSE DE ASSOCIAÇÃO ........................................................................................................................ 127 HERANÇA ................................................................................................................................................... 128

DIAGRAMA DE CLASSE ............................................................................................................................. 129 COMO FAZER UM DIAGRAMA DE CLASSES ......................................................................................... 130 IDENTIFICANDO AS CLASSES ................................................................................................................. 130 IDENTIFICANDO OS ATRIBUTOS ........................................................................................................... 131 IDENTIFICANDO O COMPORTAMENTO ............................................................................................... 131 IDENTIFICANDO GENERALIZAÇÕES ..................................................................................................... 131 IDENTIFICANDO ASSOCIAÇÃO .............................................................................................................. 131 EXEMPLO – ESTUDO DE CASO: LOCADORA DE VEÍCULOS ............................................................. 131 EXERCÍCIOS .............................................................................................................................................. 132

DIAGRAMA DE OBJETOS ............................................................................................................................ 136

EXERCÍCIOS ................................................................................................................................................. 137 TAREFA 07 – DIAGRAMA DE CLASSES E DIAGRAMA DE OBJETOS (1,0) .......................................... 138

DIAGRAMA DE SEQUENCIAS ..................................................................................................................... 139

EXEMPLO: ESTUDO DE CASO: SISTEMA GESTOR DE VOTAÇÃO INTERNA .................................... 142 EXERCÍCIOS .............................................................................................................................................. 147 TAREFA 8 – DIAGRAMA DE SEQUENCIAS (1,0) .................................................................................... 148

ANEXO - SOLUÇÕES PARA PROBLEMAS NA ENGENHARIA DE REQUISITOS ............................ 150

ELICITAÇÃO DE REQUISITOS ................................................................................................................... 151 PROBLEMAS .............................................................................................................................................. 151 DESAFIOS................................................................................................................................................... 151 PROBLEMA: ENVOLVER INTERESSADOS INAPROPRIADOS .............................................................. 152 PROBLEMA: POLÍTICA NA ORGANIZAÇÃO .......................................................................................... 152 PROBLEMA: A LINGUAGEM NATURAL E A ABSTRAÇÃO DOS REQUISITOS DE ALTO NÍVEL

DIFICULTAM O MAPEAMENTO DAS CAPACIDADES MACRO EM REQUISITOS FUNCIONAIS E NÃO

FUNCIONAIS. ............................................................................................................................................. 152 PROBLEMA: SEPARAR PREMISSAS RELACIONADAS AO DESENVOLVIMENTO DO SISTEMA DOS

SEUS REQUISITOS .................................................................................................................................... 152 CASOS DE USO .................................................................................................................................................. 153

PROBLEMA: DIFICULDADE NA DESCRIÇÃO DE REQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS.

..................................................................................................................................................................... 153 PROBLEMA: COMPLEXIDADE NO DETALHAMENTO DOS CASOS DE USO PARA DEFINIÇÃO DA

SOLUÇÃO ................................................................................................................................................... 153 PROBLEMA: DETALHAMENTO TÉCNICO DESNECESSÁRIO DURANTE A ESPECIFICAÇÃO

FUNCIONAL DO SISTEMA. ...................................................................................................................... 154 GERÊNCIA DE REQUISITOS ................................................................................................................................ 154

PROBLEMA: DIFICULDADES DE ESTABELECER UMA ESTRATÉGIA PARA A ATUALIZAÇÃO E

REUTILIZAÇÃO DE CASOS DE USO ....................................................................................................... 154 PROBLEMA: REPRESENTAR A ATUALIZAÇÃO DE CASOS DE USO ................................................... 154 PROBLEMA: DIFICULDADE DE INTEGRAÇÃO DAS PRÁTICAS DE GERÊNCIA DE REQUISITOS

COM GERÊNCIA DE CONFIGURAÇÃO. ................................................................................................. 155 PROBLEMA: TRABALHAR COM O BACKLOG DE CASOS DE USO INEXISTENTES PARA SISTEMAS

EM MANUTENÇÃO. ................................................................................................................................... 155 PROBLEMA: DIFICULDADE DE IMPLANTAÇÃO E MANUTENÇÃO DA RASTREABILIDADE DOS

REQUISITOS. .............................................................................................................................................. 155

E N G E N H A R I A D E S O F T W A R E 6

PROBLEMA: DIFICULDADES DE ESTABELECIMENTO RETROATIVO DE RASTREABILIDADE DOS

REQUISITOS............................................................................................................................................... 155

E N G E N H A R I A D E S O F T W A R E 7

IINNFFOORRMMAAÇÇÕÕEESS IIMMPPOORRTTAANNTTEESS

OBJETIVOS:

Aplicar um processo de desenvolvimento de software, ênfase na definição e

elicitação dos requisitos: Apresentar e discutir o Ciclo de Requisitos de Software: Identificação,

Elicitação, Análise, Especificação e Validação;

Apresentar e discutir as atividades de Identificação e elicitação de requisitos; Apresentar e discutir as atividades da análise de requisitos de software;

Apresentar as principais técnicas para especificação de requisitos de software; Apresentar as principais técnicas para validação de requisitos de software; Apresentar as principais técnicas para processo de gerenciamento de

mudança de requisitos de software. EMENTA:

Contexto atual das empresas em relação aos projetos de tecnologia de informação. Modelagem de Negócio para o desenvolvimento de software. Conceitos, evolução e importância da Engenharia de Requisitos. Entendendo e

analisando os problemas e as necessidades dos usuários, clientes e envolvidos no projeto. Técnicas de elicitação. Requisitos, seus tipos e matriz

de rastreabilidade. Definição do sistema a partir dos requisitos. Gerenciamento de requisitos

Sugestão de Livros, Revistas e Sites

ENGENHARIA DE SOFTWARE – Fundamentos, Métodos e Padrões – 3ª Edição – Editora GEN LTC – Autor: Wilson de Pádua Paula Filho – 2010;

ESPECIFICAÇÃO DE SISTEMAS DE SOFTWARE UTILIZANDO ANALISE E PROJETO ESTRUTURADOS – Editora UNICAMP – Autor: Thelma C. dos Santos Chiossi e Regina Lúcia O. Moraes – 2006;

ENGENHARIA DE SOFTWARE – 6ª Edição – Editora MH - MCGRAW HILL/NACIONAL – Autor: Roger S. Pressman – 2006;

AURUM, A., WOHLIN, C., Engineering and Managing Software Requirements, Springer-Verlag, 2005.

REVISTAS E SITES:

Revista Engenharia de Software: www.devmedia.com.br; http://engenhariadesoftware.blogspot.com/;

http://www.sigsoft.org/; http://rildosan.blogspot.com/; http://www.yuml.me;

http://www.wthreex.com/rup/; http://www.engenharia-software.com

http://www.facebook.com/connect/uiserver.php?app_id=318148321616976&method=permissions.request&redirect_uri=http%3A%2F%2Fapps.facebook.c

om%2Fpromonlogicalisestag%2F%3Ffb_source%3Dsearch%26ref%3Dts%26fref%3Dts&response_type=none&display=page&auth_referral=1

Softwares

Dia Portable, Visio (Fatec), Word. Máquina Virtual na Fatec : Engenharia de Software.

Quantidade de aulas semanais e Quantidade de faltas permitidas Quatro (4) aulas semanais e poderá ter vinte (20) faltas no semestre.

E N G E N H A R I A D E S O F T W A R E 8

Abono de Faltas Abono de faltas somente com atestado médico.

No final do semestre, no caso do aluno ter nota e ter entregue no mínimo 70% das atividades poderá eliminar as faltas em excesso da seguinte forma: para cada 2 horas/aula excedida deverá ser entregue manuscrito um relatório

de apresentação de TCC (DEIXAR NA SECRETARIA).

Contato

Email: simone_viana@yahoo.com.br e/ou simone@fatecpg.com.br Obs. O email: simonemviana@gmail.com é usado somente para envio

de formulários no Google Docs não há acesso da caixa postal.

TODOS OS EMAILS ENVIADOS PELO YAHOO OU PELO FATECPG SERÃO RESPONDIDOS EM UM PRAZO DE 48 HORAS. CASO NÃO HAJA RESPOSTA,

FAVOR ENVIAR NOVAMENTE. Solicito que todos deixem o email atualizado na secretaria da Fatec

pois é por este email que consta no seu cadastro que eu entro em

contato, avisando faltas, reposições, assuntos gerais, etc.

Avisos Na página de ENGENHARIA DE SOFTWARE sempre terá avisos pertinentes ao conteúdo da disciplina.

Conteúdo das Avaliações Sempre o conteúdo das avaliações será o apresentado até uma semana antes

das provas bimestrais, podendo ter eventualmente uma revisão antes da avaliação.

Forma de Avaliação

Haverá duas provas bimestrais que poderão ser dissertativas ou objetivas com valor de 10,0 pontos;

Haverá tarefas avaliativas em sala de aula que pode ter valor até 3,0 pontos que serão acrescidos a nota do bimestre;

Estas tarefas poderão ser feitas em laboratório, em casa com data de entrega estipulada ou em sala de aula, realizadas em grupo ou individualmente, participação em sala de aula, relatórios a partir de vídeos assistidos, estudos

de casos, entre outros. ATENÇÃO!!!! CASO O ALUNO FALTE – INDEPENDENTE DE TER

ATESTADO OU TER ATESTADO – NÃO SERÁ ACEITO A TAREFA POIS O MESMO NÃO ASSISTIU A AULA.

Disciplinas, Dias e Horários que me encontro na Fatec

Engenharia de Software II – quinta-feira (13h10 as 16h40); quarta-feira (19h as 22h30);

Banco de Dados – quarta-feira (13h10 as 16h40); quinta-feira (19h as 22h30);

Laboratório de Banco de Dados – quarta e quinta-feira (16h50 as 18h30)

Sábado (8h as 11h30).

Erros da Apostila:

Caso seja encontrado erro na apostila, favor enviar por email.

Obrigada!

E N G E N H A R I A D E S O F T W A R E 9

TTRRAABBAALLHHOO SSEEMMEESSTTRRAALL

O trabalho semestral deverá ser entregue na última aula do segundo semestre (antes da prova de avaliação do segundo bimestre) e deverá ter:

Capa contendo o nome dos alunos (máximo 5), o ciclo e o

período;

Estudo de caso descritivo;

Agenda da reunião – JAD;

Ata contendo o resultado da reunião JAD;

Especificação de Requisitos (mínimo 4);

Diagrama de Caso de Uso (contendo todo o projeto);

Diagrama de Classes (contendo todo o projeto);

Diagrama de Objetos (com base no diagrama de classes);

Diagrama de Sequência (de um caso de uso).

Obs. Poderá ser feito manuscrito ou utilizando um software e não é necessário entregar encadernado.

Aviso: eu sou cliente.

Portanto quero ver o

trabalho pronto e não tiro

dúvidas do mesmo. Bom Trabalho!!!!

E N G E N H A R I A D E S O F T W A R E 1 0

TAREFA 01 - REVISÃO DE ENGENHARIA DE SOFTWARE I (VALOR : 0,5)

1. Segundo a IEEE Computer Society, a engenharia de software é a

aplicação de uma abordagem sistemática, disciplinada e quantificável ao desenvolvimento, à operação e à manutenção de software, isto é,

a aplicação da engenharia ao software. Acerca dos princípios da engenharia de software, assinale a opção correta. (CESPE - 2010 -

SAD-PE - Analista de Controle Interno – Tecnologia da Informação) a) A engenharia de requisitos de um software, em geral, precede a

engenharia dos requisitos do sistema de informações no qual o software será usado.

b) A manutenção de software é uma atividade da engenharia de software que necessita do emprego de recursos que drenam cerca de

50% do investimento total em um software durante todo o seu ciclo

de vida. c) A gerência de configuração de software é uma atividade que envolve

o emprego de conceitos e práticas, tais como identificação de itens de configuração, controle, contabilização e auditoria.

d) É desejável que o valor da coesão e o do acoplamento, duas importantes propriedades da arquitetura de um software, sejam

maximizados durante a engenharia de software. e) Em ferramentas CASE, como refactoring, é melhor adotar-se uma

abordagem formal que uma abordagem heurística.

2. Um requisito de software expressa as necessidades e restrições colocadas em um produto de software que contribuem para a solução

de algum problema do mundo real. Acerca desse assunto, assinale a opção correta. (CESPE - 2010 - SAD-PE - Analista de Controle Interno

– Tecnologia da Informação)

a) Os contratantes ou clientes são os principais colaboradores envolvidos no fornecimento de informações para o processo de

levantamento ou elicitação de requisitos de software, os demais grupos de pessoas que podem fornecer informações são

considerados de importância secundária. b) As necessidades dos usuários a serem atendidas por um produto

de software constituem a classe de requisitos funcionais, e as restrições mencionadas na definição de requisitos constituem a

classe de requisitos não funcionais. c) Entre as fontes de informação para a elicitação de requisitos,

destacam-se, além dos colaboradores, o conhecimento do domínio de aplicação em que o software funcionará, o ambiente operacional

do software e o ambiente organizacional. d) A negociação de requisitos, de forma similar à observação do

ambiente organizacional, é uma atividade típica da fase de

elicitação de requisitos. e) A técnica de casos de uso, empregada em alguns modelos de

desenvolvimento de software atuais, é mais aderente à construção

E N G E N H A R I A D E S O F T W A R E 1 1

de cenários durante a construção de protótipos que durante a elicitação de requisitos.

3. O conjunto de atividades e resultados associados que resulta em um

produto de software recebe o nome de (UFG - 2010 - UFG - Analista de TI - Desenvolvimento de Sistemas):

a) engenharia de software. b) processo de software.

c) especificação de software.

d) implantação de software.

4. Assim como a Engenharia de Software, existe também na área de informática a chamada Ciência da Computação. Assinale a alternativa

que melhor apresenta a diferença entre Engenharia de Software e Ciência da Computação. (FUNIVERSA - 2009 - IPHAN - Analista -

Tecnologia da Informação) a) A Ciência da Computação tem como objetivo o desenvolvimento de

teorias e fundamentações. Já a Engenharia de Software se preocupa com as práticas de desenvolvimento de software.

b) A Engenharia de Software trata da criação dos sistemas de computação (softwares) enquanto a Ciência da Computação está

ligada ao desenvolvimento e criação de componentes de hardware. c) A Engenharia de Software trata dos sistemas com base em

computadores, que inclui hardware e software, e a Ciência da

Computação trata apenas dos aspectos de desenvolvimento de sistemas.

d) A Ciência da Computação trata dos sistemas com base em computadores, que inclui hardware e software, e a Engenharia de

Software trata apenas dos aspectos de desenvolvimento de sistemas.

e) A Ciência da Computação destina-se ao estudo e solução para problemas genéricos das áreas de rede e banco de dados e a

Engenharia de Software restringe- se ao desenvolvimento de sistemas.

5. Para garantir o desenvolvimento de qualidade, é suficiente que a

equipe tenha as ferramentas mais atuais de engenharia de software e os melhores computadores. (CESPE - 2010 - BASA - Técnico Científico -

Tecnologia da Informação - Arquitetura de Tecnologia)

_____ Certo ____ Errado

6. Sobre a engenharia de software, considere: I. Atualmente todos os problemas na construção de software de alta

qualidade no prazo e dentro do orçamento foram solucionados. II. Ao longo dos últimos 50 anos, o software evoluiu de um produto de

indústria para um ferramental especializado em solução de problemas e análise de informações específicas.

E N G E N H A R I A D E S O F T W A R E 1 2

III. Todo projeto de software é iniciado por alguma necessidade do negócio.

IV. O intuito da engenharia de software é fornecer uma estrutura para a construção de software com alta qualidade. (FCC - 2010 - TRE-RS

- Analista Judiciário - Analista de Sistemas Suporte) Está correto o que consta em

a) III e IV, somente. b) II e III, somente.

c) I, II e IV, somente.

d) II, III e IV, somente. e) I, II, III e IV.

7. De acordo com Pressman, a engenharia de software é baseada em

camadas, com foco na qualidade: (FGV - 2010 - BADESC - Analista de Sistemas - Desenvolvimento de Sistemas): Essas camadas são:

a) métodos, processo e teste. b) ferramentas, métodos e processo.

c) métodos, construção, teste e implantação. d) planejamento, modelagem, construção, validação e implantação.

e) comunicação, planejamento, modelagem, construção e implantação.

8. O objetivo da Engenharia de Software é estabelecer uma sistemática abordagem de desenvolvimento, através de ferramentas e técnicas

apropriadas, dependendo do problema a ser abordado, considerando

restrições e recursos disponíveis. A Engenharia de Software: (FCC - 2008 - METRÔ-SP - Analista Trainee - Ciências da Computação)

I. não se confunde com a Ciência da Computação, pois enquanto esta visa o desenvolvimento de teorias e fundamentações, a

Engenharia de Software se preocupa com as práticas de desenvolvimento de software.

II. tem como foco único o tratamento dos aspectos de desenvolvimento de software, o que a diferencia da Engenharia

de Sistemas, que trata dos sistemas baseados em computadores, incluindo hardware e software.

III. tem como métodos as abordagens estruturadas para o desenvolvimento de software que incluem os modelos de

software, notações, regras e maneiras de desenvolvimento. IV. segue princípios, tais como, o da Abstração, que identifica os

aspectos importantes sem ignorar os detalhes e o da

Composição, que agrupa as atividades em um único processo para distribuição aos especialistas.

É correto o que consta em: a) I e II, apenas.

b) III e IV, apenas. c) I, II e III, apenas.

d) II, III e IV, apenas. e) I, II, III e IV.

E N G E N H A R I A D E S O F T W A R E 1 3

9. No processo de engenharia de software, os requisitos funcionais podem ser também definidos como requisitos de (FCC - 2008 - METRÔ-SP -

Analista Trainee - Ciências da Computação): a) qualidade.

b) capacidade. c) segurança.

d) desempenho. e) manutenção.

10. Analise as seguintes afirmações relativas à Engenharia de Software: I. A análise de requisitos é responsável pela especificação dos

requisitos de software e hardware que serão utilizados durante o processo de desenvolvimento de um sistema.

II. A análise de requisitos define a metodologia de programação a ser utilizada no desenvolvimento do sistema.

III. A especificação de requisitos fornece ao desenvolvedor e ao cliente os parâmetros para avaliar a qualidade logo que o sistema for

construído. IV. A análise de requisitos possibilita que o engenheiro de software

especifique a função e o desempenho do sistema e estabeleça quais são as restrições de projeto que o sistema deve atender.

Estão corretos os itens: (ESAF - 2004 - CGU - Analista de Finanças e Controle - Área - Tecnologia da Informação - Prova 3):

a) I e II

b) II e III c) III e IV

d) I e III e) II e IV

E N G E N H A R I A D E S O F T W A R E 1 4

11ºº BBIIMMEESSTTRREE DDEESSEENNVVOOLLVVIIMMEENNTTOO DDEE SSOOFFTTWWAARREE

Processo de software é um conjunto de atividades que objetivam o

desenvolvimento e a evolução de software. Principais atividades são:

ESPECIFICAÇÃO: define o que o sistema deverá fazer, considerando

as suas restrições. DESENVOLVIMENTO: produção do software.

VALIDAÇÃO: checagem se o software faz o que o usuário deseja. EVOLUÇÃO: mudanças no software para atender às novas

demandas. O processo de engenharia de requisitos envolve criatividade,

interação de diferentes pessoas, conhecimento e experiência para transformar informações diversas (sobre a organização, sobre leis, sobre o

sistema a ser construído etc.) em documentos e modelos que direcionem o desenvolvimento de software (KOTONYA; SOMMERVILLE, 1998).

Figura 1 – Processo de Engenharia de Requisitos

(Fonte: adaptado de (KOTONYA;SOMMERVILLE, 1998))

Já desenvolvimento de software é um conjunto de atividades para

especificar, projetar, implementar e testar sistemas de software. As atividades necessárias para o desenvolvimento de software são:

especificação, projeto, validação e evolução.

O que é processo de software?

O que é desenvolvimento de

software?

E N G E N H A R I A D E S O F T W A R E 1 5

Para o sucesso do desenvolvimento do software é necessário um entendimento dos requisitos de software. Não importa se foi bem

projetado e/ou codificado; se o software tiver tido uma análise e uma especificação mal feita, o usuário se sentirá frustrado.

Análise de requisitos é um processo de descoberta, especificação, modelagem e refinamento.

O analista de sistema ou engenheiro de software estabelece o escopo1 do software e durante o planejamento do projeto de software vai

sendo refinado e seus detalhes sendo aperfeiçoados e através da criação

de diagramas, fluxos e modelos, o problema torna-se compreensível. O analista/engenheiro e o usuário possuem um papel ativo na análise

e especificação de requisitos. O cliente ou usuário tenta reformular um conceito de função e

desempenho de software, sem detalhes concretos. Já o analista, indaga, consulta e soluciona os problemas.

Porém, a análise e a especificação de requisitos parece ser uma tarefa simples, mas não é bem assim...

A comunicação é um fator importante, pois as interpretações erradas e informações falsas surgem a todo momento. A ambigüidade é provável.

Podemos entender o dilema, repetindo a declaração de um cliente anônimo:

1 ESCOPO: entendimento dos objetivos do projeto, dos resultados esperados e à descrição

sumária do trabalho a ser realizado. É feita na etapa de iniciação do projeto e detalhada

na etapa de planejamento. Descreve as características do produto e o trabalho

necessário para realizá-lo. O consenso inicial sobre o escopo do projeto é estabelecido

entre pessoas, organizações ou departamentos de organizações, sendo uma pessoa,

empresa, o cliente, o demandante do serviço, o prestador de serviços designado ou outra

pessoa, para fazê-lo.

―Sei que você acredita que entendeu o

que acha que eu disse, mas não estou

certo que percebeu que aquilo que ouviu

não é o que eu pretendia dizer...‖

ESCOPO É O QUE ESTÁ

SENDO

PROJETADO!!!!

E N G E N H A R I A D E S O F T W A R E 1 6

RREEQQUUIISSIITTOOSS DDEE SSOOFFTTWWAARREE

Figura 2 – Levantamento de Requisitos (Fonte: Web)

Segundo o IEEE, define requisitos de software como:

―Uma condição ou uma capacidade de que o usuário necessita para solucionar um problema ou alcançar um

objetivo; Uma condição ou uma capacidade que deve ser

alcançada ou possuída por um sistema ou componente do sistema, para satisfazer um contrato, um padrão,

uma especificação ou outros documentos impostos formalmente;

Uma representação documentada de uma condição ou capacidade‖.

Outros conceitos de requisitos de software...

Requisitos de um sistema são descrições dos serviços que devem ser

fornecidos por esse sistema e as suas restrições operacionais (SOMMERVILLE, 2007);

Um requisito de um sistema é uma característica do sistema ou a

descrição de algo que o sistema é capaz de realizar para atingir seus objetivos (PFLEEGER, 2004);

E N G E N H A R I A D E S O F T W A R E 1 7

Um requisito é descrito como uma propriedade que o software deve exibir para resolver algum problema no mundo real (SWEBOK, 2004);

Um requisito é alguma coisa que o produto tem de fazer ou uma

qualidade que ele precisa apresentar (ROBERTSON; ROBERTSON, 2006).

Existem em diversos níveis:

Figura 3 – Requisitos (extraído da WEB)

IMPORTÂNCIA DOS REQUISITOS

Quanto mais cedo no ciclo de desenvolvimento do sistema se descobre um erro, mais barato fica para acertá-lo.

FASE CUSTO DE ERRO

REQUISITO 1

ANÁLISE 5

PROJETO 10

IMPLEMENTAÇÃO 20

TESTE 50

MANUTENÇÃO 200 Figura 4 – Custo dos erros nas fases

A dificuldade de descobrir erros na fase de requisitos está no fato

de neste momento da análise, o analista está descobrindo o funcionamento do negócio que ele desconhece, e ainda a relação

analista X usuário é muito recente, fazendo com que a relação de

confiança ainda esteja em avaliação de ambas as partes. Ambiguidades decorrentes de nossa linguagem, omissões e fatos incorretos, são as

principais causas. O uso de inspeções, validação dos requisitos através de encontros

sucessivos com o usuário, ajudam a minimizar estes problemas. Pesquisa realizada na Standish Group com 350 companhias e

8.000 projetos diferentes, onde: Sucesso é quando cobre todas as funcionalidades em tempo e

dentro do custo;

E N G E N H A R I A D E S O F T W A R E 1 8

Problemático é quando não cobre todas as funcionalidades exigidas, custo maior e atraso;

Fracasso é quando o projeto foi cancelado durante o desenvolvimento.

Figura 5 – Pesquisa de projetos

As causas podem ser:

Figura 6 – Tipos de Fatores

Precisamos dos requisitos para entender o que o cliente quer, para

documentar o que o cliente quer e para assegurar a qualidade e a satisfação do cliente. Também podemos entender o problema do

negócio, documentar o escopo do projeto e definir suas restrições e definir os critérios de aceitação e gerenciar as expectativas do cliente.

QUALIDADE DOS REQUISITOS

As qualidades ―desejáveis‖ para um requisito são:

Verificável: Tem que existir uma maneira de verificar se o produto contempla o requisito;

E N G E N H A R I A D E S O F T W A R E 1 9

Priorizável: Se todos os requisitos têm a mesma prioridade, há algum problema, etc.;

Modificável: As ideias sempre mudam, logo os requisitos devem mudar também (Scott Ambler);

Inteligível, Rastreável, Completo, Claro (não ambíguo).

TIPOS DE REQUISITOS

FUNCIONAIS: os requisitos funcionais descrevem o que o sistema

deve fazer, isto é, as funções necessárias para atender os objetivos do sistema. Exemplos: Cadastrar Clientes; Fazer Análise de Crédito;

Fazer uma Transação com Banco de Dados; Cadastrar um Registro de Atendimento; Imprimir Relatório, etc.

Outras Definições: o Segundo SOMMERVILLE (2007), são declarações de serviços que

o sistema deve prover, descrevendo o que o sistema deve fazer;

o PFLEEGER (2004), diz que um requisito funcional descreve uma interação entre o sistema e o seu ambiente;

o Ainda em SOMMERVILLE (2007) seria como o sistema deve reagir a entradas específicas, como o sistema deve se comportar

em situações específicas e o que o sistema não deve fazer.

NÃO FUNCIONAIS (RNF ou Suplementares): Declaram as características que o sistema deve possuir e que estão relacionadas

às suas funcionalidades. Com as características: performance, portabilidade, segurança, usabilidade, qualidade do serviço (QoS),

confidencialidade, confiabilidade, portabilidade, precisão, integridade, eficiência, entre outras. Estes tipos de requisitos são as

causas as principais insatisfações dos usuários com relação ao software.

o Os requisitos não funcionais têm origem nas necessidades dos

usuários, em restrições de orçamento, em políticas organizacionais, em necessidades de interoperabilidade com

outros sistemas de software ou hardware ou em fatores externos como regulamentos e legislações (SOMMERVILLE,

2007).

DOMÍNIO: muito relacionado as regras de negócio ou comportamento próprio do sistema numa determinada aplicação ou

no contexto funcionando para uma empresa. Outras Definições:

o SOMMERVILLE (2007) diz que descrevem restrições sobre os serviços ou funções oferecidos pelo sistema;

o Ou ainda, as quais limitam as opções para criar uma solução para o problema (PFLEEGER, 2004);

E N G E N H A R I A D E S O F T W A R E 2 0

EXEMPLO DE REQUISITOS FUNCIONAIS

―O software deve permitir que o atendente consulte o relatório com os

resultados dos testes clínicos de um paciente.‖ [RF01] O software deve permitir que o atendente efetue cadastro de

clientes; [RF02] O software deve permitir que o caixa efetue o registro de itens

vendidos; [RF03] O software deve permitir que o administrador gere o um

relatório de vendas por mês.

EXEMPLO DE REQUISITOS NÃO FUNCIONAIS

CONFIABILIDADE: O sistema deve estar disponível 99% das vezes;

SEGURANÇA: dados devem ser protegidos; DESEMPENHO: sistema deve processar x requisições por segundo;

CAPACIDADE: deve suportar x usuários concorrentemente.

EXEMPLO DE REQUISITOS DE DOMINIO

[RN1] os campos referente a orçamento projeto vinculado só estarão ativos se o tipo de projeto for vinculado;

[RN2] o campo valor total orçado para o projeto é calculado somando-se os valores definidos para todas as rubricas incluídas no

orçamento do projeto, seja ele vinculado ou não-vinculado.

[RN3] A soma dos percentuais a ser distribuído entre os fundos incluídos no plano de aplicação deve ser entre 0 e 100%.

PROBLEMAS COMUNS NOS REQUISITOS

Nem sempre são óbvios;

São originados de várias fontes (=conflitos de interesse); Nem sempre retratam um problema que é possível ser expressado

por palavras; Sempre mudam;

Os usuários nem sempre sabem o que desejam; Os usuários têm uma tendência de privilegiar a sua área ou o seu

ponto de vista; Os analistas pensam que entendem os problemas melhor do que os

próprios usuários!

CLASSES DE REQUISITOS

Os requisitos podem ser vistos em três classes distintas: o Essenciais;

o Importantes; o Desejáveis.

Em princípio, sistema deve resolver todos os requisitos de essenciais para requisitos desejáveis.

E N G E N H A R I A D E S O F T W A R E 2 1

EENNGGEENNHHAARRIIAA DDEE RREEQQUUIISSIITTOOSS

A Engenharia de Requisitos é o processo pelo qual os requisitos

de um produto de software são coletados, analisados, documentados e gerenciados ao longo de todo o ciclo de vida do software (AURUM;

WOHLIN, 2005). Pode ser descrita como o processo de descobrir, analisar,

documentar e verificar as funções e restrições do sistema (SOMMERVILLE, 2003).

Em resumo, podemos dizer que tratamento de requisitos envolve

atividades de desenvolvimento (Levantamento, Análise e Documentação de Requisitos), gerência (Gerência de Requisitos) e

controle da qualidade (Verificação, Validação e Garantia da Qualidade de Requisitos).

Figura 7– Etapas da Engenharia de Requisitos (Fonte: extraído da Web)

RECORDANDO!!!!! A especificação de um requisito funcional deve determinar O QUE o sistema deve fazer sem a preocupação de COMO fazer.

E N G E N H A R I A D E S O F T W A R E 2 2

Ao conjunto de atividades relacionadas a requisitos, dá-se o nome de Processo de Engenharia de Requisitos.

Descreve as atividades relacionadas à INVESTIGAÇÃO e DEFINIÇÃO DE ESCOPO de um sistema. É um processo sistemático de

desenvolvimento de requisitos através de um processo cooperativo de análise onde os resultados das observações são codificados em uma

variedade de formatos e as observações são constantemente verificadas.

Pode ser classificada em:

PRODUÇÃO: levantamento, registro, obtenção de

comprometimento e verificação; A produção de requisitos é responsável por:

Levantar Requisitos; Registrar Requisitos;

Obter Comprometimento; Verificar requisitos.

GERÊNCIA: controle de mudanças, gerência de configuração,

rastreabilidade e gerência da qualidade de requisitos. A gerência de requisitos é responsável por:

Controlar Mudanças; Gerenciar Configuração;

Implementar Rastreabilidade;

Gerenciar Qualidade.

OBJETIVOS DA ENGENHARIA DE REQUISITOS

Estabelecer uma visão comum entre o cliente e a equipe de projeto em relação aos requisitos que serão atendidos pelo

projeto de software;

Registrar e acompanhar requisitos ao longo de todo o processo de desenvolvimento;

Documentar e controlar os requisitos alocados para estabelecer uma baseline para uso gerencial e da equipe de

desenvolvimento; Manter planos, artefatos e atividades de software consistentes

com os requisitos alocados.

E N G E N H A R I A D E S O F T W A R E 2 3

TAREFA 02 - QUESTÕES DE REQUISITOS (0,5)

1) Segundo Ian Sommerville, existe uma série de técnicas de validação de

requisitos que podem ser utilizadas em conjunto ou individualmente. São elas:

a) geração de casos de teste, revisões de requisitos, gerenciamento de mudanças e prototipação.

b) revisões de requisitos, prototipação, geração de casos de teste e análise automatizada da consistência.

c) prototipação, análise automatizada da consistência, revisões de

requisitos e gerenciamento de mudanças. d) gerenciamento de mudanças, análise automatizada da consistência,

revisões de requisitos e geração de casos de teste. e) análise automatizada da consistência, prototipação, gerenciamento

de mudanças e geração de casos de teste

2) Um requisito de software expressa as necessidades e restrições colocadas em um produto de software que contribuem para a solução

de algum problema do mundo real. Acerca desse assunto, assinale a opção correta.

a) Os contratantes ou clientes são os principais colaboradores

envolvidos no fornecimento de informações para o processo de levantamento ou elicitação de requisitos de software, os demais

grupos de pessoas que podem fornecer informações são considerados de importância secundária.

b) As necessidades dos usuários a serem atendidas por um produto de software constituem a classe de requisitos funcionais, e as restrições

mencionadas na definição de requisitos constituem a classe de requisitos não funcionais.

c) Entre as fontes de informação para a elicitação de requisitos, destacam-se, além dos colaboradores, o conhecimento do domínio

de aplicação em que o software funcionará, o ambiente operacional do software e o ambiente organizacional.

d) A técnica de casos de uso, empregada em alguns modelos de desenvolvimento de software atuais, é mais aderente à construção

de cenários durante a construção de protótipos que durante a

elicitação de requisitos. e) A negociação de requisitos, de forma similar à observação do

ambiente organizacional, é uma atividade típica da fase de elicitação de requisitos.

3) Sobre os processos de engenharia de requisitos, na elicitação e na

análise ocorre total interação com os stakeholders no sistema, sendo o principal objetivo:

a) obtenção dos requisitos. b) homologação do sistema.

c) elaboração do manual do usuário.

E N G E N H A R I A D E S O F T W A R E 2 4

d) conversão de especificações em requisitos. e) execução do estudo de viabilidade do sistema.

4) A respeito de análise de requisitos, julgue os itens a seguir.

I O usuário deve ser capaz de pesquisar tanto no banco de dados inteiro como em uma parte dele.

II A interface de usuário para o sistema deve ser implementada em HTML sem frames ou em applets Java.

III O sistema deve fornecer visões apropriadas para que o usuário

possa ler documentos. IV Cada ordem deve ter um identificador único (OSID), que o usuário

deve poder copiar na área permanente de armazenamento da conta.

V O processo de desenvolvimento do sistema e os documentos devem ser realizados conforme o padrão interno da empresa.

São requisitos funcionais apenas os itens: a) I, II e III.

b) I, II e V. c) ) I, III e IV.

d) II, IV e V. e) III, IV e V.

5) Identifique com V as afirmativas verdadeiras e com F, as falsas.

( ) Os requisitos não funcionais restringem o sistema que está sendo

desenvolvido e o processo de desenvolvimento que deve ser usado e estão, frequentemente, relacionados às propriedades emergentes do

sistema de modo que se aplicam ao sistema em sua totalidade. ( ) A prototipação não é considerada uma técnica usada para validação

de requisitos, pois ocorre na fase final do processo de desenvolvimento, representado a entrega do sistema aos usuários

finais e clientes. ( ) Pode-se considerar que a entrada para o estudo de viabilidade

consiste em um conjunto preliminar de requisitos de negócios, um esboço da descrição do sistema e como esse sistema pretende

apoiar os processos de negócios. A alternativa que contém a sequência correta, de cima para baixo, é a:

a) V V F b) V F V

c) F F V

d) F V F e) V V V

6) A engenharia de requisitos ajuda os engenheiros de software a

compreender melhor o problema que eles vão trabalhar para resolver. Ela inclui um conjunto de tarefas que levam a um entendimento de

qual será o impacto do software sobre o negócio, do que o cliente quer e de como os usuários finais vão interagir com o software. A função de

negociação no processo de engenharia de requisitos:

E N G E N H A R I A D E S O F T W A R E 2 5

a) especifica, revisa e valida o problema de modo a garantir que seu entendimento e o entendimento do cliente sobre o problema

coincidam. b) refina e modifica os requisitos. É uma ação de modelagem de

análise composta de várias tarefas de modelagem e refinamento. c) define quais são as prioridades, o que é essencial, o que é

necessário. Clientes, usuários e outros interessados são solicitados a ordenar os requisitos e depois discutir os conflitos de prioridade.

d) ajuda o cliente a definir o que é necessário.

e) define o escopo e a natureza do problema a ser resolvido.

7) Requisitos não-funcionais estão diretamente relacionados com a satisfação dos usuários. Assinale a alternativa que não indique um

requisito não-funcional: a) O sistema de arquivos deve ser protegido, para acesso, apenas, de

usuários autorizados. b) O software deve ser implementado usando os conceitos de

orientação a objetos. c) O tempo de desenvolvimento do software não deve ultrapassar seis

meses. d) O software poderá ser executado em plataforma windows e linux.

e) O software deve emitir relatórios de vendas a cada quinze dias.

8) As declarações de serviços que o sistema deve fornecer, de como ele

deve reagir a entradas específicas ou se comportar em determinadas situações, são chamadas de requisitos:

a) Não-funcionais b) De domínio.

c) De sistema. d) Funcionalidades.

e) De usuário.

9) Considerando-se a especificação de requisitos de um software, é incorreto afirmar:

a) a fase de especificação de requisitos pode ser iniciada logo após as fases de análise e projeto. Por essa razão, é fundamental que haja a

participação ativa do usuário. b) há técnicas para a elicitação dos requisitos; entre elas, está o uso de

entrevista e brainstorm com os potenciais usuários.

c) quanto mais cedo for identificado um problema na fase de análise de requisitos, menor será o custo de corrigi-lo.

d) o gerenciamento de requisitos contempla um conjunto de atividades que auxiliam no controle e alterações dos requisitos durante a

execução projeto. e) o seu objetivo é representar as necessidades e restrições dos

usuários de um sistema.

E N G E N H A R I A D E S O F T W A R E 2 6

EELLIICCIITTAAÇÇÃÃOO DDEE RREEQQUUIISSIITTOOSS

―A parte mais árdua na construção de um software consiste exatamente em identificar o

que construir. Nenhuma outra parte do trabalho

compromete tanto o resultado do trabalho se elaborado de forma incorreta. Nenhuma outra

parte oferece tanta dificuldade para efetuar correções posteriores." — Fred Brook

Uma das partes mais críticas do processo de desenvolvimento de

software é a elicitação (levantamento) de requisitos. Há estudos que indicam que os requisitos detectados depois

do software implementado ou erros de análise custam até vinte vezes mais caros que qualquer outro tipo de erro.

FASES DE UMA ELICITAÇÃO DE REQUISITOS

Um projeto de elicitação de requisitos têm as seguintes fases:

Figura 8 – Etapas de uma Elicitação de Requisitos (Fonte: extraído da Web)

Nesta etapa um dos artefatos2 principais é a criação do documento

visão.

2 Produto de trabalho do processo: os papéis usam os artefatos para executar atividades e produzem artefatos ao executarem as atividades (http://www.wthreex.com/rup/manuals/intro/kc_artifact.htm acessado em 08/12/2011)

E N G E N H A R I A D E S O F T W A R E 2 7

Figura 9 – Esquema para criação do documento visão (Fonte: extraído da Web)

Figura 10 – Erros de Requisitos (Fonte: extraído da Web)

A elicitação de requisitos corresponde a identificar junto aos

stakeholders3 quais são os objetivos do sistema ou produto, o que deve ser acompanhado, como o sistema ou produto se 'encaixa no contexto

das necessidades do negócio e, finalmente, como será a utilização do sistema ou produto no dia-a-dia.

É um processo complexo, porém simples. Há diversas razões para a complexidade, dentre elas, destacam-se

os seguintes problemas:

3 Qualquer pessoa ou organização que tenha interesse, ou seja, afetado pelo projeto. A palavra deriva de stake (interesse, participação, risco) e holder (aquele que possui).

E N G E N H A R I A D E S O F T W A R E 2 8

Escopo: Os limites do sistema são geralmente definidos de forma incompleta, ou os clientes4 ou usuários especificam

detalhes técnicos desnecessários;

Compreensão: Os clientes ou usuários geralmente não estão

completamente certos das necessidades, têm uma pouca compreensão ou do domínio do seu negócio, omitem

informações que julgam óbvias, etc.;

Volatilidade: Os requisitos mudam o tempo todo.

OBJETIVOS DA ELICITAÇÃO DE REQUISITOS

O objetivo da elicitação de requisitos é obter conhecimento relevante para o problema e prover o mais correto entendimento de o

que é esperado do software/sistema.

PASSOS PARA A ELICITAÇÃO DE REQUISITOS

Avaliar a viabilidade técnica e de negócio para o sistema proposto;

Identificar as pessoas que vão auxiliar a especificar os requisitos e compreender seus preconceitos organizacionais;

Definir o ambiente técnico no qual o sistema será instalado;

Identificar regras de domínio que limitam a funcionalidade ou

desempenho do software que será construído;

Definir um ou mais métodos de elicitação de requisitos;

Solicitar participação de várias pessoas para que os requisitos sejam

definidos a partir de diversos pontos de vista;

Identificar claramente a justificativa de existência para cada

requisito registrado;

Identificar requisitos ambíguos que serão candidatos a prototipação.

4 Há uma diferença entre cliente e usuário. O primeiro refere-se a quem contratou o desenvolvimento do sistema que não necessariamente será quem utilizará o sistema (usuário).

E N G E N H A R I A D E S O F T W A R E 2 9

QUESTÕES QUE PRECISAM SER RESPONDIDAS

Figura 11 – Questões que precisam ser respondidas

DOCUMENTAÇÃO DO ELICITAÇÃO DE REQUISITOS

Os documentos criados através da elicitação de requisitos irão depender do tamanho do sistema que será construído.

Estes documentos incluem as seguintes informações: As necessidades e viabilidade estruturadas;

O limite de escopo do software/sistema;

Lista de clientes, usuários e outros stakeholders que

participaram da atividade de elicitação de requisitos;

Descrição do ambiente técnico do sistema;

Lista de requisitos e as regras de domínio aplicáveis a cada um.

Conjunto de cenários de uso capazes de prover uma ideia do uso do sistema ou produto sob diferentes condições de

operação;

Qualquer protótipo que eventualmente tenha sido

desenvolvido para melhor definir os requisitos.

Cada um destes documentos deve ser revisado por todas as pessoas que tenham participado da elicitação de requisitos.

E N G E N H A R I A D E S O F T W A R E 3 0

IDENTIFICAÇÃO E ELICITAÇÃO DE REQUISITOS O sucesso no desenvolvimento de um projeto de software depende

basicamente da elicitação de requisitos, pois, é a base que permitirá ao Analista tirar conclusões sobre as situações, problemas ou fenômenos

e, assim, sugerir propostas que possam contribuir para a solução do problema.

Entretanto, esta atividade, nem sempre está presente no processo de desenvolvimento, raramente ela é elaborada de forma

metodológica, geralmente tem uma abordagem intuitiva. As informações podem ser identificadas ou encontradas em

diversas fontes, como: analista de negócio, clientes, documentos, Domain Experts5 especificações técnicas, sistemas legados-

patrocinadores ou usuários.

IDENTIFICAÇÃO DOS REQUISITOS

Também chamada de descoberta de requisitos, tem o objetivo de identificar os requisitos é a ideia inicial do sistema para compreender o

domínio do problema. Identificar as funcionalidades do software que deve ter para

atender as necessidades do usuário.

Para identificar podemos fazer as seguintes perguntas para identificar também as principais características do software:

5 Especialista em uma ou mais área de negócio.

O que o software

deve fazer?

Quais

funcionalidades ele deve ter?

Quanto a

performance, qual

é tempo de

resposta adequado?

Quais são os

requisitos de

segurança que o

software

precisa?

Quanto à

usabilidade, o

software identifica

visualmente a

empresa e possui

interface

amigável?

E N G E N H A R I A D E S O F T W A R E 3 1

Os requisitos encontrados não devem ser descritos neste

momento, precisamos apenas identificá-los (informação de alto nível). Os requisitos de software podem ser identificados no texto da

―declaração do problema‖ (geralmente são verbos que identificam algumas ações). Este documento classifica os requisitos em dois tipos.

PROBLEMAS NA IDENTIFICAÇÃO DOS REQUISITOS

ESCOPO: Limite do sistema é mal definido ou detalhes técnicos

desnecessários confundem os objetivos globais; ENTENDIMENTO: Clientes/usuários não estão completamente certos

dos que é necessário, não tem pleno entendimento do domínio do problema, têm dificuldade de comunicar as necessidades, têm pouca

compreensão das capacidades;

VOLATILIDADE: Requisitos mudam com o tempo.

EXEMPLO DE DECLARAÇÃO DO PROBLEMA

Acompanhamento das estatísticas de aprendizado do aluno e da

turma (professor);

Informação: Relatório de aproveitamento do aluno e da turma(s).

REQUISITOS FUNCIONAIS: o Sistema deve registrar as principais ações de cada usuário;

o O sistema deve fornecer um relatório do aproveitamento do aluno;

O relatório de aproveitamento do aluno deve conter o tempo de uso do software, o número de exercícios

feitos, o número de acertos e o de erros. o O sistema deve fornecer um relatório do aproveitamento da

turma. O relatório de aproveitamento da turma deve conter a

média e o desvio-padrão dos seguintes dados: tempo de uso do software, número de exercícios feitos, número de

acertos e erros de cada exercício.

REQUISITOS NÃO-FUNCIONAIS:

o O sistema deve usar gráficos comparativos do aproveitamento do aluno com a média da turma;

o O sistema deve usar cores na construção dos gráficos; o O tempo de resposta na elaboração do relatório não pode ser

superior a 15 segundos.

CARACTERÍSTICAS DA ELICITAÇÃO DE REQUISITOS

Definir as técnicas de coleta de requisitos baseadas em fatores

operacionais, táticos e financeiros;

E N G E N H A R I A D E S O F T W A R E 3 2

Criar um planejamento com objetivo de alcançar as metas estabelecidas, tais como: Prazos, Custos e Qualidade;

Promover a integração e o comprometimento de todos os envolvidos no processo, por exemplo: Clientes, Fornecedores,

Usuários e o Patrocinador; Identificar os documentos e procedimentos que definem as

políticas de negócios da empresa.

DIFERENÇA ENTRE UMA BOA E UMA MÁ ELICITAÇÃO DE REQUISITOS

Figura 12 – Diferença entre uma boa e uma má elicitação (Fonte: extraído da Web)

E N G E N H A R I A D E S O F T W A R E 3 3

TAREFA 03 – ELICITAÇÃO DE REQUISITOS (0,5)

No caça-palavras abaixo, encontre os itens:

E N G E N H A R I A D E S O F T W A R E 3 4

TTÉÉCCNNIICCAASS PPAARRAA EELLIICCIITTAAÇÇÃÃOO DDEE RREEQQUUIISSIITTOOSS

Não existe maneira única de especificar os requisitos.

A identificação e elicitação de requisitos é uma tarefa que parece simples, mas, não devemos nos enganar, às vezes, para obtermos

algumas informações é exigida muita dedicação, persistência e técnica. Esta parte apresenta e discute as principais técnicas para identificação

e elicitação de requisitos de software. Cenários: representar tarefas que executam e as que desejam

executar; Técnicas tradicionais: questionários, entrevistas, análise de

documentação existente; Técnicas de elicitação de grupo: Dinâmica de grupo;

Prototipação: quando existe alto grau de incerteza e necessita de

um rápido feedback.

Tipos de Técnicas

Existem várias técnicas para a elicitação de requisitos, todas elas

possuem seus próprios conceitos, vantagens e desvantagens. Dentre

elas, destacam-se (KENDALL; KENDALL, 2010; KOTONYA; SOMMERVILLE, 1998; AURUM; WOHLIN, 2005):

WORKSHOP DE REQUISITOS: idealizado para encorajar o consenso acerca dos requisitos da aplicação e acerca das ações

a serem tomadas em um curto intervalo de tempo. Formato: reunião intensiva (máximo 2 dias) com pessoas chaves visando

criar ou revisar as principais funcionalidade do sistema em desenvolvimento, com a participação de um mediador;

QUESTIONÁRIOS: o uso de questionários possibilita ao analista obter informações como postura, crenças,

comportamentos e características de várias pessoas que serão

afetas pelo sistema; Quem são os usuários (ou perfis de usuário)? Quem é o cliente? Eles têm necessidades diferentes em relação ao sistema? Onde mais pode ser encontrada uma solução para este problema? Estas questões nos forçam a ouvir antes de sair propondo uma solução para o problema.

OBSERVAÇÃO: consiste em observar o comportamento e o

ambiente dos indivíduos de vários níveis organizacionais. Utilizando-se essa técnica, é possível capturar o que realmente

é feito e qual tipo de suporte computacional é realmente necessário. Ajuda a confirmar ou refutar informações obtidas

com outras técnicas e ajuda a identificar tarefas que podem ser automatizadas e que não foram identificadas pelos

interessados;

E N G E N H A R I A D E S O F T W A R E 3 5

ANÁLISE DE DOCUMENTAÇÃO: pela análise de documentos existentes na organização, analistas capturam informações e

detalhes difíceis de conseguir por entrevista e observação. Documentos revelam um histórico da organização e sua

direção. CENÁRIOS: com o uso desta técnica, um cenário de interação

entre o usuário final e o sistema é montado e o usuário simula sua interação com o sistema nesse cenário, explicando ao

analista o que ele está fazendo e de que informações ele

precisa para realizar a tarefa descrita no cenário. O uso de cenários ajuda a entender requisitos, a expor o leque de

possíveis interações e a revelar facilidades requeridas; PROTOTIPAGEM (PROTOTIPAÇÃO): um protótipo é uma

versão preliminar do sistema, muitas vezes não operacional e descartável, que é apresentada ao usuário para capturar

informações específicas sobre seus requisitos de informação, observar reações iniciais e obter sugestões, inovações e

informações para estabelecer prioridades e redirecionar planos; VANTAGENS:

o permitem aos clientes e usuários do sistema experimentar o sistema;

o entendendo melhor como o sistema pode ser usado para dar suporte aos seus trabalhos;

o mal-entendidos entre projetistas e usuários podem ser

identificados quando a funcionalidade do sistema é demonstrada usando o protótipo;

o funções que estão faltando podem ser detectadas usando o protótipo;

o durante o desenvolvimento de um protótipo, requisitos incompletos e inconsistentes são descobertos.

DESVANTAGENS: o custo do desenvolvimento de um protótipo;

o tempo requerido para desenvolver um protótipo (que pode aumentar o tempo de entrega ao usuário);

o o uso de um protótipo pode induzir os usuários a prestarem mais atenção na interface com o usuário do

que nos requisitos da aplicação; o os usuários podem tornar-se familiares com uma

interface com o usuário antes da versão final do sistema

estar desenvolvida. LINGUAGEM NATURAL: na maioria das organizações, os

requisitos são escritos como parágrafos de linguagem natural, adicionados por diagramas e equações.

o Vantagem: Linguagem natural é a única notação que é geralmente entendível por todos os leitores potenciais dos

requisitos. o Desvantagem: Os requisitos em linguagem natural podem

ser ambíguos, pouco claros e causar mal entendidos.

E N G E N H A R I A D E S O F T W A R E 3 6

o Exemplo: Casos de Uso e Lista de Características (sentenças).

DINÂMICAS DE GRUPO: há várias técnicas de levantamento

de requisitos que procuram explorar dinâmicas de grupo para a descoberta e o desenvolvimento de requisitos, tais como:

brainstorming, brainswriting e JAD.

ETNOGRAFIA

Técnica de observação que pode ser utilizada para compreender os

requisitos sociais e organizacionais, ou seja, entender a política organizacional bem como a cultura de trabalho com objetivo de

familiarizar-se com o sistema e sua história. Os cientistas sociais e antropólogos usam técnicas de observação para desenvolver um

entendimento completo e detalhado de culturas particulares.

Nesta técnica, o analista se insere no ambiente de trabalho em que o sistema será utilizado. O trabalho diário é observado e são anotadas as

tarefas reais em que o sistema será utilizado. O principal objetivo da etnografia é que ela ajuda a descobrir requisitos de sistema implícitos,

que refletem os processos reais, em vez de os processos formais, onde as pessoas estão envolvidas.

Etnografia é particularmente eficaz na descoberta de dois tipos de requisitos:

1. Os requisitos derivados da maneira como as pessoas realmente trabalham, em vez da maneira pelas quais as definições de processo

dizem como elas deveriam trabalhar; 2. Os requisitos derivados da cooperação e conscientização das

atividades de outras pessoas. Alguns itens importantes que devem ser executados antes, durante e

depois do estudo de observação:

Antes, é necessário identificar as áreas de usuário a serem observadas; obter a aprovação das gerências apropriadas para

executar as observações; obter os nomes e funções das pessoas chave que estão envolvidas no estudo de observação; e explicar

a finalidade do estudo; Durante, é necessário familiarizar-se com o local de trabalho

que está sendo observado. Para isso é preciso observar os agrupamentos organizacionais atuais; as facilidades manuais e

automatizadas; coletar amostras de documentos e procedimentos escritos que são usados em cada processo

específico que está sendo observado; e acumular informações estatísticas a respeito das tarefas, como: frequência que

ocorrem, estimativas de volumes, tempo de duração para cada pessoa que está sendo observada. Além de observar as

operações normais de negócios acima é importante observar as

exceções;

E N G E N H A R I A D E S O F T W A R E 3 7

Depois, é necessário documentar as descobertas resultantes das observações feitas. Para consolidar o resultado é preciso rever

os resultados com as pessoas observadas e/ou com seus superiores.

A análise de observação tem algumas desvantagens como, consumir bastante tempo e o analista ser induzido a erros em suas observações.

Mas em geral a técnica de observação é muito útil e frequentemente usada para complementar descobertas obtidas por outras técnicas.

ENTREVISTAS

Técnica amplamente utilizada, que consiste em conversas direcionadas com um propósito específico e com formato ―pergunta-

resposta‖. Seu objetivo é descobrir problemas a serem tratados, levantar procedimentos importantes e saber a opinião e as expectativas do

entrevistado sobre o sistema. Deve ser bem planejada e preparada cuidadosamente para saber quem foi entrevistado, definir os objetivos da

entrevista, preparar antecipadamente as questões que serão formuladas (ou parte delas).

Etapas

Apresentar-se;

Repassar a agenda (objetivos, patrocinador, motivo da escolha do entrevistado);

Postura do entrevistador: credibilidade, isenção, discrição; não criar ressentimentos;

Deixar o entrevistado falar (redução da interferência); Direcionar a discussão para os objetivos;

Evitar perguntas fechadas;

Não ultrapassar o tempo; Notar sinais de impaciência.

Forma de Entrevistar

Relacione a parte da entrevista c/ partes do sistema;

Obtenha pontos de vista alternativos; Solicite detalhes do item que você estiver interessado;

Estabeleça a dependência do assunto com outros; Confirme os dados obtidos;

Focalize os requisitos (não os problemas técnicos); Não confunda sintomas com o problema.

Perguntas que devem ser respondidas

Quem são o cliente e o usuário?

Possuem necessidades diferentes? Quais são suas: Capacidades, Backgrounds, Ambientes, etc.

Qual é o problema?

E N G E N H A R I A D E S O F T W A R E 3 8

Como é resolvido atualmente? Qual a razão para resolvê-lo?

Qual o valor de uma solução bem-sucedida? Onde mais uma solução pode ser encontrada?

BRAINSTORMING

Representantes de diferentes grupos de interessados engajam-se em uma discussão informal para rapidamente gerarem o maior número

possível de ideias focadas em um objetivo claro e pré-definido. Regras devem ser seguidas em uma sessão de Brainstorm:

• Não permitir críticas ou debate; • Deixar a imaginação voar;

• Gerar tantas ideias quanto for possível; • Mudar e combinar ideias;

• Sessão consiste em duas fases: GERAÇÃO DE IDEIAS e

CONSOLIDAÇÃO; • Processo relativamente não estruturado que pode ou não

produzir a mesma qualidade ou nível de detalhe de outros processos.

TECNICAS PARA CONDUZIR

Inicie a sessão divulgando CLARAMENTE os objetivos;

Certifique-se que cada participante compreendeu exatamente os objetivos (obter feedback);

Convide ―escriba‖ para anotar cada ideia no flip-chart; Anote com clareza e precisão – evite ―telegrafar‖;

Não deixe que se percam as ideias – havendo várias ideias simultâneas, peça que cada um anote as suas ideias numa folha

para depois passá-las para o flip-chart.

Incentive a participação de todos; Evite que ideias sejam discutidas, seja qual for o pretexto;

Não tente esmiuçar, detalhar ou entender uma ideia; Não permita que hajam justificativas para uma ideia;

A sessão deve durar entre 15 e 60 minutos; O clima deve ser descontraído, mas não é CIRCO!

Após uma sessão de Brainstorming as pessoas PRECISAM relaxar! Após a sessão de brainstorming, deve haver um estudo de

viabilidade e adequação para cada ideia (organizar as ideias).

BALDE DE ÁGUA GELADA

Isso não é possível... Não temos tempo para...

Tudo isso já foi tentado...

No momento não estamos em condições...

E N G E N H A R I A D E S O F T W A R E 3 9

Na prática as coisas são diferentes... Se isso fosse útil, alguém já teria tido a ideia...

Isso é muito antiquado... Isso é moderno demais...

Vamos voltar a conversar no início do próximo ano... Já temos muitos projetos...

Você sabe que isso não funciona... Vamos nomear uma comissão para cuidar disso...

Não temos nada com isso...

Não é problema do nosso departamento... Vamos esperar os acontecimentos...

Melhor seria pensarmos um pouco mais... Outra vez você com essas suas ideias...

Se você acha que no nosso País isso vai funcionar... Isso é contra o regulamento...

Parece bom, mas... duvido que funcione... Isso só vai dar mais trabalho prá gente ...

Acho que alguém vai ficar furioso quando souber disso...

Exemplos:

1) Contexto: automação de iluminação. Aspecto surgido no brainstorming: Configuração de iluminação

automática.

Sentença descritiva: O dono de casa deve poder definir uma programação da iluminação da casa baseado nos horários do dia.

2) Contexto: Sistema de entrada de ordens de venda.

Aspecto surgido no brainstorming: Rapidez. Sentença descritiva: O tempo de resposta deve ser suficientemente

bom para não interferir na realização das ações do processo de venda.

3) Contexto: Sistema de rastreamento de falhas. Aspecto surgido no brainstorming: Notificação automática.

Sentença descritiva: Todos os grupos cadastrados devem ser notificados por email quando houver alguma modificação no processo

de fabricação.

BRAINSWRITING

Dividir os participantes em grupos de 4 ou 5 pessoas. Os grupos recebem uma questão.

O trabalho: - Escrever a sua opinião sobre a questão;

- Ao terminar, colocar a folha no centro da mesa; - Pegar a folha de respostas de outro integrante do grupo;

- Criticar as colocações encontradas;

E N G E N H A R I A D E S O F T W A R E 4 0

- Criticar todos os trabalhos do grupo, por escrito; - Completado o ciclo, o grupo pode receber nova pergunta;

- Os presentes criticam todas as posições dos grupos. Observações:

- Pode haver um relator por grupo; - Cada grupo pode receber uma questão diferente.

- Exige um relator do trabalho final.

EXERCÍCIOS

1. Vamos conduzir uma entrevista: em dupla fazer uma entrevista a

respeito de um sistema de controle de tarefas. Estas tarefas são semanais, feitas de forma individual com notas entre 1,0 e 10,0

pontos.

2. Baseado na técnica BRAINWRITING em grupo de cinco pessoas,

discutir sobre o assunto: COMO RESOLVER O PROBLEMA DE QUALIDADE DO SERVIÇO NA EDUCAÇÃO.

E N G E N H A R I A D E S O F T W A R E 4 1

JJAADD

Tradicionalmente, JAD tem sido um método utilizado por profissionais

de processamento de dados e usuários para definição de requisitos de sistemas. Por isto o nome JAD – Joint Application Design (ou

Development). Atualmente, o JAD tem sido um método utilizado por todos que desejam trabalhar em projetos, sejam da área de informática ou não,

ou que queiram tomar decisões que afetem múltiplas áreas da organização. O conceito de JAD surgiu na IBM em 1977, e entrou no Brasil

na década de 80, mas só começou a ser utilizado efetivamente, após alguns nomes de ―peso‖ na análise de sistemas avalizarem tal

metodologia. Técnica que reúne determinado número de pessoas em sessões bem estruturadas para, com tempo e esforço reduzidos,

consolidar um objetivo pré-determinado.

Figura 13 – JAD

ETAPAS PARA PREPARAR UMA REUNIÃO JAD

Figura 14 – Etapas para preparação do JAD

E N G E N H A R I A D E S O F T W A R E 4 2

PREPARAÇÃO

- OBJETIVOS

Garantir a escolha dos participantes apropriados;

Garantir que a Agenda seja preparada de forma adequada; Garantir o acordo do Grupo quanto aos objetivos e produtos a serem

obtidos;

Garantir que todo o material necessário tenha sido providenciado.

- ETAPAS

1. Examinar, se a utilização do JAD é adequada;

2. Planejar as Sessões (quantas, de que tipo, quando...); 3. Elaborar a Perspectiva Gerencial (ideia clara do projeto e da sessão,

obtidas do Patrocinador do projeto – finalidade, escopo, objetivos e

restrições); 4. Familiarizar-se com as áreas de negócio sob estudo (glossário,

entrevistas preliminares bem curtas,...); 5. Preparar a Agenda da Sessão (roteiro de passos a serem seguidos);

6. Preparar os participantes (métodos e abordagem da sessão, informações a providenciar previamente, resultados de sessões

anteriores); 7. Preparar a Agenda Detalhada (desdobramento do roteiro da sessão

com duração prevista para cada item, lembretes, dicas, ...); 8. Preparar as ferramentas para documentação (ex.: Metodologia p/

Mapeamento de Processos e ARIS da IDS SCHEER, Questionários e Formulários).

Figura 15 – Responsabilidades na etapa de Preparação do JAD

E N G E N H A R I A D E S O F T W A R E 4 3

- AGENDA

Identificar a finalidade e os objetivos da reunião (Sessão);

Identificar os produtos (resultados esperados); Identificar as informações conhecidas;

Esboçar as etapas da agenda; Verificar se etapas são logicamente coerentes;

Identificar os participantes prováveis; Identificar as etapas que os participantes não têm condição de realizar

na sessão; Identificar que informações devem ser providenciadas antes da sessão,

para viabilizar o item 7; Rever: esboço satisfaz os itens 1 e 2 ?

Refinar o trabalho, incluindo a documentação necessária.

CRITÉRIOS PARA A ESCOLHA DOS PARTICIPANTES: • Possui conhecimento e capacidade analítica em relação ao assunto;

• Tem habilidade na resolução de divergências e sabe resolver suas

diferenças em confrontos de ideias e pontos de vista; • Pode ser afetado pelas decisões tomadas, tendo a oportunidade de

compartilhar suas expectativas com o grupo; • Concorda de antemão com as regras de solução de conflitos e de

tomada de decisão determinadas pelo grupo; • Tem disponibilidade para participar com criatividade e eficácia;

EXEMPLO DE CARTA CON VITE

PARA: Ver Lista de Distribuição Rio de Janeiro, 21 de Maio de

2002

DE: Yyyyyy – Patrocinador do projeto – Cargo

REF.: Projeto XPTO – Sessão de Trabalho

Foi selecionado para participar da Sessão de Mapeamento de Processos do

projeto XPTO.

Esta Sessão integra o método JAD, já apresentado, que vem sendo utilizado

com sucesso por grandes empresas. O seu tempo será mais produtivo do que se

você participasse de entrevistas individuais.

Você foi selecionado pela sua habilidade, relação com o assunto e

capacidade de contribuir com ideias criativas e indispensáveis à produção de um

trabalho de alto nível. Você terá meu completo apoio e suporte.

A Sessão terá a duração de três dias, de 27/05/2002 até 29/05/2002, com

realização na parte da manhã de cada dia, das 9:00h às 13:00h, na Sala Nºxxx do

SENAI Artes Gráficas, localizado na Rua São Francisco Xavier Nº xx, bairro da Tijuca.

Veja em anexo, a agenda de convocação detalhando a Finalidade,

Objetivos, Escopo (Tópicos), Líder da Sessão, Participantes, Documentos a Levar e

Informações Necessárias, Restrições e Eventuais Observações.

Quaisquer dúvidas deverão ser imediatamente encaminhadas ao Sr.

Xxxxxx,.

Grato pela sua cooperação,

Yyyyyy – Patrocinador do Projeto XPTO.

E N G E N H A R I A D E S O F T W A R E 4 4

MODELO DE AGENDA DE CONVOCAÇÃO:

Figura 16 – Modelo de Agenda

TOPICOS PARA A AGEND A PADRÃO

Introdução: Breve revisão do método JAD (só se não for conhecido);

Horários, intervalos, facilidades, etc.;

Apresentação dos participantes; Apresentação da agenda, esclarecendo o que será tratado em

cada etapa.

Revisão da Perspectiva Gerencial: Definições estabelecidas p/ o projeto pelo Patrocinador;

Abertura pelo Patrocinador (só para 1ª sessão):

Discurso de 5 min. mostrando a importância do projeto no contexto do negócio, o que se espera alcançar e porque aquela

equipe foi escolhida.

Visão da Área de Informática: Rápida posição do Engenheiro de Software sobre o andamento

dos trabalhos, próximas etapas e informações tecnológicas de

interesse.

Regras de Conduta: Código de cooperação estabelecido pelo Facilitador com o Grupo,

para maior produtividade da sessão.

E N G E N H A R I A D E S O F T W A R E 4 5

Abordagem da Sessão: Roteiro passo a passo das etapas específicas (dirigidas aos

produtos metodológicos) para se alcançar os objetivos da sessão.

Revisão das Pendências: Atualização do Controle de Pendências documentando o item,

data de registro, situação, responsável pela solução, data de término prevista.

Revisão Geral: Revisão do material produzido na sessão, verificando se está

coeso e de acordo com o que estava previsto.

Avaliação e Encerramento da Sessão: Avaliação dos participantes sobre o método usado e o

desempenho do líder, para melhoria contínua.

DEVERES DAS PESSOAS CONVOCADAS PARA O JA D

Avaliar a agenda divulgada; Reunir informações e arquivos;

Convocar subordinados para esclarecimentos; Preparar-se para contribuir efetivamente durante a realização

da reunião; Estar certo de que compreendeu os objetivos e tópicos,

questionando-se: Onde posso contribuir melhor?

O que não entendo e não me compete? (Devo silenciar nestas horas)

O que gostaria de alcançar e o que me satisfaz se for alcançado? Que elementos devo levar para a reunião?

Preciso realizar contatos prévios? Usarei recursos audiovisuais? A sala suporta sua utilização?

O que preciso alterar na minha agenda, em função da reunião?

ATIVIDADES A SEREM R EALIZADAS NO DIA ANTERIOR A SESSÃO

Providenciar todo o material necessário: Transparências; Folhas de flip-chart; Projetor; Tela; Canetas para quadro; Material a ser

projetado e/ou transparências; Fita colante; Pastas do Projeto JAD para os participantes, etc.

Revisar a Agenda Detalhada (aquela que contém o script a ser

seguido pelo facilitador). Posicionar os documentadores quanto aos pontos em que são

esperadas as suas participações, através de reunião em que lhes é disponibilizada uma cópia da Agenda Detalhada.

Providenciar equipamentos dos documentadores: Micros com os softwares necessários instalados, Impressoras, Questionários,

Checklists, Formulários, etc.

E N G E N H A R I A D E S O F T W A R E 4 6

Arrumar a sala de reunião. Montar e testar equipamentos.

Figura 17 – Layout da sala de reunião de JAD

SESSÃO

OBJETIVOS

Realizar reunião com os participantes definidos na fase de

Preparação; Produzir as informações necessárias para obtenção dos resultados

previstos na fase de Preparação; Buscar a criação de sinergia do Grupo no desenvolvimento de ideias

e conceitos;

Obter consenso quanto aos resultados.

ETAPAS

Preparação do Ambiente (condições adequadas, arrumação das

mesas, equipamentos, material necessário, auxílios visuais, pastas dos participantes) no dia anterior ao da realização da sessão;

Condução da Sessão (conforme Agenda Detalhada); Documentação (providenciar ferramentas – formulários, micro,

software, impressora,...; observar passos da Agenda Detalhada;

documentar decisões; documentar detalhes; ler o que já foi documentado; gerar a documentação do dia para os participantes);

E N G E N H A R I A D E S O F T W A R E 4 7

Encerramento da Sessão (verificar atendimento de todos os itens, avaliar a sessão, entregar a documentação produzida, apresentar os

resultados da última sessão);

Figura 18 – Responsabilidades da etapa Sessão de JAD

TÉCNICAS PARA APOIAR A SESSÃO

Figura 19 – Técnicas de Apoio

Passo 1: Definir o problema e despersonalizá-lo, escrevendo-o no

quadro ou no chart, para que se torne problema do grupo; Passo 2: Fazer o grupo gerar possíveis soluções;

E N G E N H A R I A D E S O F T W A R E 4 8

Passo 3: Avaliar as soluções com o grupo, através de critérios estabelecidos, evitando que alguém se considere dono de alguma

delas; Passo 4: Fazer o grupo decidir sobre a mais adequada;

Passo 5: Fazer o grupo determinar o método de implementação da solução escolhida, se necessário;

Passo 6: Se problema não desapareceu, colocá-lo na Lista de Pendências.

AVALIAÇÃO DA SESSÃO

E N G E N H A R I A D E S O F T W A R E 4 9

E N G E N H A R I A D E S O F T W A R E 5 0

Figura 20 – Relatório de Avaliação de Sessão

AVALIAÇÃO DE ACORDO COM O TOTAL OBT IDO

Após Preenchidos Todos os Itens da Avaliação, Some Todos os Graus e Obtenha o Total Geral:

Entre 0 e 7 significa que suas reuniões estão boas; De 8 a 14 suas reuniões podem ser melhoradas;

De 15 a 22 suas reuniões começam a preocupar;

De 23 em diante, suas reuniões andam MAL, muito há que ser feito para que alcancem o nível ideal.

É fundamental que cada um também se inclua como causador dos problemas e disfunções da lista de verificação. Não se deve julgar

somente os outros, mas principalmente nós mesmos.

E N G E N H A R I A D E S O F T W A R E 5 1

ANALISADOR DA REUNIÃ O PARA TODOS OS PART ICIPANTES

Figura 21 – Modelo de análise da reunião

REVISÃO

Rever a documentação produzida na sessão; Examinar possíveis melhorias na sistemática adotada.

ETAPAS

Rever a Documentação (verificar informações incompletas, corrigir

falhas de comunicação entre facilitador e documentadores, sumarizar os resultados, encaminhar versão definitiva da

documentação para os participantes); Examinar Avaliações (visa processo permanente de

aperfeiçoamento; efetua tabulação e análise comparativa entre as sessões);

Preparar a Pasta do Projeto JAD contendo: o Perspectiva Gerencial;

o Plano de Sessões; o Carta-convite para participação do grupo;

o Agenda de cada sessão;

o Lista de Participantes de cada sessão; o Documentação produzida em cada sessão;

o Questionários de Avaliação.

E N G E N H A R I A D E S O F T W A R E 5 2

Figura 22 – Responsabilidades na etapa de Revisão do JAD

Ao final da revisão deve ser preparado um resumo do que foi

produzido na sessão, para ser apresentado ao Patrocinador do projeto.

PAPEIS DE CADA UM DENTRO DA REUNIÃO Há dois grupos de participantes:

O CLIENTE (PATROCINADOR)

Detém autoridade formal sobre as áreas de negócios afetadas pelo

sistema. O cliente estabelece as diretrizes e objetivos do projeto. É responsável pela abertura da primeira sessão de trabalho, na qual o grupo

terá oportunidade de sentir o real interesse da administração superior pelo sucesso do projeto e em dar o seu apoio.

ENGENHEIRO DE SOFTWARE

É o responsável pelo sucesso ou fracasso do projeto;

Participa do JAD na condição de membro da equipe; É o principal contato do Líder da Sessão;

Familiariza o Líder da Sessão com o projeto e com a equipe

envolvida.

E N G E N H A R I A D E S O F T W A R E 5 3

EQUIPE

São os responsáveis pelo conteúdo da sessão. Representam as áreas

envolvidas no projeto, incluindo a de informática. Os participantes são escolhidos entre as pessoas-chave das áreas de negócio, seja no nível

operacional ou não. O importante é que, na sessão, não há distinção hierárquica, todos são iguais.

OBSERVADOR

Interessado no projeto especificamente ou em conhecer a

sistemática utilizada; Não é um participante não podendo, por isso, opinar durante a

sessão.

DOCUMENTADOR

É o responsável pelo registro das decisões e especificações produzidas;

No caso Xerox, ele é também um membro de equipe; Segue orientação do Líder da Sessão no que respeita aquilo que é

considerado relevante para ser documentado.

LÍDER DE SESSÃO OU FACILITADOR

É o responsável pela condução da reunião. Deve ser um guia do grupo. O seu trabalho é conduzir os participantes ao longo da agenda,

garantindo que todos são ouvidos e que há consenso em torno das decisões tomadas. Deve ser um facilitador.

PERFIL DO LÍDER

Pessoa com facilidade de comunicação;

Capacidade de síntese; Facilidade para resumir, esclarecer e sumarizar ideias e conceitos,

inclusive escolhendo as frases mais apropriadas que reflitam os argumentos/ideias apresentados pelos participantes;

Falar claramente, precisamente; Falar pausadamente e sem bairrismos;

Capacidade de dirigir discussões para o ponto objetivo;

Evitar dispersões em considerações não relevantes; Evitar diálogos paralelos;

Controlar o horário de início e fim dos trabalhos; Controlar e informar passo a passo as etapas da agenda;

Separe as ideias das pessoas; Mostre um interesse natural;

Ouça bem, inclusive com os ―olhos‖; Mantenha os papéis claramente definidos;

Não confundir os participantes com jargões da área de sistemas.

E N G E N H A R I A D E S O F T W A R E 5 4

DICAS PARA SER UM BOM LÍDER

Não se irrite;

Não se ofenda; Não brigue;

Não monopolize; Não seja o dono da verdade;

Não faça o tipo ―sabido‖ Não leve tudo na brincadeira;

Não ignore algum participante; Não permita ―uma dupla em debate‖.

DOCUMENTADOR OU ESCR IBA

É um auxiliar do líder de sessão. É responsável pelo registro das

decisões e especificações produzidas. Apenas as informações relevantes são documentadas, segundo

orientação do líder de sessão.

OBSERVADORES

São interessados em conhecer a sistemática utilizada ou interessados no projeto especificamente. Os observadores não são participantes,

portanto, não estão autorizados a opinar durante a sessão.

FIGURINHAS DIFÍCIEIS NA REUNIÃO

O ATRASADINHO

Sempre chega atrasado às reuniões; Dá seu ―show‖ na chegada;

Insiste em interromper a sequência de argumentação do grupo. Sempre que alguém chegar atrasado, evidencie sutilmente, através

do cumprimento. Convide-o a olhar a ―memória do grupo‖ e não faça uma revisão. Isso seria punir os que chegaram na hora.

O QUE SAI MAIS CEDO

Abala a energia e a moral do grupo saindo da reunião antes de seu

término. Na primeira oportunidade, procure saber o motivo do padrão de

comportamento. Sugira, ao agendar a próxima reunião, que todos optem por um horário em que poderão estar integralmente.

O DISCO QUEBRADO

Joga areia em todas as ideias;

Supercético e crítico; Sempre esfriando o entusiasmo do grupo, dizendo algo do tipo ―isso

nunca vai funcionar‖.

E N G E N H A R I A D E S O F T W A R E 5 5

Evidenciar para o grupo os pontos que o cético não concorda, buscando obter consenso do grupo.

O MENEADOR

Expressa discordância ativamente via linguagem corporal e tiques

não-verbais, tais como: Revirar os olhos, balançar a cabeça, cruzar e descruzar os braços,

etc; Indiretamente influencia o grupo a rejeitar uma ideia, uma reunião,

etc. Procure interpelá-lo, questionando se ele discorda de alguma

coisa, ou se gostaria de enriquecer o que foi dito.

O COCHICHADOR

Vive cochichando durante as reuniões, mantendo conversas paralelas;

Coloca o líder da sessão, assim como os membros do grupo, em segundo plano.

Neste caso, só intervir quando houver absoluta certeza de que os cochichos estão sendo negativos para a reunião. Algumas vezes, basta

aproximar-se dos cochichadores para que a conversa diminua.

O DESINTERESSADO

Senta afastado da mesa ou no fundo da sala; Expressa desaprovação ou desinteresse, ignorando os

procedimentos; Pode cochilar, ler alguma coisa, ficar rabiscando papéis, para evitar

qualquer tipo de engajamento na sessão. Uma boa estratégia é envolver o desinteressado em alguma atividade

de apoio.

O AGRESSIVO

Dispara ataques verbais e pessoais contra outros membros do grupo e/ou contra o líder da sessão;

Constantemente ridiculariza um determinado ponto de vista ou posição de outra pessoa.

Relembre as regras do grupo, lembrando que devemos respeitar as opiniões alheias. Quando estas medidas não forem suficientes, colocar no

quadro a essência das discordâncias e iniciar o procedimento de obtenção de consenso.

O REI DA VOZ

Fala muito e excessivamente alto;

Domina a discussão; Aparentemente impossível fazê-lo calar;

E N G E N H A R I A D E S O F T W A R E 5 6

Pode ser alguém de nível hierárquico acima dos demais membros, o que o torna ainda mais inabalável.

Procurar aproximar-se da pessoa, ou sugerir que faça anotações individuais.

O INTÉRPRETE

Sempre fala por outra pessoa, normalmente sem ser solicitado;

Recoloca as ideias alheias, frequentemente distorcendo-as durante a sua explanação.

Confirme com o dono da ideia se ela foi recolocada pelo intérprete com fidelidade.

O FOFOQUEIRO

Traz boatos ou rumores para a reunião;

Tenta ampliar seu poder, dando a impressão que tem ―informações de cocheira‖;

Leva o grupo a debater ou argumentar baseado na veracidade daquelas informações.

Sempre que as assertivas forem do tipo ―ouvi dizer‖, ―Acho que tem uma circular‖, o líder da sessão deve tentar esclarecer: ―quem disse

isso?‖, ―Qual é mesmo a circular?‖.

O "MÓVEIS E UTENSÍLI OS"

Usa credenciais, idade, tempo de casa, etc, no debate de uma questão;

Focaliza a atenção do grupo em aspectos circunstanciais, ao invés de explorar o verdadeiro assunto.

Acolher as observações e relembrar que o objetivo do projeto é ampliar a visão do problema e ter a aceitação do grupo. Essas são

pessoas do tipo que é muito resistente a mudanças.

O LÍDER FRUSTRADO

Vive dizendo ao líder da sessão o que fazer ou o que não fazer; Tenta controlar a reunião, diminuindo os esforços do líder.

Acate as sugestões que não alterem a estrutura de sua agenda, e as que interferirem, agradeça a colaboração e mostre seu ponto de vista.

O OCUPADO

Sempre entrando e saindo das reuniões com papéis e pastas

debaixo dos braços; Permite que seja chamado com frequência por outras pessoas;

Tenta dar a impressão de muito ocupado para dar atenção integral à reunião e ao grupo.

Pedir ao próprio ocupado que sugira o que fazer para não haver interrupções (sugira outros horários de reunião, anotar recados...)

E N G E N H A R I A D E S O F T W A R E 5 7

O MAL-EDUCADO

Entra no meio das discussões, interrompendo os comentários de

alguém; Demonstra impaciência;

Fica insatisfeito quando suas próprias ideias não são bem recebidas. O grupo sempre espera, neste caso, a intervenção do líder da sessão.

Sugira que ele espere os colegas completar o raciocínio antes de contestá-los.

O CARENTE

Gasta mais tempo e energia preocupado em obter aprovação do

líder da sessão do que com o conteúdo da reunião. Quando este estiver iniciando alguma colocação olhando diretamente

para você, você deve indicar que ele deve se dirigir ao grupo.

TAREFA 04 – TECNICA JAD (1,0)

Em grupo de cinco pessoas, identifi que um papel para cada componente, resolva o estudo de caso abaixo:

Controle de Estoque de uma Rede de Supermercados O sistema de controle de estoque de uma rede de supermercados mantém na base de dados a descrição de todas as informações que permitem a manutenção

de seu estoque de mercadorias. O controle é efetuado para cada ponto de venda da rede, mas centralizado em uma única base de dados, que efetua os pedidos

de compra para todos os pontos de venda ao mesmo tempo. Quando um novo produto deve ser comprado, é emitida uma ordem de compra com a quantidade total comprada, indicando também a quantidade do produto que deve ser

entregue em cada ponto de venda. Um pedido de compra pode incluir também mais do que um produto comprado do mesmo fornecedor. Para que esse sistema

possa funcionar, o sistema de controle de estoque mantém três informações fundamentais: o estoque de cada produto existente em cada ponto de venda da

rede, as informações sobre os fornecedores e as informações sobre os pedidos em andamento. O estoque consiste na descrição de cada produto, incluindo a maneira como ele é medido (por volume, unidade, peso, etc.), como é embalado

e número de embalagens disponíveis em cada armazém. Mantêm-se também os dados sobre os preços de compra e venda, e taxa esperada e medida de venda

por mês. Como essas informações são tratadas de maneira centralizada, elas são atualizadas em lotes por meio da comunicação de cada ponto de venda com a central, e não para cada produto vendido em caixa. Sobre os fornecedores são

registrados dados gerais como identificadores, endereços, pontos de distribuição, etc., e também a relação de produtos disponíveis e prazos de entrega. Todos os

pedidos são mantidos num histórico, onde as várias atividades correspondentes são registradas, além de datas, valores e produtos envolvidos. As atividades de um pedido são: emissão do pedido de compra, entregas em cada ponto de venda

e pagamentos efetuados. Estas atividades podem assumir status de parciais ou totais, além de confirmação ou não do aceite o pedido e seu respectivo

encerramento. Note que em pedido pode constar de mais de um produto e, nesse caso, cada produto dever ser tratado separadamente.

E N G E N H A R I A D E S O F T W A R E 5 8

EESSPPEECCIIFFIICCAAÇÇÃÃOO DDEE RREEQQUUIISSIITTOOSS

No documento da especificação de requisitos descrevemos os

requisitos funcionais (obrigatórios) e requisitos não-funcionais (opcionais). Obs. Há um outro exemplo de especificação de requisitos

no Anexo A.

MODELO DE ESPECIFICAÇÃO DE REQUISITOS

Figura 23 – Modelo de especificação de requisitos

Onde: Caso de Uso: nome do caso de uso;

Objetivo: breve descrição do caso de uso; Atores: envolvidos naquele caso de uso;

Condição de início: o que dispara a funcionalidade no contexto do sistema;

Fluxo Principal: interação entre sistema e ator para que o objetivo

seja atingido; Fluxo alternativo: apoio do fluxo principal para que seja possível

atingir os objetivos secundários. Regras de negócio: restrições nas funcionalidades.

PASSOS PARA ESPECIFICAR OS REQUISITOS

1. Identifique quais os REQUISITOS e relacione com os CASOS DE

USO; 2. Identifique também os ATORES e seus respectivos PAPÉIS;

3. Dê um nome para o CASO DE USO, lembre-se que este nome deve ser único no modelo;

4. Escreva os CENÁRIOS para o CASO DE USO; 5. Compile os CENÁRIOS em único FORMULÁRIO e

6. Faça o Diagrama de Caso de Uso.

E N G E N H A R I A D E S O F T W A R E 5 9

Exemplo: Clientes são pessoas físicas e possuem nome, endereço e telefone:

CASO DE USO: CADASTRAR CLIENTE

OBJETIVO: PERMITIR QUE O FUNCIONARIO INSIRA, EXCLUA, ALTERE OU CONSULTE

CLIENTES NO SISTEMA.

ATOR: FUNCIONARIO

CONDICAO DE INICIO: FUNCIONARIO SELECIONA A OPCAO CADASTRAR CLIENTE

Obs. Deverá ser definido como será após o cadastrar cliente. Como será o diálogo? O

sistema deverá apresentar na tela um conjunto de clientes já cadastrados e no final

apresentar as opções de inserir, excluir ou alterar um cliente selecionado, pois ao

lado de cada nome haverá a opção de seleção para trabalhar com as opções de

excluir ou alterar.

FLUXO PRINCIPAL:

1. O sistema apresenta tela de cadastro de cliente contendo:

- Lista de Clientes cadastrados com as informações para cada cliente:

* Opção de Seleção

* Nome

* Endereço

* Telefone

- Apresenta ao final as opções:

* Incluir novo

* Excluir cliente

* Editar cliente

2. O Funcionário seleciona a opção Incluir novo [A16] [A27]

3. O sistema apresenta a tela de inclusão de novo cliente contendo:

- Nome

- Endereço

- Telefone

- As Opções:

* Salvar

* Cancelar

4. O funcionário informa os dados do cliente e seleciona a opção salvar [A38]

5. O sistema conclui a inclusão do novo cliente

Decidir: retorna a tela principal ou o caso de uso é encerrado?

6. O sistema retorna para a tela inicial.

7. O caso de uso é encerrado. No final de cada fluxo é importante destacar para que

parte ou tela do sistema será desviado e informar que o caso de uso está encerrado.

FLUXO ALTERNATIVO: PODERÃO OU NÃO SER EXECUTADOS

[A1] O funcionário seleciona a opção excluir Cliente.

1. O sistema exclui o cliente selecionado.

2. O sistema retorna ao passo 1 do fluxo principal.

[A2] O funcionário seleciona a opção editar Cliente.

1. O sistema apresenta a tela com as informações do cliente selecionado para

edição:

- Nome

- Endereço

- Telefone

- As opções: * Salvar * Cancelar

2. O funcionário informa os dados do cliente e seleciona a opção salvar. [A4]

3. O sistema atualiza os dados do cliente.

6 Excluir Cliente

7 Editar cliente

8 CANCELAR é fluxo alternativo

E N G E N H A R I A D E S O F T W A R E 6 0

4. O sistema retorna ao passo 1 do fluxo principal.

[A3] O funcionário seleciona a opção Cancelar.

1. O sistema retorna ao passo 1 do fluxo principal.

VISÃO E ESCOPO O documento que deve ser criado deve ter a visão e o escopo do

programa a ser desenvolvido deve apresentar e deixar claro o que será feito. Deve ser focado a no cliente, levantando os requisitos principais

na visão macro, sem detalhamento para que o cliente perceba o que está sendo feito. Os objetivos são levantamentos com reuniões

semanais até fechar pois depois começa o levantamento de requisitos. Nesta visão temos os objetivos principais e as prioridades dele.

Para seguir uma linha de raciocínio que é definido pelo cliente ou representantes deste cliente (stakeholders – envolvidos no projeto).

Para que quando for levantar os requisitos não sair da visão sabendo

que vai ser feito e o que não vai ser feito (documento do escopo), onde só poderá ser feito o que está definido.

Deve ter nível alto de abstração e deverá ter se haverá ou não: manuais, treinamentos e se for um sistema grande deverá ser dividido

em subsistemas e depois poderá ser integrado. A equipe precisa lembrar o processo de usabilidade (caso parar um o outro permanece

funcionando) e também poderá ser reutilizado. O escopo deve conter tudo que o projeto deve fazer. É importante

verificar se todo o escopo está sendo mantido (PLANEJAMENTO, DEFINIÇÃO, VERIFICAÇÃO E CONTROLE DO ESCOPO).

É importante criar uma estrutura analítica do projeto (EAP) onde são definidos os blocos de trabalho para completar o projeto como um

todo.

EXERCÍCIOS

1) ―Funcionários são identificados pelo seu número de matrícula, e devem conter ainda nome, endereço, telefone e dependentes (nome e

data de nascimento), além de estar associado, obrigatoriamente a uma filial.‖

a) Requisito Funcional: CADASTRAR FUNCIONÁRIO

2) ―O sistema deve permitir que o setor de atendimento ao cliente

consulte os clientes cadastrados por nome, cpf, data de nascimento e status (se está em dia ou inadimplente)‖

b) Requisito Funcional: CONSULTAR CLIENTES

3) Ponto de Venda: Um cliente chega no caixa com os itens que deseja comprar. O caixa usa o sistema para registrar cada item. A cada item

comprado, o sistema apresenta o subtotal da compra e os detalhes do item. O cliente entra com informação do pagamento, o qual o sistema

E N G E N H A R I A D E S O F T W A R E 6 1

valida e registra. O sistema atualiza o estoque. O cliente recebe um recibo do sistema e vai embora com os itens.

c) Requisito Funcional: PROCESSAR VENDA

4) Jogo de Banco Imobiliário. Requisito Funcional: JOGAR

TAREFA 05 – ESPECIFICAÇÃO DE REQUISITOS (0,5)

O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos para data.

O cliente informa o período, ou seja, data de chegada e partida, e qual tipo de apartamento ele precisa.

O funcionário do Setor de Reserva verifica a disponibilidade do

apartamento e informa que não tem disponibilidade de apartamento para o período informado pelo cliente e oferece um outro tipo de

apartamento. O cliente não aceita a proposta do funcionário e a reserva não é

confirmada.

E N G E N H A R I A D E S O F T W A R E 6 2

VVEERRIIFFIICCAAÇÇÃÃOO EE VVAALLIIDDAAÇÇÃÃOO DDEE RREEQQUUIISSIITTOOSS

Um software é considerado com qualidade se está em conformidade

com as especificações e padrões de desenvolvimento documentados e que atenda as necessidades dos usuários. Para garantir a qualidade do

software, um conjunto de atividades técnicas devem ser aplicadas durante todo o processo de desenvolvimento. O objetivo é garantir que tanto o

processo de desenvolvimento quanto o produto de software atinjam níveis

de qualidade especificados. A validação e a verificação (VV&T) tem o objetivo de garantir a

qualidade do software, assegurando que este cumpra as suas especificações e atenda às necessidades de seus usuários.

Validação é importante uma vez que o custo para remover um erro de requisitos é grande.

De acordo com o IEEE, define validação e verificação como: VALIDAÇÃO: avalia um sistema ou componente para

determinar se ele satisfaz os requisitos para ele especificados; O software deve atender às necessidades dos usuários.

VERIFICAÇÃO: avalia um sistema ou componente para determinar se os produtos de uma dada atividade de

desenvolvimento satisfazem as condições impostas no início desta atividade. Os artefatos construídos devem estar de acordo com a

especificação do software.

Será que realmente entendi o que o cliente

deseja?

VALIDAR É:

―Estamos construindo

o produto certo???‖

VERIFICAR É:

―Estamos construindo

certo o produto??‖

E N G E N H A R I A D E S O F T W A R E 6 3

Usamos métodos para validar e verificar para:

Resultados de estudos experimentais evidenciam benefícios da utilização destes métodos no desenvolvimento de software;

A utilização destes métodos na indústria têm mostrado resultados positivos considerando PRODUTIVIDADE e QUALIDADE.

Ao inspecionar o software, há um aumento significativo na produtividade, qualidade e estabilidade dos projetos.

Corrigir um defeito após a entrega do produto é 100 vezes mais caro do que corrigi-lo durante as atividades de requisitos e projeto do sistema

(Boehm, Basili, 2001).

TIPOS DE DEFEITO

A maior parte é de origem humana;

São gerados na comunicação e na transformação de informações; Permanecem presentes nos diversos produtos de software produzidos e

liberados; A maioria encontra-se em partes do produto de software raramente

utilizadas e/ou executadas.

A principal causa é a tradução incorreta das informações e quanto antes ser identificada, menor é o custo de correção do defeito e maior a

probabilidade de corrigi-lo corretamente, por isto é sempre importante introduzir atividades de verificação e validação ao longo de todo o

desenvolvimento.

Figura 24 – Tipos de Defeitos

E N G E N H A R I A D E S O F T W A R E 6 4

OMISSÃO

Algum requisito importante relacionado à funcionalidade, ao

desempenho, às restrições de projeto, ao atributo, ou à interface externa não foi incluído;

Não está definida a resposta do software para todas as possíveis situações de entradas de dados;

Faltam seções na especificação de requisitos; Faltam referências de figuras, tabelas e diagramas;

Falta definição de termos e unidades de medidas.

AMBIGUIDADE

Um requisito tem várias intepretações devido a diferentes termos

utilizados para uma mesma característica ou vários significados de um termo para um contexto em particular.

INCONSISTÊNCIA

Dois ou mais requisitos conflitantes.

FATO INCORRETO

Um requisito descreve um fato que não é verdadeiro, considerando as

condições solicitadas para o sistema.

INFORMAÇÃO ESTRANHA

As informações fornecidas no requisito não são necessárias ou mesmo usadas.

DOCUMENTO DE REQUISITOS

Por ser o primeiro artefato tangível a ser produzido pois descreve

todas as características e as funções que o software a ser desenvolvido deve possuir. Atua como um contrato entre o cliente e o desenvolvedor e

é a base para todas as etapas subsequentes do desenvolvimento e normalmente é escrito em linguagem natural.

E N G E N H A R I A D E S O F T W A R E 6 5

DEFEITOS NO DOCUMENTO DE REQUISITOS

Figura 25 – Defeitos no Documento de Requisitos

CONSEQUENCIAS

Estimativas de esforço e prazo deixam de fazer sentido; Desperdício de recursos;

Produto final não atende as necessidades do usuário; Corrigir defeitos após a entrega do produto pode ser até cem vezes

mais caro que corrigi-los nas primeiras fases do desenvolvimento; Em projetos recentes de software, teríamos um esforço de retrabalho

entre 40% a 50% do esforço total.

PEQUENO CHECKLIST DE REQUISITOS

VALIDADE. O sistema fornece as funções que melhor atende as

necessidades do usuário?

CONSISTÊNCIA. Existem conflitos de requisitos?

COMPLETEZA. Todas as funções necessárias para o cliente estão incluídas?

REALISMO. Os requisitos podem ser implementados com a tecnologia e orçamento disponíveis?

FACILIDADE DE VERIFICAÇÃO. Os requisitos podem ser checados?

TÉCNICAS DE VALIDAÇÃO DE REQUISITOS

REVISÃO DE REQUISITOS Análise manual sistemática dos requisitos.

E N G E N H A R I A D E S O F T W A R E 6 6

Revisões regulares devem ocorrer durante a formulação da definição dos requisitos;

Tanto o cliente quanto a equipe contratada devem estar envolvidos nas revisões;

As revisões podem ser formais (com documentos completos) ou informais. Uma boa comunicação entre os desenvolvedores, clientes e

usuários pode resolver problemas em estágios iniciais.

VERIFICAÇÃO DE REVISÕES

VERIFICABILIDADE. O requisito é realisticamente testável?

COMPREENSIBILIDADE. O requisito é propriamente entendido?

RASTREABILIDADE. A origem do requisito é claramente

estabelecida?

ADAPTABILIDADE. O requisito pode ser modificado sem grande

impacto sobre outros requisitos?

REVISÕES DE SOFTWARE

É o processo ou atividade para leitura de um artefato de seu software visando assegurar que ele cumpre sua especificação e atende às

necessidades de seus usuários e ocorre em diferentes momentos do software.

Tem como objetivo validar e verificar os artefatos de software. Pode ser aplicada a qualquer artefato produzido ao longo do processo

de desenvolvimento de software. As revisões podem ser:

PARES (PEER-REVIEWS): aumenta a probabilidade de defeitos a serem encontrados. Utilizam:

o ANÔNIMIDADE: relacionamentos pessoais não afetam a revisão.

o INDEPENDÊNCIA DOS REVISORES EM RELAÇÃO AO ARTEFATO

A SER REVISADO: permite uma avaliação objetiva sem conflitos de interesse.

TIPOS DE REVISÃO DE SOFTWARE

INSPEÇÃO DE SOFTWARE

Os benefícios e custos são:

Inspeções vêm sendo utilizadas há mais de duas décadas; Existe evidência experimental de sua usabilidade e

adequabilidade; Provêem um bom meio para o gerente do projeto monitorar a

qualidade e progresso do projeto;

E N G E N H A R I A D E S O F T W A R E 6 7

Podem amenizar atividades de manutenção, evitando que erros se propaguem pelo ciclo de vida;

Apresentam baixo custo devido ao fato do revisor não precisar investir muito tempo ou mesmo não demandar ferramentas

sofisticadas para realizá-las. Entretanto uma alta taxa de atividades de inspeção ao longo do pr0ocesso pode acrescer de

5% a 10% o custo final.

Figura 26 – Comparativo de Com e Sem Inspeção

PROCESSO DE INSPEÇÃO DE SOFTWARE

Figura 27 – Processo de Inspeção

Composta por PAPEIS E ATIVIDADES

E N G E N H A R I A D E S O F T W A R E 6 8

PAPEIS: atuam ao longo das atividades da inspeção para que no final do processo tenha um documento com os requisitos de software bem

elaborados. - moderador:

- inspetor; - autor do documento.

ATIVIDADES:

- planejamento: efetuado pelo moderador que identificada baseada

nas características do artefato, quem seriam os mais interessados em participar da inspeção e distribuía para as pessoas selecionadas nesta

atividade; - preparação individual: recebiam o material e se preparavam para a

reunião para identificar defeitos. - reunião de inspeção: depois marcava a reunião e durante ela era

feito a leitura critica do documento de requisitos para encontrar os defeitos. No final tinha-se a lista de defeitos que era entregue ao autor

- retrabalho: fazer os reajustes de acordo com o que foi elaborado. - continuação: verifica se precisa ou não passar por outra inspeção.

PROCESSO TRADICIONAL DE INSPEÇÃO

PLANEJAMENTO

Responsável: moderador Tarefas:

- Definir contexto da inspeção: descrição da inspeção, como a preparação individual deverá ocorrer, documento a ser inspecionado,

autor do documento, entre outros. - Selecionar inspetores: recomenda-se utilizar entre 3 e 5 inspetores em

uma inspeção.

- Distribuir material. PREPARAÇÃO INDIVIDUAL

- Responsável: Inspetor - Tarefas: estudar os artefatos e fazer anotações sobre os artefatos.

REUNIÃO DE INSPEÇÃO - Envolvidos: moderador, inspetores e autor

- Tarefas: - Leitura do documento com a equipe discutindo possíveis defeitos

(duração recomendada 2 horas); - Produzir uma lista de defeitos;

- Em casos de discordância a decisão sobre registrar um defeito ou não (falso positivo) é do moderador.

RETRABALHO - Responsável: Autor

- Tarefa: corrigir os defeitos encontrados.

CONTINUAÇÃO - Responsável: Moderador

- Tarefa:

E N G E N H A R I A D E S O F T W A R E 6 9

- Analisar correções do autor e inspeção como um todo; - Re-avaliar qualidade do artefato inspecionado;

- Decidir sobre a necessidade de uma nova inspeção.

WALKTHROUGHS

Alternativa com um processo menos rigoroso do que o de inspeções de software. Papéis sugeridos: líder, autor, escrivão e revisores.

Procedimento: os participantes são guiados através dos artefatos pelo líder (que eventualmente é o próprio autor) em uma reunião. Durante est

reunião deve interromper a apresentação caso encontrem defeitos. Muitas vezes condições de entrada e saída e decisões são pressupostos pelo líder

que segue sua linha de raciocínio durante a apresentação. Possuem custo aproximadamente igual ao de inspeções mas seus

resultados são inferiores: Não providenciar resultados mensuráveis;

Não fornecer base para a aplicação de controle estatístico de processos, necessários para evoluir na maturidade de processos de software.

Pode ser usado para atividades de brainstorming para explorar

alternativas de projeto e resolução de problemas (focadas em encontrar defeitos).

GGEERREENNCCIIAAMMEENNTTOO DDEE MMUUDDAANNÇÇAA DDEE RREEQQUUIISSIITTOOSS

Figura 28 – Esquema do Gerenciamento de Requisitos (Fonte: extraído da Web)

Gerenciamento de Mudança de Requisitos é o processo de controlar as

mudanças nos requisitos durante o processo de engenharia de requisitos e desenvolvimento.

Requisitos são inevitavelmente incompletos e inconsistentes:

E N G E N H A R I A D E S O F T W A R E 7 0

Novos requisitos surgem durante o processo de desenvolvimento.

Diferentes pontos de vista possuem diferentes requisitos e esses são frequentemente contraditórios.

Mudanças nos requisitos

A prioridade dos requisitos pode mudar para atender novas demandas

de negócio;

Requisitos podem sofrer alteração quando muda a regra de negócio; As pessoas que pagam pelo software/sistema podem especificar os

requisitos de maneira conflitantes com os requisitos das pessoas que irão utilizar o software/sistema;

A empresa e o ambiente técnico do software/sistema se modificam durante o processo de desenvolvimento.

Os principais objetivos desse processo são (KOTONYA; SOMMERVILLE, 1998):

Gerenciar alterações nos requisitos acordados; Gerenciar relacionamentos entre requisitos;

Gerenciar dependências entre requisitos e outros documentos produzidos durante o processo de software.

Para tal, o processo de gerência de requisitos deve incluir as seguintes atividades:

Figura 29 – Atividades de Gerência de Requisitos (Fonte: WIEGERS, 2003)

O controle de mudança define os procedimentos, processos e padrões que devem ser utilizados para gerenciar as alterações de requisitos,

assegurando que qualquer proposta de mudança seja analisada conforme os critérios estabelecidos pela organização (KOTONYA; SOMMERVILLE,

1998). Mudanças podem ser necessárias em diferentes momentos e por

E N G E N H A R I A D E S O F T W A R E 7 1

diferentes razões. De maneira geral, o controle de mudanças envolve atividades como (KOTONYA; SOMMERVILLE, 1998; WIEGERS, 2003):

Verificar se uma mudança é válida; Descobrir quais os requisitos e artefatos afetados pela mudança, o

que envolve rastrear informações; Estimar o impacto e o custo das mudanças;

Negociar as mudanças com os clientes; Alterar requisitos e documentos associados.

EVOLUÇÃO DOS REQUISITOS

Figura 30 – Evolução dos Requisitos (Fonte: extraído da Web)

REQUISITOS PERMANENTES E VOLÁTEIS

REQUISITOS PERMANENTES: Requisitos estáveis, derivados da atividade principal da organização. Exemplo: Em um hospital sempre

haverá requisitos relativos aos pacientes, aos médicos, às enfermeiras e aos tratamentos.

REQUISITOS VOLÁTEIS: Requisitos que se modificam durante o desenvolvimento ou quando o software/sistema está em uso.

Requisitos resultantes de políticas governamentais ou resultantes de regra de negócio da empresa. Exemplo: Plano de saúde; Mudança na

política de venda.

CLASSIFICAÇÃO DOS REQUISITOS

Requisitos Mutáveis: Requisitos que se modificam por causa do ambiente do sistema;

Requisitos Emergentes: Requisitos que surgem à medida que a

compreensão do cliente do sistema se desenvolve;

E N G E N H A R I A D E S O F T W A R E 7 2

Requisitos Consequentes: Requisitos que resultam da introdução do sistema de computador.

Requisitos de compatibilidade: Requisitos que dependem de outros

sistemas ou processos de negócio específicos dentro da organização.

PLANEJAMENTO DO GERENCIAMENTO DE REQUISITOS

Durante o processo de engenharia de requisitos, será necessário

planejar: IDENTIFICAÇÃO DOS REQUISITOS: Como os requisitos são

individualmente identificados;

PROCESSO DE MUDANÇA DE GERENCIAMENTO: O processo

seguinte à análise de uma mudança de requisito;

POLÍTICAS DE RASTREABILIDADE: quantidade de informações (histórico) sobre o relacionamento entre requisitos

que é mantida. Como rastrear as mudanças de requisitos e seus possíveis impactos.

SUPORTE À FERRAMENTA: suporte à ferramenta necessário para auxiliar no Gerenciamento de Mudanças de Requisitos.

RASTREABILIDADE

Rastreabilidade preocupa-se com as relações entre requisitos, suas

fontes e o projeto do software/sistema. RASTREABILIDADE DE FONTE: links de requisitos para stakeholders

que propuseram os requisitos;

RASTREABILIDADE DE REQUISITOS: links entre requisitos

dependentes;

RASTREABILIDADE DO PROJETO: links dos requisitos para o

projeto.

SUPORTE À FERRAMENTA:

Armazenamento dos requisitos: Os requisitos devem ser gerenciados em uma memória de dados segura e gerenciada;

Mudança de gerenciamento: O processo de mudança de

gerenciamento é um processo de fluxo de trabalho cujos estágios podem ser definidos e o fluxo de informação entre esses estágios parcialmente

automatizado.

Gerenciamento de rastreabilidade: Recuperação automática dos

links entre requisitos.

E N G E N H A R I A D E S O F T W A R E 7 3

Gerenciamento de Mudanças de Requisitos: Deve ser feita em qualquer proposta de mudança de requisito.

PRINCIPAIS ESTÁGIOS: Análise do problema e especificação da mudança. Discute-se os

problemas com os requisitos e propõe-se mudanças; Análise e custo da mudança. Avalia-se os efeitos da mudança em

outros requisitos do sistema; Implementação das mudanças. O documento de requisitos e

outros documentos são alterados de forma a refletir as

mudanças.

Figura 31 – Principais Estágios do Gerenciamento de Mudanças de Requisitos (Fonte:

extraído da Web)

ETAPAS PARA O RASTREAMENTO

1.Rastrear requisitos do usuário nos do sistema;

2.Rastrear requisitos no projeto;

3.Rastrear requisitos nos procedimentos de teste;

4.Rastrear requisitos do usuário no plano.

Figura 32 – Etapas para o Rastreamento (Fonte: extraído da Web)

E N G E N H A R I A D E S O F T W A R E 7 4

EXERCÍCIOS

1) Assinale a opção correta quanto a requisitos de software.( CESPE - 2010 -

TRE-MT - Técnico Judiciário - Programação de Sistemas) a)Requisitos funcionais descrevem as propriedades emergentes do

sistema, como segurança e tempo de resposta. b)Requisitos não funcionais são descritos de forma qualitativa e não

quantitativa c) Requisitos são provenientes de pessoas relevantes para o sistema, e

não de outros sistemas que interagem com o sistema que está sendo especificado.

d)A matriz de rastreabilidade não oferece suporte para requisitos funcionais.

e)Revisão de requisitos, prototipação e geração de casos de teste são

exemplos de técnicas de validação de requisitos.

2) Segundo Ian Sommerville, existe uma série de técnicas de validação de requisitos que podemser utilizadas em conjunto ou individualmente.

São elas (FUNCAB - 2010 - SEJUS-RO - Analista de Sistemas): a) geração de casos de teste, revisões de requisitos, gerenciamento de

mudanças e prototipação. b) revisões de requisitos, prototipação, geração de casos de teste e

análise automatizada da consistência. c) prototipação, análise automatizada da consistência, revisões de

requisitos e gerenciamento de mudanças. d) gerenciamento de mudanças, análise automatizada da consistência,

revisões de requisitos e geração de casos de teste. e) análise automatizada da consistência, prototipação, gerenciamento de

mudanças e geração de casos de teste.

3) No que diz respeito aos sistemas de software, teste é um conjunto de

atividades que podem ser planejadas antecipadamente e conduzidas sistematicamente. Um tipo I de teste se refere ao conjunto de atividades

que garante que o software implementa corretamente uma função específica, associado à construção do produto de forma correta ou não,

enquanto um tipo II se refere a um conjunto de atividades diferente que garante que o software construído corresponde aos requisitos do cliente,

associado à construção do produto certo. Esses testes do tipo I e II são denominados, respectivamente (FGV - 2010 - FIOCRUZ - Tecnologista em

Saúde - TI - Sistemas de Informação): a) Depuração e homologação.

b) Homologação e aceitação. c) Aceitação e verificação.

d) Verificação e validação.

e) Validação e depuração.

4) Verificação e validação são atividades da análise de software, necessárias para se identificar o que o software precisa executar, seguida

E N G E N H A R I A D E S O F T W A R E 7 5

de uma avaliação do usuário quanto às atividades definidas. (CESPE - 2011 -

TJ-ES - Técnico de Informática - Específicos) ___ CERTO ___ ERRADO

5) Os produtos de trabalho resultantes da engenharia de requisitos são avaliados quanto à qualidade durante a etapa de validação de requisitos.

Analise os itens a seguir referentes a essa etapa: I. Um dos principais mecanismos de validação de requisitos é a avaliação

técnica formal.

II. O modelo de análise pode garantir que os requisitos foram consistentemente declarados.

III. É frequentemente útil examinar cada requisito em face de um conjunto de questões do tipo checklist.

IV. A equipe de revisão que avalia os requisitos inclui apenas pessoas com conhecimento técnico na área de TI, como engenheiros de softwares,

desenvolvedores etc. Está correto o que consta em:

a) I, II, III e IV b) II e IV

c) I, II e IV d) II, III e IV

e) I, II e III

6) Assim como o software, os requisitos também devem ser avaliados

quanto à qualidade. A validação, atividade da engenharia de requisitos, é responsável por garantir que os requisitos tenham sido declarados de

forma clara e precisa. Além disso, a validação busca detectar inconsistências, erros e omissões, objetivando alinhar os requisitos às

normas estabelecidas para o projeto, produto e processo. (CESPE - 2011 -

TJ-ES - Analista Judiciário - Análise de Sistemas - Específicos)

___ CERTO ___ ERRADO

E N G E N H A R I A D E S O F T W A R E 7 6

MMAATTRRIIZZ DDEE RRAASSTTRREEAABBIILLIIDDAADDEE

Matrizes de rastreabilidade são os principais artefatos produzidos na

fase de gerência de requisitos. Elas relacionam os requisitos identificados a um ou mais aspectos do sistema ou do seu ambiente, de modo que elas

possam ser procuradas rapidamente para entender como uma modificação em um requisito vai afetar diferentes aspectos do sistema.

RASTREABILIDADE

Técnica usada para prover relacionamento entre requisitos, projeto e implementação final do sistema. É uma característica de sistemas nos

quais os requisitos são claramente ligados às suas fontes e aos artefatos criados durante o ciclo de vida de desenvolvimento de sistema.

É a habilidade de descobrir a história de toda característica do

sistema, dado que os impactos de mudanças nos requisitos podem ser identificados. (Hamilton, 1991)

Figura 33 – Esquema Rastreabilidade

OBJETIVOS

GERENCIAR O PROJETO:

o Acompanhar a evolução dos requisitos ao longo do desenvolvimento;

E N G E N H A R I A D E S O F T W A R E 7 7

o Registrar status de cada requisito em relação ao desenvolvimento, em relação a modificações aceitas e

justificativas associadas; o Estabelecer uma visão comum entre o cliente e a equipe de

projeto em relação aos requisitos que serão atendidos pelo projeto de software;

ACOMPANHAR AS MUDANÇAS:

o Atualmente tem-se a convicção que mudanças em requisitos ao longo do processo de desenvolvimento de software fazem parte

do processo; o Motivos: necessidades não identificadas inicialmente, alterações

no contexto, correção de erros ou mesmo novas perspectivas por parte dos stakeholders;

o Alterações em requisitos podem implicar em mudanças em artefatos de projeto, código, casos de testes, etc.

GARANTIA DE QUALIDADE: o Aspectos relacionados a qualidade: modelo CMM, CMMI, ISO

9001.

A rastreabilidade auxilia: ANÁLISE DE COMPLETUDE NA ALOCAÇÃO DE REQUISITOS A

COMPONENTES DO SOFTWARE: A avaliação dos links de

rastreabilidade de requisitos a artefatos de design e implementação identifica requisitos ainda não alocados ou implementados;

RESOLUÇÃO DE REQUISITOS EM CONFLITO: diferentes representantes do cliente ou usuário trazem suas necessidades em relação ao sistema.

Essas necessidades irão gerar requisitos que podem ser conflitantes. A rastreabilidade possibilita identificar rapidamente as origens dos

requisitos em conflito, para solução do problema detectado;

VERIFICAÇÃO: na análise de cobertura de requisitos nos testes, a

rastreabilidade entre requisitos e casos de testes permite identificar requisitos ou funcionalidades para os quais foram previstos casos de

testes;

CORREÇÃO DE DEFEITOS (BUGS): após a identificação do componente

que originou o erro, a análise do problema pode indicar que a origem do defeito não está no código propriamente dito, mas nos requisitos ou

em artefatos de design. Os links indicarão quais artefatos deverão ser

revistos e corrigidos, incluindo testes;

VALIDAÇÃO: a etapa final de validação do sistema criado junto ao

conjunto de clientes e usuários se beneficia da rastreabilidade, permitindo mostrar a completude da implementação em relação aos

requisitos acordados entre clientes e desenvolvedores;

E N G E N H A R I A D E S O F T W A R E 7 8

ANÁLISE DE IMPACTO NA EVOLUÇÃO DO SISTEMA: a existência de links de rastreabilidade entre requisitos e componentes possibilita

identificar rapidamente quais componentes serão afetados por mudanças em um requisito ou mesmo por inclusão de novos requisitos;

PREVISÃO DE CUSTOS E PRAZOS: quando uma nova funcionalidade deve ser incluída no sistema em implementação ou quando uma

mudança num requisito já implementado é solicitada, o gerente de projeto necessita de estimativas confiáveis para poder negociar custos

e prazos junto ao cliente;

GERENCIAMENTO DE RISCOS: a rastreabilidade apoia a identificação de artefatos atingidos por cada fator de risco, possibilitando a

elaboração de estratégias para tratamento ou mitigação dos riscos (por exemplo, riscos associados a custos e cronograma);

UPGRADE DE HARDWARE E/OU AMBIENTE OPERACIONAL: em sistemas embarcados ou em software utilitário existem relacionamentos fortes

entre componentes do hardware e do software. Na mudança de versão do ambiente operacional ou na troca de hardware, links de

rastreabilidade possibilitam identificar rapidamente componentes atingidos;

REUSO DE COMPONENTES: obter ativos reusáveis a partir de sistemas existentes tem incrementado o reuso na indústria; uma abordagem que

propicia este incremento utiliza a recuperação de links de rastreabilidade entre código e documentos escritos em linguagem

natural.

MATRIZ DE RASTREABILIDADE DEFINIDAS

Com a matriz abaixo é possível visualizar as ligações entre os requisitos

de software.

E N G E N H A R I A D E S O F T W A R E 7 9

Figura 34 – Matriz de Rastreabilidade

A matriz de rastreabilidade de requisitos é destinada a apoiar o

trabalho do engenheiro de software nas atividades do processo de

desenvolvimento, criando automaticamente elos de rastreabilidade entre os requisitos e cenários de aplicação.

<nome da empresa>

APROVAÇÕES

Nome Data

Assinatura

Nome Data

Assinatura

<nome do projeto>

Matriz de Rastreabilidade de Requisitos

Elaborado por: Data: dia/mês/ano

<nome(s) do(s) elaborador(es)>

ID Requisito Descrição Prioridade Responsável /

Proprietário

Versão Caso de Teste Data

Alteração

Data

Conclusão

Id do

requisito (Feature)

identificado no

Documento

(Análise) de

Requisitos.

Descrição

do

requisito.

Prioridade

elencada

para o

requisito.

Nome do

responsável

pela

execução e

controle do

requisito.

Número

da versão

do

requisito.

Identificação

do caso de

teste elaborado

para o

requisito.

Data de

alteração

do

requisito.

Data de

conclusão

do

requisito.

Figura 35 – Modelo de Matriz de Rastreabilidade (Fonte: extraído da Web)

EXERCÍCIOS

1) As políticas de rastreabilidade de requisitos são decididas durante o estágio de (FCC - 2010 - MPE-RN - Analista de Tecnologia da

Informação - Engenharia de Software)

E N G E N H A R I A D E S O F T W A R E 8 0

a) Agregação dos requisitos funcionais, apenas. b) implementação do sistema, apenas.

c) implementação do sistema. d) eliminação dos requisitos não funcionais.

e) gerenciamento de requisitos.

2) O gerenciamento de requisitos deve compreender e controlar mudanças nos requisitos de sistema, além de avaliar os seus impactos.

Para atingir esse propósito, podem ser mantidas informações de

rastreabilidade a serem usadas para avaliar quais outros requisitos seriam afetados por uma mudança, bem como o impacto da mudança de requisitos no projeto e na implementação do sistema. (CESPE - 2009

- SECONT-ES - Auditor do Estado – Tecnologia da Informação)

___ CERTO ____ ERRADO

OORRIIEENNTTAAÇÇÃÃOO AA OOBBJJEETTOOSS

Adaptado da Revista: ENGENHARIA DE SOFTWARE MAGAZINE

HISTÓRIA

Em 1962, Ole-Johan Dahl e Kristen Nygaard criaram uma linguagem chamada Simula, baseada na linguagem Algol 60 que tinha

o objetivo é permitir o projeto de simulações. Surgia a primeira linguagem orientada a objetos, apresentando os conceitos de classe e

herança.

Essa foi a semente que inspirou o desenvolvimento de uma nova linguagem, a primeira totalmente orientada a objetos —o SmallTalk.

Nela, não existem tipos primitivos, tudo é representado em forma de objeto: números, caracteres etc.

Disponibilizada ao público no início dos anos 80, SmallTalk solidificou para a comunidade os conceitos de classe, objeto, atributo,

método, encapsulamento, herança e mensagem. A partir daí, novas linguagens surgiram, como o C++ (versão OO

da linguagem C), Object Pascal (versão OO do Pascal), Eiffel e Java (criado a partir do C++).

E N G E N H A R I A D E S O F T W A R E 8 1

Figura 36 – Tela do programa Smalltalk

http://zeromeia.net84.net/smalltalk/programando.html

CONCEITOS FUNDAMENTAIS

Figura 37 – Conceitos fundamentais da UML

Surgiu devido a necessidade em se enfatizar unidades discretas, e

obter a reutilização de código, mantendo-se a qualidade do software.

E N G E N H A R I A D E S O F T W A R E 8 2

O foco da Orientação a Objetos é sobre os dados, em vez dos processos, compondo módulos auto-suficientes — os objetos —,

encerrando em sua estrutura todo o conhecimento dos dados e dos processos para manipulação desses dados.

Objetivo Principal: possibilidade de se abstrair diretamente os conceitos do mundo real, sem subterfúgios para se chegar à solução

computacional. Se um dos conceitos fundamentais de orientação a objetos não for

atendido, não podemos afirmar que determinada tecnologia possa ser

nomeada como orientada a objetos. Exemplo: Visual Basic, que antes da sua versão .NET não implementava todos os conceitos.

OBJETO

Figura 38 – Exemplo de Objeto

Objeto é qualquer coisa existente no mundo real, em formato concreto ou abstrato, ou seja, que exista fisicamente ou apenas

conceitualmente, o qual se pode caracterizar e identificar comportamentos.

Podemos afirmar que um objeto é uma caixa-preta que recebe e envia mensagens, ou seja, num sistema orientado a objetos, os objetos

trocam informações por meio de mensagens. Num sistema orientado a objetos não modelamos apenas objetos

de negócio. Muitas vezes, de acordo com a arquitetura utilizada, modelamos objetos computacionais, visuais ou não.

Exemplo: ao levantarmos os requisitos para informatizar uma concessionária, encontraremos o objeto automóvel (físico), da mesma

forma que podemos modelar o objeto venda (conceitual).

E N G E N H A R I A D E S O F T W A R E 8 3

ATRIBUTO

Figura 39 – Exemplo de Atributo

São as características ou propriedades associadas aos objetos. Para os objetos de negócio, é comum usarmos o conceito de atributo.

Para os objetos visuais, utilizamos o conceito de propriedade.

Exemplos: atributos da classe Cargo: descricao e salario;

atributos da classe Automóvel: modelo, cor, numeroPortas, ano, placa, etc.

OPERAÇÃO X MÉTODO

Figura 40 - Exemplo de Operação x Método

O comportamento dos objetos é representado pelas operações. Contudo, a operação para um objeto representa apenas a definição

do serviço que ele oferece a outras estruturas. Quando tratamos da implementação dessa operação, ou seja, da sua

representação em código, estamos nos referindo ao seu método. Os métodos de uma classe manipulam somente as estruturas de

dados daquela classe, ou seja, para se ter acesso aos dados de outra classe, isso deve ser feito por meio de mensagens.

E N G E N H A R I A D E S O F T W A R E 8 4

Exemplo: operações da classe Cargo: cadastrar() e reajustarSalario(percentual: float).

RESUMINDO: as operações são métodos ou funções que atuam sobre os objetos e afetam o comportamento dos mesmos.

CLASSE

Ao modelarmos uma classe precisamos sempre considerar o

contexto. Se não fosse isso, bastaria um famoso metodologista publicar as soluções para todas as classes de negócio. EXEMPLOS:

EXEMPLO 1: Desta forma, não teremos necessariamente os mesmos atributos e operações para a classe aluno, por exemplo, modelada num

sistema acadêmico de uma escola de nível médio, e a mesma classe aluno, modelada num sistema acadêmico de uma Universidade. Não é

garantia termos os mesmos atributos e operações nem se

considerarmos dois sistemas acadêmicos modelados para distintas Universidades.

EXEMPLO 2: classe Automóvel. Se estivermos no contexto de uma concessionária, teremos operações como: cadastrar,

alterarProprietario, etc. Em contrapartida, se estivermos no contexto de um simulador para auto-escola, seu comportamento deve reproduzir

o objeto real, com operações como: ligar, aumentar marcha, reduzir marcha, acelerar etc.

ESTADO

São os valores assumidos pelos atributos de um objeto.

Exemplo: em um determinado objeto cargo, o estado do seu atributo salario é o valor R$ 5000,00.

MENSAGEM

É a solicitação que um objeto faz a outro, invocando a execução de

um determinado serviço. Por exemplo, para que um objeto possa calcular a folha de pagamento, ele precisa saber o salário de cada funcionário.

Assim, ele passa uma mensagem ao objeto cargo, solicitando a execução do serviço obterSalario, que nada mais é do que uma operação do objeto

cargo.

ENCAPSULAMENTO

É a utilização de um sistema orientado a objetos que não deve depender de sua implementação interna, e sim de sua interface.

Isso garante que os atributos e os métodos estarão protegidos, só podendo ser acessados pela interface disponibilizada pelo objeto, ou seja,

sua lista de serviços. Essa proteção garante que os usuários de uma

classe não sejam influenciados por quaisquer alterações feitas em seu conteúdo. Exemplo:

E N G E N H A R I A D E S O F T W A R E 8 5

Na prática, imagine uma classe Produto que possua a operação obterPrecoVenda: float. Essa operação é pública, tornando-se um serviço

disponibilizado a outras classes. Em qualquer rotina que se queira mostrar o preço de venda de um produto, basta instanciar um objeto Produto, e

passar uma mensagem para executar o serviço, ou seja, chamar a execução da operação obterPrecoVenda.

Suponha que as rotinas A, B, C e D usem esse serviço e que até ontem esse valor de venda fosse obtido apenas com um cálculo simples:

precoVenda = precoCusto * (1 + lucro/100)

Esse cálculo está na implementação de uma operação, ou seja, é o seu método, e fica encapsulado (escondido).

Suponha agora que hoje foi colocada uma nova versão da classe Produto, na qual esse cálculo passa a ser:

precoVenda = precoCusto * (1 + lucro/100) precoVenda = precoVenda * (1 - descontoMes/100)

As rotinas A, B, C e D receberão uma exceção em virtude da regra de

cálculo ter sido alterada? Não, eu respondo. É transparente para essas rotinas (e precisa ser assim) que houve alteração na forma de cálculo do

preço de venda. Se estivermos diante de um componente (por exemplo, uma dll), absolutamente nada será preciso fazer com essas rotinas. Se

estivermos com as rotinas dentro do mesmo pacote que a classe, basta recompilar tudo.

HERANÇA

Ao refinarmos a modelagem de um sistema é comum encontrarmos

características redundantes entre objetos. Essa redundância pode ser evitada pela separação dos atributos e operações numa classe comum,

identificada como superclasse.

Essa classe comum (superclasse) passa a ser a generalização de outras classes que encerram em si apenas os atributos e operações

específicos a cada uma. Exemplo: Suponha que temos duas classes: Cliente e Funcionario. São atributos dessas classes:

Cliente (cpf, nome, dataNascimento, endereco, dataPrimeiraCompra); Funcionario (cpf, nome, dataNascimento, endereco, dataAdmissao,

funcao). Imagine que existem operações que validam o CPF, retornam a idade

de um cliente ou funcionário, ou formatam o endereço. E que todas essas funções apareçam em duplicidade nas classes Cliente e Funcionário. Numa

situação dessas, o que se espera na orientação a objetos é que essa redundância seja eliminada com a herança.

Assim, cria-se uma superclasse Pessoa, e a ela são atribuídos todos os atributos e operações comuns à Cliente e Funcionario. Sobram nas

subclasses (Cliente e Funcionario) somente os atributos e operações

específicos a cada um. Na prática, ao se usar uma subclasse, tem-se acesso a todos os elementos das classes ascendentes, como se tivessem

sido criadas na própria classe filha. Abaixo o resultado:

E N G E N H A R I A D E S O F T W A R E 8 6

CLASSES ATRIBUTOS

Antes da herança

Cliente cpf

nome dataNascimento

endereco dataPrimeiraCompra

Funcionario cpf

nome dataNascimento

endereco dataAdmissao

função

Após a herança

Pesoa cpf nome

dataNascimento endereco

Cliente dataPrimeiraCompra

Funcionário dataAdmissao

funcao

Quando uma subclasse possui mais do que uma superclasse é dito

que temos uma herança múltipla.

A herança não precisa se limitar aos objetos de negócio. Pelo contrário, um dos maiores ganhos que nós temos com a orientação a

objetos é a possibilidade de se estender todo esse conceito de utilização para todos os componentes do nosso sistema.

Exemplo: podemos criar uma classe para um relatório, com o logotipo da empresa, dados de identificação do cabeçalho e do rodapé, e a

partir dessa classe, herdar todos os outros relatórios do sistema, particularizando em cada um, as características específicas. Imagine o

esforço necessário para se trocar o logo e incluir o nome do usuário logado em todos os 1000 relatórios de um sistema: calculo uns dois

minutos.

POLIMORFISMO

Uma operação pode ter implementações diferentes em diversos pontos da hierarquia de classes. Isso significa que ela terá a mesma

assinatura (mesmo nome, lista de argumentos e retorno), porém implementações diferentes (métodos). Isso é o polimorfismo (poli =

muitas; morphos = forma). Exemplo: Há uma operação calcularSalario() que pertence à classe

Funcionario. Herdamos de Funcionario a classe Professor, o que resulta

automaticamente na herança de calcularSalario(). Contudo o cálculo do salário de um professor não é o mesmo que o cálculo do salário de um

E N G E N H A R I A D E S O F T W A R E 8 7

funcionário, o que nos leva a ter a mesma operação, porém com métodos diferentes.

ANÁLISE ORIENTADA A OBJETOS

A análise visa investigar e resolver um problema. O objetivo da

análise é levar o analista ou projetista a investigar e a descobrir como tratar o problema que ele tem em mãos. Ao finalizar a análise, deverá

ocorrer uma compreensão completa do problema e, portanto, o projeto será a sua solução.

A análise orientada a objetos é uma atividade essencial num processo de desenvolvimento de software.

Seu objetivo principal é identificar objetos, atributos desses objetos e as operações que atuam sobre eles.

Note que a análise é essencial para criação de um modelo de

classes do sistema a partir dos casos de uso (da etapa de levantamento de requisitos). O objetivo da análise é identificar as

classes necessárias para implementar os casos de uso do sistema, como discutido adiante.

Um processo de desenvolvimento de software compreende um conjunto de atividades, dentre elas, levantamento de requisitos,

análise e projeto como etapas iniciais do processo de desenvolvimento de software.

Antes de iniciar a modelagem com uma linguagem como a UML, devemos proceder a análise orientada a objetos, que compreende os

seguintes passos: 1) Entender o problema do cliente e identificar e documentar os

requisitos; 2) Descrever os requisitos funcionais usando diagramas de casos de

uso da UML; 3) Identificar objetos e classes a partir das informações no documento

de requisitos, descrição do sistema e especificação de casos de uso;

4) Identificar relacionamentos entre as classes do item 3; 5) Identificar atributos e operações (para as classes identificadas no

item 3); 6) Elaborar e analisar os diagramas de classes de sistema, adicionando

e/ou corrigindo atributos e operações, bem como revisando os relacionamentos identificados.

O que é análise????

E N G E N H A R I A D E S O F T W A R E 8 8

EXERCÍCIOS

1) O paradigma de orientação a objetos é centrado em conceitos que

envolve os seguintes princípios fundamentais: abstração, encapsulamento, herança e polimorfismo. Esse paradigma evoluiu

desde a sua concepção original e tornou-se uma força pivotal no desenvolvimento da ciência, da tecnologia e de quaisquer outros

domínios em que é aplicada, inclusive na área de desenvolvimento de software. A esse respeito, assinale a opção correta. (CESPE -

2010 - SAD-PE - Analista de Controle Interno – Tecnologia da Informação) a) Na implementação de linguagens de programação orientada a objetos

(POO), o polimorfismo é, usualmente, possível por meio do emprego da

técnica de ligação estática, de modo que a escolha da implementação específica que tratará determinado envio de mensagem será efetuada em tempo de compilação.

b) O conceito de abstração, presente na POO, oferece maior suporte aos métodos de desenvolvimento embasados em refinamentos top-down que

aos embasados em refinamentos bottom-up. c) Na POO, o encapsulamento aplica-se, fundamentalmente, aos campos ou

variáveis de estado de determinado objeto, sendo de pouca utilidade a

sua aplicação a métodos. d) Uma das formas comuns de se evitar o uso excessivo de herança como

mecanismo de refinamento de POO é o emprego de delegação, que evita a criação de número excessivo de subclasses em modelos orientados a objetos.

e) Nas linguagens orientadas a objeto da atualidade, é comum o uso de herança múltipla, que permite a determinada classe herdar diretamente

das implementações de uma ou mais classes, possibilitando mais expressividade semântica e facilitando a manipulação do sistema de tipos nessas linguagens.

2) Com relação ao emprego de conceitos do paradigma de orientação a

objetos na análise e no projeto de sistemas de software, assinale a opção correta. (CESPE - 2010 - SAD-PE - Analista de Controle Interno –

Tecnologia da Informação)

a) Os métodos clássicos de análise e de projeto orientado a objetos buscam refinar aplicação orientada a objetos, desde os requisitos até o código, empregando o conceito de desenvolvimento sem compartimentos, no

qual as abstrações orientadas a objeto de nível mais elevado são transformadas em novo conjunto de abstrações que pouco preservam as

relações com nível superior por meio da transição bem definida entre as fases do processo de desenvolvimento.

b) Um modelo orientado a objetos em nível de análise é, tipicamente,

composto por grande número de classes inter-relacionadas, contendo cada uma delas um conjunto de variáveis de estado e métodos em sua

interface. c) Na modelagem orientada a objetos, a ênfase reside nos dados mantidos

pelas abstrações do modelo, em oposição ao que ocorre nos métodos

estruturados, cuja ênfase inicial recai sobre as funções realizadas pelas abstrações do modelo.

E N G E N H A R I A D E S O F T W A R E 8 9

d) Aspectos como concorrência, distribuição e persistência são mais comumente trabalhados na fase de projeto orientado a objetos que na

fase de análise. e) Um conjunto de cartões adequadamente desenvolvidos por meio da

técnica CRC (Class-Responsibilities-Colaborators) constitui um artefato

útil para um desenvolvedor iniciar o processo de codificação de um programa orientado a objetos, na linguagem de programação na qual

tenha proficiência.

3) Considere: Casas ABC Ltda., Empresa e Nome da Empresa. Na orientação a objetos, os itens acima representam, respectivamente, (FCC - 2008 - TCE-AL - Programador)

a) Atributo, classe e objeto. b) Classe, atributo e objeto.

c) Classe, objeto e atributo. d) Objeto, atributo e classe.

e) Objeto, classe e atributo.

4) Os conceitos de generalização e especialização da orientação a objetos estão diretamente relacionados ao conceito de (FCC - 2008 -

TCE-AL - Programador)

a) Agregação b) Associação

c) Encapsulamento d) Polimorfismo

e) Herança

5) Os componentes de uma biblioteca de software, no modelo orientado a objetos, correspondem a (FCC - 2008 - TCE-AL -

Programador)

a) Objetos b) Classes

c) Subclasses d) Métodos

e) Mensagem

6) Sobre os conceitos de orientação a objetos, considere:

I. Classe encapsula dados para descrever o conteúdo de alguma entidade do mundo real.

II. Objetos são instâncias de uma classe que herdam os atributos e as operações da classe.

III. Superclasse é uma especialização de um conjunto de classes relacionadas a ela.

IV. Operações, métodos ou serviços fornecem representações dos comportamentos de uma classe. Está completo e correto o que consta em (FCC - 2011 - TRT - 23ª

REGIÃO (MT) - Analista Judiciário - Tecnologia da Informação)

a) I, II, III e IV

E N G E N H A R I A D E S O F T W A R E 9 0

b) I, II e IV, apenas. c) II, III e IV, apenas.

d) I e II, apenas e) II e IV, apenas.

7) A Análise e Projeto Orientado a Objetos, um recurso tem como meta

principal reduzir o número de variáveis globais usadas dentro de um programa, consistindo na separação dos aspectos externos de

um objeto, permitindo que a sua implementação possa ser

modificada sem que afete as aplicações que o utilizam. Este recurso é denominado:

a) Encapsulamento b) Independência

c) Polimorfismo d) Modularidade

e) Herança

8) Orientação a Objetos é um paradigma de análise, projeto e programação de sistemas de software. A respeito desse paradigma, assinale a afirmativa incorreta. (FGV - 2009 - MEC -

Analista de Sistemas - Especialista)

a) Um objeto pode ser considerado um conjunto de dados.

b) Os objetos possuem identidade, estado e comportamento. c) Um evento pode existir se não houver um objeto a ele

associado. d) Um objeto pode existir mesmo que não exista nenhum evento

associado a ele. e) A orientação a objetos implementa o conceito de abstração,

classe, objeto, encapsulamento, herança e polimorfismo.

9) Em desenvolvimento de sistemas, focalizar nos aspectos essenciais

inerentes a uma entidade e ignorar propriedades significa concentrar-se no que um objeto é e faz antes de se decidir como

ele será implementado. Na orientação a objetos, este é um conceito típico (FCC - 2011 - TRE-RN - Técnico Judiciário - Programação de

Sistemas)

a) Herança

b) Reusabilidade c) Abstração

d) Encapsulamento e) Compartilhamento

E N G E N H A R I A D E S O F T W A R E 9 1

22ºº BBIIMMEESSTTRREE UUMMLL

Adaptado da Revista Engenharia de Software Magazine

Figura 41 – Os três amigos da UML

HISTÓRIA

No início da década de 90 havia mais de 50 métodos disputando o mercado para se tornar ―o‖ método principal para a orientação a

objetos. Contudo, a maior parte desses métodos cometia um grave pecado: ser uma extensão dos métodos estruturados. Os maiores

prejudicados eram os usuários que não conseguiam encontrar uma solução única e devidamente discutida.

Em 1995, mesmo com contribuições valiosas de outros metodologistas, três metodologias começaram a dominar o mercado:

OMT – Object Modeling Technique de James Rumbaugh, método Booch

de Grady Booch e OOSE – Object-Oriented Software Engineering de Ivar Jacobson.

Nasceu ainda como um método, teve a mudança de perspectiva, passando a ser uma linguagem de modelagem, desacoplando o

processo de desenvolvimento. Nascia a UML – Unified Modeling Language na sua versão 0.9.

E N G E N H A R I A D E S O F T W A R E 9 2

Figura 42 – Evolução da UML (site official da OMG)

Em 1996, a UML já era vista pelas organizações como uma ótima

estratégia para seus negócios. A OMG (Object Management Group) emitiu uma RFP (Request for Proposals), que objetivava receber

propostas de padronização para uma metodologia de desenvolvimento orientado a objetos. Respostas foram recebidas da comunidade de

engenharia de software e de grandes empresas (Digital, HP, IBM, Microsoft, Oracle e Unisys, entre outras) fortalecendo a proposta da

UML. Os objetivos que levaram os desenvolvedores da linguagem UML

a lançarem sua versão 2.0 foi reestruturá-la e refiná-la de maneira a

torná-la mais fácil de aplicar, implementar e adaptar, melhorando sua precisão e capacidade de reutilização.

CONCEITO

A UML é uma linguagem usada para especificar, visualizar e

documentar os artefatos de um sistema baseado em objeto, sob desenvolvimento. Ela representa a unificação das notações de Booch,

Rumbaugh e Jacobson, bem como as melhores ideias de uma

quantidade de outros teóricos de metodologia. Unificando as notações usadas por esses métodos baseados em objeto, a Unified Modelling

Language oferece a base para um padrão de fato no domínio de análise e projeto baseado em objeto, apoiada em uma ampla base de

experiência (Rational Software Corporation).

E N G E N H A R I A D E S O F T W A R E 9 3

Figura 43 – Planta de uma casa

Ou seja, é uma linguagem para visualizar, especificar, construir e documentar artefatos de sistema de software. É apenas uma abordagem

de notação e não propõem/define como organizar as atividades de

projeto. Por isto, pode ser ajustada para satisfazer a diferentes situações de desenvolvimento e ciclos de vida. Onde:

VISUALIZAR: facilitar entendimento dos modelos projetados; ESPECIFICAR: permite construir modelos precisos, não ambíguos e

completos; CONSTRUIR: por possuir semântica, os elementos da UML podem estar

associados a linguagens de programação.

UTILIZAÇÃO

A UML pode ser usada para modelar visualmente:

A interação de sua aplicação com o mundo externo; O comportamento de sua aplicação;

A estrutura de seu sistema; Os componentes de seu sistema;

A arquitetura de sua empresa; Ajuda a visualizar o sistema;

Especifica a estrutura e o comportamento; Proporciona um guia para a construção do sistema;

Documenta as decisões tomadas.

E N G E N H A R I A D E S O F T W A R E 9 4

NOTAÇÃO

Possui semântica bem definida;

Satisfaz bem as necessidades para representação de um sistema;

É bem entendida pelos participantes; É genérica e flexível;

Não é especifica para linguagem de programação.

VANTAGENS

Padrão aberto e não proprietário; Independência do processo de desenvolvimento;

Aplicável a todas as fases do ciclo de desenvolvimento;

Independência de linguagem de implementação; Integração das melhores práticas de modelagem;

Extensível; Suporte a conceito de alto nível.

FASES DO DESENVOLVIMENTO UML

ANÁLISE DE REQUISITOS: captura as decisões e necessidades dos usuários (funções); diagrama de caso de uso mostra que os futuros

usuários podem esperar do aplicativo e não se preocupando de como será implementado. Mostra o que o usuário vai fazer. Ou seja,

documento com todas as funções que ele precisa;

ANALISE: objetos e mecanismos que estarão no domínio do

problema. As classes se relacionam (diagrama de classes);

DESIGN: O resultado da analise através de periféricos,. Banco de

dados, comunicação entre sistemas, integração, componentes que precisam ser colocados;

PROGRAMAÇÃO: as classes do design são convertidas para a linguagem orientada a objeto, como Java, .Net. Esta conversão

dependendo da linguagem pode ou não ser fácil;

TESTES: unidade (classes individuais ou grupos, feita por

programadores), integração (classes e componentes integrados para

verificar se as classes estão cooperando uma com as outras e aceitação (testa o sistema como uma caixa preta verificando todo o

sistema. Se está de acordo com os requisitos).

E N G E N H A R I A D E S O F T W A R E 9 5

COMPONENTES DA UML

VISÕES: mostra diferentes aspectos do sistema que esta sendo

modelado. É uma abstração com base em diversos diagramas;

MODELOS DE ELEMENTOS: representam definições comuns como

mensagens, relacionamentos entre as classes, casos de uso, etc.;

MECANISMOS GERAIS: comentários suplementares, ou seja,

informações ou semânticas sobre os componentes do modelo. Podem ter mecanismos de extensão para estender a UML em um método ou

processo;

DIAGRAMAS: gráficos que descrevem as visões;

TESTES: há documentação de testes. Como por exemplo, casos de teste.

MODELOS DE ELEMENTOS

São os conceitos utilizados nos diagramas. Pode ser uma

representação gráfica presente em diversos diagramas ou definido para que faça parte de um diagrama. São eles: CLASSES, OBJETOS, ESTADOS,

PACOTES, COMPONENTES e RELACIONAMENTOS9.

CLASSES

Descrição de um tipo de objeto. Objeto é uma instância de uma classe que define os seus atributos e comportamentos. Exemplo:

Figura 44 – Exemplo de Classe

OBJETOS

Elemento que pode manipular, acompanhar seu comportamento, criar, destruir, etc. Tem a semântica de ser exibido sublinhado e antes da

classe vem o nome do objeto instanciado. Exemplo:

9 Usado para conectar outros modelos de elementos.

E N G E N H A R I A D E S O F T W A R E 9 6

Figura 45 – Exemplo de Objetos

ESTADOS

Todos os objetos possuem um estado que significa o resultado de

atividades executadas pelo objeto, e é normalmente determinada pelos

valores de seus atributos e ligações com outros objetos.

PACOTES

Mecanismo de agrupamento, onde todos os modelos de elementos

podem ser agrupados.

Figura 46 – Exemplo de Pacotes

COMPONENTES

Pode ser tanto um código em linguagem de programação como um código executável já compilado.

E N G E N H A R I A D E S O F T W A R E 9 7

Figura 47 – Exemplo de Componentes

RELACIONAMENTOS

Os relacionamentos ligam as classes/objetos entre si criando relações

lógicas entre estas entidades. Tipos de relacionamentos: ASSOCIAÇÃO;

GENERALIZAÇÃO;

DEPENDÊNCIA E REFINAMENTOS.

TIPOS DE ASSOCIAÇÃO

NORMAIS: tipo mais comum. É apenas uma conexão entre classes. Possui um verbo ou substantivo na linha da associação e pode ter

uma seta indicando a direção.

Figura 48 – Exemplo de Associação

RECURSIVA: é possível conectar uma classe a ela mesma através

de uma associação e que ainda representa semanticamente a conexão entre dois objetos, mas os objetos conectados são da

mesma classe.

E N G E N H A R I A D E S O F T W A R E 9 8

Figura 49 – Exemplo de Recursividade

QUALIFICADA: associações classificadas são usadas como

associações de um para vários (1..*) ou de vários para vários (*).

Figura 50 – Exemplo de Qualificada

EXCLUSIVA: é uma restrição em duas ou mais associações. Onde

os objetos só podem participar de uma classe em determinado

momento (linha tracejada).

Figura 51 – Exemplo de Exclusividade

ORDENADA: as associações entre objetos podem ter uma ordem implícita. O padrão para uma associação é desordenada.

CLASSE: uma classe pode ser associada a uma outra associação.

E N G E N H A R I A D E S O F T W A R E 9 9

Figura 52 – Exemplo de classe associativa

TERNÁRIA: mais de duas classes podem ser associadas entre si, a

associação ternária associa três classes.

Figura 51 – Exemplo de classe ternária

AGREGAÇÃO: caso particular da associação. Pode ser:

o COMPARTILHADA: é quando uma das classes é uma parte, ou

está contida da outra, mas esta parte pode fazer estar contida na outras várias vezes em um mesmo momento;

Figura 52 – Exemplo de agregação

E N G E N H A R I A D E S O F T W A R E 1 0 0

o COMPOSIÇÃO: uma classe que está contida na outra ―vive‖ e constitui a outra. Se o objeto da classe que contém for

destruído, as classes da agregação de composição serão destruídas juntamente já que as mesmas fazem parte da

outra.

Figura 53 – Exemplo de composição

GENERALIZAÇÃO: relacionamento entre um elemento geral e um

outro mais específico. Pode ser:

Figura 54 – Exemplo de generalização

NORMAL: a classe mais específica (subclasse) herda tudo da classe mais geral (superclasse);

RESTRITA: especifica informações mais precisas sobre como a generalização deve ser usada e estendida no futuro. As restrições

definem a generalizações restritas com mais de uma subclasse:

DEPENDÊNCIAS: conexão semântica entre dois modelos de elementos,

um independente e outro dependente.

E N G E N H A R I A D E S O F T W A R E 1 0 1

Figura 55 – Exemplo de dependência

REFINAMENTOS: tipo de relacionamento entre duas descrições de uma mesma coisa, mas em níveis de abstração diferentes e podem

ser usados para modelar diferentes implementações de uma mesma coisa.

MECANISMOS GERAIS

ORNAMENTO: anexado ao modelo acrescentando semântica.

Exemplo separar o tipo de instancia que é colocado em negrito. Uma classe é colocada em negrito e se há um objeto é colocado

sublinhado. Outro é a multiplicidade; NOTA: nem tudo pode ser definido na linguagem e para colocar

observações usamos notas em UML e pode ser colocada em qualquer lugar do diagrama.

DIAGRAMAS

Um diagrama é uma representação gráfica parcial ou total de um modelo. Apresentação gráfica de uma coleção de elementos de modelo,

geralmente processados como um gráfico de arcos (relacionamentos) e vértices (outros elementos de modelo) conectados.

A UML 2.0 (versão atual) define 13 tipos de diagramas divididos em duas categorias de modelagem: ESTÁTICA (ESTRUTURAL) ou

DINÂMICO (COMPORTAMENTO).

DIAGRAMAS ESTRUTURAIS (ESTÁTICOS)

Definem estaticamente a arquitetura de um modelo. São usados para modelar as ―coisas‖ que compõem um modelo - as classes, os

objetos, as relações e os componentes físicos. Além disso, também são usados para modelar os relacionamentos e as dependências entre

elementos. Fazem parte dos diagramas da modelagem estruturada:

DIAGRAMA DE CLASSES – apresenta classes conectadas por

relacionamentos. Usado para exibir entidades do mundo real, além de elementos de análise e projeto;

DIAGRAMA DE OBJETOS – apresenta objetos e valores de dados. Corresponde a uma instância do diagrama de classes, mostrando o

estado de um sistema em um determinado ponto do tempo;

E N G E N H A R I A D E S O F T W A R E 1 0 2

DIAGRAMA DE COMPONENTES – mostra as dependências entre componentes de software, apresentando suas interfaces;

DIAGRAMA DE ESTRUTURA COMPOSTA – usado para mostrar a composição de uma estrutura. Útil em estruturas compostas de

estruturas complexas ou em projetos baseados em componentes;

DIAGRAMA DE PACOTES – usado para organizar elementos de

modelo e mostrar dependências entre eles;

DIAGRAMA DE IMPLANTAÇÃO – mostra a arquitetura do sistema

em tempo de execução, as plataformas de hardware, artefatos de

software e ambientes de software (como sistemas operacionais e máquinas virtuais).

DIAGRAMAS COMPORTAMENTAIS (DINÂMICOS)

Os diagramas dinâmicos ou de comportamento apresentam as

variedades da interação e do estado instantâneo dentro de um modelo enquanto é ―executado‖. São eles:

DIAGRAMA DE CASOS DE USO – mostra os casos de uso, atores e

seus relacionamentos que expressam a funcionalidade de um sistema;

DIAGRAMA DE ATIVIDADES – representa a execução de ações ou atividades e os fluxos que são disparados pela conclusão de outras

ações ou atividades;

DIAGRAMA DE MÁQUINA DE ESTADOS – representa as ações

ocorridas em resposta ao recebimento de eventos;

DIAGRAMAS DE INTERAÇÃO: o DIAGRAMA DE SEQUÊNCIAS – mostra as interações que

correspondem a um conjunto de mensagens trocadas entre objetos e a ordem que essas mensagens acontecem;

o DIAGRAMA DE COMUNICAÇÃO – antigo diagrama de colaboração, que mostra objetos, seus inter-relacionamentos e o fluxo de

mensagens entre eles;

o DIAGRAMA TEMPORAL – mostra a mudança de estado de um

objeto numa passagem de tempo, em resposta a eventos externos;

o DIAGRAMA DE VISÃO GERAL DE INTERAÇÃO – uma variação do diagrama de atividades que mostra de uma forma geral o fluxo

de controle dentro de um sistema ou processo de negócios. Cada nó ou atividade dentro do diagrama pode representar outro

diagrama de interação.

E N G E N H A R I A D E S O F T W A R E 1 0 3

Pode-se afirmar que é possível se completar a modelagem de um

sistema de pequeno ou médio porte, com sucesso, com apenas três diagramas (casos de uso, classes e sequências), tendo o suporte,

dependendo do contexto, de três outros diagramas (objetos, atividades e máquina de estados). O paradigma da orientação a objetos veio

definitivamente ocupar um espaço que há muito se necessitava no mercado de desenvolvimento. Cabe aos desenvolvedores entenderem a

importância de se respeitar todos os seus conceitos, para que se

obtenha o melhor do que ele nos propõe.

EXERCÍCIOS

1) Os diagramas UML da categoria comportamental são os de (FCC -

2008 - TCE-AL - Programador)

a) Classes, Objetos e componentes b) Casos de Uso, Sequências e Classes

c) Classes, Atividades e Sequências d) Casos de uso, atividades e máquina de estados

e) Objetos, estrutura composta e máquinas de estado

2) Um diagrama UML é uma apresentação gráfica de uma coleção de

elementos do modelo de um sistema. O diagrama utilizado pela UML que apresenta a interação entre os

objetos em relação ao tempo é o de (FESMIP-BA - 2011 - MPE-BA -

Analista de Sistemas) a) Componentes

b) Implantação c) Estado

d) Classes

e) Sequência

3) Na UML, os diagramas de sequência e os diagramas de atividade, também denominados diagramas de interação, auxiliam a modelar

os aspectos dinâmicos de sistemas. Um diagrama de interação é formado pelo conjunto de objetos e seus relacionamentos e inclui

as mensagens que poderão ser enviadas entre eles. (CESPE - 2010 -

TRE-BA - Técnico Judiciário - Programação de Sistemas)

__ Certo __ Errado

4) Analise as seguintes afirmativas sobre os Diagramas de Interação da UML.

I. Um Diagrama de Interação mostra a interação entre um conjunto de objetos e seus relacionamentos, incluindo as

mensagens que poderão ser trocadas entre eles. II. Diagramas de Sequência e Diagramas de Colaboração são

Diagramas de Interação e modelam aspectos dinâmicos de sistemas.

E N G E N H A R I A D E S O F T W A R E 1 0 4

III. Diagramas de Colaboração dão ênfase à ordenação temporal das mensagens trocadas entre os objetos.

Marque a alternativa CORRETA: (FUMARC - 2011 - BDMG - Analista de

Sistemas)

a) Afirmativas I e II são verdadeiras. b) Afirmativas I e III são verdadeiras.

c) Afirmativas II e III são verdadeiras. d) Todas as afirmativas são verdadeiras.

5) A respeito da linguagem UML é correto afirmar que (Concurso

Serpro-2001): a) não se trata de uma linguagem de documentação.

b) é voltada para a representação conceitual e física de um sistema. c) não abrange a documentação para a realização de testes.

d) não deve ser empregada para a documentação de artefatos que façam uso de sistemas completos de software.

e) é uma linguagem utilizada para a realização de testes de

programas.

6) Entre outros, a UML inclui os diagramas de (Concurso Serpro-2001): a) classes, objetos, fluxo de dados e de atividades.

b) classes, implantação, gráficos de estado e de sequências. c) objetos, classes, contexto, implantação.

d) classes, objetos, testes, implantação. e) objetos, casos de uso, contexto, implantação.

7) Na UML, as classes A e B legam suas estruturas e comportamentos à

classe C. Considerando apenas o fato apresentado nessa circunstância, é correto afirmar que aí se aplica tipicamente o

conceito de (FCC - 2009 - TRT - 7ª Região (CE) - Analista Judiciário - Tecnologia

da Informação)

a) delegação.

b) derivação. c) herança múltipla.

d) método polimórfico. e) multiplicidade.

8) A UML define em sua versão 2.0, treze tipos de diagramas, divididos

em duas categorias: diagramas estruturais e diagramas dinâmicos. Assinale a alternativa que não indique um diagrama estrutural da

UML. (FGV - 2009 - MEC - Analista de Sistemas - Especialista) a) Diagrama de Visão Geral.

b) Diagrama de Implantação. c) Diagrama de Pacotes.

d) Diagrama de Classes. e) Diagrama de Objetos.

E N G E N H A R I A D E S O F T W A R E 1 0 5

DDIIAA PPOORRTTAABBLLEE

Figura 56 – Tela principal do Dia Portable

O Dia Portable é uma ferramenta baseada no Microsoft Visio, com

a qual pode-se compor layouts, fluxogramas, organogramas e diagramas em geral, contando também com objetos para modelagem

UML e de sistemas Estruturados. Este programa pode ser utilizado tanto em seu computador como a partir de um pendrive.

Auxilia os analistas e desenvolvedores de sistemas na criação e

integração dos diagramas de dados da UML com a lógica. Com ele é possível especificar recursos, transações, trocas de comunicação, plano

de custos com tempo, esforço, entre outras. Além disto, além de modelagem de negócio voltada para informática, também é possível

montar diversos tipos de diagramas. A interface é disposta de forma que no centro está o espaço para o

projeto, acima estão os menus e opções e à esquerda encontram-se as ferramentas para modelagem. Ainda com relação a estas ferramentas,

elas estão dispostas em dois grupos. O mais acima possui formas geométricas, textos, setas e opções de linha para ligação. Logo abaixo

estão os objetos de um diagrama conforme categoria. Basicamente estas categorias são quatro: variados, fluxograma,

UML e outras folhas. Esta última categoria contém 35 grupos de objetos, constando entre eles alguns relacionados à cibernética, luzes,

peças de quebra cabeça, hidráulicos, banco de dados, UML, BPMN,

E N G E N H A R I A D E S O F T W A R E 1 0 6

cisco, entre muitos outros. Desta forma, é muito pouco provável que você não venha a encontrar o desenho que precisa para seu diagrama.

Para utilizá-lo é simples, basta abrir um novo projeto e começar a desenhar seus diagramas. Para inserir novos objetos, primeiro escolha

uma categoria na caixa de opções no lado esquerdo da tela. Feito isto, escolha as formas que deseja inserir em seu projeto e para adicioná-las

basta clicar sobre a figura com o mouse e arrastá-la até o quadro (ou clicar sobre a figura e sobre o quadro)

À medida que uma figura vai sendo posicionada na tela, você pode

observar seu enquadramento correto por meio do fundo quadriculado e das réguas horizontais e verticais dispostas para tal função. Se após

inserir a figura houver algum problema, para apagá-la basta selecionar e utilizar o delete do teclado.

Na barra de ferramentas situada na borda superior do programa estão disponíveis diversos tipos de opções para ajudar em seu

desenho, como opções de criação de camadas, exibição de grade, posicionamento, métodos de entrada, seleção, gravação de seu

diagrama, entre outras.

E N G E N H A R I A D E S O F T W A R E 1 0 7

MMIICCRROOSSOOFFTT VVIISSIIOO 22000033

Figura 57 – Tela principal do Visio 2003

Na barra de ferramentas situada na borda superior do programa

estão disponíveis diversos tipos de opções para ajudar em seu desenho, como opções de criação de camadas, exibição de grade, posicionamento,

métodos de entrada, seleção, gravação de seu diagrama, entre outras. Clique em Software e Banco de Dados e escolha...

DIAGRAMA DE MODELO UML

Surge a tela a seguir:

E N G E N H A R I A D E S O F T W A R E 1 0 8

Figura 58 – Tela do Diagrama do Modelo UML

Divide-se em:

ATIVIDADE DE UML

Figura 59 – Atividade de UML

COLABORAÇÃO DE UML

Figura 60 – Colaboração de UML

E N G E N H A R I A D E S O F T W A R E 1 0 9

COMPONENTE UML

Figura 61 – Componente UML

IMPLANTAÇÃO DE UML

Figura 70 – Implantação de UML

SEQUÊNCIA DE UML

Figura 62 – Sequência de UML

GRÁFICO DE ESTADO DE UML

Figura 63 – Gráfico de Estado de UML

E N G E N H A R I A D E S O F T W A R E 1 1 0

ESTRUTURA ESTÁTICA DE UML

Figura 64 – Estrutura Estática de UML

Nesta área se encontra as formas para o diagrama de classes.

CASO DE USO

Figura 65 – Caso de Uso

PROPRIEDADES DA FORMA

Para inserir uma forma é necessário selecioná-la e arrastá-la para a área de trabalho. Com a forma na área de trabalho, dê um clique duplo e

surge a tela de propriedades de acordo com a forma escolhida.

E N G E N H A R I A D E S O F T W A R E 1 1 1

Figura 66 – Exemplo de Propriedades

Para salvar o arquivo como imagem basta escolher o menu ARQUIVO, SALVAR ou SALVAR COMO e escolher em SALVAR COMO TIPO, o Formato

JPEG (*.jpg):

Figura 67 – Tela do Salvar Como

OBSERVAÇÕES

Neste site há uma apostila sobre o assunto: http://www.projetoderedes.com.br/apostilas/apostilas_so.php

Serial: PHGVY-62VQH-6YR3J-46D86-TG2MT

E N G E N H A R I A D E S O F T W A R E 1 1 2

DDIIAAGGRRAAMMAA DDEE CCAASSOO DDEE UUSSOO

Figura 68 – Etapas do caso de uso

CASOS DE USO

Descreve um conjunto particular de funcionalidades do sistema, modelando o diálogo que uma entidade externa, chamada ator, realiza

com o sistema.

Especifica o comportamento de um sistema ou parte dele. É também uma descrição do conjunto de passos que o sistema executará

para desempenhar suas funções. É baseado em um cenário descritivo de como a entidade externa

interage com o sistema. Identifica eventos que podem ocorrer e descreve a resposta do sistema para estes eventos.

Quando combinados, os casos de uso constituem todas as formas de uso do sistema e fornecem uma visão do sistema focada na

funcionalidade. Possibilita um formato de apresentação compreensível que pode

ser utilizado para aprimorar a comunicação, especialmente entre os projetistas da aplicação e os clientes. São muito usados nas fases

posteriores do ciclo de vida, ajudando na identificação dos objetos, desenvolvimento de planos de teste e documentação.

E N G E N H A R I A D E S O F T W A R E 1 1 3

Figura 57 – Exemplo de diagrama de caso de uso

O fator mais importante para o caso de uso é a ESPECIFICAÇÃO PARA CADA CASO DE USO.

Análise tradicional: O QUE O SISTEMA DEVE FAZER? Análise por caso de uso: O QUE O SISTEMA DEVE FAZER... E PARA

QUEM?

ATOR São entidades do meio ambiente (externa ao sistema)

que interagem com o sistema para obter alguma funcionalidade. Podem ser: humanos, outros sistemas,

organizações, dispositivos externos, etc., que interagem com o sistema. Alguns atores dão início a eventos enquanto outros

interagem com o sistema em decorrência do resultado de outros eventos.

COMO IDENTIFICAR OS ATORES

Quem utilizará as funcionalidades do sistema?

Quem irá manter, administrar e fazer com que o sistema permaneça em operação?

Quem se interessa pelos resultados produzidos pelo sistema? Com quais outros dispositivos ou sistemas o sistema em foco irá

interagir?

CASO DE USO Utilizado para representar as funcionalidades do

sistema. Representar o que o sistema faz (não como).

Figura 69 – Exemplo de diagrama de caso de uso

A descrição do caso de uso ocorre na especificação de casos de uso.

Exemplo: Cliente de banco pode usar um caixa automático para

sacar dinheiro, transferir dinheiro ou consultar o saldo da conta:

E N G E N H A R I A D E S O F T W A R E 1 1 4

Ator: CLIENTE Casos de Uso: sacar dinheiro, transferir dinheiro e consultar

saldo.

Figura 70 – Exemplo de diagrama de caso de uso

COMO IDENTIFICAR CASOS DE USO

O ator precisa ler, criar, destruir, modificar ou armazenar algum tipo de

informação no sistema? O trabalho do ator pode ser simplificado ou tornado mais eficiente

através de novas funções no sistema?

Quais as funções que o ator necessita no sistema? O que o ator necessita fazer?

Quais são os principais problemas com a implementação atual do sistema?

Quais são as entradas e as saídas desejadas?

CENÁRIO

Um cenário é a descrição de uma das maneiras pelas quais um caso

de um pode ser realizado. Um cenário também é chamado de instância de um caso de uso.

Normalmente há diversos cenários para um mesmo um caso de uso.

RELACIONAMENTO DE EXTENSÃO

Um caso de uso pode ser estendido por outro (funcionalidade).

Pode ser usada para: Simplificar fluxos de eventos complexos;

Representar comportamentos opcionais; Lidar com exceções.

A extensão ocorre em pontos específicos (pontos de extensão).

E N G E N H A R I A D E S O F T W A R E 1 1 5

A extensão pode ou não ser usada pelo caso de uso de origem. O <<extend>> ocorre somente entre casos de uso.

Em uma especificação de caso de uso, a extensão seria o fluxo alternativo (comportamento opcional).

RELACIONAMENTO DE INCLUSÃO

Um caso de uso pode ser incluir outro no sentido de sempre utilizar suas funcionalidades. Pode ser usada para:

Representar comportamentos reutilizáveis; Simplificar fluxos de eventos complexos.

O <<include>> é um vínculo obrigatório, ou seja, SEMPRE usará as suas funcionalidades (inclui todo o comportamento do caso de uso que

está sendo incluído).

RELACIONAMENTO DE ESPECIALIZAÇÃO

Um caso de uso pode ser especializar outro (adição/refinamento do

fluxo de eventos original). Especialização permite modelar comportamento de estruturas de aplicação em comum.

Este tipo de relacionamento ocorre entre atores e entre casos de uso.

RELACIONAMENTO ENTRE CASOS DE USO

GENERALIZAÇÃO: mesma semântica da generalização entre classes;

INCLUDE: caso de uso base incorpora o comportamento do caso de uso incluído (reutilização);

EXTEND: caso de uso base incorpora o comportamento de um outro

caso de uso em local especificado. Utilizamos este relacionamento quando é necessário modelar parte do caso de uso que o usuário

pode ver como comportamento opcional do sistema.

E N G E N H A R I A D E S O F T W A R E 1 1 6

Figura 71 – Tipos de Relacionamentos

As setas do <<include>> e do <<extend>> são tracejadas, o que

muda é o sentido da seta: no include, a seta parte do caso de uso base para o caso de uso a ser incluído. Já no extend a seta parte do caso de

uso que estende para o caso de uso estendido.

Exemplo de INCLUDE:

Figura 72 – Exemplo de diagrama de caso de uso <<include>>

E N G E N H A R I A D E S O F T W A R E 1 1 7

Exemplo de EXTEND:

Figura 73 – Exemplo de diagrama de caso de uso <<extend>>

EXEMPLO: ESTUDO DE CASO – LOCADORA DE VEÍCULOS

Uma locadora de veículos deseja um sistema para facilitar o atendimento a seus clientes. O processo de aluguel de carros atual é confuso e está gerando insatisfação entre os clientes. A locadora é composta basicamente pelos seus

funcionários e carros para aluguel. Os funcionários são identificados por cpf, nome, endereço, telefone. Já os carros estão divididos em diversos tipos:

popular, luxo, utilitário, etc. As informações importantes sobre os carros a serem armazenadas são: código (chapa do carro), tipo, modelo, ano, cor, chassis, km e valor do aluguel (diárias e semanais).

Os funcionários serão responsáveis pelo cadastro dos clientes e dos carros adquiridos pela locadora, por efetuar o aluguel de um carro para o cliente e dar

baixa no aluguel. Existem clientes especiais e clientes comuns. Os especiais possuem uma taxa de desconto e um valor de quilometragem extra para seus

aluguéis. Qualquer cliente é identificado por RG, nome, CPF, telefone, endereço, cidade.

Desta forma, o cliente poderá solicitar o aluguel de carros a um funcionário

da locadora. Os tópicos abaixo descrevem as funcionalidades do sistema. Alugar Carro: cliente deve solicitar ao funcionário o aluguel do carro. O

sistema verifica se o carro solicitado pelo cliente está disponível. Caso esteja, o processo de locação é concluído e o carro passa a estar indisponível. A data de aluguel deve ser guardada para calculo do valor do

aluguel na devolução. Dar Baixa: cliente faz devolução do carro para o funcionário e solicita

nota fiscal (recibo) com a quilometragem percorrida e o valor do aluguel. O funcionário coloca o status do carro novamente como disponível, solicita ao sistema para calcular o valor a ser pago e emite o recibo para o cliente.

Cadastrar Cliente: cliente solicita ao funcionário que o cadastre na locadora. O funcionário recebe os dados e cadastra-o.

E N G E N H A R I A D E S O F T W A R E 1 1 8

Cadastrar Carro: funcionário cadastra o carro adquirido.

CASOS DE USO: Alugar carro, dar baixa, cadastrar cliente e

cadastrar carro; ATOR: Funcionario.

Figura 74 – Exemplo de diagrama de caso de uso

ANÁLISE DE CASOS DE USO

Os Casos de uso expressam ―o quê‖ o sistema deverá fazer. E não ―como‖ fazer.

Casos de uso formam a base para testes e documentação do sistema. O modelo de casos de uso expressam todos os casos de uso do

sistema e os seus relacionamentos.

As técnicas para criar e expressar casos de uso em uma aplicação Web são as mesmas para construir outros sistemas de software.

OBJETIVOS: Identificar os atores;

Identificar os casos de uso; Desenhar os casos de uso;

Escrever cenários.

EXERCÍCIOS

1) A figura abaixo ilustra um Diagrama de Casos de Uso e é utilizada no desenvolvimento de projetos de sistemas, utilizando

ferramentas da Análise Orientada a Objetos. O relacionamento entre o ator Cliente e o caso de uso Comprar um produto, é denominado e definido como: (FGV - 2009 - MEC - Analista de Sistemas

- Especialista)

E N G E N H A R I A D E S O F T W A R E 1 1 9

a) Associação/uma funcionalidade do sistema do ponto de vista do

usuário b) Generalização/uma funcionalidade do sistema do ponto de vista do

usuário. c) Associação/uma funcionalidade do sistema do ponto de vista do

relacionamento. d) Globalização/uma funcionalidade do sistema do ponto de vista do

relacionamento. e) Generalização/ uma funcionalidade do sistema do ponto de vista do

relacionamento.

2) ESTUDO DE CASO: RESERVA DE PASSAGENS AÉREAS:

E N G E N H A R I A D E S O F T W A R E 1 2 0

Com base na lista de requisitos funcionais, elabore o diagrama de caso de uso:

RF1: Sistema deve permitir o cadastro de usuários. RF2: Sistema deve permitir que usuário se identifique.

RF3: Sistema deve consultar a classe de voo. RF4: Sistema deve consultar o trecho da viagem.

RF5: Sistema deve permitir consulta aos aeroportos. RF6: Sistema deve permitir consulta as datas disponíveis de ida e

volta.

RF7:Sistema deve permitir que usuário consulta as formas de pagamento.

RF8:Sistema deve enviar para os usuários cadastrados e-mails promocionais.

RF9: Sistema deve permitir que usuário consulta CEP no sistema de correios

RF10: Sistema deve permitir que o usuário solicite a reserva on-line. RF11: Sistema deve gerar código da reserva.

RF12: Sistema deve emitir e-mail para usuário confirmando a reserva com dados.

RF13: Sistema deve permitir que usuário cancela a reserva. RF14: Sistema deve permitir que o administrador emita relatório de

reservas confirmadas. RF15: Sistema deve permitir que o administrador emita relatório de

reservas canceladas.

RF16: Sistema deve validar o pagamento junto com a operadora de cartão.

RF17: Sistema deve permitir que o Administrador emita relatório de usuário cadastrados.

RF18: Sistema deve permitir que usuário edite seus dados pessoais.

3) ESTUDO DE CASO: GESTÃO DE USUÁRIO DE SISTEMAS DE FORMAÇÃO:

RF1:O software deve identificar e validar todos os usuários que desejarem acessá-lo, identificando o seu perfil.

RF2:O software deve disponibilizar ao usuário identificado: as funcionalidades associadas ao seu perfil e ao seu papel no sistema

(coordenador, bolsista, etc), as funcionalidades de acesso restrito e as funcionalidades de acesso público.

RF3:O software deve disponibilizar ao usuário não identificado somente

as funcionalidades públicas. RF4:O software deve permitir ao usuário recuperar a sua senha, caso

esqueça. RF5:O software deve permitir que o administrador inclua, altere ou

exclua usuários. RF6:O software deve permitir que o administrador inclua, altere ou

exclua perfis de acesso.

E N G E N H A R I A D E S O F T W A R E 1 2 1

RF7:O software deve permitir que o administrador associe as funcionalidades disponíveis nos módulos aos perfis cadastrados ou

exclua dos perfis as funcionalidades previamente associados. RF8:O software deve permitir que o administrador associe um usuário

a um perfil de acesso. RF9:O software deve permitir ao administrador consultar as

funcionalidades associadas a um perfil. RF10:O software deve permitir ao administrador consultar aos usuários

associados a um determinado perfil.

RF11:O software deve permitir ao administrador indicar se determinado usuário pode administrar seus substitutos ou não.

RF12:O software deve permitir que os usuários devidamente autorizados designem um ou mais substitutos com os respectivos

períodos de substituição (data inicial e final) e selecionem um subconjunto das suas funcionalidades as quais os substitutos terão

acesso. RF13:O software deve permitir que todos os usuários façam a

manutenção de seus dados pessoais: email, localização, senha e telefones.

RF14:O software deve permitir que os administradores reenviem a senha de qualquer usuário e que os usuários reenviem a própria

senha. RF15:O software deve gerar senhas temporárias, válidas somente no

primeiro login, quando as senhas forem reenviadas pelos

administradores ou pelos próprios usuários. RF16:O software deve solicitar a troca de senha, após o login, para

todas as senhas que já expiraram. RF17:O software deve, caso o usuário corrente seja um substituto,

apresentar a lista de usuários que ele está substituindo na data corrente.

RF18:O software deve, caso o usuário corrente seja um substituto, permitir que ele selecione o usuário com o qual vai atuar, caso ele

seja substituto de mais de um usuário.

4) Estudo de Caso: Transportadora:

Os funcionários da transportadora devem cadastrar clientes, filiais, veículos, funcionários, tipos de veículos, cidades, distancias, categorias

de frete e fretes de clientes.

Clientes são pessoas físicas e possuem: nome, endereço e telefone.

Filiais têm: nome, endereço, telefone, funcionário responsável e

vários veículos. Veículos devem possuir placa e um tipo de veiculo, além de ser necessariamente de uma filial.

Funcionários são identificados pela matricula e têm ainda: nome, endereço, telefone e dependentes (nome e data de nascimento),

além de estar associado, obrigatoriamente a uma filial. Tipo de

E N G E N H A R I A D E S O F T W A R E 1 2 2

veículo apresenta uma descrição (caminhão, moto, etc) e o peso máximo que Pode transportar além de estar associado a veículos.

Cidades contêm nome e estado a que pertence, representando as cidades abrangidas pela empresa. Distância envolve as cidades

origem e destino e para cada par de cidades atendidas, deve haver a distância em quilômetros entre elas.

Categoria do frete deve conter descrição e um percentual, que deve incidir sobre o valor do frete onde, por exemplo, entregas rápidas

têm aumento de 10% entregas super-rápidas tem aumento de 30%

e entrega normal não tem acréscimo no valor. Cada frete tem um código, um cliente, o veiculo deve efetuar o frete, cidade origem e

destino, funcionário responsável e itens a serem transportados, não podendo haver um frete sem os dados citados. Ainda precisa ter o

valor a ser calculado através da distância percorrida entre as cidades: origem e destino e da categoria do frete. Para isso, deve

existir um valor padrão para o km rodado. Um item de transporte é cada objeto a ser transportado num frete e deve possuir apenas

uma descrição e seu peso. Por fim, temos que o sistema ainda deve emitir Nota Fiscal com todas as informações de um determinado

frete, logo após o seu cadastramento.

a) Diagrama de Caso de Uso;

b) Especificação do caso de uso: Cadastrar Cliente.

5) Com base nos requisitos funcionais, criar um diagrama de caso de

uso: RF01 – Cadastrar aparelho de refrigeração

RF02 – Efetuar logon de funcionário RF03 – Cadastrar funcionário

RF04 – Consultar histórico RF05 – Consultar temperatura de ambiente

RF06 – Alterar temperatura de ambiente RF07 – Encaminhar ordem de serviço

RF08 – Gerar relatório de gastos RF09 – Gerar relatório de performance e consumo

RF10 – Consultar funcionário RF11 – Remover funcionário

RF12 – Consultar aparelho de refrigeração RF13 – Remover aparelho de refrigeração

6) ESTUDO DE CASO: LOCADORA DE VEÍCULOS Uma locadora de veículos deseja um sistema para facilitar o

atendimento a seus clientes. O processo de aluguel de carros atual é confuso e está gerando insatisfação entre os clientes. A locadora é

formada basicamente pelos seus clientes e carros para aluguel. Os carros estão divididos em diversos tipos: popular, luxo e utilitário. As

informações importantes sobre os carros a serem armazenadas são:

E N G E N H A R I A D E S O F T W A R E 1 2 3

código (placa do carro), tipo, modelo, ano, cor, chassis, quilometragem e valor do aluguel (diária).

Os funcionários serão responsáveis pelo cadastro dos clientes e dos carros adquiridos pela locadora, por efetuar o aluguel de um carro

para o cliente e dar baixa no aluguel. Existem clientes especiais e clientes comuns. Os especiais possuem uma taxa de desconto e um

valor de quilometragem extra para seus aluguéis. Qualquer cliente é identificado por RG, nome, CPF, telefone, endereço, contato.

a) Diagrama de Caso de Uso; b) Especificação do caso de uso: Cadastrar Cliente e Efetuar Aluguel.

7) ESTUDO DE CASO: SALÃO DE FESTAS RF01 - O software deverá permitir que o gerente cadastre salões de festas. RF02 - O software deverá permitir que o gerente cadastre profissionais. RF03 - O software deverá permitir que o gerente realize o cadastramento de

serviços utilizados em uma festa de casamento, como buffet, carros utilizados.

RF04 - O software deverá permitir que o cliente realize o cadastramento da lista de convidados.

RF05 – O software deverá permitir que o cliente realize o cadastramento das lojas de presentes. RF06 - O software deverá permitir que o cliente elabore da configuração da

festa pelo cliente. RF07 - O software deverá permitir a geração do orçamento para o cliente.

RF08 - O software deverá permitir que o gerente realize a impressão de relatórios de festas. RF09 - O software deverá permitir que o cliente cadastre a lista de presentes.

RF10 - O software deverá permitir que o gerente realize o cadastramento de usuários.

RF11 - O software deverá permitir a autenticação dos usuários

a) Diagrama de caso de uso;

TAREFA 06 – DIAGRAMA DE CASO DE USO (1,0)

Para este sistema, o gerente deve cadastrar agências, clientes e

abrir e fechar contas bancárias. Um cliente possui nome, endereço e

telefone. Um cliente pode abrir várias contas e uma conta pode ser de vários clientes, para o caso de contas conjuntas.

Contas são de uma determinada agência (que possui nome e número), além de poderem estar vinculadas a uma conta de

investimento, que nada mais é que outra conta bancária. Contas ainda devem possuir um número (formado pelo número da agência e pelo

número da própria conta) e saldo disponível, podendo ser corrente normal, corrente especial e poupança.

Para contas poupança, devem-se armazenar os dias de vencimento e, para contas corrente especiais, informar o limite de

crédito. Contas ainda possuem movimentações de saque e depósito,

E N G E N H A R I A D E S O F T W A R E 1 2 4

que devem ter data e valor, além do tipo de movimento, que pode ser débito ou crédito.

Clientes ainda podem solicitar cartões de contas bancárias, que devem ter número, validade e senha para cada cliente, além de talões

de cheques para contas correntes, que devem armazenar o número inicial e final das folhas do talão. O sistema ainda deve permitir aos

clientes consultar saldos e extratos.

DDIIAAGGRRAAMMAA DDEE CCLLAASSSSEESS

Representação dos dados manipulados e armazenados pelos programas de acordo com os conceitos de Orientação a Objetos. Notação

fortemente baseada no Diagrama Entidade-Relacionamento de Peter

Chen. Deve-se observar que o Diagrama de Classes privilegia a descrição segundo o paradigma OO. Resumindo: Trata de dados e funções.

CLASSE É uma descrição de um conjunto de objetos que compartilham os

mesmos atributos, operações, relacionamentos e semântica.

Representa a abstração de um conjunto de OBJETOS do Mundo Real que possuem tipos de características e de comportamento em comum.

Exemplo: PESSOA.

Figura 75 – Elementos de uma Classe (Fonte: RAMOS - USP)

Toda classe deve representar uma abstração conceitual do domínio do problema ou da solução. Assim, uma classe bem estruturada deve ser

uma abstração de um conceito presente no domínio do problema ou da

solução, ser fortemente coesa e possui baixo acoplamento.

E N G E N H A R I A D E S O F T W A R E 1 2 5

CONVENÇÕES

O nome da classe deve começar por letra maiúscula;

O nome do atributo deve iniciar por minúsculo, porém o segundo nome deve ser maiúsculo. Exemplo: Cliente ou SensorTemperatura;

O nome da classe deve ser no singular; Pode-se ter classes sem atributos ou métodos;

Deve ter um nome que a diferencie das outras classes; Normalmente são substantivos ou expressões breves;

ATRIBUTOS

Um atributo é uma propriedade nomeada de uma classe que descreve um intervalo de

valores que as instâncias podem apresentar. Uma classe pode ter qualquer número de

atributos ou mesmo nenhum atributo. Representa alguma propriedade do item

que está sendo modelado, compartilhado por todos os objetos desta classe. Um objeto de

uma classe poderá ter valores específicos para

cada um dos seus atributos. Exemplo: Todo estudando possui nome, data de nascimento, e

sexo.

OPERAÇÕES

Uma operação é a assinatura de uma implementação de um serviço

que pode ser solicitado por algum objeto da classe para modificar seu estado.

VISIBILIDADE É uma propriedade cujo valor (público, protegido ou privado) denota

como o elemento poderá ser visto externamente:

PÚBLICO (+): qualquer objeto pode acessar os atributos ou operações da classe que se relacione com a classe que o possui;

PROTEGIDO (#): atributos e operações de uma classe são acessíveis apenas por suas subclasses, ou seja, pode ser acessado apenas pelos

descendentes da classe; PRIVADO(-): atributos e operações de uma classe são acessíveis

apenas pela própria classe.

RELACIONAMENTOS Especifica como as classes se relacionam. Podem ser de três tipos:

E N G E N H A R I A D E S O F T W A R E 1 2 6

ASSOCIAÇÃO

Especifica que objetos de um elemento estão conectados a objetos de

outros elementos.

Figura 76 – Exemplo de Associação entre Classes (Fonte: RAMOS - USP)

ASSOCIAÇÃO COM NAVEGAÇÃO

É possível navegar de objetos de um tipo até objetos do outro tipo. A

menos que seja especifico o contrário, a navegação será bidirecional. A seta indica a direção a ser seguida.

Figura 77 – Exemplo de Associação com Navegação (Fonte: RAMOS - USP)

AGREGAÇÃO

A informação de agregação é representada por um losango colocado junto à classe que representa o elemento agregador ou ―o todo‖, ou seja,

o diamante indica a classe todo (a que agrega). RESUMO: FAZ PARTE.

E N G E N H A R I A D E S O F T W A R E 1 2 7

Figura 78 – Exemplo de Agregação entre Classes (Fonte: RAMOS - USP)

COMPOSIÇÃO

Também chamada de AGREGAÇÃO COMPOSTA é uma variante à agregação simples, em que é adicionada a seguinte semântica:

– (1) forte pertença do ―todo‖ em relação à ―parte‖; – (2) tempo de vida delimitado (as ―partes‖ não podem existir sem o

―todo‖). Adicionalmente, o ―todo‖ é responsável pela disposição das suas

―partes‖, ou seja, ―o todo‖ é responsável pela criação e destruição das suas ―partes‖. A informação de agregação composta é representada por

um losango cheio colocado junto à classe que representa o elemento agregador ou ―o todo‖.

Figura 79 – Exemplo de Composição entre Classes (Fonte: RAMOS - USP)

CLASSE DE ASSOCIAÇÃO

A associação entre classes pode também ter os seus próprios atributos (e eventualmente operações), devendo ser, por conseguinte,

modelada também como uma classe. A este tipo chamamos de CLASSE DE ASSOCIAÇÃO.

E N G E N H A R I A D E S O F T W A R E 1 2 8

Figura 80 – Exemplo de Classe Associação (Fonte: RAMOS - USP)

HERANÇA

Simplifica a definição de classes que são quase iguais às que já foram

definidas. Permite a reutilização de definições comuns. Geralmente identifica-se uma herança quando diz-se a palavra ―é um‖.

Figura 81 – Exemplo de Herança (Fonte: RAMOS - USP)

HERANÇA MÚLTIPLA

Na herança única, uma classe tem um conjunto de pais (uma cadeia de superclasse). A herança múltipla envolve do que uma cadeia de

superclasses. Problemas:

Choques de nomes de atributos ou métodos; Dificulta a manutenção do código fonte.

E N G E N H A R I A D E S O F T W A R E 1 2 9

Figura 82 – Exemplo de Herança Múltipla (Fonte: RAMOS - USP)

MULTIPLICIDADE

Embora a multiplicidade seja especificada para classes, ela define a

quantidade de objetos que participam de um relacionamento. Existem dois indicadores de multiplicidade para cada associação ou agregação (uma em

cada final de linha).

Figura 85 – Exemplo de Multiplicidade

DIAGRAMA DE CLASSE

É utilizado para:

modelar a visão estática do projeto de um sistema; modelar o relacionamento entre os diversos objetos que farão

parte do sistema; capturar o vocabulário do problema;

ancorar os comportamentos em suas classes;

E N G E N H A R I A D E S O F T W A R E 1 3 0

gerar as declarações da estrutura das classes.

Figura 86 – Exemplo de diagrama de classe

Explicação do diagrama de classes: CLIENTE pode estar associado a 0 OU N PEDIDOS e este está associado a pelo menos um tipo de pagamento

(abstrata, não é instanciada: crédito, dinheiro ou cheque). PEDIDO é composto de partes (agregação): detalhes do pedido, ou seja, um ou mais

detalhes de pedido e está associado a um item do estoque que será dado baixa. A dificuldade é elaborar o diagrama e não na leitura, principalmente

quando há muitas informações. Há projetos com 100 classes e tende a ter complexidade alta e quando o domínio é definido é mais fácil.

COMO FAZER UM DIAGRAMA DE CLASSES

Identifique um primeiro conjunto de classes; Adicione atributos e comportamentos;

Encontre generalizações; Adicione associações;

Reveja o modelo construído adicionando ou removendo classes, atributos, associações ou generalizações.

IDENTIFICANDO AS CLASSES

Ler a especificação de requisitos;

Extrair nomes: simples ou compostos; Eliminar os que são: redundantes, representam instâncias, são vagos

ou genéricos demais e desnecessários para a solução do problema; Atentar na especificação para os nomes que indicam atores que

interagem com o usuário; Decida baseando-se em seu conhecimento do domínio, na

especificação de requisitos ou em um especialista do domínio os dados que devem ser contidos em cada classe.

E N G E N H A R I A D E S O F T W A R E 1 3 1

IDENTIFICANDO OS ATRIBUTOS

Se um subconjunto de atributos de uma classe formam um grupo

coerente pode ser interessante criar uma outra classe para estes atributos.

IDENTIFICANDO O COMPORTAMENTO

Ler a especificação de requisitos;

Extrair verbos: simples ou compostos; Eliminar os que são: redundantes, representam instâncias, são vagos

ou genéricos demais ou desnecessários para a solução do problema; Colocar os comportamentos extraídos nas classes identificadas.

IDENTIFICANDO GENERALIZAÇÕES

Existem duas formas para identificação de generalização:

o BOTTOM-UP: agrupa classes simulares criando uma superclasse; o TOP-DOWN: procurar por classes mais genéricas para então, se

preciso, especializá-las.

IDENTIFICANDO ASSOCIAÇÃO

Começar com as classes considerando mais centrais e importantes; Decidir quais os relacionamentos destas com as outras;

Uma associação existe se uma classe: possui, controla, está conectada para, está relacionada para, é parte de, tem como parte, é membro de

e tem como membro; Alguma outra classe no modelo;

Evite adicionar muitas associações a uma classe. O acoplamento fica

muito alto; Especifique a multiplicidade.

EXEMPLO – ESTUDO DE CASO: LOCADORA DE VEÍCULOS

Este estudo está completo na página 89.

Alugar Carro: cliente deve solicitar ao funcionário o aluguel do carro. O

sistema verifica se o carro solicitado pelo cliente está disponível. Caso esteja, o processo de locação é concluído e o carro passa a estar

Vamos

fazer juntos

????

E N G E N H A R I A D E S O F T W A R E 1 3 2

indisponível. A data de aluguel deve ser guardada para calculo do valor do aluguel na devolução.

Dar Baixa: cliente faz devolução do carro para o funcionário e solicita nota fiscal (recibo) com a quilometragem percorrida e o valor do aluguel.

O funcionário coloca o status do carro novamente como disponível, solicita ao sistema para calcular o valor a ser pago e emite o recibo para o cliente.

Cadastrar Cliente: cliente solicita ao funcionário que o cadastre na locadora. O funcionário recebe os dados e cadastra-o.

Cadastrar Carro: funcionário cadastra o carro adquirido.

PASSOS PARA IDENTIFICAR AS CLASSES (HEURÍSTICA)

1. Descrição dos requisitos; 2. Extrair os substantivos;

3. Tentativa de classes; 4. Eliminar classes estranhas;

5. Classes identificadas.

EXERCÍCIOS

1) Em relação aos relacionamentos abaixo responda:

a) Qual a representação mais correta – a primeira ou segunda relação? Por quê?

2)Qual a diferença de intepretação entre as duas representações? Qual

seria mais indicada para um tribunal regional eleitoral?

E N G E N H A R I A D E S O F T W A R E 1 3 3

3) Com base nos requisitos funcionais abaixo, defina um diagrama de classes: RF01 - O software deverá permitir que o gerente cadastre salões de festas. RF02 - O software deverá permitir que o gerente cadastre profissionais.

RF03 - O software deverá permitir que o gerente realize o cadastramento de serviços utilizados em uma festa de casamento, como buffet, carros utilizados.

RF04 - O software deverá permitir que o cliente realize o cadastramento da lista de convidados. RF05 – O software deverá permitir que o cliente realize o cadastramento das

lojas de presentes. RF06 - O software deverá permitir que o cliente elabore da configuração da festa

pelo cliente. RF07 - O software deverá permitir a geração do orçamento para o cliente. RF08 - O software deverá permitir que o gerente realize a impressão de

relatórios de festas. RF09 - O software deverá permitir que o cliente cadastre a lista de presentes.

RF10 - O software deverá permitir que o gerente realize o cadastramento de usuários. RF11 - O software deverá permitir a autenticação dos usuários

4) Com base no estudo de caso abaixo faça o diagrama de classes:

Os funcionários da transportadora devem cadastrar clientes, filiais,

veículos, funcionários, tipos de veículos, cidades, distancias, categorias de

frete e fretes de clientes. Clientes são pessoas físicas e possuem: nome, endereço e telefone.

Filiais têm: nome, endereço, telefone, funcionário responsável e vários veículos. Veículos devem possuir placa e um tipo de veiculo, além de

ser necessariamente de uma filial.

Funcionários são identificados pela matricula e têm ainda: nome,

endereço, telefone e dependentes (nome e data de nascimento), além de estar associado, obrigatoriamente a uma filial. Tipo de veículo

apresenta uma descrição (caminhão, moto, etc) e o peso máximo que Pode transportar além de estar associado a veículos.

Cidades contêm nome e estado a que pertence, representando as cidades abrangidas pela empresa. Distância envolve as cidades origem

E N G E N H A R I A D E S O F T W A R E 1 3 4

e destino e para cada par de cidades atendidas, deve haver a distância em quilômetros entre elas.

Categoria do frete deve conter descrição e um percentual, que deve incidir sobre o valor do frete onde, por exemplo, entregas rápidas têm

aumento de 10% entregas super-rápidas tem aumento de 30% e entrega normal não tem acréscimo no valor. Cada frete tem um código,

um cliente, o veiculo deve efetuar o frete, cidade origem e destino, funcionário responsável e itens a serem transportados, não podendo

haver um frete sem os dados citados. Ainda precisa ter o valor a ser

calculado através da distância percorrida entre as cidades: origem e destino e da categoria do frete. Para isso, deve existir um valor padrão

para o km rodado. Um item de transporte é cada objeto a ser transportado num frete e deve possuir apenas uma descrição e seu

peso. Por fim, temos que o sistema ainda deve emitir Nota Fiscal com todas as informações de um determinado frete, logo após o seu

cadastramento.

4) Com base nos requisitos funcionais abaixo, faça o diagrama de caso de uso e o diagrama de classe:

RF01. O sistema deve permitir á secretaria cadastrar cursos contendo código, descrição e professor coordenador.

RF02. O sistema deve permitir à secretaria cadastrar disciplinas de cursos contendo código, descrição, carga horária, ementa, bibliografia e pré-

requisitos;

RF03. O sistema deve permitir à secretaria cadastrar alunos contendo matrícula, o nome, endereço, telefone e curso para o qual aprovado.

RF04. O sistema deve permitir ao departamento de recursos humanos (RH) cadastrar professores, contendo nome, endereço, telefone e titulação

máxima (graduação, especialização, mestrado, doutorado) e cursos que esteja vinculado.

RF05. O sistema deve permitir à secretaria abrir turmas de disciplinas e cursos, informando ano e semestre, dias da semana e horários de

realização. RF06. O sistema deve permitir aos coordenadores de curso alocar

professores a determinadas turmas. RF07. O sistema deve permitir a secretaria matricular alunos em turmas.

RF08. O sistema deve permitir aos professores lançar avaliações (duas notas parciais, nota da prova final e frequência) dos alunos das turmas

que estejam sob sua responsabilidade.

RF09. O sistema deve permitir aos alunos consultar suas avaliações. RF10. O sistema deve permitir à secretaria emitir diários de classes de

turmas. RF11. O sistema deve permitir à secretaria emitir históricos escolares de

alunos. RF12. O sistema deve efetuar o cálculo da aprovação de alunos em

turmas, sendo que para ser aprovado, deve-se ter frequência mínima de 75%. Além disso, para aprovação sem prova final, a média das notas

E N G E N H A R I A D E S O F T W A R E 1 3 5

parciais deve ser maior ou igual a 70. Para reprovação direta esta média deve ser menor que 30. Médias entre 30 (inclusive) e 70 (exclusive)

colocam o aluno em prova final. Se média da prova final com a média anterior for menor que 50, o aluno está reprovado, caso contrário,

aprovado. RF09. O sistema deve controlar a situação de um aluno, podendo estar

matriculado, trancado, formado, ou ter abandonado o curso.

5) Faça o diagrama de classes do estudo de caso abaixo: Uma locadora de veículos deseja um sistema para facilitar o

atendimento a seus clientes. O processo de aluguel de carros atual é confuso e está gerando insatisfação entre os clientes. A locadora é

formada basicamente pelos seus clientes e carros para aluguel. Os carros estão divididos em diversos tipos: popular, luxo e utilitário. As

informações importantes sobre os carros a serem armazenadas são: código (placa do carro), tipo, modelo, ano, cor, chassis, quilometragem e

valor do aluguel (diária). Os funcionários serão responsáveis pe3lo cadastro dos clientes e dos carros adquiridos pela locadora, por efetuar o

aluguel de um carro para o cliente e dar baixa no aluguel. Existem clientes especiais e clientes comuns. Os especiais possuem uma taxa de desconto

e um valor de quilometragem extra para seus aluguéis. Qualquer cliente é identificado por RG, nome, CPF, telefone, endereço, contato.

6) Faça o diagrama de controle de respostas das questões de uma prova: A Instituição de Ensino ―UniLinense‖ deseja controlar todas as

respostas referentes às questões, de uma determinada prova, aplicadas aos alunos da instituição. Sabe-se que uma prova tem que ter

obrigatoriamente uma questão e pode ter várias, as questões por sua vez fazem parte da prova e só podem estar vinculada a uma determinada

prova. Cada prova tem somente um professor responsável e um mesmo

professor pode se responsabilizar por várias provas. Os alunos a serem controlados se subdividem em alunos regulares e alunos dependentes.

Ambos alunos respondem várias questões e uma questão é aplicada a vários alunos. Para cada questão aplicada a um aluno deseja-se

armazenar uma resposta.

7) Faça o diagrama de controle de venda de veículos:

O objetivo principal desse sistema é controlar as vendas de veículos, direto da fábrica, realizadas pelos Concessionários aos clientes. Sabe-se

que um Concessionário pode vender vários Veículos diretamente da fábrica e que os veículos podem ser vendidos em vários concessionários

(por exemplo, um Gol pode ser vendido por vários concessionários). Toda Venda é destinada a um e somente um Cliente e todo cliente pode

comprar vários veículos.

E N G E N H A R I A D E S O F T W A R E 1 3 6

DDIIAAGGRRAAMMAA DDEE OOBBJJEETTOOSS

Representa a instância (uma ocorrência) do diagrama de classes. Para cada classe temos um objeto (instância) em um determinado tempo.

Podemos enxergar dados reais facilitando a compreensão e a modelagem de estrutura complexas de dados. Auxilia ainda na

identificação de problemas na execução de uma aplicação. A representação gráfica é semelhante à classe, um retângulo com

duas partes. Na primeira é exibido o nome do objeto sublinhado (pode ser omitido desde que mantenha os dois pontos e o nome da classe e na

segunda os seus atributos um em cada linha com seus respectivos

valores:

Nome do Objeto: nome do objeto : nome da classe. Exemplo:

Nome do Atributo: nome do atributo : tipo = valor. Exemplo:

O relacionamento entre os objetos é feito através de links que é a

instância de uma associação. Um nome de papel pode ser mostrado no

final de cada link. Multiplicidade não pode ser exibida para links, pois estão instanciadas. Podem ser exibidos os adornos de agregação,

composição, navegação e qualificadores, notas, restrições e pacotes. Exemplo:

Diagrama de Classes

func1: Funcionário

: Funcionário

Funcionário1

Produto1:Produto

descrição= ―Sala‖ cor = ―azul‖ tamanho = 40 preço = 15,00

Funcionário

nome : string cargo : string salário : real

Projeto

descrição:string inicio: date fim : date custo : real

FuncionárioContratado

carteiraProfissional: string dataAdmissão:date

FuncionárioTerceirizado

inicioContrato:date terminoContrato:date prestadoraServicos:string taxaAdministracao:real

trabalha

gerencia

1..* 1

1

0..1

E N G E N H A R I A D E S O F T W A R E 1 3 7

Diagrama de Objetos

Figura 75 – Modelo de Diagrama de Objetos

EXERCÍCIOS

01. Desenhe um diagrama de objetos para o diagrama de classes abaixo:

P1:Projeto

descrição= ―Desenvolvimento do Sistema DKA‖

inicio = 01/12/2006 fim = 02/02/2007 custo = 6000,00

F1:FuncionarioContratado

nome = ―Porsidônio Souza‖

cargo = ―Analista de Sistemas‖

salário = 3500,00

carteiraProfissional = ―02468-0‖ dataAdmissao = ―01/10/2000‖

F1:FuncionarioContratado

nome = ―Firminiano Neves‖ cargo = ―Analista de Sistemas‖

salário = 3800,00

carteiraProfissional = ―01357-9‖

dataAdmissao = ―15/01/1995‖

F1:FuncionarioTerceirizado

nome = ―Silvio Abreu‖

cargo = ―Analista de Sistemas‖

salário = 2500,00 inicioContrato = ―02/12/2006‖

fimContrato = ―26/02/2007‖

prestadoraServiço = ―SISTEM‖

taxaAdministrativa = 6

gerente

E N G E N H A R I A D E S O F T W A R E 1 3 8

02. Suponha um objeto Matemática de uma classe Disciplina. Escreva as formas nas quais podemos representar esse objeto.

03. Marque dentre os elementos abaixo quais podem ser colocamos em

um diagrama de objetos: ( ) tipo dos atributos

( ) valor dos atributos ( ) nome de papel

( ) nome de associação

( ) multiplicidade ( ) agregação

( ) composição ( ) navegação

( ) notas ( ) restrições

04. Em UML, um diagrama de objetos (Concurso Serpro-2001-

Técnico/Programador de Computador):

a) é a representação de um conjunto de classes. b) é a representação do relacionamento entre interfaces.

c) representa retratos estáticos de instâncias de itens encontrados em diagramas de classes.

d) abrange a visão dinâmica de um sistema.

e) mostra a configuração dos nós de processamento em tempo de execução.

TAREFA 07 – DIAGRAMA DE CLASSES E DIAGRAMA DE OBJETOS (1,0)

Para este sistema, o gerente deve cadastrar agências, clientes e abrir

e fechar contas bancárias. Um cliente possui nome, endereço e telefone. Um cliente pode abrir várias contas e uma conta pode ser de vários

clientes, para o caso de contas conjuntas. Contas são de uma determinada agência (que possui nome e

número), além de poderem estar vinculadas a uma conta de investimento, que nada mais é que outra conta bancária. Contas ainda devem possuir

um número (formado pelo número da agência e pelo número da própria conta) e saldo disponível, podendo ser corrente normal, corrente especial

e poupança. Para contas poupança, devem-se armazenar os dias de vencimento e,

para contas corrente especiais, informar o limite de crédito. Contas ainda possuem movimentações de saque e depósito, que devem ter data e

valor, além do tipo de movimento, que pode ser débito ou crédito. Clientes ainda podem solicitar cartões de contas bancárias, que

devem ter número, validade e senha para cada cliente, além de talões de

cheques para contas correntes, que devem armazenar o número inicial e final das folhas do talão. O sistema ainda deve permitir aos clientes

consultar saldos e extratos.

E N G E N H A R I A D E S O F T W A R E 1 3 9

DDIIAAGGRRAAMMAA DDEE SSEEQQUUEENNCCIIAASS

Vamos imaginar a seguinte situação:

Figura 87 – Exemplo de situação do cotidiano

Um diagrama de sequências exibe a troca de mensagens entre os

objetos na ordem em que elas acontecem, não mostrando os detalhes do que precisa para isto acontecer. A representação gráfica é feita assim:

o OBJETOS: retângulo alinhado no topo do diagrama partindo dele uma linha vertical tracejada chamada LINHA DE VIDA desenhada

até o fim do diagrama. Exemplo:

Figura 88 – Exemplo de Objeto

o CRIAÇÃO DE UM OBJETO: a seta que representa essa mensagem é

desenhada de forma a apontar sua cabeça para o símbolo do objeto. Pode conter o esteriótipo <<create>>.

Figura 89 – Exemplo de criação de objetos

o DESTRUIÇÃO DE UM OBJETO: a seta que representa essa

mensagem é direcionada a um grande X colocado no final da linha de vida. Pode conter o esteriótipo <<destroy>>.

Relatório de Comissões

Preciso da lista de vendedores com o total

de vendas.

Resposta:

100 – Afonso – 15.000,00

215 – Andréa – 30.000,00

A quem pertence a matrícula 100?

RESPOSTA:

100 - Afonso

LivroA:Livro

:Funcionário :ContraCheque

novo()

E N G E N H A R I A D E S O F T W A R E 1 4 0

Figura 90 – Exemplo de destruição de objeto

o MENSAGENS: são enviadas de um objeto a outro, por meios das

setas que partem de uma linha de vida a outra, identificadas por um nome de operação. Estas mensagens podem ser numeradas.

Ativação: é quando um método de um objeto está sendo executado. Exemplo:

Figura 91 – Exemplo de troca de mensagens

A iteração representa o envio da mesma mensagem diversas vezes para o mesmo objeto, sendo comum o tratamento de coleções de objetos.

A representação é feita dentro de colchetes, incluindo ates do colchete inicial, o asterisco (*). Exemplo:

*[para cada aluno da turma] CalcularMedia() Chamada recursiva ou auto-chamada é quando um objeto passa

mensagem para ele próprio. Exemplo:

Figura 92 – Exemplo de iteração

O diagrama de sequências pode ser desenhado dentro de um frame

(versão 2.0) que identificará o diagrama. Use o prefixo sd(sequence diagram) para indicar o tipo de interação.

:Funcionário :Benefício

excluirBenefício()

x

:Curso :Aluno

Ativação

Mensagem de retorno

obterNome(matrícula)

Mensagem

Iteração

Coordenador

cursoX:Curso disc1:Disciplina

obterGrade()

Grade

*[para cada disciplina]

obterInfDisciplina(cursoX)

[se a Disciplina tem PreReq]

obterPreRequisito(disc1)

auto-chamada

condição: só se

for verdadeira

E N G E N H A R I A D E S O F T W A R E 1 4 1

Figura 93 – Exemplo de diagrama sequência

O diagrama de sequências é frequentemente usado para representar

cenários de casos de uso. Exemplo: CASO DE USO REGISTRAR VENDAS: Diagrama de Classes:

Figura 94 – Exemplo de Diagrama de Classes

Caso de Uso: Registrar vendas

Objetivo: permite cadastrar as vendas efetuadas pelos vendedores.

Ator: assistente de gerência

Cenário Principal

1. O sistema prepara uma lista dos vendedores cadastrados na loja.

2. O usuário informa o número da venda. 3. O usuário informa ainda: a data da venda e o valor da venda.

4. O usuário seleciona o vendedor que efetuou a venda, a partir da lista já montada pelo sistema.

5. O sistema efetua a gravação da venda.

Cenário Alternativo: Venda já cadastrada.

2ª. Se o número da venda já estiver cadastrado, informar ao usuário, mostrar as informações da venda na tela e entrar em modo de

alteração dos dados.

sd DiagramaSeq1

objeto1 objeto2

mensagem

Vendedor

matrícula : string

nome : string dataAdmissao : date

salarioBruto : real

/salarioLiquido : real

percentualComissao : real

obterListaVendedoresAtivos()

calcularSalarioLiquido(dataRef) : real

Venda

numero : integer

data : date valor : real

grava()

1 0..*

E N G E N H A R I A D E S O F T W A R E 1 4 2

Diagrama de Sequências:

Figura 95 – Exemplo de diagrama de sequência

EXEMPLO: ESTUDO DE CASO: SISTEMA GESTOR DE VOTAÇÃO INTERNA

:TelaCadastro :Venda :Vendedor

Assistente de

Gerência

numero_venda

data, valor

seleção do vendedor

obterListaVendedoresAtivos()

busca(número_venda)

grava()

Vamos fazer juntos???

E N G E N H A R I A D E S O F T W A R E 1 4 3

Figura 96 – Estudo de caso – diagrama de sequência

E N G E N H A R I A D E S O F T W A R E 1 4 4

Com base nas especificações de caso de uso abaixo, vamos criar o diagrama de sequências:

Listagem 1. UC Manter Eleição

Descrição: Este caso de uso tem por objetivo manter o cadastro de eleições, permitindo a inclusão, alteração, exclusão ou consulta de eleições.

Atores: Coordenadoria de Eleições Cenário principal: 1. O sistema prepara uma lista de eleições cadastradas, exibindo para cada

uma: objetivo, data da eleição, status da apuração. 1.1. O usuário pode pesquisar uma eleição, informando os seguintes

critérios: - objetivo ou

- período inicial e final em que ocorreu a eleição 2. O sistema habilita as seguintes opções para o usuário:

2.1. Inclusão de eleição 2.2. Alteração de eleição

2.2.1. Para alteração, o usuário deve pré-selecionar a eleição

2.3. Exclusão de eleição 2.3.1. Para exclusão, o usuário deve pré-selecionar a eleição

3. Para a opção de ―Inclusão‖ ou ―Alteração‖: 3.1. O usuário informa/edita:

3.1.1. objetivo da eleição

3.1.2. data da eleição 4. Para a opção de ―Exclusão‖:

4.1. O sistema exibe os dados do item 3.1 desabilitados para edição. 4.2. O usuário confirma a exclusão da eleição.

5. O usuário confirma a operação.

5.1. O sistema atualiza o cadastro de eleições.

Cenários alternativos: Pesquisa de eleição

1.a. A pesquisa de eleição deve desconsiderar caixa alta e baixa, acentuação e realizar a localização dos trechos em qualquer ordem que os mesmos apareçam no cadastro.

1.b. A pesquisa de período deve ser feita considerando os períodos inicial e final, inclusive; podendo ser informado apenas um dos períodos.

Permissão de “Alteração” da eleição 2.a. Se já houver data que indique o início da votação, a eleição não poderá ser alterada. Exibir mensagem de erro e retornar ao passo 1.

Permissão de “Exclusão” da eleição 2.b. Se já houver data que indique o início da votação, a eleição não poderá

ser excluída. Exibir mensagem de erro e retornar ao passo 1. Validação da data de eleição 3.a. Se o usuário informar uma data de eleição que não seja futura, exibir

mensagem de erro e retornar ao passo 3. 3.a. Se o usuário informar uma data de eleição futura que já esteja cadastrada

para outra eleição, exibir mensagem de erro informando a qual eleição a data já está cadastrada e retornar ao passo 3.

E N G E N H A R I A D E S O F T W A R E 1 4 5

Listagem 2. UC Manter Candidatos Descrição: Este caso de uso tem por objetivo manter o cadastro de candidatos,

permitindo a inclusão, alteração, exclusão ou consulta de candidatos. Atores: Coordenadoria de Eleições Pré-condição: existir cadastro prévio de eleições.

Cenário principal: 1. O sistema prepara uma lista de eleições cadastradas, que ainda não

tenham ocorrido a votação (início de votação em branco), exibindo para cada uma: objetivo, data da eleição, lista de candidatos cadastrados. Para cada candidato cadastrado, exibir: número e nome.

2. O usuário seleciona uma eleição. 3. O sistema habilita as seguintes opções para o usuário:

3.1. Inclusão de candidato 3.2. Alteração de candidato

3.2.1. Para alteração, o usuário deve pré-selecionar também o

candidato. 3.3. Exclusão de candidato

3.3.1. Para exclusão, o usuário deve pré-selecionar também o candidato.

4. Para a opção de ―Inclusão‖ ou ―Alteração‖:

4.1. O usuário informa/edita: 4.1.1. número do candidato

4.1.2. nome do candidato 4.1.3. foto do candidato

5. Para a opção de ―Exclusão‖:

5.1. O sistema exibe os dados do item 4.1 desabilitados para edição. 5.2. O usuário confirma a exclusão da eleição.

6. O usuário confirma a operação. 6.1. O sistema atualiza o cadastro de candidatos.

Cenários alternativos:

Validação do número do candidato

4.a. Se o usuário informar um número de candidato já cadastrado na eleição escolhida, exibir mensagem de erro informando a que candidato está associado

e retornar ao passo 4. Listagem 3. UC Iniciar Votação

Descrição: Este caso de uso tem por objetivo dar início à votação de uma eleição.

Atores: Mesário Pré-condição: existir uma eleição cuja data é igual à data vigente e que ainda não tenha tido a votação iniciada.

Cenário principal: 1. O sistema busca a eleição cuja data é igual à data vigente.

2. O usuário confirma o início da votação. 2.1. O sistema atualiza o cadastro de eleições, registrando a data e hora

atual no campo ―início da votação‖.

Cenários alternativos:

Não se aplica

E N G E N H A R I A D E S O F T W A R E 1 4 6

Listagem 4. UC Habilitar Eleitor Descrição: Este caso de uso tem por objetivo validar o eleitor e liberar a urna

para votação. Atores: Mesário Pré-condição: existir uma eleição cuja data é igual à data vigente e cujo início

da votação já tenha sido preenchido. Cenário principal:

1. O usuário informa a matrícula do eleitor. 1.1. O sistema busca o eleitor, exibindo o seu nome.

2. O usuário libera a urna para votação.

Cenários alternativos:

Validação da matrícula do eleitor 1.a. Se o usuário informar um número de matrícula que não exista no cadastro, exibir mensagem de erro e retornar ao passo 1.

1.b. Se o eleitor já tiver votado na eleição corrente, exibir mensagem de erro e retornar ao passo 1.

Permissão para liberar a urna 2.a. Se o eleitor anterior ainda não tiver finalizado a votação, exibir mensagem de erro e retornar ao passo 1.

Listagem 5. UC Votar

Descrição: Este caso de uso tem por objetivo permitir que o eleitor registre o seu voto. Atores: Eleitor

Pré-condição: a urna estar liberada para votação. Receber a identificação da eleição e do eleitor habilitado para votação.

Cenário principal: 1. O sistema busca e exibe todos os candidatos associados à eleição

identificada. 1.1. Para cada candidato, o sistema exibe: número do candidato, nome do

candidato e foto do candidato.

2. O sistema habilita as opções ―Nulo‖ e ―Branco‖. 3. O usuário seleciona um dos candidatos ou uma das opções ―Nulo‖ ou

―Branco‖. 4. O usuário confirma a votação. 5. O sistema atualiza o cadastro de votação.

5.1. O sistema registra que o eleitor identificado já efetuou seu voto, sem associá-lo ao voto.

5.2. O sistema computa 1 voto para o candidato selecionado ou para as opções ―Nulo‖ ou ―Branco‖.

5.3. O sistema libera a urna.

Cenários alternativos:

Permissão de correção da votação 4.a. O usuário pode solicitar a correção do seu voto, no momento de confirmar a votação. Nesse caso, o sistema deve retornar ao passo 3.

E N G E N H A R I A D E S O F T W A R E 1 4 7

EXERCÍCIOS

01. No diagrama de sequências, o que representa a dimensão vertical?

02. No diagrama de sequências, como é chamada a linha que parte da

representação do objeto?

03. No diagrama de sequências, o que representa um grande X no final da linha de vida?

04. Como as mensagens são enviadas num diagrama de sequências?

05. O que representa a ativação num diagrama de sequências?

06. Indique quais elementos abaixo não aparecem em um diagrama de sequências:

objetos, mensagens, iteração, nós, condições, relacionamento de agregação, ator e estado.

07. Faça o diagrama de sequência para abertura de conta comum:

Inicialmente o Cliente solicita ao Funcionário a abertura de uma conta, então o Banco faz uma consulta do cliente pelo seu CPF

(Método), na classe Física, se o cliente se encontra cadastrado, a consulta retorna com os Dados do Cliente, se não o cadastro do

cliente deverá ser realizado. No cadastro do cliente (Física), deverá conter um método para

validar o CPF, evitando assim, o cadastro de clientes com CPF inexistente.

Após o cadastro do cliente o funcionário receberá uma resposta do

Sistema informando que o cliente está atualizado, da mesma forma que o funcionário comunica ao cliente que seu cadastro foi

aprovado. Ao receber a resposta do funcionário, o cliente deve informar valor

do depósito a ser feito e sua senha. Essa mensagem irá disparar um método para abertura de uma nova conta comum, que por sua vez,

irá registrar esse histórico. O Cliente deverá ser informado sobre o status de sua conta, ou seja,

que a abertura da conta foi concluída.

08. Faça o digrama de sequência para o encerramento de uma conta:

Neste caso o Cliente solicita ao Funcionário o encerramento de sua

conta, o Funcionário por sua vez deve verificar a conta, neste

momento, é necessária a senha do cliente e em seguida se existe Saldo.

Se o Funcionário receber a resposta de que o saldo é positivo, deve haver o saque do valor.

E N G E N H A R I A D E S O F T W A R E 1 4 8

Assim como qualquer movimentação, havendo o saque deve-se registrar o histórico referente ao Saque.

Após a confirmação do saque, deve ser disparado o método de encerramento de Conta. Em seguida avisar ao cliente.

09. Diagrama referente a solicitação de Extrato de uma conta comum através de um caixa eletrônico.

10. Com base na especificação de caso de uso abaixo, criar um diagrama

de sequências:

Criar Matrícula (CSU001) Sumário: O aluno solicita do sistema, sua matrícula em uma determinada disciplina. O sistema verifica se o aluno possui os pré-requisitos necessários e em

caso afirmativo registra a matrícula. Ator Primário: Aluno

Pré-condições: O aluno está logado no sistema. Fluxo Principal

1. O aluno solicita o formulário (tela) de matrícula. 2. O sistema solicita um código de disciplina. 3. O aluno fornece um código de disciplina.

4. O sistema exibe o nome completo (descrição) da disciplina. 5. O sistema verifica a grade do curso para conhecer os pré-requisitos para

aquela disciplina. 6. O sistema verifica o histórico do aluno para determinar se ele possui os pré-requisitos necessários.

7. Se sim, o sistema registra a nova matrícula, emite uma mensagem de aceitação.

8. O sistema oferece alternativa de mais matrículas ou de encerramento. 10. O aluno seleciona encerramento e o caso de uso se encerra. Fluxo Alternativo: O aluno seleciona mais matrículas e o caso de uso retorna

ao passo 2 (pode acontecer no passo 8). Fluxo de exceção: O aluno não possui os pré-requisitos (pode acontecer no

passo 6). 1. O sistema reporta essa situação e retorna ao passo 8. Pós-condições: As matrículas efetuadas tornam-se disponíveis aos

coordenadores de curso para avaliação. Regras de Negócio: Um aluno não pode se matricular em disciplinas que não

tenha cursado seus pré-requisitos.

TAREFA 8 – DIAGRAMA DE SEQUENCIAS (1,0)

Uma locadora de veículos deseja um sistema para facilitar o atendimento a seus clientes. O processo de aluguel de carros atual é

confuso e está gerando insatisfação entre os clientes. A locadora é formada basicamente pelos seus clientes e carros para aluguel. Os carros

estão divididos em diversos tipos: popular, luxo e utilitário. As informações importantes sobre os carros a serem armazenadas são:

E N G E N H A R I A D E S O F T W A R E 1 4 9

código (placa do carro), tipo, modelo, ano, cor, chassis, quilometragem e valor do aluguel (diária). Os funcionários serão responsáveis pe3lo

cadastro dos clientes e dos carros adquiridos pela locadora, por efetuar o aluguel de um carro para o cliente e dar baixa no aluguel. Existem clientes

especiais e clientes comuns. Os especiais possuem uma taxa de desconto e um valor de quilometragem extra para seus aluguéis. Qualquer cliente é

identificado por RG, nome, CPF, telefone, endereço, contato.

a) Cadastrar cliente; b) Efetuar aluguel.

E N G E N H A R I A D E S O F T W A R E 1 5 0

AANNEEXXOO -- SSOOLLUUÇÇÕÕEESS PPAARRAA PPRROOBBLLEEMMAASS NNAA EENNGGEENNHHAARRIIAA DDEE

RREEQQUUIISSIITTOOSS

Figura 64 – Requisitos

Recordando, engenharia de requisitos, descreve o conjunto de atividades para a produção de requisitos e gerencia de requisitos. Há dois

grupos de atividades:

PRODUÇÃO DE REQUISITOS

o LEVANTAMENTO: atividade que se relaciona com a obtenção dos requisitos e para isto temos analistas e engenheiros que

trabalham junto com o usuário para levantar as limitações de hardware, o funcionamento do sistema, desempenho do sistema,

e outras informações necessárias para dar continuidade da produção do software. Há varias atividades como entrevistas,

JAD, BRAINTORMING, WORKSHOP DE REQUISITOS, USO DE PROTOTIPOS PARA APOIAR O REQUISITO.

o Registro: uma vez identificados precisam ser documentados para servir de base para o resto do desenvolvimento. Ou seja é

especificação, descrição dos requisitos levantamentos junto com o cliente neste contexto. Administrar o grande volume de

informações levantados é um problema, é preciso identificar o

nível de detalhe correto para suprir as necessidades de diferentes atividades no ciclo de vida do projeto.

o VALIDAÇÃO: comprometimento do cliente de acordo com os requisitos levantados; aceite do cliente sobre determinado

artefato. Ou seja identificamos o que o software atende.

E N G E N H A R I A D E S O F T W A R E 1 5 1

o VERIFICAÇÃO: examina a especificação do software assegurando que todos os requisitos foram definidos, sem omissão,

ambiguidade, detectando e corrigindo defeitos na fase de definição dos requisitos, fornecendo uma melhor qualidade nos

requisitos que está sendo elaborada.

GERENCIA DE REQUISITOS Os requisitos são voláteis e diversos fatores contribuem para isto

(mudança externa, por exemplo: legislação, mercado, posicionamento

estratégico da empresa, erros ocorridos no processo de requisitos). E isto traz a necessidade de alteração nos requisitos e esta alteração

precisa ser ordenada para que não haja perda de custo e prazo. CONTROLE DE MUDANÇA: como são voláteis, sofrem mudanças e

para conduzir a mudança é necessário o preparo e planejamento. Uma forma para organizar é definir um processo mais formal

para ter controle sobre a mudança e sobre isto há uma analise de impacto para achar em que momento a mudança pode ser

atendida e o impacto desta mudança no software e esta mudança pode ser aprovada ou rejeitada que deverá apresentar os motivos

da rejeição. GERENCIA DE CONFIGURAÇÃO: Assunto amplo. Garantir que

estamos trabalhando com as versões corretas dos diferentes itens de configuração que esta sendo criado no desenvolvimento

e a especificação de requisitos é um destes documentos. Para

garantir que a equipe esteja trabalhando na ultima versão. RASTREABILIDADE: permite identificar ou entender como os

diferentes conceitos ou elementos estão sendo tratados nas diferentes fases do desenvolvimento e devemos garantir que as

transformações estejam correndo e de forma correta. Podemos verificar a analise de impacto de uma alteração.

GERENCIAMENTO DA QUALIDADE DE REQUISITOS: garante que as atividades do produto produzido estão sendo seguidas

corretamente.

ELICITAÇÃO DE REQUISITOS Por ser onde identificamos os requisitos, ou seja a ideia inicial do

sistema, é necessário a compreensão do problema.

PROBLEMAS

Escopo; Entendimento;

Volatilidade.

DESAFIOS

Falta de conhecimento do usuário das suas reais necessidades;

E N G E N H A R I A D E S O F T W A R E 1 5 2

Falta de conhecimento do desenvolvedor do domínio do problema; Domínio do processo de elicitação de requisitos pelos desenvolvedores;

Comunicação inadequada entre os desenvolvedores e usuários; Dificuldade do usuário tomar decisões;

Problemas de comportamento; Questões técnicas.

PROBLEMA: ENVOLVER INTERESSADOS INAPROPRIADOS

SOLUÇÃO

Identificar interessados apropriados; Verificar constantemente a necessidade de participação de outros

usuários; Utilizar técnicas de apoio como workshop e requisitos JAD.

PROBLEMA: POLÍTICA NA ORGANIZAÇÃO

SOLUÇÃO

Ciclo de vida iterativo incremental;

Obtenção explícita do comprometimento com os requisitos;

Análise de impacto.

PROBLEMA: A LINGUAGEM NATURAL E A ABSTRAÇÃO DOS REQUISITOS DE ALTO NÍVEL DIFICULTAM O MAPEAMENTO DAS CAPACIDADES MACRO EM REQUISITOS

FUNCIONAIS E NÃO FUNCIONAIS.

SOLUÇÃO

Necessário aumentar a interação entre o engenheiro de requisitos e o usuário;

Iniciar as entrevistas com o cliente com perguntas abertas; Possibilidade de empregar técnicas de elicitação complementares como

etnografia (observação do ambiente operacional do cliente).

PROBLEMA: SEPARAR PREMISSAS RELACIONADAS AO DESENVOLVIMENTO DO

SISTEMA DOS SEUS REQUISITOS

SOLUÇÃO

Estabelecer templates e diretrizes que orientem a separação adequada

do conteúdo do documento de requisitos; Fazer uso de revisões técnicas para assegurar a qualidade dos

documentos produzidos.

E N G E N H A R I A D E S O F T W A R E 1 5 3

CASOS DE USO

Figura 65 – Exemplo de Especificação de Caso de Uso

PROBLEMA: DIFICULDADE NA DESCRIÇÃO DE REQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS.

SOLUÇÃO

Utilização de revisões técnicas formais; Treinamentos podem ser conduzidos focando nos problemas

encontrados nas inspeções.

PROBLEMA: COMPLEXIDADE NO DETALHAMENTO DOS CASOS DE USO PARA

DEFINIÇÃO DA SOLUÇÃO

SOLUÇÃO

Manter os passos simplificados, contudo assegurando que todas as

informações necessárias (informações recebidas, opções

disponibilizadas, informações fornecidas e ações realizadas) estejam descritas;

A separação do caso de uso em diversos casos de uso relacionados através de inclusões (includes) e extensões (extends).

E N G E N H A R I A D E S O F T W A R E 1 5 4

PROBLEMA: DETALHAMENTO TÉCNICO DESNECESSÁRIO DURANTE A ESPECIFICAÇÃO FUNCIONAL DO SISTEMA.

SOLUÇÃO

Utilização de revisões técnicas formais; Treinamento pode ser fornecido para esclarecer o conteúdo apropriado

da especificação funcional.

GERÊNCIA DE REQUISITOS

PROBLEMA: DIFICULDADES DE ESTABELECER UMA ESTRATÉGIA PARA A ATUALIZAÇÃO E REUTILIZAÇÃO DE CASOS DE USO

SOLUÇÃO

Criar uma biblioteca de casos de uso estruturada de acordo a divisão funcional (módulos) dos sistemas da organização;

Tratar cada caso de uso como um item de configuração.

PROBLEMA: REPRESENTAR A ATUALIZAÇÃO DE CASOS DE USO

SOLUÇÃO

Preenchimento de um histórico de versões dos casos de uso, informando a data, as alterações realizadas e o responsável pelas

alterações. Tratar cada caso de uso como um item de configuração e inserir no

processo de gerência de configuração.

Figura 63 – Exemplo de histórico de versões

E N G E N H A R I A D E S O F T W A R E 1 5 5

PROBLEMA: DIFICULDADE DE INTEGRAÇÃO DAS PRÁTICAS DE GERÊNCIA DE REQUISITOS COM GERÊNCIA DE CONFIGURAÇÃO.

SOLUÇÃO

Definir um processo de gerência de configuração padrão. A evolução dos requisitos deve estar alinhada com a evolução das baselines de

requisitos;

Os requisitos acordados em uma baseline somente podem ser alterados

através de solicitações de mudança.

PROBLEMA: TRABALHAR COM O BACKLOG DE CASOS DE USO INEXISTENTES PARA SISTEMAS EM MANUTENÇÃO.

SOLUÇÃO

Considerar uma abordagem evolutiva para a criação dos casos de uso, onde inicialmente a documentação consiste de um resumo do caso de

uso (contendo, por exemplo, apenas o fluxo principal).

PROBLEMA: DIFICULDADE DE IMPLANTAÇÃO E MANUTENÇÃO DA

RASTREABILIDADE DOS REQUISITOS.

SOLUÇÃO

Estabelecer um processo de desenvolvimento que integre as atividades

relacionadas ao estabelecimento da rastreabilidade com as próprias atividades de engenharia do software;

Algumas ferramentas CASE permitem o estabelecimento dos links de rastreabilidade no momento da criação e atualização dos artefatos.

PROBLEMA: DIFICULDADES DE ESTABELECIMENTO RETROATIVO DE RASTREABILIDADE DOS REQUISITOS

SOLUÇÃO

O estabelecimento retroativo de rastreabilidade pode ser

extremamente custoso e uma análise de custo/benefício deve ser considerada antes de realizar esta tarefa.

BOAS FÉRIAS!!!! Obrigada por tudo e me desculpe

por alguma coisa.