Engenharia de Software II - Apostila

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). Lincoln). 2º SEMESTRE DE 2013

ENGENHARIA

DE

SOFTWARE

2

Sumário

INFORMAÇÕES IMPORTANTES ................................................................. ................................................... 7 OBJETIVOS: ............................................................... ................................................................. .................. 7  Sugestão de L i vr os, Revistas Revi stas e Si Si tes  ............................................................................................................... 7  Softwares ........................................................... ........................................................... ................................................................. ............................. 7  Quant idade de aul as semanais e Quan ti dade de f altas per per mi ti das  ............................................................... 7  Abono de F altas ........................................................... ........................................................... ................................................................. .................. 8 Contato .............................................................. .............................................................. ................................................................. ............................. 8   .............................................................................................................................................................. .............................................................................................................................................................. 8 Avisos  Con teúdo teúdo das d as Aval A val i ações ........................................................ ........................................................ .............................................................. .......... 8 F or m a de Aval A val i ação ........................................................................................................................................ ........................................................................................................................................ 8 Di scipl scipl in as, as, Di as e Hor ár ios que me encontr encontr o na F atec ............................................................. .................. 8 Er ros da Apostil Apostil a: ........................................................ ......................................................................................................................... ................................................................. .................. 8

TRABALHO SEMESTRAL ......................................................... .............................................................. .......... 9 TAREFA 01 - REVISÃO REV ISÃO DE ENGENHARIA DE SOFTWARE I (VALOR : 0,5) 0,5 ) ........................................... 10

1ºBIMESTRE

DESENVOLVIMENTO DESOFTWARE .................................................................................................. 14

REQUISITOSDE DESO 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

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

ELICITAÇÃODERE REQUISITOS.......... .... ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... ......... .... 26 OBJETIVOS DA ELICITAÇÃO DE REQUISITOS ........................................................................................ 28 PASSOS PARA A ELICITAÇÃO DE REQUISITOS ............................................................ ....................................................................................... ........................... 28 QUESTÕES QUE PRECISAM SER RESPONDIDAS 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  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

ENGENHARIA

DE

SOFTWARE

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................................................................................................................... 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  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  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....................................................................................... REQUISITOS...................................... ................................................. 65 CONSEQUENCIAS ....................................................................................................................................... 65 PEQUENO CHECKLIST DE 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: FERRAMEN TA: ............................................................ ........................................................... 72  ETAPAS PARA O RASTREAMENTO ........................................................... ................................................. 73  EXERCÍCIOS ......................................................................... ............................................................... ........ 74

MATRIZ DE RASTREABILIDADE ................................................................................................................ 76 RASTREABILIDADE ................................................................ ................................................................................................................................ ...................................................................... ...... 76 OBJETIVOS................................................................................................................................................... 76  MATRIZ DE R ASTREABILIDADE ........................................................................................................ ................................................. 78 ASTREABILIDADE DEFINIDAS .......................................................  EXERCÍCIOS ......................................................................... ............................................................... ........ 79

ORIENTAÇÃO A OBJETOS ................................................................................................ ............................ 80 HISTÓRIA ........................................................................................................................................................ 80 CONCEITOS FUNDAMENTAIS......................................................... ....................................................................................................................... ...................................................................... ........ 81 OBJETO ........................................................................................................................................................ 82  ATRIBUTO ........................................................ ................................................................. ........................... 83

ENGENHARIA

DE

SOFTWARE

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

ENGENHARIA

DE

SOFTWARE

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 DESENVOLVIMEN TO 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 ESPE CIFICAÇÃ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 INEXISTEN TES PARA SISTEMAS  EM MANUTENÇÃO. ............................................................... ................................................................. ... 155  PROBLEMA: DIFICULDADE DE IMPLANTAÇÃO E MANUTENÇÃO DA RASTREABILIDADE DOS  REQUISITOS................................................................ ................................................................. .............. 155

ENGENHARIA

DE

SOFTWARE

