6 2 Scrum e a modelagem de software

Prévia do material em texto

1. A linguagem UML oferece uma maneira padronizada de documentar e projetar sistemas. A respeito das características da linguagem, leia as 
assertivas a seguir: 
I - A UML possibilita que detalhes de implementação possam ser abstraídos para fins de facilitar a comunicação com outros setores de negócio 
ou com o próprio cliente. 
II - Os diagramas disponíveis na UML permitem que tanto o funcionamento de um sistema como a sua implementação possam ser representados. 
III - Cada diagrama UML tem o seu escopo de uso bem definido, de maneira a evitar que um elemento de diagrama seja usado em um diagama de 
outro tipo. 
IV - Por ser uma linguagem estritamente gráfica, a UML possibilita que o entendimento sobre um sistema seja formalizado de maneira detalhada e 
completa, o que viabiliza a ampla compreensão do mesmo. 
Quais assertivas estão corretas? 
A. I e II. 
I - Correta, pois como diferentes níveis de abstração podem ser alcançados com a UML, a não representação de detalhes de implementação facilita a 
comunicação com o público não técnico. 
II - Correta, pois os diagramas UML podem ser agrupados em comportamentais e estruturais, capturando aspectos tanto dinâmicos como 
estáticos de um sistema. 
III - Incorreta, pois a especificação UML não impede a mistura de diferentes tipos de diagramas, podendo haver inclusive a mistura de elementos 
estruturais e comportamentais em um único diagrama. 
IV - Incorreta, pois a UML não é estritamente visual nem completa. Logo, não é possível ter a plena garantia do entendimento do sistema representado. 
 
B. II e IV. 
I - Correta, pois como diferentes níveis de abstração podem ser alcançados com a UML, a não representação de detalhes de implementação facilita a 
comunicação com o público não técnico. 
II - Correta, pois os diagramas UML podem ser agrupados em comportamentais e estruturais, capturando aspectos tanto dinâmicos como 
estáticos de um sistema. 
III - Incorreta, pois a especificação UML não impede a mistura de diferentes tipos de diagramas, podendo haver inclusive a mistura de elementos 
estruturais e comportamentais em um único diagrama. 
IV - Incorreta, pois a UML não é estritamente visual nem completa. Logo, não é possível ter a plena garantia do entendimento do sistema representado. 
 
C. I, II, e III. 
I - Correta, pois como diferentes níveis de abstração podem ser alcançados com a UML, a não representação de detalhes de implementação facilita a 
comunicação com o público não técnico. 
II - Correta, pois os diagramas UML podem ser agrupados em comportamentais e estruturais, capturando aspectos tanto dinâmicos como 
estáticos de um sistema. 
III - Incorreta, pois a especificação UML não impede a mistura de diferentes tipos de diagramas, podendo haver inclusive a mistura de elementos 
estruturais e comportamentais em um único diagrama. 
IV - Incorreta, pois a UML não é estritamente visual nem completa. Logo, não é possível ter a plena garantia do entendimento do sistema representado. 
 
D. 
II, III e IV. 
I - Correta, pois como diferentes níveis de abstração podem ser alcançados com a UML, a não representação de detalhes de implementação facilita a 
comunicação com o público não técnico. 
II - Correta, pois os diagramas UML podem ser agrupados em comportamentais e estruturais, capturando aspectos tanto dinâmicos como 
estáticos de um sistema. 
III - Incorreta, pois a especificação UML não impede a mistura de diferentes tipos de diagramas, podendo haver inclusive a mistura de elementos 
estruturais e comportamentais em um único diagrama. 
IV - Incorreta, pois a UML não é estritamente visual nem completa. Logo, não é possível ter a plena garantia do entendimento do sistema representado. 
 
E. II e III. 
I - Correta, pois como diferentes níveis de abstração podem ser alcançados com a UML, a não representação de detalhes de implementação facilita a 
comunicação com o público não técnico. 
II - Correta, pois os diagramas UML podem ser agrupados em comportamentais e estruturais, capturando aspectos tanto dinâmicos como 
estáticos de um sistema. 
III - Incorreta, pois a especificação UML não impede a mistura de diferentes tipos de diagramas, podendo haver inclusive a mistura de elementos 
estruturais e comportamentais em um único diagrama. 
IV - Incorreta, pois a UML não é estritamente visual nem completa. Logo, não é possível ter a plena garantia do entendimento do sistema representado. 
 