6

 PROBLEMA: DIFICULDADES DE ESTABELECIMENTO RETROATIVO DE RASTREABI LIDADE DOS  REQUISITOS...................................................................................................................... ......................... 155

ENGENHARIA

DE

SOFTWARE

7

INFOR MAÇÕES  IIMPOR TANTES 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%26f  ref%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.

ENGENHARIA

DE

SOFTWARE

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: [email protected] e/ou [email protected] Obs. O email: [email protected] é 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!

ENGENHARIA

DE

SOFTWARE

9

TR ABALHO  S SEMESTR AL

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!!!!

ENGENHARIA

DE

SOFTWARE

10

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

1.

a) b)

c) d) e)

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 engenharia de requisitos de um software, em geral, precede a engenharia dos requisitos do sistema de informações no qual o software será usado. 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. 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. É 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. 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

ENGENHARIA

DE

SOFTWARE

11

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.

ENGENHARIA

DE

SOFTWARE

12

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.

ENGENHARIA

DE

SOFTWARE

13

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

ENGENHARIA

DE

SOFTWARE

14

1º BIMESTR E DESENVOLVIMENTO DE SOFTWAR E O que é processo de software? O que é desenvolvimento de software?

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.

ENGENHARIA

DE

SOFTWARE

15

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: ―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!!!!

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. 1

 ESCOPO:

ENGENHARIA

DE

SOFTWARE

16

R EQUISITOS DE SOFTWAR E

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);

ENGENHARIA





DE

SOFTWARE

17

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; 

ENGENHARIA





DE

SOFTWARE

18

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; 

ENGENHARIA







DE

SOFTWARE

19

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: Segundo SOMMERVILLE (2007), são declarações de serviços que o sistema deve prover, descrevendo o que o sistema deve fazer; PFLEEGER (2004), diz que um requisito funcional descreve uma interação entre o sistema e o seu ambiente; 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. o

o

o



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. 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). o



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: SOMMERVILLE (2007) diz que descrevem restrições sobre os serviços ou funções oferecidos pelo sistema; Ou ainda, as quais limitam as opções para criar uma solução para o problema (PFLEEGER, 2004); o

o

ENGENHARIA

DE

SOFTWARE

20

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: Essenciais; Importantes; Desejáveis. Em princípio, sistema deve resolver todos os requisitos de essenciais para requisitos desejáveis. o o o

ENGENHARIA

DE

SOFTWARE

21

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

ENGENHAR IA DE R EQUISITOS 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)

ENGENHARIA

DE

SOFTWARE

22

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, comprometimento e verificação; A produção de requisitos é responsável por: Levantar Requisitos; Registrar Requisitos; Obter Comprometimento; Verificar requisitos.

obtenção

de

   



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.

ENGENHARIA

DE

SOFTWARE

23

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.

ENGENHARIA

DE

SOFTWARE

24

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:

ENGENHARIA

DE

SOFTWARE

25

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.

ENGENHARIA

DE

SOFTWARE

26

ELICITAÇÃO DE R EQUISITOS ― 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 artefatos 2 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)

ENGENHARIA

DE

SOFTWARE

27

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).

ENGENHARIA







DE

SOFTWARE

28

Escopo: Os limites do sistema são geralmente definidos de forma incompleta, ou os clientes 4  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 















4

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.

  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).

ENGENHARIA

DE

SOFTWARE

29

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. 













ENGENHARIA

DE

SOFTWARE

30

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 Experts 5   especificações técnicas, sistemas legadospatrocinadores 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:

Quanto a performance, qual é tempo de resposta adequado?

Quais funcionalidades ele deve ter?

Quanto à usabilidade, o software identifica visualmente a empresa e possui interface ami ável?

5

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

O que o software deve fazer?

Quais são os requisitos de segurança que o software recisa?

ENGENHARIA

DE

SOFTWARE

31

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: Sistema deve registrar as principais ações de cada usuário; 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 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. o o

o



REQUISITOS NÃO-FUNCIONAIS: O sistema deve usar gráficos comparativos do aproveitamento do aluno com a média da turma; O sistema deve usar cores na construção dos gráficos; O tempo de resposta na elaboração do relatório não pode ser superior a 15 segundos. o

o o

CARACTERÍSTICAS DA ELICITAÇÃO DE REQUISITOS 

Definir as técnicas de coleta de requisitos baseadas em fatores operacionais, táticos e financeiros;

ENGENHARIA







DE

SOFTWARE

32

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)

ENGENHARIA

DE

SOFTWARE

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

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

33

ENGENHARIA

DE

SOFTWARE

34

TÉCNICAS  P PAR A  E ELICITAÇÃO  D DE R  R EQUISITOS 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 pr oblema? 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;

ENGENHARIA







SOFTWARE

35

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: permitem aos clientes e usuários do sistema experimentar o sistema; entendendo melhor como o sistema pode ser usado para dar suporte aos seus trabalhos; mal-entendidos entre projetistas e usuários podem ser identificados quando a funcionalidade do sistema é demonstrada usando o protótipo; funções que estão faltando podem ser detectadas usando o protótipo; durante o desenvolvimento de um protótipo, requisitos incompletos e inconsistentes são descobertos. DESVANTAGENS: custo do desenvolvimento de um protótipo; tempo requerido para desenvolver um protótipo (que pode aumentar o tempo de entrega ao usuário); 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; 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. Vantagem: Linguagem natural é a única notação que é geralmente entendível por todos os leitores potenciais dos requisitos. Desvantagem: Os requisitos em linguagem natural podem ser ambíguos, pouco claros e causar mal entendidos. o

o

o

o

o

o o

o

o



DE

o

o

ENGENHARIA

o



DE

SOFTWARE

36

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; 



ENGENHARIA

DE

SOFTWARE

37

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?

ENGENHARIA

   

DE

SOFTWARE

38

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...

ENGENHARIA

                 

DE

SOFTWARE

39

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;

ENGENHARIA

DE

SOFTWARE

40

- 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.

ENGENHARIA

DE

SOFTWARE

41

J AD 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

ENGENHARIA

DE

SOFTWARE

42

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

ENGENHARIA

DE

SOFTWARE

43

- 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 CONVITE

2002

PARA: Ver Lista de Distribuição

Rio de Janeiro, 21 de Maio de

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.

ENGENHARIA

DE

SOFTWARE

44

MODELO DE AGENDA DE CONVOCAÇÃO:

Figura 16 – Modelo de Agenda TOPICOS PARA A AGENDA 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.

ENGENHARIA

 

 

 

 

DE

SOFTWARE

45

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 JAD    



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 REALIZADAS 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.

ENGENHARIA

 

DE

SOFTWARE

46

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);

ENGENHARIA



DE

SOFTWARE

47

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;

ENGENHARIA



 



DE

SOFTWARE

48

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

ENGENHARIA

DE

SOFTWARE

49

ENGENHARIA

DE

SOFTWARE

50

Figura 20 – Relatório de Avaliação de Sessão AVALIAÇÃO DE ACORDO COM O TOTAL OBTIDO

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.    

ENGENHARIA

DE

SOFTWARE

51

ANALISADOR DA REUNIÃO PARA TODOS OS PARTICIPANTES

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: Perspectiva Gerencial; Plano de Sessões; Carta-convite para participação do grupo; Agenda de cada sessão; Lista de Participantes de cada sessão; Documentação produzida em cada sessão; Questionários de Avaliação. o o o o o o o

ENGENHARIA

DE

SOFTWARE

52

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.

ENGENHARIA

DE

SOFTWARE

53

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.

ENGENHARIA

DE

SOFTWARE

54

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 ESCRIBA

É 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‖.

ENGENHARIA

DE

SOFTWARE

55

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;

ENGENHARIA

DE

SOFTWARE

56

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ÍLIOS"

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...) 

 

ENGENHARIA

DE