2. Diante da publicação do manifesto ágil, a relevância do uso da linguagem UML para a documentação de sistemas passou a ser reavaliada. 
Marque V para verdadeiro e F para falso nos itens que tratam do uso da UML no contexto da metodologia ágil Scrum. Depois, selecione a 
sequência correta. 
( ) Por ser do tipo comportamental, o uso de diagramas de sequência no Scrum oferece uma garantia da correta execução do software. 
( ) O uso de diagramas de classe no Scrum minimiza o impacto que alterações nos requisitos do sistema geram sobre sua arquitetura. 
( ) Ainda que os diagramas UML disponíveis estejam sendo introduzidos no Scrum, seu caráter iterativo e incremental não foi comprometido. 
( ) As propostas de mesclagem do Scrum com documentação UML ainda têm sido avaliadas e carecem de um conscenso quanto à viabilidade. 
A. V - V - V - F 
(F) Por ser do tipo comportamental, o uso de diagramas de sequência no Scrum oferece uma garantia da correta execução do software. 
Falso, porque o Scrum é focado no preceito do código em funcionamento. O uso de diagramas de sequência, além de ser opcional, não dá qualquer 
garantia de corretude na execução do software. 
(F) O uso de diagramas de classe no Scrum minimiza o impacto que alterações nos requisitos do sistema geram sobre sua arquitetura. 
Falso, porque como o Scrum é uma metodologia ágil, alterações nos requisitos são absorvidas em todas as etapas e o impacto gerado sobre a arquitetura é 
gerenciado a cada iteração sistema. Diagramas de classe não podem comprometer essa dinâmica. 
(F) Ainda que os diagramas UML disponíveis estejam sendo introduzidos no Scrum, seu caráter iterativo e incremental não foi comprometido. 
Falso, porque apenas os diagramas de classe e de implantação têm sido comumente usados em projetos Scrum. A introdução de todos os diagramas UML 
e de uma metodologia ágil acarretaria na descaracterização dessa forma de desenvolver software. 
(V) As propostas de mesclagem do Scrum com documentação UML ainda têm sido avaliadas e carecem de um conscenso quanto à viabilidade. 
Verdadeiro, pois se por um lado há pesquisadores e profissionais que defendem os benefícios da introdução de alguns diagramas UML no Scrum, por outro 
há aqueles que consideram os benefícios limitados frente ao esforço de manutenção dessa documentação. 
 
 
 
B. F - F - F - V 
(F) Por ser do tipo comportamental, o uso de diagramas de sequência no Scrum oferece uma garantia da correta execução do software. 
Falso, porque o Scrum é focado no preceito do código em funcionamento. O uso de diagramas de sequência, além de ser opcional, não dá qualquer 
garantia de corretude na execução do software. 
(F) O uso de diagramas de classe no Scrum minimiza o impacto que alterações nos requisitos do sistema geram sobre sua arquitetura. 
Falso, porque como o Scrum é uma metodologia ágil, alterações nos requisitos são absorvidas em todas as etapas e o impacto gerado sobre a arquitetura é 
gerenciado a cada iteração sistema. Diagramas de classe não podem comprometer essa dinâmica. 
(F) Ainda que os diagramas UML disponíveis estejam sendo introduzidos no Scrum, seu caráter iterativo e incremental não foi comprometido. 
Falso, porque apenas os diagramas de classe e de implantação têm sido comumente usados em projetos Scrum. A introdução de todos os diagramas UML 
e de uma metodologia ágil acarretaria na descaracterização dessa forma de desenvolver software. 
(V) As propostas de mesclagem do Scrum com documentação UML ainda têm sido avaliadas e carecem de um conscenso quanto à viabilidade. 
Verdadeiro, pois se por um lado há pesquisadorese profissionais que defendem os benefícios da introdução de alguns diagramas UML no Scrum, por outro 
há aqueles que consideram os benefícios limitados frente ao esforço de manutenção dessa documentação. 
 
C. F - V - F - F 
(F) Por ser do tipo comportamental, o uso de diagramas de sequência no Scrum oferece uma garantia da correta execução do software. 
Falso, porque o Scrum é focado no preceito do código em funcionamento. O uso de diagramas de sequência, além de ser opcional, não dá qualquer 
garantia de corretude na execução do software. 
(F) O uso de diagramas de classe no Scrum minimiza o impacto que alterações nos requisitos do sistema geram sobre sua arquitetura. 
Falso, porque como o Scrum é uma metodologia ágil, alterações nos requisitos são absorvidas em todas as etapas e o impacto gerado sobre a arquitetura é 
gerenciado a cada iteração sistema. Diagramas de classe não podem comprometer essa dinâmica. 
(F) Ainda que os diagramas UML disponíveis estejam sendo introduzidos no Scrum, seu caráter iterativo e incremental não foi comprometido. 
Falso, porque apenas os diagramas de classe e de implantação têm sido comumente usados em projetos Scrum. A introdução de todos os diagramas UML 
e de uma metodologia ágil acarretaria na descaracterização dessa forma de desenvolver software. 
(V) As propostas de mesclagem do Scrum com documentação UML ainda têm sido avaliadas e carecem de um conscenso quanto à viabilidade. 
Verdadeiro, pois se por um lado há pesquisadores e profissionais que defendem os benefícios da introdução de alguns diagramas UML no Scrum, por outro 
há aqueles que consideram os benefícios limitados frente ao esforço de manutenção dessa documentação. 
 
D. V - F - F - V 
(F) Por ser do tipo comportamental, o uso de diagramas de sequência no Scrum oferece uma garantia da correta execução do software. 
Falso, porque o Scrum é focado no preceito do código em funcionamento. O uso de diagramas de sequência, além de ser opcional, não dá qualquer 
garantia de corretude na execução do software. 
(F) O uso de diagramas de classe no Scrum minimiza o impacto que alterações nos requisitos do sistema geram sobre sua arquitetura. 
Falso, porque como o Scrum é uma metodologia ágil, alterações nos requisitos são absorvidas em todas as etapas e o impacto gerado sobre a arquitetura é 
gerenciado a cada iteração sistema. Diagramas de classe não podem comprometer essa dinâmica. 
(F) Ainda que os diagramas UML disponíveis estejam sendo introduzidos no Scrum, seu caráter iterativo e incremental não foi comprometido. 
Falso, porque apenas os diagramas de classe e de implantação têm sido comumente usados em projetos Scrum. A introdução de todos os diagramas UML 
e de uma metodologia ágil acarretaria na descaracterização dessa forma de desenvolver software. 
(V) As propostas de mesclagem do Scrum com documentação UML ainda têm sido avaliadas e carecem de um conscenso quanto à viabilidade. 
Verdadeiro, pois se por um lado há pesquisadores e profissionais que defendem os benefícios da introdução de alguns diagramas UML no Scrum, por outro 
há aqueles que consideram os benefícios limitados frente ao esforço de manutenção dessa documentação. 
 