SOFTWARE

57

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 componente, resolva o estudo de caso abaixo:

papel

para

cada

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.

ENGENHARIA

DE

SOFTWARE

58

ESPECIFICAÇÃO  D DE R  R EQUISITOS 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.

ENGENHARIA



DE

SOFTWARE

59

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 [A1 6] [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 [A3 8] 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

ENGENHARIA

DE

SOFTWARE

60

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

ENGENHARIA

DE

SOFTWARE

61

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.

ENGENHARIA

DE

SOFTWARE

62

VER IFICAÇÃO  E E  V VALIDAÇÃO  D DE  R  R EQUISITOS

Será que realmente entendi o que o cliente deseja?

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. VALIDAR É:  ―Estamos construindo o produto certo???‖ 

VERIFICAR É:  ―Estamos construindo certo o produto??‖ 

ENGENHARIA

DE

SOFTWARE

63

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

ENGENHARIA

DE

SOFTWARE

64

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.

ENGENHARIA

DE

SOFTWARE

65

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.

ENGENHARIA

DE

SOFTWARE

66

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. estabelecida?

A

origem

do

requisito

é

claramente

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: ANÔNIMIDADE: relacionamentos pessoais não afetam a revisão. INDEPENDÊNCIA DOS REVISORES EM RELAÇÃO AO ARTEFATO A SER REVISADO: permite uma avaliação objetiva sem conflitos de interesse. 

o

o

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;  



ENGENHARIA





DE

SOFTWARE

67

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

ENGENHARIA

DE

SOFTWARE

68

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:

ENGENHARIA

DE

SOFTWARE

69

- 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).  



GER ENCIAMENTO D DE  M MUDANÇA  D DE  R  R EQUISITOS

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:

ENGENHARIA

 

DE

SOFTWARE

70

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

ENGENHARIA

DE

SOFTWARE

71

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;

ENGENHARIA





DE

SOFTWARE

72

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.

ENGENHARIA

DE

SOFTWARE

73

Gerenciamento de Mudanças de Requisitos: 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 Requi sitos (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)

ENGENHARIA

DE

SOFTWARE

74

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 (FUNCAB - 2010 - SEJUS-RO - Analista de Sistemas 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, 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 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 ( FGV - 2010 - FIOCRUZ - Tecnologista em Saúde - TI - Sistemas de Informação): 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  de   software, software, necessárias para se identificar o que o software precisa executar, seguida

ENGENHARIA

DE

SOFTWARE

75

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, 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

ENGENHARIA

DE

SOFTWARE

76

MATR IZ  D DE  R  R ASTR EABILIDADE 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: Acompanhar a evolução desenvolvimento; o

dos

requisitos

ao

longo

do

ENGENHARIA

o

o



DE

SOFTWARE

77

Registrar status de cada requisito em relação ao desenvolvimento, em relação a modificações aceitas e  justificativas associadas; 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: Atualmente tem-se a convicção que mudanças em requisitos ao longo do processo de desenvolvimento de software fazem parte do processo; Motivos: necessidades não identificadas inicialmente, alterações no contexto, correção de erros ou mesmo novas perspectivas por parte dos stakeholders; Alterações em requisitos podem implicar em mudanças em artefatos de projeto, código, casos de testes, etc. GARANTIA DE QUALIDADE: Aspectos relacionados a qualidade: modelo CMM, CMMI, ISO 9001. o

o

o



o











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;

ENGENHARIA



DE

SOFTWARE

78

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.

ENGENHARIA

DE

SOFTWARE

79

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. APROVAÇÕES Nome

Data

Assinatura Nome

Data

Assinatura Matriz de Rastreabilidade de Requisitos Data: dia/mês/ano Elaborado por: ID Requisito Descrição Prioridade Responsável / Versão Caso de Teste Data Data Proprietário Alteração Conclusão Id do Descrição Prioridade  Nome do  Número Identificação Data de Data de requisito (Feature  ) do elencada responsável da versão do caso de alteração conclusão identificado no requisito.  para o  pela do teste elaborado do do Documento requisito. execução e requisito.  para o requisito. requisito. (Análise) de controle do requisito. Requisitos. 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)