E. V - V - F - F 
(F) Por ser do tipo comportamental, o uso de diagramas de sequência no Scrum oferece uma garantia da correta execução do software. 
Falso, porque o Scrum é focado no preceito do código em funcionamento. O uso de diagramas de sequência, além de ser opcional, não dá qualquer 
garantia de corretude na execução do software. 
(F) O uso de diagramas de classe no Scrum minimiza o impacto que alterações nos requisitos do sistema geram sobre sua arquitetura. 
Falso, porque como o Scrum é uma metodologia ágil, alterações nos requisitos são absorvidas em todas as etapas e o impacto gerado sobre a arquitetura é 
gerenciado a cada iteração sistema. Diagramas de classe não podem comprometer essa dinâmica. 
(F) Ainda que os diagramas UML disponíveis estejam sendo introduzidos no Scrum, seu caráter iterativo e incremental não foi comprometido. 
Falso, porque apenas os diagramas de classe e de implantação têm sido comumente usados em projetos Scrum. A introdução de todos os diagramas UML 
e de uma metodologia ágil acarretaria na descaracterização dessa forma de desenvolver software. 
(V) As propostas de mesclagem do Scrum com documentação UML ainda têm sido avaliadas e carecem de um conscenso quanto à viabilidade. 
Verdadeiro, pois se por um lado há pesquisadores e profissionais que defendem os benefícios da introdução de alguns diagramas UML no Scrum, por outro 
há aqueles que consideram os benefícios limitados frente ao esforço de manutenção dessa documentação. 
 
 
3. Diagrama de classes UML é um poderoso recurso para a representação de conceitos de negócio e interações entre os seus diversos 
elementos. 
A respeito desse diagrama, marque a alternativa correta. 
A. Dois objetos com propriedades contendo valores distintos devem ser instâncias de duas classes distintas, respectivamente. 
Objetos são instâncias de uma classe; logo dois objetos cujos valores de propriedades sejam distintos podem pertencer naturalmente à mesma classe ou 
ao mesmo molde. Da mesma forma, infinitos objetos podem ser gerados a partir de uma única classe; logo não há limitação no número de objetos que 
podem ser gerados a partir de um diagrama. Os quatro tipos básicos de relacionamentos disponíveis nesse diagrama consideram o impacto que a 
existência de uma classe pode ou não ter sobre a outra. Como o comportamento (ou métodos) disponível nos objetos é definido em sua respectiva 
classe, quaisquer que sejam os objetos, eles apresentarão o mesmo comportamento. Além disso, se um relacionamento entre duas classes distintas não 
está definido no diagrama, as instâncias ou objetos gerados a partir delas jamais poderia invocar métodos uns dos outros. 
 
B. O número de objetos que podem ser gerados a partir de um diagrama está limitado ao número de classes que foi representado nele. 
Objetos são instâncias de uma classe; logo dois objetos cujos valores de propriedades sejam distintos podem pertencer naturalmente à mesma classe ou 
ao mesmo molde. Da mesma forma, infinitos objetos podem ser gerados a partir de uma única classe; logo não há limitação no número de objetos que 
podem ser gerados a partir de um diagrama. Os quatro tipos básicos de relacionamentos disponíveis nesse diagrama consideram o impacto que a 
existência de uma classe pode ou não ter sobre a outra. Como o comportamento (ou métodos) disponível nos objetos é definido em sua respectiva 
classe, quaisquer que sejam os objetos, eles apresentarão o mesmo comportamento. Além disso, se um relacionamento entre duas classes distintas não 
está definido no diagrama, as instâncias ou objetos gerados a partir delas jamais poderia invocar métodos uns dos outros. 
 
 
 
C. A definição do tipo de relacionamento entre um par de classes depende de como uma afeta o ciclo de vida da outra. 
Objetos são instâncias de uma classe; logo dois objetos cujos valores de propriedades sejam distintos podem pertencer naturalmente à mesma classe ou 
ao mesmo molde. Da mesma forma, infinitos objetos podem ser gerados a partir de uma única classe; logo não há limitação no número de objetos que 
podem ser gerados a partir de um diagrama. Os quatro tipos básicos de relacionamentos disponíveis nesse diagrama consideram o impacto que a 
existência de uma classe pode ou não ter sobre a outra. Como o comportamento (ou métodos) disponível nos objetos é definido em sua respectiva 
classe, quaisquer que sejam os objetos, eles apresentarão o mesmo comportamento. Além disso, se um relacionamento entre duas classes distintas não 
está definido no diagrama, as instâncias ou objetos gerados a partir delas jamais poderia invocar métodos uns dos outros. 
 
D. Dois objetos distintos gerados a partir de uma mesma classe devem apresentar métodos ou comportamentos também distintos. 
Objetos são instâncias de uma classe; logo dois objetos cujosvalores de propriedades sejam distintos podem pertencer naturalmente à mesma classe ou 
ao mesmo molde. Da mesma forma, infinitos objetos podem ser gerados a partir de uma única classe; logo não há limitação no número de objetos que 
podem ser gerados a partir de um diagrama. Os quatro tipos básicos de relacionamentos disponíveis nesse diagrama consideram o impacto que a 
existência de uma classe pode ou não ter sobre a outra. Como o comportamento (ou métodos) disponível nos objetos é definido em sua respectiva 
classe, quaisquer que sejam os objetos, eles apresentarão o mesmo comportamento. Além disso, se um relacionamento entre duas classes distintas não 
está definido no diagrama, as instâncias ou objetos gerados a partir delas jamais poderia invocar métodos uns dos outros. 
 
E. Dois objetos gerados a partir de duas classes respectivas que não têm relacionamento entre si podem interagir por meio de seus métodos. 
Objetos são instâncias de uma classe; logo dois objetos cujos valores de propriedades sejam distintos podem pertencer naturalmente à mesma classe ou 
ao mesmo molde. Da mesma forma, infinitos objetos podem ser gerados a partir de uma única classe; logo não há limitação no número de objetos que 
podem ser gerados a partir de um diagrama. Os quatro tipos básicos de relacionamentos disponíveis nesse diagrama consideram o impacto que a 
existência de uma classe pode ou não ter sobre a outra. Como o comportamento (ou métodos) disponível nos objetos é definido em sua respectiva 
classe, quaisquer que sejam os objetos, eles apresentarão o mesmo comportamento. Além disso, se um relacionamento entre duas classes distintas não 
está definido no diagrama, as instâncias ou objetos gerados a partir delas jamais poderia invocar métodos uns dos outros. 
 
 
4. Outros dois diagramas UML amplamente utilizados na documentação de sistemas são o diagrama de componentes e o diagrama de casos de 
uso. 
A respeito desses dois diagramas, assinale a alternativa correta. 
A. Em um diagrama de caso de uso, cada ator é representado uma única vez em associação com cada uma das funcionalidades que ele pode 
acionar. 
Não há qualquer restrição quanto à multiplicidade de atores em um caso de uso. Logo um mesmo ator pode ser representado várias vezes em um 
mesmo diagrama. O diagrama de componentes é empregado para representar uma decomposição do sistema em subsistemas ou para descrever o 
seu funcionamento interno sob a óptica dos principais componentes. O ambiente de execução não faz parte do escopo desse diagrama e não deve ser 
representado nele. Um componente é uma parte substituível e executável de um sistema cujos detalhes de implementação são ocultos. Logo nada do 
que se refere à implementação do componente é representado em um diagrama de componentes. Em um diagrama de casos de uso, o ator sempre é 
externo ao sistema e cada caso de uso representa uma funcionalidade interna do mesmo. Logo a fronteira do sistema delimita o escopo de atuação 
de cada um. Além disso, a UML não faz restrições quanto ao uso dos elementos de um diagrama em outro. 
 
B. O ambiente onde um sistema é executado é representado em um diagrama de componentes em associação com os demais componentes do 
sistema. 
Não há qualquer restrição quanto à multiplicidade de atores em um caso de uso. Logo um mesmo ator pode ser representado várias vezes em um 
mesmo diagrama. O diagrama de componentes é empregado para representar uma decomposição do sistema em subsistemas ou para descrever o 
seu funcionamento interno sob a óptica dos principais componentes. O ambiente de execução não faz parte do escopo desse diagrama e não deve ser 
representado nele. Um componente é uma parte substituível e executável de um sistema cujos detalhes de implementação são ocultos. Logo nada do 
que se refere à implementação do componente é representado em um diagrama de componentes. Em um diagrama de casos de uso, o ator sempre é 
externo ao sistema e cada caso de uso representa uma funcionalidade interna do mesmo. Logo a fronteira do sistema delimita o escopo de atuação 
de cada um. Além disso, a UML não faz restrições quanto ao uso dos elementos de um diagrama em outro. 
 