ENGENHARIA

DE

SOFTWARE

80

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

OR IENTAÇÃO A A  O OBJETOS

HISTÓRIA

Adaptado da Revista: ENGENHARIA DE SOFTWARE MAGAZINE

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++).

ENGENHARIA

DE

SOFTWARE

81

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.

ENGENHARIA

DE

SOFTWARE

82

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).

ENGENHARIA

DE

SOFTWARE

83

 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.

ENGENHARIA

DE

SOFTWARE

84

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:

ENGENHARIA

DE

SOFTWARE

85

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:  

ENGENHARIA

DE

SOFTWARE

CLASSES  Antes da herança Cliente

Funcionario

86

ATRIBUTOS cpf nome dataNascimento endereco dataPrimeiraCompra 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

ENGENHARIA

DE

SOFTWARE

87

funcionário, o que nos leva a ter a mesma operação, porém com métodos diferentes.

ANÁLISE ORIENTADA A OBJETOS O que é análise????

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.

ENGENHARIA

DE

SOFTWARE

88

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)

b) c) d)

e)

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. 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. 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. 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. 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.

ENGENHARIA

d) e)

DE

SOFTWARE

89

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. 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

ENGENHARIA

DE

SOFTWARE

90

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

ENGENHARIA

DE

2º  B BIMESTR E

SOFTWARE

91

UML Adaptado da Revista Engenharia de Software Magazine

HISTÓRIA

Figura 41 – Os três amigos da UML

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.

ENGENHARIA

DE

SOFTWARE

92

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).

ENGENHARIA

DE

SOFTWARE

93

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.         

ENGENHARIA

DE

SOFTWARE

94

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).

ENGENHARIA

DE

SOFTWARE

95

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 RELACIONAMENTOS 9. 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.

ENGENHARIA

DE

SOFTWARE

96

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.

ENGENHARIA

DE

SOFTWARE

97

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.

ENGENHARIA

DE

SOFTWARE

98

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.

ENGENHARIA

DE

SOFTWARE

99

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

ENGENHARIA

o

DE

SOFTWARE

100

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: 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: DEPENDÊNCIAS: conexão semântica entre dois modelos de elementos, um independente e outro dependente.

ENGENHARIA

DE

SOFTWARE

101

Figura 55 – Exemplo de dependência



REFINAMENTOS: 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: 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: 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 com põ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;

ENGENHARIA









DE

SOFTWARE

102

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: INTERAÇÃ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; DIAGRAMA DE COMUNICAÇÃO – antigo diagrama de colaboração, que mostra objetos, seus inter-relacionamentos e o fluxo de mensagens entre eles; DIAGRAMA TEMPORAL –  mostra a mudança de estado de um objeto numa passagem de tempo, em resposta a eventos externos; 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. o

o

o

o

ENGENHARIA

DE

SOFTWARE

103

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.

ENGENHARIA

DE

SOFTWARE

104

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.

ENGENHARIA

DE

SOFTWARE

105

DIA  P POR TABLE

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,

ENGENHARIA

DE

SOFTWARE

106

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.

ENGENHARIA

DE

SOFTWARE

107

MICR OSOFT  V VISIO  2 2003

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:

ENGENHARIA

DE

SOFTWARE

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

108

ENGENHARIA

DE

SOFTWARE

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

109

ENGENHARIA

DE

SOFTWARE

110

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.

ENGENHARIA

DE

SOFTWARE

111

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

ENGENHARIA

DE

SOFTWARE

112

DIAGR AMA  D DE C CASO  D DE  U USO

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.

ENGENHARIA

DE

SOFTWARE

113

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

uso.

A descrição do caso de uso ocorre na especificação de casos de

Exemplo: Cliente de banco pode usar um caixa automático para sacar dinheiro, transferir dinheiro ou consultar o saldo da conta:

ENGENHARIA

 

DE

SOFTWARE

114

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).   

ENGENHARIA

DE

SOFTWARE

115

A extensão pode ou não ser usada pelo caso de uso de origem. O 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 é 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.

ENGENHARIA

DE

SOFTWARE

116

Figura 71 – Tipos de Relacionamentos

As setas do e do 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

ENGENHARIA

DE

SOFTWARE

117

Exemplo de EXTEND:

Figura 73 – Exemplo de diagrama de caso de uso

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. 





ENGENHARIA







DE

SOFTWARE

118

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)

ENGENHARIA

a) b) c) d) e)

2)

DE

SOFTWARE

Associação/uma funcionalidade do sistema do ponto de vista usuário Generalização/uma funcionalidade do sistema do ponto de vista usuário. Associação/uma funcionalidade do sistema do ponto de vista relacionamento. Globalização/uma funcionalidade do sistema do ponto de vista relacionamento. Generalização/ uma funcionalidade do sistema do ponto de vista relacionamento.

ESTUDO DE CASO: RESERVA DE PASSAGENS AÉREAS:

119

do do do do do

ENGENHARIA

DE

SOFTWARE

120

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.

ENGENHARIA

DE

SOFTWARE

121

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 





ENGENHARIA

DE

SOFTWARE

122

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:

ENGENHARIA

DE

SOFTWARE

123

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,

ENGENHARIA

DE

SOFTWARE

124

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. DIAGR AMA  D DE C CLASSES 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.

ENGENHARIA

DE

SOFTWARE

125

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

sexo.

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

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 (#): 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(-):  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:

ENGENHARIA

DE

SOFTWARE

126

 ASSOCIAÇ  ASSOCIAÇÃO Ã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Ç  AGREGAÇÃO Ã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.

ENGENHARIA

DE

SOFTWARE

127

Figura 78 – Exemplo de Agregação entre ent re 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 Cl asses (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.

ENGENHARIA

DE

SOFTWARE

128

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.  

ENGENHARIA

DE

SOFTWARE

129

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;  

 

ENGENHARIA



DE

SOFTWARE

130

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.

ENGENHARIA

DE

SOFTWARE

131

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: BOTTOM-UP: agrupa classes simulares criando uma superclasse; TOP-DOWN: procurar por classes mais genéricas para então, se preciso, especializá-las. o o

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

Vamos fazer juntos ????



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

ENGENHARIA







DE

SOFTWARE

132

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?

ENGENHARIA

DE

SOFTWARE

133

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 







ENGENHARIA



DE

SOFTWARE

134

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

ENGENHARIA

DE

SOFTWARE

135

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.

ENGENHARIA

DE

SOFTWARE

136

DIAGR AMA  D DE O OBJETOS 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: func1: Funcionário



Funcionário1

: Funcionário

Nome do Atributo: nome do atributo : tipo = valor. Exemplo: Produto1:Produto descrição= ―Sala‖  cor = ―azul‖  tamanho = 40 preço = 15,00

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 Funcionário nome : string cargo : string salário : real

Projeto

trabalha

1..*

1

1

0..1 gerencia

FuncionárioContratado

FuncionárioTerceirizado

carteiraProfissional: string dataAdmissão:date

inicioContrato:date terminoContrato:date prestadoraServicos:string taxaAdministracao:real

descrição:string inicio: date fim : date custo : real

ENGENHARIA



DE

SOFTWARE

137

Diagrama de Objetos P1:Projeto descrição= ―Desenvolvimento do Sistema DKA‖  inicio = 01/12/2006 fim = 02/02/2007 custo = 6000,00

gerente F1:FuncionarioContratado

F1:FuncionarioContratado

nome = ―Firminiano Neves‖  cargo = ―Analista de Sistemas‖  salário = 3800,00 carteiraProfissional = ―01357 -9‖  dataAdmissao = ―15/01/1995‖ 

nome = ―Porsidônio Souza‖  cargo = ―Analista de Sistemas‖  salário = 3500,00 carteiraProfissional = ―02468-0‖  dataAdmissao = ―01/10/2000‖ 

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

Figura 75 – Modelo de Diagrama de Objetos

EXERCÍCIOS 01. Desenhe um diagrama de objetos para o diagrama de classes abaixo:

ENGENHARIA

DE

SOFTWARE

138

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-2001Té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.

ENGENHARIA

DE

SOFTWARE

139

DIAGR AMA  D DE S SEQUENCIAS Vamos imaginar a seguinte situação: Preciso da lista de vendedores com o total de vendas. Relatório de Comissões

Resposta: 100 – Afonso – 15.000,00 215 – Andréa – 30.000,00 A quem pertence a matrícula 10 0?

RESPOSTA: 100 - Afonso

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: 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: o

LivroA:Livro 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 . :Funcionário

:ContraCheque novo()

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 .

ENGENHARIA

DE

SOFTWARE

140

:Benefício

:Funcionário

x

excluirBenefício()

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: :Curso

:Aluno obterNome(matrícula) Ativação

Mensagem de retorno Mensagem

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: Iteração cursoX:Curso

disc1:Disciplina

Coordenador

obterGrade()

*[para cada disciplina] obterInfDisciplina(cursoX)

[se a Disciplina tem PreReq] obterPreRequisito(disc1) condição: só se for verdadeira

Grade

auto-chamada

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.

ENGENHARIA

DE

SOFTWARE

141

sd DiagramaSeq1

objeto1

objeto2

mensagem

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: 

Vendedor

Venda

matrícula : string nome : string dataAdmissao : date salarioBruto : real  /salarioLiquido : real percentualComissao : real

1

0..*

numero : integer data : date valor : real grava()

obterListaVendedoresAtivos() calcularSalarioLiquido(dataRef) : real

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.

ENGENHARIA



DE

SOFTWARE

142

Diagrama de Sequências: :Venda

:TelaCadastro Assistente de Gerência

obterListaVendedoresAtivos() numero_venda busca(número_venda) data, valor seleção do vendedor grava()

Figura 95 – Exemplo de diagrama de sequência

EXEMPLO: ESTUDO DE CASO: SISTEMA GESTOR DE VOTAÇÃO INTERNA

Vamos fazer  juntos???

:Vendedor

ENGENHARIA

DE

SOFTWARE

Figura 96 – Estudo de caso – diagrama de sequência

143

ENGENHARIA

DE

SOFTWARE

144

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.

ENGENHARIA

DE

SOFTWARE

145

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

ENGENHARIA

DE

SOFTWARE

146

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.

ENGENHARIA

DE

SOFTWARE

147

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.

ENGENHARIA





DE

SOFTWARE

148

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:

ENGENHARIA

DE

SOFTWARE

149

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.

ENGENHARIA

DE

SOFTWARE

150

ANEXO  -- S SOLUÇÕES  P PAR A  P PR OBLEMAS  N NA  E ENGENHAR IA  D DE R EQUISITOS

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 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. 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. 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. o

o

o

ENGENHARIA

o

DE

SOFTWARE

151

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;

ENGENHARIA

     

DE

SOFTWARE

152

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.

ENGENHARIA

DE

SOFTWARE

153

CASOS DE USO

Figura 65 – Exemplo de Especificação de Caso de Uso

PROBLEMA: DIFICULDADE NA DESCRIÇÃO DE REQUISITOS FUNCIONAIS E NÃOFUNCIONAIS. SOLUÇÃO  

Utilização de revisões técnicas formais; Treinamentos podem ser conduzidos encontrados nas inspeções.

focando

nos

problemas

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).

ENGENHARIA

DE

SOFTWARE

PROBLEMA: DETALHAMENTO TÉCNICO ESPECIFICAÇÃO FUNCIONAL DO SISTEMA.

154

DESNECESSÁRIO

DURANTE

A

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