C. A forma como um componente é implementado é representada em conjunto com os seus relacionamentos com os demais componentes no 
diagrama. 
Não há qualquer restrição quanto à multiplicidade de atores em um caso de uso. Logo um mesmo ator pode ser representado várias vezes em um 
mesmo diagrama. O diagrama de componentes é empregado para representar uma decomposição do sistema em subsistemas ou para descrever o 
seu funcionamento interno sob a óptica dos principais componentes. O ambiente de execução não faz parte do escopo desse diagrama e não deve ser 
representado nele. Um componente é uma parte substituível e executável de um sistema cujos detalhes de implementação são ocultos. Logo nada do 
que se refere à implementação do componente é representado em um diagrama de componentes. Em um diagrama de casos de uso, o ator sempre é 
externo ao sistema e cada caso de uso representa uma funcionalidade interna do mesmo. Logo a fronteira do sistema delimita o escopo de atuação 
de cada um. Além disso, a UML não faz restrições quanto ao uso dos elementos de um diagrama em outro. 
 
D. O escopo de atuação de um ator e de funcionamento de um caso de uso é delimitado pelas fronteiras do sistema. 
Não há qualquer restrição quanto à multiplicidade de atores em um caso de uso. Logo um mesmo ator pode ser representado várias vezes em um 
mesmo diagrama. O diagrama de componentes é empregado para representar uma decomposição do sistema em subsistemas ou para descrever o 
seu funcionamento interno sob a óptica dos principais componentes. O ambiente de execução não faz parte do escopo desse diagrama e não deve ser 
representado nele. Um componente é uma parte substituível e executável de um sistema cujos detalhes de implementação são ocultos. Logo nada do 
que se refere à implementação do componente é representado em um diagrama de componentes. Em um diagrama de casos de uso, o ator sempre é 
externo ao sistema e cada caso de uso representa uma funcionalidade interna do mesmo. Logo a fronteira do sistema delimita o escopo de atuação 
de cada um. Além disso, a UML não faz restrições quanto ao uso dos elementos de um diagrama em outro. 
 
E. A presença de elementos de um diagrama de caso de uso em um diagrama de componentes indica falha na modelagem e violação dos padrões 
UML. 
Não há qualquer restrição quanto à multiplicidade de atores em um caso de uso. Logo um mesmo ator pode ser representado várias vezes em um 
mesmo diagrama. O diagrama de componentes é empregado para representar uma decomposição do sistema em subsistemas ou para descrever o 
seu funcionamento interno sob a óptica dos principais componentes. O ambiente de execução não faz parte do escopo desse diagrama e não deve ser 
representado nele. Um componente é uma parte substituível e executável de um sistema cujos detalhes de implementação são ocultos. Logo nada do 
que se refere à implementação do componente é representado em um diagrama de componentes. Em um diagrama de casos de uso, o ator sempre é 
externo ao sistema e cada caso de uso representa uma funcionalidade interna do mesmo. Logo a fronteira do sistema delimita o escopo de atuação 
de cada um. Além disso, a UML não faz restrições quanto ao uso dos elementos de um diagrama em outro. 
 
5.Em um cenário em que um usuário precisa fazer uma consulta em um sistema sobre a situação do seu título de eleitor, os seguintes elementos 
foram identificados em um diagrama de sequência: 
1. Atores: usuario. 
2. Objetos: telaConsulta, bancoDeDados. 
Assinale a alternativa que indica o fluxo correto de mensagens até que o usuário receba uma mensagem de erro indicando que seu título eleitoral 
está com problemas (o símbolo -> está sendo usado de forma simplificada para indicar o envio de uma mensagem). 
A.1. usuario -> envia título -> bancoDeDados. 
2. telaConsulta -> enviatítulo -> bancoDeDados. 
3. bancoDeDados -> envia erro -> telaConsulta. 
4. telaConsulta -> envia erro -> usuario. 
O fluxo inicia com o usuário enviando os dados do título eleitoral para a tela de consulta (usuario -> envia título -> telaConsulta). 
Em geral, isso é feito através do preenchimento de um formulário Web. Ao acionar a consulta do título, o usuário faz com que a tela de consulta envie o título 
para o que o banco de dados possa consultar a situação do título (telaConsulta -> envia título -> bancoDeDados). 
Após feita a pesquisa e detectado um problema com o título informado, o banco de dados devolve uma mensagem de erro para a tela de consulta 
(bancoDeDados -> envia erro -> telaConsulta). 
De posse da mensagem retornada pelo banco de dados, a tela de consulta apresenta para o usuário o status do título informado (telaConsulta -> envia 
erro -> usuario). 
 
B.1. usuario -> envia título -> telaConsulta. 
2. telaConsulta -> envia título -> bancoDeDados. 
3. telaConsulta -> envia erro -> usuario. 
4. bancoDeDados -> envia erro -> telaConsulta. 
O fluxo inicia com o usuário enviando os dados do título eleitoral para a tela de consulta (usuario -> envia título -> telaConsulta). 
Em geral, isso é feito através do preenchimento de um formulário Web. Ao acionar a consulta do título, o usuário faz com que a tela de consulta envie o título 
para o que o banco de dados possa consultar a situação do título (telaConsulta -> envia título -> bancoDeDados). 
Após feita a pesquisa e detectado um problema com o título informado, o banco de dados devolve uma mensagem de erro para a tela de consulta 
(bancoDeDados -> envia erro -> telaConsulta). 
De posse da mensagem retornada pelo banco de dados, a tela de consulta apresenta para o usuário o status do título informado (telaConsulta -> envia 
erro -> usuario). 
 
C.1. usuario -> envia título -> bancoDeDados. 
2. bancoDeDados -> envia título -> telaConsulta. 
3. telaConsulta -> envia erro -> bancoDeDados. 
4. bancoDeDados -> envia erro -> usuario. 
O fluxo inicia com o usuário enviando os dados do título eleitoral para a tela de consulta (usuario -> envia título -> telaConsulta). 
Em geral, isso é feito através do preenchimento de um formulário Web. Ao acionar a consulta do título, o usuário faz com que a tela de consulta envie o título 
para o que o banco de dados possa consultar a situação do título (telaConsulta -> envia título -> bancoDeDados). 
Após feita a pesquisa e detectado um problema com o título informado, o banco de dados devolve uma mensagem de erro para a tela de consulta 
(bancoDeDados -> envia erro -> telaConsulta). 
De posse da mensagem retornada pelo banco de dados, a tela de consulta apresenta para o usuário o status do título informado (telaConsulta -> envia 
erro -> usuario). 
 
D.1. usuario -> envia título -> telaConsulta. 
2. telaConsulta -> envia erro -> bancoDeDados. 
3. telaConsulta -> envia erro -> telaConsulta. 
4. telaConsulta -> envia erro -> usuario. 
O fluxo inicia com o usuário enviando os dados do título eleitoral para a tela de consulta (usuario -> envia título -> telaConsulta). 
Em geral, isso é feito através do preenchimento de um formulário Web. Ao acionar a consulta do título, o usuário faz com que a tela de consulta envie o título 
para o que o banco de dados possa consultar a situação do título (telaConsulta -> envia título -> bancoDeDados). 
Após feita a pesquisa e detectado um problema com o título informado, o banco de dados devolve uma mensagem de erro para a tela de consulta 
(bancoDeDados -> envia erro -> telaConsulta). 
De posse da mensagem retornada pelo banco de dados, a tela de consulta apresenta para o usuário o status do título informado (telaConsulta -> envia 
erro -> usuario). 
 
E.1. usuario -> envia título -> telaConsulta. 
2. telaConsulta -> envia título -> bancoDeDados. 
3. bancoDeDados -> envia erro -> telaConsulta. 
4. telaConsulta -> envia erro -> usuario. 
O fluxo inicia com o usuário enviando os dados do título eleitoral para a tela de consulta (usuario -> envia título -> telaConsulta). 
Em geral, isso é feito através do preenchimento de um formulário W eb. Ao acionar a consulta do título, o usuário faz com que a tela de consulta envie o título 
para o que o banco de dados possa consultar a situação do título (telaConsulta -> envia título -> bancoDeDados). 
Após feita a pesquisa e detectado um problema com o título informado, o banco de dados devolve uma mensagem de erro para a tela de consulta 
(bancoDeDados -> envia erro -> telaConsulta). 
De posse da mensagem retornada pelo banco de dados, a tela de consulta apresenta para o usuário o status do título informado (telaConsulta -> envia 
erro -> usuario).