SóProvas



Questões de Diagrama de Casos de Uso


ID
5737
Banca
CESGRANRIO
Órgão
EPE
Ano
2006
Provas
Disciplina
Engenharia de Software
Assuntos

Para os diagramas utilizados na UML 2.0 são feitas as afirmativas abaixo.

I - No Diagrama de Classes é possível modelar o estereótipo das classes, o nível de visibilidade de seus atributos e a navegabilidade das associações entre as classes.

II - O Diagrama de Tempo unifica em um único diagrama os Diagramas de Seqüência e Interação da UML 1.4, sendo utilizado para especificar as restrições de tempo sobre mensagens enviadas e recebidas no decorrer de uma interação.

III - O Diagrama de Atividades permite definir pré e pós-condições associadas a ações do diagrama. As pré-condições definem o estado exigido do sistema quando a ação é invocada e as pós-condições especificam o estado exigido do sistema no término da ação.

IV - Juntos, os diagramas de Objetos e Comunicação descrevem como um sistema de software é instalado e executado no ambiente de processamento identificando as partes físicas do software e o ambiente necessário para execução.

V - Em um diagrama de Caso de Uso a generalização define os relacionamentos de herança entre os casos de uso ou entre os atores, enquanto que as associações indicam quais atores interagirão com os casos de uso do sistema.

Está(ão) correta(s) apenas a(s) afirmativa(s):

Alternativas
Comentários
  • II - O Diagrama de Tempo Diagrama de visão geral da interação unifica em um único diagrama os Diagramas de Seqüência e Interação da UML 1.4, sendo utilizado para especificar as restrições de tempo sobre mensagens enviadas e recebidas no decorrer de uma interação.

    IV - Juntos, os diagramas de Objetos e Comunicação Diagrama de instalação descrevem como um sistema de software é instalado e executado no ambiente de processamento identificando as partes físicas do software e o ambiente necessário para execução.
  • A assertiva V na minha opnião está errada, pois nos Diagramas de Casos de Uso não é a generalização que define o relacionamento de herança e sim a Generalização/Especialização ou somente a Especializalção.


ID
7312
Banca
ESAF
Órgão
CGU
Ano
2004
Provas
Disciplina
Engenharia de Software
Assuntos

Na modelagem com UML, o Diagrama de Casos de Uso fornece

Alternativas
Comentários
  • O diagrama de casos de uso fornece um modo de descrever a visão externa do sistema e suas interações com o mundo exterior, representando uma visão de alto nível da funcionalidade do sistema mediante uma requisição do usuário.
  • Parabéns aos que chegaram ao fim dessa bateria de questões, nos vemos no dia 16.06.2012 na prova da CGU.
    Que Deus nos abençoe!
    Abs

ID
11977
Banca
CESPE / CEBRASPE
Órgão
Polícia Federal
Ano
2004
Provas
Disciplina
Engenharia de Software
Assuntos

Considere que se deseja desenvolver um sistema para controle
de caixa de supermercado tendo como base um computador
que registra os produtos vendidos, interagindo com
dispositivos de entrada e saída tais como impressora, teclado
e leitora de código de barras. Esse sistema deve interagir
também com o operador do caixa e com um banco de dados do
estabelecimento. A partir dessas informações, julgue os itens
que se seguem.

Em uma análise orientada a objetos, é comum o uso de UML para modelar o sistema. A descrição do processo de compra de uma mercadoria do supermercado, por meio de uma seqüência de eventos entre os objetos do sistema, é realizada mediante diagramas de casos de uso em UML.

Alternativas
Comentários
  • " entre os objetos do sistema", o casos de uso antecede a criação de objetos do sistema, portanto errado
  • Isso é realizado por meio do diagrama de sequência e não de caso de uso
  • Acrescento que o objetivo dos diagramas de seqüência é descrever as comunicações necessárias entre objetos para a realização dos processos em um sistema. Neste caso a questão se encaixa perfeitamente a este conceito, ja que o diagrama de sequencia iria descrever a sequencia de eventos (torca de menssagens, funções, etc) entre os OBJETOS do sistema para realização do processo do sistema (processo de compra de uma mercadoria).

    Abraços

  • Seria incorreto dizer que a descrição do processo ocorre no diagrama de casos de uso. A descrição de um caso de uso ocorre em um modelo de caso de uso e não no diagrama em si. O diagrama apenas representa a modelagem gráfica.

    Modelo de Caso de Uso ≠ Diagrama de Caso de Uso

  •  A questão troca conceitos. Na verdade, essa "seqüência de eventos entre os objetos do sistema" é realizada por um Diagrama de Sequência. O diagrama de caso de uso faria a especificação dos casos de uso e do limite do sistema. O caso de uso em si é realizado por diagramas de interação.

  • errado-

    UML atualmente esta na versao 2.4.1 e uma das novidades é a abordagem em 4 camadas e a possibilidade de desenvolver "perfis" particulares a apartir de notacoes UML


ID
17767
Banca
CESGRANRIO
Órgão
BNDES
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

O diagrama UML mais indicado para representar o passo a passo do fluxo de eventos principal de um caso de uso de um software orientado a objetos é o diagrama de

Alternativas
Comentários
  • O diagrama de atividades é um diagrama de estados e ilustra o fluxo de eventos de um caso de uso, pussui um fluxo básico e um ou vários fluxos alternativos, melhor explicação pode ser encontrada aqui:

    http://www.wthreex.com/rup/process/modguide/md_actd.htm

  • b´-

    Este diagrama é bom para comportamentos paralelos. Um Diagrama de Atividades é um fluxograma que destaca atividade ao longo do tempo.


    Um Diagrama de Atividades tem:


    - Início: círculo preenchido.


    -Estado de Atividade ou Atividade: retângulo com bordas arredondadas.


    -Transição: linha orientada.atividade termina e o fluxo de controle passa para a atividade seguinte.


    -Desvio: losango.


    -Intercalação: Também losango, marca o final de um comportamento condicional iniciado por um desvio: múltiplas entradas e
    uma única saída.


    -Separação: traço horizontal, quando ha comportamento paralel: uma entrada e várias de saída em paralelo.


    -Junção: traço horizontal, completa a separação. Sincorinza comportamento paralelo


    swimlanes: retângulos dos objetos. Entidades responsáveis pela atividade


ID
41677
Banca
FCC
Órgão
TRE-PI
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

No diagrama de sequência da UML, cada objeto participante é representado por uma caixa e uma linha vertical denominada linha de

Alternativas
Comentários
  • Em um diagrama de seqüência, os seguintes elementos podem ser encontrados: * Linhas verticais representando o tempo de vida de um objeto (lifeline); * Estas linhas verticais são preenchidas por barras verticais que indicam exatamente quando um objeto passou a existir. Quando um objeto desaparece, existe um "X" na parte inferior da barra; * Linhas horizontais ou diagonais representando mensagens trocadas entre objetos. Estas linhas são acompanhadas de um rótulo que contém o nome da mensagem e, opcionalmente, os parâmetros da mesma. Observe que também podem existir mensagens enviadas para o mesmo objeto, representando uma iteração; * Uma condição é representada por uma mensagem cujo rótulo é envolvido por colchetes; * Mesagens de retorno são representadas por linhas horizontais tracejadas. Este tipo de mensagem não é freqüentemente representada nos diagramas, muitas vezes porque sua utilização leva a um grande número de setas no diagrama, atrapalhando o entendimento do mesmo. Este tipo de mensagem só deve ser mostrada quando forfundamental para a clareza do diagrama.

ID
79228
Banca
FCC
Órgão
TRT - 18ª Região (GO)
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Se em algum ponto de um Caso de Uso houver a necessidade de inserir incondicionalmente um cenário contido em outro Caso, deve-se usar o relacionamento de dependência estereotipado como

Alternativas
Comentários
  • Utiliza-se  <<EXTENDS>> apenas sob certas condições.

    Por exemplo:

    http://content.screencast.com/users/sabiotriste/folders/UML/media/b52dec7a-83cb-41ba-b93f-dc9c4e36a4b2/uml_1.PNG

    Caso a pessoa precise encerrar uma conta, se ela estiver com o saldo negativo, deve depositar um montante para zerar a conta, então <<extend>> Depósito.

    Caso ele tenha um saldo positivo, então <<extend>> Saque.
  • INcondicional = INclude;
    condicional = extend


ID
79231
Banca
FCC
Órgão
TRT - 18ª Região (GO)
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Atividade, Caso de Uso e Componente são diagramas da UML 2.0 classificados, respectivamente, no âmbito

Alternativas
Comentários
  • Diagramas EstruturaisDiagrama de classes,de objetos, componentes, de instalação, de pacotes,de estrutura.
    Diagramas ComportamentaisDiagrama de Caso de Uso, de transição de estados, de atividade e os diagramas de interação.
  • Diagramas estruturais (visão estática): Classe - Estrutura composta - Componente - Objeto - Implantação - ArtefatosDiagramas comportamentais (visão dinâmica)Caso de Uso - Atividade - Sequencia - Estado - Comunicação
  • Uma maneira rápida de decorar quais são os diagramas estruturais que eu encontrei foi essa:

    C = classes

    O = objetos

    C = componentes

    I = implantação

    P = pacotes

    E = Estrutura composta

    "C O C I P E"

    Assim, vc guarda essa palavra e o que não for estrutural é comportamental.

  • c-

    DIAGRAMAS ESTRUTURAIS


    De Classe: fundamental e mais utilizado e apoia outros diagramas. O Diagrama de Classe mostra classes com atributos e métodos e os relacionamentos


    De Objeto: O relacionado com o de classes e é um complemento dele. visão dos valores em um momento da execução

     

    De Componentes: associado à linguagem de programação e organiza componentes do software e seus relacionamentos.


    De Implantação: hardware e características físicas


    De Pacotes: subsistemas de forma a determinar partes que o compõem.


    De Estrutura: estrutura interna de um classificador.


ID
104755
Banca
FCC
Órgão
TCM-PA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Considere o caso de uso Movimentar Estoque. Se o estoque necessitar de reposição porque atingiu o limite mínimo desejável, outro caso de uso é envolvido para emitir ordem de compra. Essa situação indica o uso de

Alternativas
Comentários
  • Essa questão está classificada erroneamente, ela é da disciplina de tecnologia da informação. Não cai a disciplina de Administração de Recursos Materiais para essa prova do TCM-PA - Técnico em Informática.

  • Acredito que classificaram a questão erroneamento só porque viram as palavras 'Movimentar Estoque'. Já notifiquei o site!

  • Só se for...

    Nunca ouvi falar!

  • Relacionamento entre casos de Uso:

    1) Include: Quando o caso de uso A “inclui” o caso de uso B, significa que sempre que o caso de uso A for executado o caso de uso B também será executado.

    2) Extend: Quando o caso de uso B estende o caso de uso A, significa que quando o caso de uso A for executado o caso de uso B poderá (poderá – talvez não seja) ser executado também.

    Resposta: Letra D.

  • 1) Include: Quando o caso de uso A “inclui” o caso de uso B, significa que sempre que o caso de uso A for executado o caso de uso B também será executado.

    2) Extend: Quando o caso de uso B estende o caso de uso A, significa que quando o caso de uso A for executado o caso de uso B poderá (poderá – talvez não seja) ser executado também.

     

    Se o estoque necessitar de reposição porque atingiu o limite mínimo desejável.

    Esse SE é uma possibilidade, ou seja, o estoque poderá ou não de reposição.


ID
118642
Banca
FCC
Órgão
TRT - 20ª REGIÃO (SE)
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Na UML, o diagrama que serve para organizar o comportamento do sistema é o diagrama de

Alternativas
Comentários
  • Achei esse pergunta mal formulada, pois o diagrama de sequencia e estados tbm podem mostrar caracteristicas comportamentais do sistema.
  • De acordo com o manual da UML 4º edição, dos criadores da linguagem a características do diagrama de caso de uso é "Organizar os comportamentos do sistema" enquanto que o diagrama de sequência é para "expor a ordem temporal das mensagens" e o de estados "enfatizar o estado de mudança de um sistema orientado por eventos" os diagramas de classe e objetos não são diagramas comportamentais e sim estruturais
  • Sequencia: comportamento do objeto em relação a outro.

    Estado: comportamento do objeto em um dado momento da execução do sistema.

    Casos de Uso: comportamento geral do sistema para o usuário final.


ID
120685
Banca
FCC
Órgão
SERGAS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Em UML, são diagramas feitos para facilitar a comunicação com os futuros usuários do sistema, e com o cliente, sendo especialmente úteis para determinar os recursos necessários que o sistema deve ter, mas não são adequados para representar o desenho e não podem descrever os mecanismos internos de um sistema. São diagramas de

Alternativas
Comentários
  • Sobre UML:a) O Diagrama de Sequencia expressa a colaboração entre classes para realizar determinadas tarefas. Somente o pessoal da área de programação teria este entendimento. É muito técnico para tratar com usuário final, logo ERRADO.b) O Diagrama de Colaboração é um complemento do Diagrama de Sequência. Diferencia-se deste por possuir uma estrutura menos rigida e estar preocupado apenas em como as classes estão sendo tratados entre si. É fácil observar este tipo de Diagrama quando se deseja entender as relações entre as diversas classes de Framework para realização de uma tarefa. Neste caso a preocupação está no contexto e não numa sequência TEMPORAL de troca de mensagens. Logo ERRADO.c) Não há este diagrama na UML. Logo ERRADO.d) O caso de uso expressa os cenários em que os usuários estarão envolvidos com a utilização do sistema, dele pode-se entender quais os requisitos estão envolvidos, logo pode-se extrair quais são as necessidades de recursos para um sistema. Não podem representar o desenho do sistema, pois faltaria, por exemplo explicar como o sistema deveria ser estruturado, dessa forma, muito menos pode descrever mecanismos internos de um sistema. Logo CORRETOe) Este representa os passos que devem ser dados um sistema, uma operação ou mesmo uma tarefa de implantação para que consiga-se realizar uma determinada atividade. Podem até ser tratados e apresentados usuários e clientes, pois possuem fácil entendimento, mas não determinam recursos necessários do sistema, muito menos representa o desenho do software ou qualquer mecanismo interno do mesmo. Logo ERRADO.
  • d-

     A questao descreve diagramas de caso de uso, os quais devem ser mantidos simples para comunicação com usuarios, sendo tb usado para elicitar requisitos.


ID
121141
Banca
FCC
Órgão
AL-SP
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Um relacionamento estendido entre dois casos de uso é um relacionamento de

Alternativas
Comentários
  • Os relacionamentos ligam as classes/objetos entre si criando relações lógicas entre estas
    entidades. Os relacionamentos podem ser dos seguintes tipos:
    · Associação: É uma conexão entre classes, e também significa que é uma conexão
    entre objetos daquelas classes. Em UML, uma associação é definida com um
    relacionamento que descreve uma série de ligações, onde a ligação é definida como a
    semântica entre as duplas de objetos ligados.
    · Generalização: É um relacionamento de um elemento mais geral e outro mais
    específico. O elemento mais específico pode conter apenas informações adicionais.
    Uma instância (um objeto é uma instância de uma classe) do elemento mais específico
    pode ser usada onde o elemento mais geral seja permitido.
    · Dependência e Refinamentos: Dependência é um relacionamento entre elementos, um
    independente e outro dependente. Uma modificação é um elemento independente
    afetará diretamente elementos dependentes do anterior. Refinamento é um
    relacionamento entre duas descrições de uma mesma entidade, mas em níveis
    diferentes de abstração.
  • estendido nao tem haver com extend nao???? deveria ser generalizacao!!!
  • Na minha opnião seria letra A (Associação), entendi essa questão como (caso A extende <> caso B)
    Os relacionamentos entre casos de uso são: Associação (include, extend) e generalização.
  • Relacionamentos entre dois casos de uso existem em duas situações:
    1 - Generalização (herança)
    2 - Dependência (Include e Extend)

    OBS.: Include e Extend são relacionamentos de dependência e não de associação, como disse nosso amigo logo acima.

ID
128671
Banca
FCC
Órgão
MPE-SE
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Na representação da UML 2.0, um caso de uso incluído em outro caso de uso, estabelecido estereotipadamente como <<include>>, é um relacionamento

Alternativas
Comentários
  • resposta: letra bporem nao concordo com esse gabarito. Segundo o livro "desenvolvendo aplicações com UML" de Ana Cristina Melo, o relcionamento de inclusao indica queum dos casos de uso tera seu procedimento copiado num local especificado no outro, identificado como base.isso evita cópia de trechos identicos.De onde tiraram a dependência????
  • A dependência vem do seguinte aspecto:
    quando vc inclui um caso de uso em outro, sempre que o primeiro for acionado, o segundo também será acionado. Ex: Caso de uso base: "Incluir nota fiscal" e caso de uso incluído "Incluir itens nota fiscal". Itens da nota fiscal sempre serão dependentes de uma nota fiscal.

    Este conceito é diferente do extends, onde um caso de uso pode utilizar funcionalidades de outro, mas mesmo assim ainda existe uma dependência, pois um caso de uso extendido também só pode existir com um caso de uso base.

    No caso da exclusão do caso de uso base, tanto os casos de uso extendidos como os caso de usos incluídos deverão ser excluídos também. Esse é outro aspecto que denota dependência.

    Abraços
  • Tenho visto em várias questões aqui mesmo no QC, por exemplo, Q80261, Q53867, Q64299, pedindo os possíveis tipos de relacionamentos presentes nos casos de uso:

    - ASSOCIAÇÃO
      ocorre associação entre os ATORES e os CASOS DE USO

    - GENERALIZAÇÃO
      pode ocorrer generalização de ATORES ou  generalização de CASOS DE USO

    - DEPENDÊNCIA
      a relação de dependência entre casos de uso abrange tanto os casos de INCLUSÃO ("INCLUDE") quanto os de EXTENSÃO ("EXTENDS"); para exemplificar este conceito transcrevo a seguinte frase, retirada da obra "The UML Reference Manual - Second edition " (Rumbaugh, Jacobson, Booch): "Classes may have interfaces, which describe their externally-visible behaviour. Other relationships are include ande extend dependencies of use cases."
  • Vc é o cara!!
  • b-

    Conceitualmente dependencia é o nome da relação estabelecida quando houver 1 ou + casos de uso contidos em outro caso de uso. É indicado com <> por uma flecha de traços indicando o caso de uso base em direção ao caso de uso contido.


ID
135436
Banca
CESPE / CEBRASPE
Órgão
EMBASA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação aos conceitos e às disciplinas considerados no
processo unificado, julgue os itens de 76 a 80.

No processo unificado, os modelos de caso de uso encontramse na disciplina de requisitos, enquanto plano de desenvolvimento de software e especificações suplementares são partes da disciplina gerenciamento de projeto.

Alternativas
Comentários
  • Especificações suplementares fazem parte da disciplina de requisitos e não de gerenciamento de projeto, como fala a questão.

ID
135490
Banca
CESPE / CEBRASPE
Órgão
EMBASA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

A respeiro dos diagramas da UML, julgue os itens subsequentes.

Um diagrama de casos de uso descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. É comum o uso de atores nesse diagrama.

Alternativas
Comentários
  • Alguém já viu um caso de uso sem ator???

    Marquei errado justamente com base na pergunta acima. Isso porque na parte da questão ele diz que "É comum o uso de atores nesse diagrama", Ora, se não existe caso de uso sem ator, não é só comum, é obrigatório.

    O caso de uso é justamente para descrever como se dará as funcionalidades do sistema e suas interações com o usuário (Ator).

    Se eu estiver errado, peço pelo amor de deus que me corrijam, pq to muito puto com essa questão.

    Obrigado.
  • Sim, existe caso de uso sem ator. Imagina uma rotina que é executada automaticamente no sistema. Ela não precisa de nenhum ator para ativá-la.
    Um sistema de backup que é executado todo dia às 12:00, por exemplo.
  • Acho que nesse caso você consideraria o relógio como sendo um ator.

    O ator não é necessáriamente uma pessoa, pode ser uma máquina ou outro sistema.

    Também fiquei com medo de marcar Certo, mas preferi ser um pouco tolerante com a banca. No mais se algo acontece sempre, não deixa de ser comum para se tornar incomum.

     

     


ID
142057
Banca
CESPE / CEBRASPE
Órgão
TRE-MT
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca de diagramas de casos de uso da UML, assinale a opção correta.

Alternativas
Comentários
  •  Os estereótipos estão incompletos. Enquanto não ajeitam...

    O estereótipo da alternativa B é "includes", e o da alternativa C é "extends".

  • a) Os diagramas de casos de uso são diagramas UML para modelagem de aspectos estáticos dinâmico de sistemas.

    b) O relacionamento de dependência que usa o estereótipo <include> <extends>especifica que um caso de uso incorpora recursos opcionais, ou seja, o sistema pode ser utilizado com ou sem os recursos adicionais.

     c) O relacionamento de dependência que usa o estereótipo <extends> <include > especifica que o caso de uso de origem incorpora explicitamente outro caso de uso, que representa uma atividade significativa.

    d) Em diagramas de casos de uso, não é possível utilizar relacionamento de generalização entre atores nem e entre casos de uso.
  • a) é um diagrama dinâmico

    b) include é obrigatório

    c) extends é opcional e não incorpora outro caso, mas o estende, aumenta seu escopo. Ex. "ver histórico detalhado" ESTENDE ver "informações da conta"

    d) é difícil dizer que algo não é permitido na UML, é uma linguagem muito flexível

    e) correto.


ID
142855
Banca
FIP
Órgão
Câmara Municipal de São José dos Campos - SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Um diagrama de casos de uso na UML 2.0 descreve:

Alternativas
Comentários
  • Resposta correta é a letra "B", como visto abaixo:

    Os clientes utilizarão os casos de uso para entenderem o comportamento do sistema e, como eles precisam aprovar o fluxo de eventos do caso de uso, também o utilizarão para aprovarem o resultado da modelagem de casos de uso.

    Fonte: http://www.wthreex.com/rup/portugues/process/artifact/ar_uc.htm


  • b-

    use case diagrams é um diagrama comportamental alto nivel usado para coleta de requisitos. por isso é considerado do ponto de vista do usuario.


ID
143728
Banca
FIP
Órgão
Câmara Municipal de São José dos Campos - SP
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Um diagrama de casos de uso na UML 2.0 descreve:

Alternativas
Comentários
  • Um caso de uso define um conjunto de instâncias de casos de uso, no qual cada instância é uma seqüência de ações realizada por um sistema que produz um resultado de valor observável para determinado ator.

    Fonte: http://www.wthreex.com/rup/portugues/process/artifact/ar_uc.htm

    Letra D.


ID
144502
Banca
CESPE / CEBRASPE
Órgão
TRE-MA
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os seguintes itens, relativos a caso de uso.

I Os casos de uso podem ser aplicados para captar o comportamento pretendido do sistema que está sendo desenvolvido, sem ser necessário especificar como esse comportamento é implementado.
II Os casos de uso fornecem uma maneira para os desenvolvedores chegarem a uma compreensão comum com os usuários finais do sistema e com os especialistas.
III Os casos de uso servem para validar a arquitetura e para verificar o sistema à medida que ele evolui durante seu desenvolvimento.
IV Um caso de uso envolve a interação dos atores com o sistema.

A quantidade de itens certos é igual a

Alternativas
Comentários
  • Do timaster...


    No UML:Guia do Usuário, cap. 17, pág. 227, tem o seguinte:

    "...
    Além disso os casos de uso servem para AJUDAR a validar a arquitetura e para
    verificar o sistema à media que ele evolui durante seu desenvolvimento.
    ..."

    Parece que aos olhos do examinador a omissão do verbo ajudar não faz com que
    a afirmativa se torne incorreta.  No entanto, meu entendimento é o mesmo que
    o seu: só com o caso de uso não se valida a arquitetura. Inclusive o próprio
    guia do usuário define arquitetura como um artefato que se relaciona com a
    estrutura, comportamento, funcionalidade, desempenho, etc... (pág. 34). A
    arquitetura faz uso do modelo de visão 4(projeto, implementação,
    implantação, processo) + 1(caso de uso)  para ser construída.


    --
    Leonardo Marcelino
    Belo Horizonte - MG

  • Eu discordo da III.

    "[...] validar a arquitetura [...]"


    Acho errado.
  • Também compartilho o questionamento dos colegas. O item III está errado. Estranho esta questão não ter sido anulada. Acho que o gabarito da questão deveria ser alterado para a letra "D", mesmo a banca mantendo a letra "E".


ID
144505
Banca
CESPE / CEBRASPE
Órgão
TRE-MA
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Em UML (unified modeling language), os diagramas estruturais são organizados em função dos principais grupos de itens encontrados na modelagem de um sistema. Os diagramas estruturais em UML não incluem o diagrama de

Alternativas
Comentários

ID
144625
Banca
CESPE / CEBRASPE
Órgão
SECONT-ES
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca de conceitos da UML, julgue os itens seguintes.

Casos de uso podem ser empregados para captar o comportamento de um sistema ou de parte de um sistema. O comportamento do caso de uso pode ser especificado pela descrição do fluxo de eventos de forma suficientemente clara para que os seus usuários sejam capazes de compreendê-lo. Nesse fluxo, devem ser incluídas definições relacionadas à forma de implementação, para que sejam diretamente utilizadas pelos implementadores.

Alternativas
Comentários
  •  Errado

    O erro da questão é afirmar que o caso de uso deve incluir a forma de implementação, pois o caso de uso deve capturar o que o sistema deve fazer - requisitos funcionais - não se preocupar como implementar esses requisitos.

  • Casos de uso define o QUE fazer e não COMO fazer.
  • Não há o que se falar em forma de implementação a nível de caso de uso. A questão está ERRADA, pois não cabe na descrição de casos de uso, definições sobre implementação do sistema.


ID
148087
Banca
FCC
Órgão
TRT - 16ª REGIÃO (MA)
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Considere um Caso de Uso Base ? UCB ? que represente o atendimento a um trabalhador para uma reclamação trabalhista. Entretanto, na ocorrência de uma determinada condição como, por exemplo, "o reclamante tem precedentes judiciais", um outro Caso de Uso ? UCS ? envia um comportamento ao UCB. Nessa situação, a UML representa o relacionamento de UCB com UCS como

Alternativas
Comentários
  • Questão mau formulada. A questão não explica se o trabalhador poderia dar ou não continuidade à sua reclamação trabalhista, após a mensagem "o reclamante tem precedentes judiciais" o que pode levar a 2 opções: Inclusão (<< include >>) ou Extensão (<< extend >>).
     
    se fosse o primeiro (INCLUSÃO), o caso de uso UCB só pode ser realizado se o caso de uso UCS não tiver restrição judicial, como afirma a questão. Se fosse o segundo, o caso de uso UCB poderia dar continuidade à reclamação, mesmo emitindo a mensagem "o reclamante tem precedentes judiciais".
  • Questão bem formulada e boa pra embaralhar o candidato.

    Sem quebrar muito a cabeça se souber o conceito de cada relacionamento matamos a questão.
    O X da questão esta em "determinada condição"  pois :

    inclusão = é obrigatorio um Caso de uso sempre quando for executado chamar o outro de inclusão;
    extensão = opcional ou melhor (quando ocorre uma condição) para um caso de uso chamar o outro.


    Considere um Caso de Uso Base ? UCB ? que represente o atendimento a um trabalhador para uma reclamação trabalhista. Entretanto, na ocorrência de uma determinada condição como, por exemplo, "o reclamante tem precedentes judiciais", um outro Caso de Uso ? UCS ? envia um comportamento ao UCB. Nessa situação, a UML representa o relacionamento de UCB com UCS como

    LETRA : B  extensão

ID
148393
Banca
FCC
Órgão
TRT - 16ª REGIÃO (MA)
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

São diagramas comportamentais da UML:

Alternativas
Comentários
  • Para não esquecer!

    Diagramas Estruturais:
    Diagrama de classes
    Diagrama de objetos
    Diagrama de componentes
    Diagrama de instalação
    Diagrama de pacotes
    Diagrama de estrutura
     
    Diagramas Comportamentais:
    Diagrama de Caso de Uso
    Diagrama de Estados
    Diagrama de atividade
    Diagramas de Interação (também são comportamentais):
    Diagrama de sequência
    Diagrama de Interatividade
    Diagrama de colaboração ou comunicação
    Diagrama de tempo

     
  •  e)Use Case e Sequence.

    Structural diagrams - estrutura do PC.
    Class diagram
    Component diagram
    Composite structure diagram
    Deployment diagram
    Object diagram
    Package diagram
    Profile diagram

     

    Behavioral diagrams - tu, aciss?
    Activity diagram
    Communication diagram
    Interaction overview diagram
    Sequence diagram
    State diagram
    Timing diagram
    Use case diagram


ID
150361
Banca
FCC
Órgão
TJ-PA
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Nos relacionamentos entre Casos de Uso

Alternativas
Comentários
  • Na letra "A", a parte que diz: "sob certas condições" deixa o intem incorreto. Estaria certo se estivesse se referindo ao Extend.
  • a) um include significa que o caso de uso base incorpora implicitamente o comportamento de outro, sob certas condições.

    Isso é o <EXTEND>
    o <INCLUDE> é como se fosse a chamada de uma função. Um caso de uso usa outro caso de uso como se este fosse uma sub-rotina.


    b) não é permitida a generalização.

    Generalização é permitida tanto para casos de uso quanto para atores.

    c) somente include é considerado um estereótipo.
    <INCLUDE> e <EXTEND> são esteriótipos

    d) somente extend é considerado um estereótipo.
    <INCLUDE> e <EXTEND> são esteriótipos (2)

    e) tanto include quanto extend são considerados estereótipos.
    <INCLUDE> e <EXTEND> são esteriótipos (3)
  • Casos de uso sao tarefas ou funções que podem ser usadas pelos usuarios. POde tambem ser consiederados conjunto de sequencias de ações que um sistema executa para causar um resultado de um valor a um ator especifico. 

     a) um include significa que funcoes usam a mesma solicitação. logo, essa rotina é colocada em um caso de uso especifico. 

     b) generalização é agrupar itens com atributos comuns. A documentacao contera somente as caracteristicas especificas de cada 1.

     e) estereótipos sao o núcleo do mecanismo de extesao do UML. Estendem o significado de um elemento em um diagrama. Podem ser gráficos(desenho) ou label <<<>>>


ID
150937
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

O modelo de casos de uso é um dos artefatos mais importantes previstos pelo Processo Unificado. Sobre o modelo de casos de uso, são feitas as afirmativas a seguir.

I - Atores humanos são identificados com base no papel que desempenham do ponto de vista do sistema, e não necessariamente no cargo que ocupam na instituição em que o sistema rodará.

II - A evolução dos casos de uso ao longo do ciclo de vida do projeto prevê que os mesmos ganhem em seu texto os detalhes específicos de implementação necessários à construção do software na tecnologia adotada.

III - As combinações possíveis do fluxo principal com os fluxos alternativos de um caso de uso fornecem todos os cenários possíveis para o mesmo, os quais, por sua vez, podem ser utilizados como unidades de planejamento, implementação e testes.

IV - É recomendável que cada caso de uso seja decomposto funcionalmente e passe a incluir casos de uso menores, sucessivamente, até a menor unidade implementável possível, atendendo ao princípio da decomposição funcional.

Estão corretas APENAS as afirmativas

Alternativas
Comentários
  •  II - não está certo colocar que um caso de uso irá representar detalhes de implementação

    IV - não é necessário dividir um caso de uso até a menor unidade implementável, os casos de uso críticos são implementados.

  • I. Correto! Pessoas e sistemas são respresentados pelos atores.
    II. Errado! Detalhes técnicos, como tecnologias adotadas não fazem parte dos casos de uso;
    III. Correto! Fluxos principais e alternativos são os passos-a-passo de todas possibilidades do caso de uso.
    IV. Errado! A decomposição só ocorre caso o caso de uso seja muito complexo.
  • De acordo com o RUP (http://www.wthreex.com/rup/portugues/index.htm):

    Caso de Uso (classe)
    Uma descrição de comportamento do sistema em termos de seqüências de ações. Um caso de uso deve produzir um resultado de valor observável para um ator. Ele contém todos os fluxos alternativos de eventos referentes à produção do "resultado de valor observável".
    Mais formalmente, um caso de uso define um conjunto de instâncias de casos de uso ou cenários.


    Ator
    Alguém ou algo fora do sistema que interage com ele.

    Sobre Visão de Caso de Uso:
    Para fornecer uma base para o planejamento do conteúdo técnico de iterações, uma visão de arquitetura chamada visão de casos de uso é utilizada na disciplina Requisitos. Só existe uma visão de casos de uso do sistema, que ilustra os casos de uso e cenários que englobam o comportamento, as classes ou os riscos técnicos significativos do ponto de vista da arquitetura. A visão de casos de uso é refinada e considerada inicialmente em cada iteração.

     
    Especificação de uma seqüência de ações (incluindo variantes) que um sistema (ou outra entidade) pode executar, interagindo com atores do sistema. Consulte instância de caso de uso, cenário.

ID
157822
Banca
FCC
Órgão
METRÔ-SP
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Considere:

I. Farol ligado.
II. Comprar produto.
III. Máquina elétrica.

Os itens acima são representados em diagramas UML, respectivamente, como

Alternativas

ID
161608
Banca
FCC
Órgão
MPE-RS
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

No diagrama de casos de uso da UML, o relacionamento
de generalização acontece entre

Alternativas
Comentários
  •    Os relacionamentos entre casos de uso podem ser do tipo INCLUSÃO, EXTENSÃO ou GENERALIZAÇÃO
       Na INCLUSÃO(Possibilidade de decompor casos de uso complexos em partes menores ou separar partes que serão utilizadas em vários casos de uso), o caso de uso é incluído e passa a fazer parte do outro.
       Na EXTENSÃO Funções são incluídas em outros casos de uso, representam uma excessão(comportamento não anormal do sistema)
       Na GENERALIZAÇÃO trata de herança entre um caso de uso mais específico ou seja especifica que um caso de uso herda as características do "super" caso de uso. Os casos de uso de B são também casos de uso de A e A tem seus próprios casos de uso      
  • Letra C

    Uma generalização de casos de uso é um relacionamento de um caso de uso filho com um caso de uso pai, especificando como um filho pode adotar todo o comportamento e as características descritas para o pai,sendo assim possivel ter generalização tanto entre casos de uso e entre atores.

  • Gabarito: C

    A resposta é entre casos de uso e entre atores. Tomar cuidado com o item D, pois numa leitura rápido pode confundir.

    Explicação:
    Casos de uso - Relacionamentos permitidos:
    Associação:
    Generalização
    Dependência: Extensão e Inclusão

    Relacionamento de associação
    * Indica que há uma interação (comunicação) entre um caso de uso e um ator;
    * Um ator pode se comunicar com vários casos de uso;

    Relacionamento de generalização
    Atores:
    * Quando dois ou mais atores podem se comunicar com o mesmo conjunto de casos de uso;
    * Um filho (herdeiro) pode se comunicar com todos os casos de uso que seu pai se comunica.
    Casos de Uso:
    * O caso de uso filho herda o comportamento e o significado do caso de uso pai;
    * O caso de uso filho pode incluir ou sobrescrever o comportamento do caso de uso pai;
    * O caso de uso filho pode substituir o caso de uso pai em qualquer lugar que ele apareça;

    -----------------------------

    Outra boa referência sobre o assunto: http://www.dsc.ufcg.edu.br/~sampaio/cursos/2007.1/Graduacao/SI-II/Uml/diagramas/usecases/usecases.htm
  • Gabarito letra "C".

    d) Errada. Não ocorre generalização somente entre casos de uso e entre atores. Pode existir, por exemplo, um relacionamento de generalização entre pacotes dentro de um diagrama de casos de uso.
  • Tipos de relacinamentos no diagrama de casos de uso:

    Dependência - Entre Casos de Uso (Generalização, extensão e inclusão)

    Generalização - Entre Atores e entre Casos de uso. (Herança)

    Associação - Entre Casos de Uso e Atores

    Corrijam caso eu esteja errado. Por favor.


ID
164008
Banca
FCC
Órgão
TJ-PI
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Em UML (Unified Modeling Language), os Diagramas de Caso e Uso são

I. adequados para representar o desenho e descrever os mecanismos internos de um sistema.

II. feitos para facilitar a comunicação com os futuros usuários do sistema e com o cliente.

III. projetados para determinar o que o sistema deve fazer e especificar como isto será conseguido.

IV. especialmente úteis para determinar os recursos necessários que o sistema deve ter.

É correto o que consta APENAS em

Alternativas
Comentários
  • O diagrama de casos de uso e' uma representacao simplificada da realidade (facilita o entendimento pelo usuario) utilizado para representar os requisitos funcionais e principalmente quem faz o que no sistema, sem considerar o comportamento interno.

  • I. adequados para representar o desenho e descrever os mecanismos internos de um sistema. Errado. Os casos de uso não representa o desenho do sistema.

    II -  feitos para facilitar a comunicação com os futuros usuários do sistema e com o cliente. ok. è um dos objetivos dos casos de uso.

    III - projetados para determinar o que o sistema deve fazer e especificar como isto será conseguido.  Errado. Não determina como deve ser feito.

    especialmente úteis para determinar os recursos necessários que o sistema deve ter. ok.
  • A tradução do item IV está incorreta, por isso a questão está complicada.

    A frase
    "IV. especialmente úteis para determinar os recursos necessários que o sistema deve ter"
    parece ser uma tradução desta
    "specially helpful to determine the required features the system is to have."

    Features não são recursos, são características, o que daí sim faz sentido em se tratando de casos de uso.

    A fonte é esta: http://docs.kde.org/stable/en/kdesdk/umbrello/uml-elements.html#use-case-diagram

    Agora só preciso aprender a detectar traduções mal feitas durante as provas. =/
  • Bem apontado pelo colega, eliminei a IV pois Recursos me lembra estrutura física e não características do sistema.
  • que piada essa FCC, não sabe nem fazer uma tradução!
  • e-

    Use case diagrams are usually referred to as behavior diagrams used to describe a set of actions (use cases) that some system or systems (subject) should or can perform in collaboration with one or more external users of the system (actors). Each use case should provide some observable and valuable result to the actors or other stakeholders of the system.

    https://www.uml-diagrams.org/use-case-diagrams.html

    diagramas de caso de uso sao para comunicacao com o usuario, sendo bem útil durante a fase de levantamento de requisitos.

    "especialmente úteis para determinar os recursos necessários que o sistema deve ter."

    assim como os colegas, creio que tb se trate de características. "recursos" remete a requisitos nao -funcionais, o que nao se relaciona com esse diagrama

  • Fui por eliminação. O item III está incorreto pois os diagramas de Casos de Uso não determinam como o sistema deve ser feito, logo só me restou a alternativa E.

ID
171235
Banca
FGV
Órgão
MEC
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Na UML o diagrama que descreve uma sequência de ações que representam um cenário principal e cenários alternativos, com o objetivo de demonstrar o comportamento de um sistema, por meio de interações com atores, é o diagrama de:

Alternativas
Comentários
  •  Sempre que existirem atores, o diagrama é de Caso de Uso.

  • O Diagrama de Casos de Uso tem o objetivo de auxiliar a comunicação entre os analistas e o cliente.
    Um diagrama de Caso de Uso descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. 
    O cliente deve ver no diagrama de Casos de Uso as principais funcionalidades de seu sistema.
    Notação
    O diagrama de Caso de Uso é representado por:
    • atores;
    • casos de uso;
    • relacionamentos entre estes elementos.
    Estes relacionamentos podem ser:
    • associações entre atores e casos de uso;
    • generalizações entre os atores;
    • generalizações, extends e includes entre os casos de uso.
  • No diagrama de Casos de Uso há a ideia de SEQUÊNCIA?????

  • Taciano Alcântara, lembre-se que no Diagrama de Sequência também pode existir ator. O Diagrama de Sequência "registra o comportamento de um único caso de uso" (Wikipedia). Portanto, vale ficar atento.

  • também achei estranho a questão da sequência ¬¬

  • Caso de Uso não tem "uma sequência de ações "

  • No diagrama de Sequência pode ter atores também.



ID
171238
Banca
FGV
Órgão
MEC
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

A UML (Unified Modeling Language) possui vários tipos de diagramas que em conjunto são utilizados para descrever a visão estática e dinâmica de um sistema.
Assinale a alternativa em que todos os diagramas listados descrevem uma visão dinâmica de um sistema.

Alternativas
Comentários
  • alguém poderia me explicar sobre esse diagrama Visão Geral??? Nunca ouvi falar dele na UML 2.0. Por eliminação só podia ser essa alternativa mesmo, mas fiquei com essa dúvida.

  • Item correto Letra E

    Os diagramas são os gráficos que descrevem o conteúdo em uma visão. A visão é uma abstração de uma série de diagramas. Cada visão é descrita por um número de diagramas que contém informações que dão ênfase aos aspectos particulares do sistema. Existe em alguns casos uma certa sobreposição entre os diagramas o que significa que um deste pode fazer parte de mais de uma visão. Os diagramas que compõem as visões contém os modelos de elementos do sistema. As visões que compõem um sistema são:Visão "use-case",  Visão Lógica,  Visão de Componentes,   Visão de concorrência e Visão de Organização.

  • A UML 2.0 classifica de forma geral seus diagramas da seguinte forma:

    Diagrama de Comportamento, Interação e Extrutura.

    Diagramas de comportamento. Um tipo de diagrama que descreve características comportamentais de um sistema ou processo de negócio. Isto inclui a actividade, máquina de estado e diagramas de casos de uso, ,bem como os quatro diagramas de interação

    Diagramas de interação. Um subconjunto dos diagramas de comportamento que enfatizam interações de objetos. Isso inclui a comunicação, visão geral de interação, seqüência e diagramas de tempo.

    Diagramas de estrutura. Um tipo de diagrama que descreve os elementos de uma especificação que são independentes do tempo. Isto inclui estrutra composta, estrutura de classes, componentes, implantação, objeto e diagramas de pacote.

    fonte: http://www.agilemodeling.com/essays/umlDiagrams.htm

  • O diagrama de visão geral (ou mais adequadamente, visão geral de integração), é uma variante do diagrama de atividades, e inclui diferentes sequências num fluxo de atividades para mostrar suas interações. 
    Ex:
  • e-

    os diagramas estruturais: Classes, Objetos, Implantação, composite structure e Pacotes. O que nao estiver entre eles, sera de comportamento


ID
192904
Banca
FCC
Órgão
MPE-RN
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Os relacionamentos presentes nos diagramas de casos de uso podem ser de

I. Agregação.
II. Generalização.
III. Dependência.
IV. Associação.

Está correto o que consta em

Alternativas
Comentários
  • Gabarito: D

    Casos de uso - Relacionamentos permitidos:
    Associação:
    Generalização
    Dependência: Extensão e Inclusão

    Relacionamento de associação
    * Indica que há uma interação (comunicação) entre um caso de uso e um ator;
    * Um ator pode se comunicar com vários casos de uso;

    Relacionamento de generalização
    Atores:
    * Quando dois ou mais atores podem se comunicar com o mesmo conjunto de casos de uso;
    * Um filho (herdeiro) pode se comunicar com todos os casos de uso que seu pai se comunica.
    Casos de Uso:
    * O caso de uso filho herda o comportamento e o significado do caso de uso pai;
    * O caso de uso filho pode incluir ou sobrescrever o comportamento do caso de uso pai;
    * O caso de uso filho pode substituir o caso de uso pai em qualquer lugar que ele apareça;

    Relacionamento de dependência:
        Extensão:
    * Representa uma variação/extensão do comportamento do caso de uso base
    * O caso de uso estendido só é executado sob certas circunstâncias
    * Separa partes obrigatórias de partes opcionais
    * Partes obrigatórias: caso de uso base
    * Partes opcionais: caso de uso estendido
    * Fatorar comportamentos variantes do sistema (podendo reusar este comportamento em outros casos de uso)
       Inclusão:
    * Evita repetição ao fatorar uma atividade comum a dois ou mais casos de uso
    * Um caso de uso pode incluir vários casos de uso

    Fonte: http://wiki.les.inf.puc-rio.br/uploads/0/0b/Aula01-diagrama_casos_uso.ppt

  • Relacionamentos permitidos em Diagrama de Casos de Uso:

    - Entre  casos de uso: inclusão (dependência), extensão (dependência), generalização

    - Entre atores: generalização

    - Entre caso de uso e ator: associação (comunicação)

    Fonte: UML Guia do Usuário - Booch, Rumbaugh, Jacobson
  • Como não foi falado nos comentários acima o erro da questão.A incorreção se deve ao fato que agregação é uma das formas de associação e não um novo relacionamento, ou seja, agregação está contida já na opção IV.Associação por isso o erro da alternativa I.

     


ID
195271
Banca
CESPE / CEBRASPE
Órgão
TCU
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens seguintes, a respeito de engenharia de requisitos.

Para o desenvolvimento de casos de uso, é fundamental a identificação dos atores, tanto os principais quanto os secundários, já na primeira iteração do levantamento de requisitos.

Alternativas
Comentários
  • Na primeira iteração do levantamento de requisitos, identifica-se primeiramente APENAS os atores principais.

  •  Não há impedimento que outros atores sejam identificados em outras iterações.

  • Eu penso que nada garante que os atores estarão claros ou bem definidos na primeira iteração.
    Pode ser necessário uma compreensão do sistema antes de identificar os atores, o que pode acontecer em iterações posteriores.
  • Atores secundários são aqueles que existem apenas para que os atores primários utilizem o sistema. (Fonte: Princípios de Análise e projeto de Sistemas com UML). Logo, é pouco provável que já na primeira iteração, possa-se identificá-los.
  • Capítulo 7, Engenharia de Requisitos (PRESSMAN), página 130:

    “Como o levantamento de requisitos é uma atividade evolutiva, nem todos os atores são identificados durante a primeira iteração. É possível identificar atores principais durante a primeira iteração, e os atores secundários quando se fica sabendo mais a respeito do sistema. O atores principais interagem para conseguir a função desejada do sistema e derivar o benefício pretendido com o sistema. Eles trabalham direta e frequentemente com o software. Os atores secundários dão suporte ao sistema, de modo que os atores principais possam fazer o seu trabalho."

    Errado. Apenas os atores PRINCIPAIS são identificados na primeira iteração.

ID
201490
Banca
FCC
Órgão
BAHIAGÁS
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

É um tipo de diagrama comportamental da UML. Trata-se do Diagrama de

Alternativas
Comentários
  • Diagramas Estruturais
     - Diagrama de classes
     - Diagrama de objetos
     - Diagrama de componentes
     - Diagrama de instalação
     - Diagrama de pacotes
     - Diagrama de estrutura
    Diagramas Comportamentais
     - Diagrama de Caso de Uso
     - Diagrama de transição de estados
     - Diagrama de atividade
    Diagramas de Interação
     - Diagrama de sequência
     - Diagrama de Interatividade
     - Diagrama de colaboração ou comunicação
     - Diagrama de tempo


ID
218164
Banca
CESPE / CEBRASPE
Órgão
TRE-BA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

A respeito de UML (unified modeling language), julgue os
itens 59 e 60.

O propósito maior de um caso de uso é fornecer uma descrição do comportamento do sistema. Assim, em um processo de desenvolvimento orientado a objetos, os objetivos de um caso de uso são: definir escopo, detalhar os processos e cálculos do sistema, organizar e dividir o trabalho, estimar o tamanho do projeto e direcionar os testes.

Alternativas
Comentários
  • Os casos de uso mapeiam o comportamento do sistema, identificam quem e o quê interage com o sistema e também o que o sistema deve fazer.

    O modelo de caso de uso representa as futuras funcionalidades do sistema.

    A utilização de Casos de Uso descreve os requisitos do sistema.

    Os diagramas de caso de uso ajudam os stakeholders a entender a natureza e escopo da area de negócio ou sistema em desenvolvimento, mas NÃO É objetivo dos diagramas de caso de uso definir o escopo.

  •  Comentário postado pelo Fernando Pedrosa no TIMasters

    1. Segundo o RUP, o conjunto de Casos de Uso do sistema define o seu escopo. 
    - OK.

    2. Cálculos internos *nunca* são detalhados em um caso de uso.
    - isso é má prática, e esta é uma das razões pelas quais a questão está errada.

    3. Casos de uso organizam e dividem o trabalho a ser realizado
    - OK.

    4. Eu diria que casos de uso AJUDAM a estimar o tamanho do projeto, mas não estimam por si só
    - frase imprecisa.


    5. Casos de teste são gerados a partir de casos de uso
    - OK.

  • Vanuza, por qual motivo o UC não tem o objetivo de definir o escopo?

    Eu acho que ele pode fazer isso sim. O cliente observando um diagrama de casos de uso pode sugerir algum fluxo não previsto antes (um exemplo de auxílio na definição do escopo).

  • Fodástico esse caso de uso, hein
  • [Rogeer S. Pressman]

    Em um livro que discute como redigir casos de uso eficazes, Alistair Cockburn [Coc01b] observa que “um caso de uso captura um contrato... [que] descreve o comportamento do sistema sob várias condições à medida que o sistema responde a uma solicitação de um de seus interessados...”. Essencialmente, um caso de uso conta uma história estilizada sobre como um usuário final (desempenhando um de uma série de papéis possíveis) um caso de uso representa o software. 
    Independentemente de sua forma, um caso de uso representa o software ou o
    sistema do ponto de vista do usuário final.

    ----------------------------------------------------------------------------------------------------------------------------------------

    - O propósito maior de um caso de uso é fornecer uma descrição do comportamento do sistema [OK]

    - Processo de desenvolvimento orientado a objetos, os objetivos de um caso de uso são: definir escopo [OK], detalhar os processos e cálculos do sistema [OK detalha os processos e os cálulos para a equipe de dedsenvolvimento que irá ussar o caso de uso], organizar e dividir o trabalho [OK, casos ddee uso dividem o trabalho geeralmente por funcionalidaddes do sistema], estimar o tamanho do projeto e direcionar os testes [Casos de Uso não direcionam os testes. Documeento de Casos de teste que direcionam os testes. Caso de uso também não tem objetivo de estimar o tamanho do projeto, a contagem de pontos de função não é feita no caso dee uso].

    Os casos dee uso direcionam os requisitos do sistema e não teste do sistema.

    Há um exemplo na questão 60 desta prova.


ID
218167
Banca
CESPE / CEBRASPE
Órgão
TRE-BA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

A respeito de UML (unified modeling language), julgue os
itens 59 e 60.

Considerando o caso de uso e ator a seguir, é correto afirmar que, na narrativa do caso de uso, não é necessário se preocupar em como o sistema obteve ou calculou os dados, e que o desenvolvedor deve limitar-se a escrever o que o sistema responde e não como ele obtém a resposta.
caso de uso: consultar preço
ator: vendedor
1. O ator inicia o caso de uso selecionando "consultar preço";
2. O sistema oferece a interface para consulta de preços;
3. O ator seleciona um grupo de produtos;
4. O sistema lista os subgrupos do grupo selecionado;
5. O ator seleciona um subgrupo de produtos;
6. O sistema apresenta os produtos do subgrupo selecionado;
7. O ator seleciona os produtos;
8. O sistema calcula os preços.

Alternativas
Comentários
  • "A criação de casos de uso deve ser feita de uma maneira completamente fechada, ou seja, assumindo que o actor não tem conhecimento sobre o estado interno do sistema quando acessa uma dada funcionalidade. Devendo as iterações ser descritas do ponto de vista externo. Esta forma de encarar a descrição de iteração simplifica a descrição dos requisitos evita falsas assumpções sobre como a funcionalidade será implementada no sistema."

    Fonte: http://pt.wikipedia.org/wiki/Caso_de_uso
  • concordo com a questão mediante a seguinte ressalva: "e que o desenvolvedor deve limitar-se a escrever o que o sistema responde e não como ele obtém a resposta.". A questão está afirmando que é o desenvolvedor que escre o caso de uso, algo que é incorreto.

ID
235402
Banca
CETAP
Órgão
AL-RR
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Analise os seguintes enunciados relacionados aos componentes da linguagem UML e marque a alternativa CORRETA.

I- Os diagramas de casos de uso têm como objetivo ilustrar a interação entre elementos (atores) e funcionalidades do sistema;

II- O modelo de classes de domínio representa as classes no domínio do negócio em questão e não leva em consideração restrições inerentes à tecnologia a ser utilizada na solução;

III- Uma classe em um diagrama de classes é definida por um nome, uma lista de atributos (não obrigatória) e uma lista de operações (não obrigatória);

IV- O modelo de interação pode ser descrito utilizando diagramas de componentes ou diagramas de estados;

V- Os pacotes são mecanismos de agrupamento genérico e podem ser utilizados para agregar casos de uso, classes e alguns outros tipos de elementos.

Alternativas
Comentários
  • IV- O modelo de interação pode ser descrito utilizando diagramas de sequencia, de comunicação, de visão geral de interação e de tempo. componentes ou diagramas de estados;
  • d-

    I- enunciado I esta em todas. Noa percamos tempo analisando-o.

    II- O unico diagrama que está associado à linguagem de programação cuja finalidade é indicar os componentes do software e relacionamentos é o de componentes

    III- pode fazr um diagarma de classe sem especificar seus atributos e metodos, mas o nome é sempre necessario

    IV- interação: TICS: tempo, visao geral, comunicação, sequencia,

    V- diagramas de pacotes: mostra pacotes de classes e as dependências entre eles. Visão como um todo, assim como subsistemas.
    divisões lógicas e suas interações em alto nível.


ID
240790
Banca
FCC
Órgão
TRT - 8ª Região (PA e AP)
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Os relacionamentos que podem ser representados em um diagrama de caso de uso são:

Alternativas
Comentários
  • Os relacionamentos do diagrama de caso de uso:

    Associação
    Pode ser unidirecional ou bi-direcional.
    Quando uma seta aponta para o ator, significa que a informação está indo do sistema para o ator.
    Quando uma seta aponta para o caso de uso, significa que a informação está indo do ator, ou usuário, para o sistema.
    Quando não tem seta, significa que o negócio é full-duplex ou half-duplex se for um negócio sincrono. Significa que a informação flui entre as partes livremente.

    Generalização/Especialização
    Pode ser entre casos de uso ou entre atores.
    Quando um caso de uso herda de outro, herda também todas as suas depedências, tudo o que o caso de uso base se associa, todos os extends ou includes.

    Include
    É como se o caso de uso estive chamando uma função em linguagem de programação, incluíndo uma sub-rotina comum a muitos casos de uso.

    Extends
    Parece com o include, mas só é utilizado em casos especiais, sob algum evento particular.



    Eu não encontrei em nenhum lugar explicitamente falando em dependência, mas acredito que seja um relacionamento implícito válido para qualquer um dos que foram citados. Se você Associa, Herda, Inclui ou Extend algo, então você depende disso.
  • Para dar mais uma clareada no assunto...

    Associação: Você associa um ator com um ou mais casos de uso. Uma relação entre um ator e um caso de uso indica que o ator inicia o caso de uso, o caso de uso fornece resultados ao ator, ou ambos.

    Generalização: Atores e casos de uso podem ser generalizados da mesma forma que muitos outros classificadores.
    A generalização de ator é utilizada para extrair requisitos comuns de vários atores diferentes para simplificar a modelagem.
    A generalização de caso de uso é utilizada para expressar algumas necessidades funcionais de alto nível de um sistema, sem entrar em especificidades. A generalização é representada por uma linha contínua com uma seta fechada apontando do caso de uso especializado para o caso de uso básico.

    Inclusão: é um caso de uso compartilhado. O caso de uso que inclui outro caso de uso é incompleto. A funcionalidade incluída não é considerada opcional; ela é destacada (separada) simplesmente para permitir a reutilização em outros casos de uso. É representada por uma linha tracejada com uma seta aberta (DEPENDÊNCIA) apontando do caso de uso básico para o caso de uso incluído e a palavra "include"
    Extensão: fornece a capacidade de se conectar um caso de uso ADICIONAL a um caso de uso básico se condições específicas forem atendidas. A extensão também é representada com uma seta de DEPENDÊNCIA apontando do caso de uso de extensão para o caso de uso básico e a palavra "extends"

  • Podemos tirar a conclusão que a DEPENDENCIA são os includes e os extends. Portanto a resposta é associação, generalização e dependencia.
  • Podemos concluir que a relação de include se configura em uma dependência total entre os casos de uso envolvidos e que a relação de extend seria uma dependência parcial, podendo ocorrer ou não, dependendo de uma ou mais condições.

ID
277294
Banca
CESPE / CEBRASPE
Órgão
TRE-ES
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens subsecutivos, referentes a UML.

Os modelos de casos de uso enfatizam os objetivos e as perspectivas do usuário, demonstrando a visão de quem utiliza o sistema.

Alternativas
Comentários
  • Segundo Ivar Jacobson, idealizador do modelo de caso de uso, pode-se dizer que um casos de uso é um "documento narrativo que descreve a sequência de eventos de um ator que usa um sistema para completar um processo. Ou seja, o modelo de casos de uso deve sempre representar a sequência de eventos de processos sob a ótica dos atores (quem utiliza o sistema).
  • É correto falar que um caso de uso enfatiza os objetos? Até agora imaginava que o caso de uso era um diagrama mais abstrato, não descendo ao nível de objetos do sistema, mas apenas exponto as atividades, atores e seus relacionamentos.

    Alguém comenta?
  • Concordo com Benjamin: De acordo com o UML Guia do Usuário : 

    Os casos de usos podem ser aplicados para captar o comportamento pretendido do sistema que está sendo desenvolvido, sem ser necessário espcificar como esse comportamento é implementado. 
    Casos de uso bem-estruturados denotam somente o comportamento essencial do sistema ou subssistema e não são amplamente gerais, nem muito específicos.
  • Falta de atenção minha. A questão fala em objetivos, e não objetos.


ID
280162
Banca
IADES
Órgão
CFA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Um diagrama é uma apresentação gráfica de um conjunto de elementos, geralmente representada como um gráfico conectado de vértices (itens) e arcos (relacionamentos). Na notação da UML existem diversos tipos de diagramas. Com base nas funções de cada diagrama, julgue os itens a seguir.

I O diagrama de classes é um diagrama estrutural que mostra um conjunto de classes, interfaces, colaborações e seus relacionamentos.

II O diagrama de casos de uso é um diagrama comportamental que mostra um conjunto de casos de uso, atores e seus relacionamentos

III O diagrama de colaboração é um diagrama comportamental que mostra o conjunto de componentes e seus relacionamentos

IV O diagrama de sequência é um diagrama estrutural que mostra uma interação, dando ênfase à ordenação temporal das mensagens.

A quantidade de itens certos é igual a

Alternativas
Comentários
  • item I - ERRADO : Diagrama de classes com interfaces, colaborações??? não.
    Item II - CORRETO
    Item III - CORRETO
    Item IV - ERRADO: O diagrama de sequência é um diagrama de interação(subconjunto dos diagramas Comportamentais)
     
    bons estudos
    Marcelo
  • Entendo que as afirmativas corretas são I e II. Justificativa para considerar correta a afirmativa I:

    Afirmativa I - é possível representar nos diagramas de classes :

    interfaces: são  tipos especiais de classe, e portanto plenamente possível mostrá-las no diagrama de classes; podem, por exemplo, aparecer nos diagramas de classes através do estereótipo "interface"

    colaborações: em termos gerais correspondem ao uso em conjunto de vários elementos para a solução de determinado propósito; no livro UML Distilled, Martin Fowler descreve:

       "When you use a collaboration, you can show that by placing a collaboration occurrence on a class diagram, ..."

    Por outro lado, considero a afirmativa III incorreta pelo fato de que nos diagramas de colaboração são mostrados os relacionamentos entre os objetos e não entre os componentes (os componentes são explicitados nos diagramas de componentes).

  • I O diagrama de classes é um diagrama estrutural que mostra um conjunto de classes, interfaces, colaborações e seus relacionamentos.- CORRETO

    II O diagrama de casos de uso é um diagrama comportamental que mostra um conjunto de casos de uso, atores e seus relacionamentos. CORRETO

    III O diagrama de colaboração é um diagrama comportamental que mostra o conjunto de componentes e seus relacionamentos  - ERRADO
      RESP. CERTA: O diagrama de colaboração(ou comunicação na UML 2.0) é um diagrama comportamental que dá ênfase à organização estrutural dos objetos que enviam e recebem mensagens. Um diagrama de comunicação mostra um conjunto de papéis, as conexões existentes entre esses papéis e as mensagens enviadas a recebidas pelas instâncias.
    O diagrama de componentes mostra as partes internas, os conectores e as portas que implementam um componente.


    IV O diagrama de sequência é um diagrama estrutural que mostra uma interação, dando ênfase à ordenação temporal das mensagens. ERRADO
    O diagrama de sequência é um diagrama de interação que dá ênfasse á ordenação temporal das mensagens.



ID
308731
Banca
CESPE / CEBRASPE
Órgão
TJ-ES
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Com referência a engenharia de software e uso de UML para a
modelagem de sistemas, julgue os itens subsecutivos.

Os casos de uso devem ser definidos de tal forma que representem todas as situações possíveis de utilização do sistema que está sendo definido; opcionalmente, a descrição dos casos de uso pode ser feita por meio de cenários.

Alternativas
Comentários
  • Não concordo com o gabarito da questão. Já vi outra questão do CESPE que falava o seguinte:

    "Um cenário, também denominado instância de caso de uso, é uma sequência específica de ações e interações entre atores e o sistema em discussão. Assim, um caso de uso é uma coleção de cenários relacionados de sucesso e fracasso, que descrevem atores usando um sistema como meio para atingir um objetivo. "

    Se um caso de uso é uma coleção de cenários, então a descrição do caso de uso DEVE ser feita por meio de cenários e não opcionalmente.

    O que vocês acham ?
  • Cintia,
             O UC pode ser definido de diversas maneiras. Desde uma matriz que relaciona regras de negócios e dados necessários ao UC e pode ser construido da maneira mais usual, a partir de cenários em tópicos (modelo proposto pelo RUP).

    Espero ter ajudado.

    []'s
  • Discordo quando fala em "todas as situações possíveis", o que é totalmente inviável.
  • Concordo com o comentário do colega. Todas as situações possíveis não tem como. Geralmente são atacadas aquelas que ajudam a estabelecer as funcionalidades principais do sistema ou que venham ser importantes para a definição da arquitetura.

    Está evidente que esta questão está errada. É impossível refletir todos as possibilidades de casos de uso de um sistema. Se alguém encontrar alguma fonte que mostre o contrário, mudo o meu posicionamento.
  • Em (UML 2, Gilleanes T.A.Guedes, ed. Novatec), um diagrama de Caso de Uso deve demonstrar o comportamento externo do sistema, procurando apresentar o sistema através de uma perspectiva do usuário, demonstrando funções e serviços oferecidos e quais usuários poderão utilizar cada serviço. Quando a questão fala em "todas as situações possiveis" está correto, dentro do escopo definido para a realização de um UC específico, atendendo à visão do usuário, e só. Opcionalmente, cenários podem representar especificidades do UC geral, o que não é problema algum. 

  • "Todos" é muita coisa meu querido...


ID
315646
Banca
FCC
Órgão
TRE-RN
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Na modelagem de Caso de Uso, <<include>> e <<extend>> são relacionamentos de

Alternativas
Comentários
  • <INCLUDE> e <EXTEND> são relacionamentos de dependência.

    A --------<<include>>----------->B
    INCLUDE: Uso obrigatório, toda vez que o caso de uso A for executado, obrigatoriamente o B também deverá ser executado.

    A <--------<<extends>>-----------B
    EXTENDS: Facultativo, ao executar o caso de uso A, não se torna obrigatorio a execução do caso de uso B.

  • "O relacionamento estendido é representado como uma dependência, esteriotipada como extend."


    UML, Guia do Usuário (Booch, Rumbaugh, Jacobson) Pág. 257.


ID
319111
Banca
FCC
Órgão
NOSSA CAIXA DESENVOLVIMENTO
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Quando da movimentação de materiais surge uma exceção que é a emissão de ordem de compra quando o estoque ficar abaixo do mínimo recomendado. Assim, a representação dessa situação no Diagrama de Caso de Uso é um relacionamento de

Alternativas
Comentários
  • Isso seria uma extensão, representada pelo esteriótipo <<EXTEND>>

    Note o exemplo:

    http://img814.imageshack.us/img814/5643/uml1.png

    Nesse caso, ao encerrar a conta temos dois casos excepcionais. Caso o usuário tenha dinheiro na conta ele deve fazer um saque. Caso o usuário tenha algum débito ele deve fazer um depósito.

    Já uma relação de inclusão é como a chamada de uma função|método|subprograma. Sempre irá acontecer.

  • Caso de Usos (Extensão) - Utilizado para expressar diferente sequências entre casos de uso (caminhos alternativos ou exceções). Representa um comportamento opcional, que só ocorre sobre certas condições.

    Caso de Usos (Inclusão) - Possibilita a subdivisão de casos de uso, bem como evita a descrição de uma mesma sequência de interações. Permite agrupar funcionalidades comuns em um ponto único de utilização.

    Caso de Usos (Generalização) - Pode existir entre dois casos de uso ou dois atores. Permite que se herde características de outro mais genérico.


ID
321100
Banca
CESPE / CEBRASPE
Órgão
Correios
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

A respeito da UML (unified modeling language), julgue os próximos itens.

Um relacionamento include de um caso de uso A para um caso de uso B indica que B é essencial para o comportamento de A. Então, ao se executar o caso de uso A, executa-se também o B.

Alternativas
Comentários
  • CORRETO. Se fosse EXTEND estaria errado visto que EXTEND acontece numa situação especial, não necessariamente SEMPRE.
  • Pessoal, fiquei com a impressão de que a questão colocou que o UC A foi incluído no UC B, o que tornaria o UC A essencial para o comportamento do UC B e não o contrário, conforme a questão coloca. Alguém mais interpretou dessa forma?
  • ML

    Um relacionamento include de um caso de uso A para um caso de uso B indica que B é essencial para o comportamento de A.

    Ou seja, seria o "sacar dinheiro" include "Checar senha" nesta figura http://www.linhadecodigo.com.br/artigos/img_artigos/admilson_nogueira/uml_EsteriotipoInclude_1.jpg
  • Não seria o contrário? Não entendi a questão...
  • Não seria A é essencial para que B ocorra?

    Como é um include, então quando A ocorrer B ocorrerá também.

    Alguem interpreta de outra maneira?!
  • Neste caso é so atentarmos na leitura correta da questão!
    Partindo de A que tem um "include" de B, nos mostra que realmente A depende de B. E não ao contrário. Portanto, questão correta!
  • Inclusão: Use quando o mesmo comportamento se repete em mais de um Caso de Uso e o processo de realizar X sempre envolve realizar Y pelo menos uma vez. 

    Extensão: Use quando você quiser modelar um comportamento opcional de um Caso de Uso.


  • Include = Composição / Extend = Agregação. Seria isso?



ID
328621
Banca
FUNIVERSA
Órgão
SEPLAG-DF
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Na análise orientada a objetos, um caso de uso pode representar uma funcionalidade oferecida pelo sistema. Acerca dos casos de uso, assinale a alternativa correta.

Alternativas

ID
334618
Banca
FCC
Órgão
TRT - 23ª REGIÃO (MT)
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Em UML NÃO é característica de Use Case:

Alternativas
Comentários
  • A letra B representa uma característica do Diagrama de Sequencia.
  • O diagrama de casos de uso corresponde a uma visão externa do sistema e representa graficamente os atores, os casos de uso, e os relacionamentos entre estes elementos. Ele tem como objetivo ilustrar em um nível alto de abstração quais elementos externos interagem com que funcionalidades do sistema, ou seja, a finalidade de um diagrama de caso de uso é apresentar um tipo de diagrama de contexto que apresenta os elementos externos de um sistema e as maneiras segundo as quais eles as utilizam.

    Em síntese: o Diagrama de Sequência é uma das ferramentas UML usadas para representar interações entre objetos de um cenário, realizadas através de operações ou métodos.
  • Não acredito que um conjunto de diagramas de caso de uso consiga essa proeza:

    Letra E - "representar todas as situações possíveis de utilização do sistema"

    Alguém comenta?
  • Na teoria os conjuntos de diagramas de caso de uso deveriam representar todas as funcionalidades do sistema (sua utilização), mas na prática sabemos que não é bem assim, principalmente quando não conhecemos o sistema a ser desenvolvido. Por isso o uso de ciclo interativo, a medida que vc vai aprendendo o sistema, vc conseguirá chegar perto de um todo necessário.
  • No meu entendimento a FCC fez uma confusão entre o conceito de Caso de Uso e de Diagrama de Caso de Uso. A letra E diz respeito ao conceito de Diagrama de Caso de Uso, mas não ao conceito de Caso de Uso, presente no início da questão, fato que, ao meu ver, poderia ser motivo para recurso. A letra B está terminantemente errada, e me parece a opção mais óbvia para marcar na prova!! Mas a letra E também está errada!!

    Bons estudos!!
  • "representar todas as situações possíveis de utilização do sistema, através do conjunto de todos os Use Case."

    Representar todas as situações possíveis? um sistema está em contínuo desenvolvimento/manutenção e nenhum diagrama ao meu ver, consegue representar todas as situações possíveis.


ID
337819
Banca
CS-UFG
Órgão
UFG
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Os diagramas de caso de uso UML são importantes para a modelagem do contexto de um sistema, subsistema ou classe, assim como a modelagem dos requisitos do comportamento desses elementos. Uma outra utilidade dos diagramas de caso de uso UML é a sua aplicação em

Alternativas

ID
348382
Banca
FUNCAB
Órgão
SEMARH-GO
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Na UML 2.0 há um diagrama que mostra os elementos de configuração de processamento runtime, e os componentes de software, processos e objetos que neles se mantêm. Este diagrama é de:

Alternativas
Comentários
  • e-

    O Diagrama de Implantação é configuração e a arquitetura ligandos os componentes. Exibe nós de processamento in runtime e os componentes existentes

    .
    Neste diagrama também representa estrutura de hardware e requisitos mínimos onde o sistema será executado, modelando a visão estática da implantação de um sistema e expressando hardware e tecnologia física. SIM, O DIAGRAMA DE IMPLANTAÇÃO, EMBORA SEJA UMA VISÃO ESTÁTICA (É UM DIAGRAMA ESTRUTURAL), MOSTRA O FUNCIONAMENTO DO SISTEMA COMPUTACIONAL EM RUNTIME, ISTO É , COMO ELE DEVE SER FUNCIONANDO.

     

    Os Diagramas de Implantação também podem especificar os módulos do sistema que deverão ser instalados no cliente.


ID
348811
Banca
FGV
Órgão
CODESP-SP
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

No emprego da UML utilizam-se diversos diagramas. Nos Casos de Uso, analise a situação abaixo:

Sejam ALFA e BETA dois casos de uso.
Quando BETA herda de ALFA, as sequências de comportamento de ALFA valem também para BETA.
Quando for necessário, BETA pode redefinir as sequências de comportamento de ALFA.
Além disso, BETA, na condição de caso de uso herdeiro, participa em qualquer relacionamento no qual ALFA participa.


A situação descrita caracteriza um relacionamento denominado

Alternativas
Comentários
  • Especialização/Generalizaçã– O relacionamento é uma forma de associação entre Casos de Uso na qual existem dois ou mais Casos de Uso com características semelhantes, apresentando pequenas diferenças entre si. Quando tal situação ocorre, costuma-se definir um Caso de Uso Geral que descreve as características compartilhadas por todos os Caos de Uso em questão e então relacioná-lo com os outros Casos de Uso envolvidos, cuja documentação conterá somente as características específicas de cada um. Estes conceitos valem também para classes, onde a superclasse (Mamíferos, no exemplo) representa a generalização das subclasses e as subclasses (Homem, Cão e Gato, no exemplo) representam a especialização da superclasse.

    http://ticnapratica.blogspot.com/2010/06/uml-e-oo.html
  • Segue a figura abaixo:


    http://4.bp.blogspot.com/_SP3vXljkCfg/TCYEmkylnyI/AAAAAAAAAZo/MGiqa8dPfoI/s320/uml-00-8-1.jpg
  • Analisemos:

    a) de inclusão.  INCORRETA
    O relacionamento de inclusão é um tipo específico de relacionamento de realização (estabelecimento de um contrato) onde se utiliza o estereótipo <> .

    b) de extensão. INCORRETA
    É um tipo de relacionamento de realização (estabelecimento de um contrato) onde se utiliza o estereótipo <> .

    c) generalização. CORRETA
    Também é chamado de herança. ALFA é pai de BETA, este herda suas características.

    d) associação. INCORRETA
    Tipo de relacionamento onde há asssociação de instâncias de classes, pode possuir multiplicidades.

    e) agregação. INCORRETA
    Tipo de associação onde há relação de todo/parte.

ID
359974
Banca
FEPESE
Órgão
UDESC
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Analise o texto abaixo:

Existe uma correspondência, ___________de ____________ , entre os casos de uso e os requisitos _____________ de um software. No entanto, não é verificada correspondência entre requisitos _____________ e casos de uso.

Assinale a alternativa que completa correta e sequencialmente as lacunas do texto.

Alternativas
Comentários
  • Letra B -  Um caso de uso representa um relato de uso de certa funcionalidade do sistema em questão. Logo, há uma relação entre os casos de uso e os requisitos funcionais, não sendo necessariamente, uma relação de um-para-um, já que um requisito funcional pode precisar de um ou mais casos de uso para atendê-lo.
  • Como assim?!! Aí não casa lacuna com resposta.
  • Existe uma correspondência, não necessáriamente de um para um, entre os casos de uso e os requisitos funcionais de um software.
    Normalmente 1 requisito descrito no documento de requisitos vira um caso de uso no diagrama de caso de uso, mas essa relação não é obrigatóriamente 1 para 1. Podemos ter mais de uma funcionalidade(Requisito) descrita pelo usuário sendo atendida no mesmo caso de uso.
    No entanto, não é verificada correspondência entre requisitos não funcionais e casos de uso.
    Requisitos não funcionais não são descritos em casos de usos.
  •  “O modelo de casos de uso representa os possíveis usos do sistema, e cada um desses usos pode ser associado a um ou mais requisitos identificados para o sistema.” (Princípios de Análise e Projeto de Sistemas com UML - Eduardo Bezerra, p. 56)

    Ou seja:  Casos de usos:Requisitos ==> 1:1 ou 1:N

  • b)não necessariamente ; um para um ; funcionais ; não-funcionais

    use cases sao usados para ilustrar os requisitos funcionais e têm relacionamento 1-1 porque demonstram como o ator se relaciona com um evento do sistema. requisitos nao-funcionais nao têm relação com use cases porque estes sao requisitos para suportar o uso dos requisitos funcionais, especificados pelo usuario


ID
362776
Banca
CESPE / CEBRASPE
Órgão
TRE-BA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir com relação à UML, uma linguagem gráfica
para visualização, especificação, construção e documentação de
artefatos de sistemas complexos de software.

Um cenário, também denominado instância de caso de uso, é uma sequência específica de ações e interações entre atores e o sistema em discussão. Assim, um caso de uso é uma coleção de cenários relacionados de sucesso e fracasso, que descrevem atores usando um sistema como meio para atingir um objetivo.

Alternativas
Comentários
  • O que me confundiu nessa questão foi afirmar que um caso de uso é uma coleção de "cenários". Pois bem, para que ninguém mais caia nessa pegadinha segue o porque a questão está correta:

    Todo caso de uso deve conter no mínimo um cenário principal. Ele pode conter também as variações desse cenários que são os cenários alternativos, definidos como Exceções. Cada exceção é também um cenário.
  • Pg 233 Guia do usuário UML
    "Existe um fator de expansão dos casos de uso para os cenários. Um sistema modestamente complexo poderá ter algumas dúvidas de casos de uso captando esse comportamento e cada caso de uso poderá ser exapandido em várias dúvidas de cenários. Para cada caso de uso, você encontrará cenários primários (que definem as sequencias essenciais) e cenários secundários (que definem as seuqencias alternativas)."

ID
362779
Banca
CESPE / CEBRASPE
Órgão
TRE-BA
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir com relação à UML, uma linguagem gráfica
para visualização, especificação, construção e documentação de
artefatos de sistemas complexos de software.

Casos de uso do tipo caixa-preta descrevem o funcionamento interno de um sistema, seus componentes ou projeto. Além do tipo de visibilidade caixa-preta versus caixa-branca, os casos de uso são escritos nos graus de formalidade extenso, formal e incompleto.

Alternativas
Comentários
  • "A descrição de cada caso de uso nem sempre é suficiente para localizar as classes de análise e seus objetos. Geralmente, o cliente acha desinteressantes as informações sobre o que ocorre no sistema, de forma que as descrições de casos de uso não precisam incluir esse tipo de informação. Em casos como esse, a descrição do caso de uso é lida como uma descrição em 'caixa preta', na qual detalhes internos sobre como o sistema responde às ações de um ator estão ausentes ou descritas muito resumidamente. Para encontrar os objetos que realizam o caso de uso, é preciso uma descrição em 'caixa branca' do que o sistema executa por uma perspectiva interna."

    fonte: http://www.wthreex.com/rup/process/activity/ac_ucana.htm
  • Além do erro na descrição do tipo de caso de uso caixa-preta a questão também está incorreta em relação aos graus de formalidade do caso de uso.

    Os graus de formalidade de um caso de uso são:

    1. Breve / Resumido
    2. Casual / Informal
    3. Completo
  • Tipos de Casos de Uso
    Caso de Uso Caixa Preta: detalhes internos sobre como o sistema responde às ações de um ator estão ausentes ou descritas muito resumidamente.
     
    Caso de Uso Caixa Branca: detalhes internos sobre como o sistema responde às ações de um ator estão presentes e descritas detalhadamente.
     
    Formatos dos Casos de Uso
    1. Breve / Resumido: Breve: resumo conciso de um parágrafo que, usualmente, trata do  cenário principal. 
    2. Casual / Informal: Casual: vários parágrafos informais são definidos para abordar vários  cenários.
    3. Completo: é o mais elaborado. Todos os passos e variações são
    descritos detalhadamente. Também incluem outras seções, como as
    pré-condições e pós-condições.

ID
369814
Banca
CESPE / CEBRASPE
Órgão
TCE-RN
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue o item subsequente, acerca do RUP (Rational Unified Process), versão 7.0, e da UML (Unified Modeling Language), versão 2.0.


Estruturar o modelo de caso de uso de negócios, que é o modelo das metas de negócio e as funções pretendidas, é uma tarefa da disciplina requisitos.

Alternativas

ID
370429
Banca
CESPE / CEBRASPE
Órgão
TCE-RN
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue o item subsequente, acerca do RUP (Rational Unified Process), versão 7.0, e da UML (Unified Modeling Language), versão 2.0.


Casos de usos são classificadores de comportamentos, os quais podem ser descritos por uma especificação de interações ou de atividades.

Alternativas

ID
370957
Banca
FCC
Órgão
TCE-GO
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Para evitar descrever o mesmo fluxo de eventos diversas vezes quando se tratar de um comportamento comum a vários casos de uso, é recomendado escrever esse comportamento em um único caso de uso e relacioná-lo aos demais por meio de um relacionamento de

Alternativas
Comentários
  • No relacionamento de inclusão, o caso de uso é incluído e passa a fazer parte de outro. As utilidades em decompor um caso de uso para ser utilizado através de inclusão são muitas, mas entre as principais esta a possibilidade de decompor casos de uso complexos em partes menores ou mesmo separar partes que serão utilizadas em vários casos de uso.
  • Na UML há três tipos de relacionamentos entre Casos de Uso

    Inclusão - Possibilita a subdivisão de casos de uso, bem como evita a descrição de uma mesma sequência de interações. Permite agrupar funcionalidades comuns em um ponto único de utilização.

    Generalização - Pode existir entre dois casos de uso ou entre dois atores. Permite que tanto um caso de uso como um ator herdem características de outro mais genérico. O caso de uso ou ator herdeiro pode especializar o comportamento do caso de uso ou ator base. Utiliza o mesmo símbolo da herança de classes. UML também permite utilizar o conceito de entidade abstrata ao Caso de Uso - descrito em itálico.

    Extensão - Não confundir com generalização. Utilizado para expressar diferentes sequências de interações entre casos de uso. Caminhos alternativos ou exceções. Cada uma das diferentes sequências representa um comportamento opcional, que só ocorre sob certas condições ou cuja realização depende da escolha do ator.
  • Ilustrando o comentário acima, eis um exemplo:
  • Segundo Martin Fowler no livro UML Essencial:
    " A associação de inclusão ocorre quando há uma parte  do comportamento que é semelhante em mais de uma caso de uso e 
    você não quer ficar  copiando a descrição deste comportamento."
  • Com explicação e ilustração:

    http://celodemelo.wordpress.com/2007/03/17/entendedo-o-diagrama-de-casos-de-uso/
  • Se você é programador, uma dica pra você não confundir extensão com inclusão, o segundo você lembra do #include <biblioteca.h> lá do C, C++, onde você inclui no seu programa funções da biblioteca ou funções escritas por você mesmo, não sendo necessário escrever a função toda vez que você precisar, bastando chama-la no teu código principal, mesma coisa acontece aqui, onde você faz uma inclusão sempre que tiver um mesmo comportamento para vários casos de uso.

    Fica a dica.

ID
389167
Banca
NCE-UFRJ
Órgão
UFRJ
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

Uma técnica usada para descrever e definir os requisitos funcionais de um sistema é conhecida como diagrama de caso de uso. Uma característica desta técnica é:

Alternativas
Comentários
  •  e)ator é um agente externo que interage com o sistema, mas sobre o qual não se tem controle.

    O ator pode ser o usuario ou outro sistema, mas so ha controle sobre o sistema desenvolvido, nao os existentes


ID
425035
Banca
UFBA
Órgão
UFBA
Ano
2009
Provas
Disciplina
Engenharia de Software
Assuntos

A Associação de Inclusão geralmente é usada quando existe um serviço, situação ou rotina comum a mais de um Caso de Uso.

Alternativas
Comentários
  • <<include>>: Obrigatórios
    <<extends>>: opcional
  • No contexto de casos de uso você pode ter uma inclusão no qual o caso incluído passa a fazer parte do outro include ou extensão extend onde é incorporado o comportamento de outro caso de uso.
  • A associação de Inclusão costuma ser utilizada quando existe um serviço, situação ou rotina comum a mais de um Caso de Uso. Quando isso ocorre, a documentação dessa rotina é colocada num Caso de Uso específico para que outros Casos de Uso utilizem-se desse serviço, evitando-se descrever uma mesma sequência de passos em vários Casos de Uso. Os relacionamentos de Inclusão indicam uma obrigatoriedade, ou seja, quando um determinado Caso de Uso possui um relacionamento de Inclusão com outro, a execução do primeiro obriga também a execução do segundo. Uma associação de Inclusão é representada por uma reta tracejada contendo uma seta em uma de suas extremidades que aponta para o Caso de Uso incluído no Caso de Uso posicionadado do outro lado da reta. As associações de Inclusão costumam apresentar também um Estereótipo contendo o texto include, entre dois sinais de menor e dois sinais de maior (include).



ID
425185
Banca
COPEVE-UFAL
Órgão
UFAL
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Em termos de documentação de software, o diagrama UML mais recomendado para documentar requisitos funcionais e as dependências entre eles é o

Alternativas
Comentários
  •  diagrama de casos de uso.

    Porém no RUP, os diagramas de CASO de USO e de Classes são utilizados na fase de concepção para a definição dos requisitos.

    O RUP é orientada a casos de uso e centrado em arquitetura.

    Já na fase de concepção é produzido uma arquitetura preliminar do sistema que possui diagramas de classe. A Elaboração vai definir uma arquitetura base sólida para a construção. Porém, da mesma forma que uma arquitetura preliminar é estabelecida ainda na concepção, uma implementação preliminar é realizada ainda na elaboração.

  • Os casos de Usos são uma técnica para captar os requisitos funcionais de um sistema. Eles servem para descrever as interações típicas entre os usuários de um sistema e proprio sistema..

    UML Essencial 3a Ediçao, Martin Fowler;

  • d)diagrama de casos de uso.

    diagramas use cases sao usados para ilustrar as funcionalidades do sistema e a relação entre eles e atores do ponto de vista externo


ID
441361
Banca
FCC
Órgão
TRE-AP
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

A questão abaixo refere-se à
UML 2.0.

Os casos de uso podem ser organizados pela especificação de relacionamentos de

Alternativas
Comentários
  • Diagramas de Caso de Uso:

    Exibe um conjunto de dados de uso e atores e seus relacionamentos. Caso de uso é um documento narrativo que descreve a sequência de eventos de um ator que usa o sistema para completar um processo.
    • Generalização: Pode existir entre dois casos de uso ou dois atores. Permite que se herde características de outro mais genérico.
       
    • Inclusão: uma das formas de interação, dado caso de uso pode incluir outro. Incluir é uma relação direta entre dois casos de usos, implicando que o comportamento do caso de uso incluído é inserido no comportamento do caso de uso inclusor. Esta relação indica uma obrigatoriedade do caso de uso incluir a funcionalidade do caso de uso incluído.
       
    • Extensão: um caso de uso pode estender outro. Esta relação indica o comportamento do caso de uso estendido pode ser ou não inserida no caso de uso extensor. Notas ou restrições podem ser associadas ao relacionamento para ilustrar as condições em que este comportamento será executado.
  • Relacionamentos na UML:

    1.Entre Casos de Uso: generalização, inclusão e extensão

    2. Entre Classes: associação simples, agregação, composição, dependência, generalização 

    3. Entre Interfaces: generalização
    4. Entre Atores: generalização
    5. Entre Classes e Interfaces: associação, realização e dependência

    Bons estudos!

ID
459277
Banca
FCC
Órgão
INFRAERO
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Para captar os requisitos funcionais de um sistema pode- se utilizar a UML. O diagrama mais adequado para essa finalidade é o diagrama de

Alternativas
Comentários
  • 1 - Diagrama de Caso de Uso: Diagramas de caso de uso são usados para modelar os requisitos funcionais dos sistemas. Atores e Use-Cases são classes. Um ator é conectado a um ou mais Use-Cases através de associações, e tanto atores quanto Use-Cases podem possuir relacionamentos de generalização que definem um comportamento comum de herança em superclasses especializadas em subclasses.

    pastedGraphic.pdf

  • E o medo de marcar a letra A, mesmo sabendo que é a mais certa! rsrsrsrs

  •  a)casos de uso.

    Casos de uso demonstra a interação usuario-sistema. Diagrama de classe mostra a relação dos objetos do sistema, incluindo os atores


ID
486655
Banca
FCC
Órgão
TCE-AL
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Uma seta pontilhada saindo de um caso de uso a ser adicionado para um caso de uso base indica um relacionamento de

Alternativas
Comentários
  • Questão muito ruim.
    Quando essa parte de "ser adicionado para um caso" é obrigatória, essa relação é de inclusão.
    Mas quando for um "adicionado" opcional, é extensão.
    A questão, na minha leitura, não deixou claro qual caso se refere.
    Essa deve ser a descrição de algum autor específico, mas eu não achei em lugar nenhum.
  • A questão é realmente muito mal escrita, mas esta correta.

    a seta saindo de um caso de uso e apontanto para o caso de uso base indica uma relação de extensão (opcionalidade na execução do caso extendido)

    Já a seta saindo do caso de uso base e apontando para um caso de uso indica uma relação de inclusão (obrigatoriedade na execução do caso de uso incluido)

    Normalmente inclui-se os estereótipos <<include>>, <<extends>> nestas setas.
  • A extensão representa funcionalidades adicionais que podem ser incluídas ao caso de uso base. Neste caso a seta sai do caso de uso extend para o caso de uso Base. O contrário ocorre na inclusão. Na extensão o caso de uso extend é dependente do base. Na inclusão o Base é dependente do included.

    fonte: UML in a Nutshell. Capítulo 7 seção 7.3
  • Segue abaixo um exemplo prático da diferença entre as setas de inclusão de extensão.
    Notem que inclusão a seta parte do caso de uso que está incluindo as funcionalidades. Já na extensão ela parte do caso de uso que está sendo estendido.
  • Questão mal elaborada.


ID
486658
Banca
FCC
Órgão
TCE-AL
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Os diagramas UML da categoria comportamental são os de

Alternativas
Comentários
  • Diagramas Estruturais: Classe, Objeto, Pacote, Componentes, Estrutura Composta e Implantação;
    Diagramas Comportamentais: Caso de uso, Atividades e Máquina de estado;
    Diagramas Comportamentais de Interação: Sequência, Comunicação, Interação Geral e Tempo.
    • a) classes, objetos e componentes.
    • b) casos de uso, sequência e classes.
    •  c) classes, atividades e sequência.
    •  d) casos de uso, atividades e máquinas de estados.
    •  e) objetos, estrutura composta e máquinas de estado.
  • casos de uso, atividades e máquinas de estados.


ID
495787
Banca
FUMARC
Órgão
BDMG
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

São elementos que podem estar presentes em um Diagrama de Casos de Uso da UML, EXCETO:

Alternativas
Comentários
  • Resolução:

    Em um caso de uso podemos ter:

    Um ator -  sim, este ator poder ser um usuario ou um sistema
    Um assunto -  sim, inclusive podemos ate colocar uma fronteira do assunto, que é um retangulo contendo as elipses pertencentes ao assunto
    relacionamento de generalização - sim pois  um ator pode se relacionar com outro via generalização

    Logo resta objeto.

ID
610318
Banca
CONSULPLAN
Órgão
INB
Ano
2006
Provas
Disciplina
Engenharia de Software
Assuntos

Quando da elaboração do Diagrama de User-case (na UML) para se identificar os atores que vão participar do modelo devemos fazer as seguintes perguntas, EXCETO:

Alternativas
Comentários
  • Atores são papéis de elementos externos ao sistema e 

    que interagem diretamente com o sistema.


    Quem paga o sistema não fará interações com o sistema necessariamente.
    Todas as outras perguntas indicam algum tipo de interação, exceto esta.
    Resposta "B"

ID
613192
Banca
CESPE / CEBRASPE
Órgão
BRB
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Com relação a UML 2, julgue os itens subsecutivos.

O diagrama de casos de uso é o mais específico e formal da UML, pois, além de servir de referência para a construção de outros diagramas, é utilizado nas fases de levantamento de sistemas e pode ser consultado durante todo o processo de modelagem.

Alternativas
Comentários
  • O diagramas de casos de uso podem servir de referência para a construção de outros diagramas e é utilizado nas fases de levantamento de requisitos e podem ser consultados durante todo o processo de modelagem. Entretanto, como no desenvolvimento de um software pode-se esperar sempre que os requisitos mudarão em algum momento, não faria sentido dizer que o diagram de casos de uso é "o mais específico". Ainda, como os diagramas de casos de uso podem ser utilizados juntamente com os clientes ou usuários durante as fases de levantamento de requisitos, e estes sempre terão muito pouco ou nenhum conhecimento de UML, não faria sentido se este tipo de diagrama fosse desenvolvido de maneira muito formal.
  • Diagrama de caso de uso é mais INformal!!
  • Normalmente em casos de uso evitam-se o uso de termos técnicos, preferindo a linguagem do utilizador final, são empregados tanto por quem desenvolve o software quanto pelos utilizadores do software.Ou seja, deve ser informal. Portanto questão ERRADA.
    abraço
    Marcelo
  • O diagrama de casos de uso é o mais específico e formal da UML, pois, além de servir de referência para a construção de outros diagramas, é utilizado nas fases de levantamento de sistemas e pode ser consultado durante todo o processo de modelagem.

     específico e formal: casos de uso são representações genéricas de interações no sistema, de maneira próxima à visão/compreensão do usuário. Há certa formalidade na sua confecção pelo uso da linguagem, mas certamente não é tão formal quanto, por exemplo, um diagrama de sequência ou de classes.
  • O diagrama de casos de uso é o mais específico e formal da UML, pois, além de servir de referência para a construção de outros diagramas, é utilizado nas fases de levantamento de sistemas e pode ser consultado durante todo o processo de modelagem.

    Eu marquei errado, pois creio eu, que o mais correto seria fases de levantamento de requisitos e não de sistema, nunca vi fases de levantamento de sistemas.




    " O diagrama de caso de uso tem por finalidade trazer uma notação ou linguagem simples,trazendo um entendimento do comportamento de um sistema por um agente externo. Este tipode diagrama tem como objetivo principal apresentar uma visão externa e geral dasfuncionalidades e serviços que o sistema deverá oferecer aos usuários. "

    Em relação a "específico e formal", apenas a palavra específico esta incorreto, como foi dito no comentário acima. Caso de Uso é formal, pois qualquer pessoa pode ter um entendimento de como o sistema funciona  sem precisar ter conhecimentos específicos da UML.
  • é o mais informal, montado em consultas com os clientes.
  • A questão está ERRADA, pois o diagrama de casos de uso é o mais abstrato (e não específico) e mais informal (e não formal) da UML. O restante da questão está corretíssimo!

    Segue texto completo, de onde provavelmente foram coletadas as informações para a criação da questão:

    "O diagrama de casos de uso procura, por meio de uma linguagem simples, possibilitar a compreensão do comportamento externo do sistema por qualquer pessoa, tentando apresentar o sistema através de uma perspectiva do usuário. É, dentre todos os diagramas da UML o mais abstrato e, portanto o mais flexível e informal. O diagrama de casos de uso costuma ser utilizado principalmente no início da modelagem do sistema, principalmente nas etapas de levantamento e análise de requisitos, embora venha a ser consultado e possivelmente modificado durante todo o processo de engenharia e sirva de base para a modelagem de outros diagramas."

    Fonte: http://www.passeidireto.com/arquivo/1480156/apostila-uml/9.

    Espero ter contribuído. Bons estudos!

  • Prezados,

    O diagrama de casos de uso é um dos menos específicos, pois mostra somente a iteração do ator com um caso de uso.

    Portanto a questão está errada


ID
616918
Banca
FCC
Órgão
MPE-SE
Ano
2010
Provas
Disciplina
Engenharia de Software
Assuntos

No contexto da UML, definir o sistema e entender de forma macro os seus objetivos, identificar os possíveis atores e as atividades que envolvem esses atores, estabelecer os relacionamentos entre os elementos, e checar o modelo com usuários e cliente, constituem um roteiro que pode ser seguido na elaboração do Diagrama de

Alternativas
Comentários
  • c-

    Modelo de casos de uso usa atores para representar usuarios e casos de uso sao as ações possiveis, sendo usado no levantamento de requisitos por ser de alto nivel e de facil compreensao


ID
641341
Banca
FCC
Órgão
TRT - 2ª REGIÃO (SP)
Ano
2008
Provas
Disciplina
Engenharia de Software
Assuntos

Em um diagrama de Caso de Uso são admitidos os relacionamentos

Alternativas
Comentários
  • Nos diagramas de Caso de Uso, temos os relacionamentos de Generalização (conhecidos como Herança), dependência (que pode ser do tipo extend ou include) e  a Associação.

    Portanto a resposta correta é a alternativa c) dependência, generalização e associação.

  • c-

    A associação no use case diagram é a relação que um obejto tem com outro (e.g.: aluno faz matricula). Dependencia sao as condicoes de guarda (extends) e herança e generalização permite especificar ou generalizar um agente


ID
659917
Banca
FCC
Órgão
TRE-CE
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Na UML 2.0, representam comportamentos de um sistema, os diagramas de

Alternativas
Comentários
  • Conforme UML 2.0, são exemplos de diagramas comportamentais,:

    diagramas de caso de uso
    diagrama de transição de dados
    diagrama de atividades

    e tambem os diagramas de interação são considerados como comportamentais, que são eles
    diagrama de interatividade
    diagrama de colaboração e comunicação
    diagrama de tempo.

  • O diagrama de casos de uso corresponde a uma visão externa do sistema e representa graficamente os atores, os casos de uso, e os relacionamentos entre estes elementos. Ele tem como objetivo ilustrar em um nível alto de abstração quais elementos externos interagem com que funcionalidades do sistema, ou seja, a finalidade de um diagrama de caso de uso é apresentar um tipo de diagrama de contexto que apresenta os elementos externos de um sistema e as maneiras segundo as quais eles as utilizam.
  • Diagramas Estruturais (estáticos):
    - Diagrama de Classe;
    - Diagrama de Objeto;
    - Diagrama de Pacote;
    - Diagrama de Componente;
    - Diagrama de Implantação;
    - Diagrama de Perfil;
    - Diagrama de Estrutura Composta

    Diagramas Comportamentais (dinâmicos)
    - Diagrama de Caso de Uso;
    - Diagrama de Atividade;
    - Diagrama de Máquina de Estado;

    Diagramas Comportamentais de Interação (dinâmicos)
    - Diagrama de Tempo
    - Diagrama de Sequência
    - Diagrama de Comunicação
    - Diagrama de Integração Geral



  • Estrutural: estática
    ?Diagrama de Classes
    ?Diagrama de Objetos
    ?Diagrama de Componentes
    ?Diagrama de Implantação
    ?Diagrama de Pacote
    ?Diagrama de Perfil
    ?Diagrama de Estrutura composta
    MENEMÔNICO: COCIPPE
    Comportamental: dinâmica
    ?Diagrama de Casos de Uso
    ?Diagrama de Seqüência
    ?Diagrama de Atividades
    ?Diagrama de Estados
    ?Diagrama de Colaboração ou comunicação
    ?Diagrama de Interação
    ?Diagrama de Tempo
    Alternativa: A
  • a) comunicação e de caso de uso. => Comportamentais

    b) sequência e de implantação. => Comportamentais e Estruturais

    c) componentes e de atividades => Estruturais e Comportamentais

    d) pacotes e de componentes. => Estruturais

    e) atividades e de implantação. => Comportamentais e Estruturais

  • a-

    diagramas estruturais- cocipe - classe, objeto, componente, implantação (deploy ou instalação, depende do autor), package, estrutura composta. O que nao for cocipe, é comportamento


ID
661756
Banca
FCC
Órgão
TRE-CE
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

A UML fornece um conjunto considerável de diagramas que ajudam a definir uma aplicação. Com relação a esses diagramas, analise:

I. Na atividade de análise de requisitos, pode ser utilizado para descrever como as pessoas interagem com o sistema.

II. Descreve os tipos de objeto presentes no sistema e os vários tipos de relacionamento existente entre eles. Também mostra as propriedades e operações de uma classe e as restrições que se aplicam à maneira como os objetos estão conectados.

III. Normalmente captura o comportamento de um único cenário e mostra vários exemplos de objetos e mensagens que são passadas entre esses objetos dentro de um caso de uso.

IV. São uma técnica para descrever a lógica de procedimentos, processo de negócio e fluxo de trabalho. Suportam comportamento paralelo, ao contrário dos fluxogramas.

Os itens I, II, III e IV descrevem, respectivamente, os diagramas de

Alternativas
Comentários
  • O Diagrama de Casos de Uso tem o objetivo de auxiliar a comunicação entre os analistas e o cliente. Ele descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário.  O cliente deve ver no diagrama de Casos de Uso as principais funcionalidades de seu sistema.
    O Diagrama de Classe representa a estrutura do sistema, recorrendo ao conceito de classe e suas relações. O modelo de classes resulta de um processo de abstracção onde são identificados os objectos relevantes do sistema em estudo.
    Um Diagrama de Seqüência descreve a maneira como os grupos de objetos colaboram em algum comportamento ao longo do tempo. Ele registra o comportamento de um único caso de uso e exibe os objetos e as mensagens passadas entre esses objetos no caso de uso.
    O Diagrama de Atividade representa os fluxos conduzidos por processamentos. É essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra.
  • e-

    Caso de Uso-é usado para levantamento de requidsitos, sendo um meio de comunicação em alto nivel para comunicar com stakeholders.

    Classe - mostra os relacionamentos e propriedades das classes utilizadas, assim como seus metodos e atrubutos.

    Sequência - mostra troca de mensagens entre objetos e sua duração (lifeline)

    Atividade. - fluxo de informações e decisoes.

  • Para quem achou que o item II era diagrama de objetos, nesse tipo de diagrama não aparece os métodos de uma classe, somente seus atributos.


ID
661795
Banca
FCC
Órgão
TRE-CE
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Em UML, os diagramas de Caso de Uso tem por objetivo

Alternativas
Comentários
  • a) representar os atributos e operações de uma classe ou objeto. (Diagrama de Classe)
    b) mostrar o fluxo de mensagens de uma atividade do sistema para outra. (Diagrama de Atividades)

    c) capturar funcionalidades e requerimentos do sistema. (Diagrama de Caso de Uso) - CERTA

    d) exibir uma interação entre um conjunto de objetos e seus relacionamentos. (Diagrama de Interação Geral)
    e) representar o estado ou situação em que um objeto pode se encontrar no decorrer da execução de processos de um sistema. (Diagrama de Máquina de estados)
  • d) Entendo que "exibir uma interação entre um conjunto de objetos e seus relacionamentos"  se refere ao DIAGRAMA DE COLABORAÇÃO (COMUNICAÇÃO na UML 2.0) e não ao de INTERAÇÃO GERAL como foi dito pelo amigo acima, conforme definição encontrada abaixo:
    O Diagrama de Colaboração exibe uma interação, consistindo de um conjunto de objetos e seus relacionamentos, incluindo as mensagens que podem ser trocadas entre eles(WIKIPEDIA)
  • pq diagrama de comunicação não pode ser a letra B?

     

  • c-

    diagrama de casos de uso sao para fase de levantamento de requisitos, sendo um meio de comunicar os requisitos funcionais do sistema pelso stakeholders


ID
662230
Banca
FCC
Órgão
INFRAERO
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Considere:
I. Generalização.
II. Exclusão.
III. Agregação.
IV. Inclusão.
 V. Composição.
VI. Extensão.

São relacionamentos aplicáveis aos casos de uso os que constam em

Alternativas
Comentários
  • I. Generalização.  (Diagrama de classe e casos de uso)
    II. Exclusão.  (Desconheço)
    III. Agregação.  (Diagrama de classe)
    IV. Inclusão. (Diagrama de casos de uso)
     V. Composição.  (Diagrama de classe)
    VI. Extensão.  (Diagrama de casos de uso)


ID
666052
Banca
FUNCAB
Órgão
MPE-RO
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

O Diagrama UML que procura identificar os atores (usuários, sistemas, hardware etc) que irão utilizar de alguma forma o software a ser desenvolvido é:

Alternativas

ID
669637
Banca
CONSULPLAN
Órgão
TSE
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

O desenvolvimento de um sistema de software complexo demanda que seus desenvolvedores tenham a possibilidade de examinar e estudar esse sistema a partir de diversas perspectivas. O uso da UML sugere que um sistema pode ser descrito por meio de cinco visões independentes do sistema. Duas dessas visões são detalhadas a seguir. Observe.

I. Descreve o sistema de um ponto de vista externo como um conjunto de interações entre o sistema e os agentes externos do sistema.

II. Enfatiza as características de concorrência e paralelismo, sincronização e desempenho do sistema.

As duas visões detalhadas são conhecidas, respectivamente, por visões de

Alternativas
Comentários
  • casos de uso e processo.
  • A UML apresenta 5 viões distintas, a que cada um dos diagramas propostos tem maior afinidade:

    Visão de Caso de Uso
    Esta visão descreve a funcionalidade que o sistema irá fornecer. É destinada aos usuários, analistas, projetistas, desenvolvedores, e equipes de testes. É de grande importância porque o seu conteúdo irá acionar o desenvolvimento de outras visões. Tenha sempre em mente que esta visão deverá ser tecnologicamente neutra e focalizar o “que” e não o “como“.
    Visão Lógica
    Esta visão irá descrever como será fornecida a funcionalidade, destinada principalmente aos projetistas e desenvolvedores.
    Esta visão descreve a estrutura estática (classes, objetos e relacionamentos) e as dinâmicas que ocorrem na aplicação.
    As tabelas, relacionamentos, classes , propriedades, métodos devem ser descritos nesta visão.
    Visão de Processo
    Nesta visão descrevemos o sistema em processo, esta divisão permite o uso eficiente de recursos, a manipulação síncrona e assíncrona dos eventos. É destinada aos desenvolvedores.
    Visão de Implementação
    A visão de implementação descreve os módulos e suas dependências. Estes módulos podem proporcionar a verificação cruzada para outros produtos garantindo que todos os requisitos estejam eventualmente atualizados. É destinada aos desenvolvedores.
    Visão de Implantação
    Esta visão descreve a disponibilidade física do sistema e recursos que o sistema ira utilizar. Descreve toda a estrutura onde o sistema é instalado. É destinada aos desenvolvedores, equipe de suporte, de testes e equipe de instalação.

    Fonte:http://techblog.desenvolvedores.net/2011/07/16/visoes-da-uml/
  • Visão de Caso de Uso: Descreve a funcionalidade do sistema.


    Visão Lógica: Descreve requisitos comportamentais e a decomposição do sistema em um conjunto de abstrações.​


    Visão de Implementação: Usada para descrever os módulos do sistema.


    Visão de Implantação: Descreve como a aplicação é instalada e como executa em uma rede de computadores.

     

    Visão de Processos: Descreve os processos do sistema e como eles se comunicam


ID
695251
Banca
FCC
Órgão
TRF - 2ª REGIÃO
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre os casos de uso do diagrama de Casos de Uso da UML, é correto afirmar:

Alternativas
Comentários
  • b) Os casos de uso devem se focar tanto no diagrama como no conteúdo textual descrevendo os casos de uso.
    d) Normalmente o levantamento de requisitos se dá durante o desenvolvimento, então as versões detalhadas dos casos de uso também se dão durante o desenvolvimento.
    e) Casos de uso não representam uma visão interna do sistema.
    A afirmação da a) está aqui. Apesar de não ser muito confiável a fonte...
    A letra c) eu não vi erros.
  • Texto copiado ipsis litteris do livro: UML Essencial, Martin Fowler 3 edição pg. 107.
  • c) A técnica de descrever as funcionalidades do sistema e de criar os casos de uso possuem o mesmo propósito e características, pois ambas descrevem requisitos.

    São técnicas diferentes e por isso têm caraterísticas diferentes, embora dividam o mesmo propósito.
  • A letra A) foi uma tradução mal feita do livro do Martin Fowler:
    a system use case is an interaction with the software, whereas a business
    use case discusses how a BUSINESS responds to a customer or an event.*

    Traduziram Business para "Aplicação".

    Fonte: http://br.groups.yahoo.com/group/timasters/message/154780

    Em relação a letra C, FUNCIONALIDADES são criadas para ATENDER os REQUISITOS. Os CASOS DE USO servem para IDENTIFICAR os REQUISITOS (análise). As funcionalidade descrevem o que o sistema terá como funcionalidade para atender ao requisito (projeto).

    Fonte: http://br.groups.yahoo.com/group/timasters/message/156725



  • Talvez foi retirado deste mestrado, visto que é EXATAMENTE como foi escrito pelo mestre:
    http://msoo.pbworks.com/f/Diagrama+de+Casos+de+Uso.pdf



ID
695560
Banca
FCC
Órgão
TRF - 2ª REGIÃO
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Atenção: As questões de números 43 a 46 referem-se à UML.

O Diagrama de Caso de Uso NÃO tem como objetivo:

Alternativas
Comentários
  • A letra a) está correta visto que a descrição dos casos de uso é objetivo do diagrama de casos de uso.
    letra b) acredito que o erro da letra b é dizer que é objetivo do sistema: especificar um conjunto de exigências de como o sistema deve fazer.
    o diagrama de casos de uso não diz como fazer e sim o que fazer, haja vista que não é voltado a uma implementação específica.
    letra c) está correta o diagrama de casos de uso tem como um de seus principais objetivos ser um elo de comunicação entre
    analistas/projetistas e usuários, facilitando o entendimento de como o sistema deverá funcionar
    letra d) está correta, os atores se relacionam com casos de uso, por exemplo: o ator cliente se relaciona com o caso de uso comprar produto
    letra e) está correta, temos por exemplo os relacionamentos de dependência entre casos de uso, como inclusão e extensão
  • Apenas complementando...

    Para representar interfaces externas fornecidas / requeridas é necessário utilizar um diagrama estrutural como:
    • Diagrama de Classes
    • Componentes
    • Pacotes
    • Estrutura composta

    Diagrama de caso de uso é um diagrama comportamental
  • Discordo do colega acima, tendo em vista o seguinte entendimento:

    O diagrama de casos de uso é um diagrama que mostra atores, casos de uso e seus relacionamentos.
    A especificação de caso de uso descreve os cenários do caso de uso.
    O modelo de casos de uso abrange os dois acima, juntamente com suas regras de negócio, mensagens e outros requisitos(não funcionais, quando cabíveis).

    Portanto acredito que a letra a) está errada pois não é atribuição do "Diagrama" associar uma narrativa de texto ao caso de uso.

  • Eu concordo com o Gunter Amorim.
    Eu tive a mesma conclusão. Diagrama != Narrativas textuais.
    Porém, a expressão "como" da alternativa B deixa aquela dúvida no ar.
  • tambem concordo com o colega. pois "narrativas de texto" é na especificação e não no diagrama.
  • Acredito que o que a questão quis dizer com a associação de narrativas textuais ao diagrama de caso de uso se deve ao fato do modelo de caso de uso abstrair textos, usando ícones, facilitando, assim, a interpretação da funcionalidade. Isso se dá porque com textos não há semântica. 
  • Também fiquei com essa dúvida, uma vez que no diagrama não há a descrição textual.
    Errei a questão, porque acabei associando às etapas da engenharia de requisitos, onde na etapa de elaboração seria construído somente o diagrama de caso de uso com os atores e casos de uso, a fim de validar com o cliente o conhecimento obtido durante a elicitação dos requisitos.
    Somente após a validação e negociação com o cliente é que de fato a especificação do caso de uso é feita, com a descrição textual de como o sistema deve se comportar.
    Concordo que a expressão como o sistema deve fazer na alternativa B, invalida a questão. Mas, na minha opinião, a letra A também não está correta.
  • Pessoal, lembrem: isso é FCC, ou seja,  vocês devem escolher entre a mais errada ou mais certa, infelizmente.
  • Posso estar errado mas caso de uso é algo mais alto nível, portando creio que mostra o que fazer e não como fazer.. por isso a letra b estaria errado a respeito do assunto e correto na questão.

  • O que a alternativa A quis dizer é simplesmente que você atribui à descrição do diagrama de caso de uso a narrativa de texto, como normalmente utilizá-se descrições curtas acabamos não atentando para isso, mas usamos descrições que remetam à narrativa do caso de uso, e foi isso que a alternativa expôs, corretamente.

  • a) Esta correta, segundo Martin Fowler os Casos de Uso servem para descrever as interações típicas entre os usuários de um sistema e o próprio sistema, fornecendo uma narrativa sobre como o sistema é utilizado. Dessa forma, as narrativas são associadas sim ao CSU.

    b) Está errada, segundo Martin Fowler, cada passo em um caso de uso é um elemento da interação entre um ator e o sistema. O passo deve mostrar a intenção do ator e não os mecanismos do que o ator faz. Consequentemente, você não descreve a interface com o usuário no caso de uso. Na verdade, a escrita do caso de uso normalmente precede o projeto da interface com o usuário, nas etapas posteriores do desenvolvimento.

    as demais alternativas acredito que seja claro a percepção de estarem corretas.


ID
704305
Banca
CESPE / CEBRASPE
Órgão
MPE-PI
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Supondo que um sistema tenha sido desenvolvido e documentado
de acordo com os conceitos da análise e do projeto orientado a
objetos e tenha sido utilizada, como ferramenta para modelagem, a
UML (Unified Modeling Language), versão 2.0, julgue os próximos
itens.

Considere um sistema de gerenciamento de documentos em que um diagrama da UML represente o caso de uso denominado “protocolar requerimento” e o caso de uso “protocolar retificação de requerimento”. Nessa situação, a representação mais adequada é a que consiste em inserir um ponto de extensão no segundo caso de uso, a partir do qual ele será estendido pelo comportamento do primeiro.

Alternativas
Comentários
  • A questão informa dois casos de uso:
    1. protocolar requerimento
    2. protocolar retificação de requerimento
    Pede ao candidato que subentenda que a retificação de um requerimento é algo não mandatório, que pode ocorrer ou não.
    A partir disso, podemos definir o relacionamento de extensão (opcional) entre os casos de uso, sendo que o caso 2 será uma extensão do caso 1, ou o primeiro será extendido pelo segundo.

    A questão está incorreta por ter invertido a direção do relacionamento.
  • UC01 protocolar requerimento
    UC02 protocolar retificação de requerimento

    Devemos entender que, uma retificação não é algo obrigatório. Ela pode ocorrer ou não. Neste caso será utilizado um ponto de EXTENSÃO (O INCLUDE é obrigatório)

    Para não haver erros com relação de como ler esta extensão, é so lermos no sentido da seta. Na Extensão, a seta vai em direção ao caso de uso principal.
    Logo, 'protocolar retificação de requerimento' irá em direção de 'protocolar requerimento'.

    Sendo assim, UC02 extende UC01, ou UC01 será extendido por UC02... Ou ainda UC02 será uma extensão de UC01.

  • Nessa situação, a representação mais adequada é a que consiste em inserir um ponto de extensão no segundo caso de uso, a partir do qual ele será estendido pelo comportamento do primeiro. (a partir do qual o primeiro será estendido pelo comportamento do segundo)
  •    O erro está em definir que o ponto de extensão estará no segundo caso de uso (protocolar retificação de requerimento). Estará, sim, no primeiro, pois ele é quem terá a marcação da ocorrência dos casos de uso tanto extendido quanto incluídos, justamente por nele haver a definição de quando aqueles ocorrerão.

       A citação sobre quem extende quem é complexa pois se falarmos que o UCA extende o UCB, da mesma forma que o UCA inclui o UCB, haja vista que é em UCA que estão localizadas as referências, e considerando a relação ativa é de A -> B e de A  -> C, a relação passiva tem que ser referência ao contrário. Assim, B é extendido por A e C é incluído por A. Daí dizer que B (protocolar retificação de requerimento) será extendido pelo comportamento de A (protocolar requerimento) não está incorreto

    Idioma complicado este nosso!
  • O relacionamento de extensão conecta um caso de uso de extensão a um caso de uso base. No exemplo dessa questão, o base seria o "Protocolar Requerimento" e o UC de extensão seria o "Protocolar Retificação de requerimento". Agora vamos pensar: Sempre que eu for protocolar um requerimento, tenho que protocolar uma retificação de requerimento? Não, só quando estiver retificando um requerimento.
    Isso significa que o UC de extensão será executado somente se uma determinada condição for atendida e, portanto, dizemos que o relacionamento é “não obrigatório”.
    Agora, eu acho que confunde muito é a leitura deles e, por isso, deixo uma dica:
    Exemplo:
    UC Protocolar retificação de requerimento -------->  UC Protocolar requerimento

    A leitura segue a ordem da seta, ou seja, o Protocolar Retificação de Requerimento extende o Protocolar Requerimento. A seta fica sempre do lado do caso de uso extendido, ou seja, o base.
  • A leitura do relacionamento segue o sentido da seta. 
    Por exemplo: “protocolar retificação de requerimento” estende “protocolar requerimento”. Ou seja, a seta sai de “protocolar retificação requerimento” , caso de uso "filho", e chega em “protocolar requerimento”, caso de uso "pai".
  • Galera,

    Acho que vocês deram uma viajada na maionese... rsrsrsrs

    Se a questão não fala em obrigatoriedade, não há que se levar isto em consideração ou não... se extensão ou inclusão... se é obrigatório ou não... Já pararam para pensar no caso de ESPECIALIZAÇÃO de UCs? Neste caso trata-se de ESPECIALIZAÇÃO, o que negativa a questão!

    GABARITO: ERRADO

  • na minha humilde opinião a questão está errada por amarrar o ponto de extensão no caso B. Acho que B seria uma opção de A, afinal de contas um requerimento poderá ser corrigido ou não. Ou seja, A extende B. O ponto de extensão será inserto no A indicando que B serpa extendido por A.

    veja:

    A---------------------->B (A extende B) ou seja, B será uma opção de A.

  • O segundo estende o primeiro, e não o contrário.


ID
748075
Banca
CESGRANRIO
Órgão
Petrobras
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Um restaurante contratou uma equipe para desenvolver um sistema de informação que auxilie nas tarefas diárias do negócio. Após um levantamento inicial, a equipe listou os seguintes requisitos:

• o caixa será responsável por encerrar uma conta e registrar o pagamento da mesma;

• caso o pagamento seja feito com cheque, será necessário que o sistema do restaurante se comunique com o sistema de consulta de cheques do Serviço de Proteção ao Lojista para obter informações sobre o cliente;

• caso o pagamento seja feito com cartão de crédito, será necessário que o sistema do restaurante se comunique com o sistema da administradora do cartão para obter autorização;

• apenas o gerente terá acesso à função de estorno do valor pago. Caso a despesa tenha sido paga com cartão, será necessário se comunicar com o sistema da administradora;

• tanto o sistema da administradora de cartões como o de consulta de cheques serão acessados via web service;

• o gerente também poderá encerrar uma conta.

Qual diagrama de caso de uso descreve adequadamente os requisitos acima?

Alternativas
Comentários
  • Segundo Jacobson, "Um caso de uso é uma descrição de um conjunto de sequências de ações, inclusive variantes, que um sistema executa para produzir um resultado observável por um ator (...) Um caso de uso captura o comportamneto pretendido do sistema (ou subsistema, classe ou interface) que você está desenvolvendo, sem ser preciso especificar como esse comportamento é implementado. Essa é uma separação importante, porque a análise de um sistema (que especifica o comportamento) deve, tanto quanto possível, não ser influenciada por questões referente a implementação (que especifica como esse comportamento pe executado)" (UML Guia do Usuário - 2ed) - Ou seja, dá pra perceber que "WebService" não é um caso de uso. WebService é um detalhe de implementação e não deveria aparecer no diagrama de caso de uso. Com isso eliminamos as alternativas "A", "D" e "E". - De cara já dá pra eliminar a letra "B", pois um caso de uso só se comunica com um ator através do relacionamento de associação. E na letra "B" tem dois relacionamentos de dependência ligando ator/caso de uso: (1) Entre "Encerrar conta" e "Sistema Consulta de Cheques" e (2) Entre "Estornar Valor Pago" e "Sistema Adm Cartão". Além disso, é o gerente que herda de caixa e não o contrário.
    Pergunta: "Todo gerente pode exercer as funções de um caixa? Sim. Todo caixa pode exercer as funções de um Gerente? Não. Pois as funções do gerente são mais específicas." Logo,  um Gerente "é um" caixa. Em contrapartida, um caixa "não é" (necessariamente) um gerente. Temos que Gerente (Subclasse) herda de Caixa (Superclasse).  Logo, Gabarito letra "C". 
  • Um caso de uso representa uma funcionalidade do sistema e "WebService" é apenas um passo da implementação de um dos casos de uso.
    Falado a grosso modo: faria todo sentido ter na tela da aplicação um botão/funcionalidade chamado "encerrar conta" ou "estornar valor pago", mas não faria o menor sentido, nesse contexto, ter um botão chamado "WebService".
    E na letra B contem um relacionamento inexistente entre o caso de uso "encerrar conta" e os atores.

    restando apenas como alternativa a letra C.
  • Acredito que webservice, por estar ligado à implementação, poderia ser limado logo de cara.
    A UML independe de tecnologia

ID
779215
Banca
CESPE / CEBRASPE
Órgão
TRE-RJ
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens seguintes, acerca das metodologias de análise,
projeto, desenvolvimento de sistemas e ferramentas de
desenvolvimento e apoio ao desenvolvimento de software.

Na metodologia orientada a objetos, o processo baseia-se em uma coleção de objetos. Nessa metodologia, se utiliza o UML, uma linguagem de modelagem que possui as seguintes visões: casos de uso, projeto, implementação, implantação e processo. A visão de implementação apresenta os aspectos estruturais e comportamentais do ambiente em que o sistema deverá ser implementado.

Alternativas
Comentários
  •  A UML é uma linguagem muito expressiva, abrangendo todas as visões necessárias ao desenvolvimento e implantação de sistemas:

    · Visão de caso de uso: focaliza os comportamentos de um sistema devendo ser transparente a todos os envolvidos: gerentes, analistas, programadores e usuários finais.

    · Visão de Projeto: focaliza a estrutura de um sistema através da definição de classes, colaborações e as interfaces do sistema.

    · Visão de Processo: focaliza as questões de desempenho e escalabilidade do sistema.

    · Visão de Implementação: focaliza os artefatos físicos (programas, bibliotecas, banco de dados) para a efetiva montagem do sistema.

    · Visão de Implantação: focaliza a topologia do hardware, liberação e instalação do sistema.

  • Modelo de Visão 4+1 da Arquitetura (UML)

    Visão de Implantação: abrange os nós que formam  a topologia de hardware em que o sistema é executado;
    Visão de Processo: mostra o fluxo de controle entre as várias partes, incluindo mecanismos de concorrência e de sincronização;
    Visão de Projeto (ou Lógica): abrange as classes, interfaces e colaborações que formam o vocabulário do problema e sua solução;
    Visão de Implementação: abrange os componentes e os artefatos utilizados para a montagem e fornecimento do sistema físico;
    Visão de Casos de uso: abrange os casos de uso que descrevem o comportamento do sistema conforme é visto pelos seus usuários finais, analistas e testadores;

    Pode-se notar que a Visão de Implementação abrange apenas aspectos estruturais e, não, comportamentais. Para saber mais: http://www.wthreex.com/rup/portugues/process/modguide/md_sad.htm
  • Visão 4 x 1 da Arquitetura:

    - Visão de caso de uso: Funcionalidade

    - Visão Logica (Projeto): Estrutura

    - Visão Processos: Escalabilidade, Performance e Vazão

    - Visão de Implementação: Gerenciamento de Software

    - Visão de Implantação: Topologia do Sistema, Instalação, Implantação.

ID
783598
Banca
CESPE / CEBRASPE
Órgão
MEC
Ano
2011
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue o  item  seguinte , relativo a processos de software e a sistemas orientados a objetos (OO).

O diagrama de caso de uso de negócio é um diagrama do RUP utilizado para mapear e descrever atores e funções envolvidos na modelagem de negócio.

Alternativas
Comentários
  • eu pensei que o diagrama de caso de uso fosse da UML... que é utilizado pelo RUP.

  • diagrama de caso de uso de negócio e diagrama de caso de uso são coisas diferentes

  • Questão louca essa!Mal elaborada!


ID
784780
Banca
ESAF
Órgão
CGU
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

No RUP (Rational Unified Process), casos de uso são

Alternativas
Comentários
  • - Um caso de uso define um conjunto de cenários;
    - Cada cenário descreve o comportamento do sistema em termos de sequências de ações;
    - Um caso de uso deve produzir um resultado de valor observável para um ator;

    Atores são as entidades que interagem com o sistema

    Fonte: Material do professor Fernando Pedrosa
  • O UP é o primeiro modelo de processo inteiramente adaptado ao uso com a UML e desenvolvido pelo mesmo grupo

    O caso de uso é um processo compreendido do ponto de vista do usuário. Para a UP, o conjunto de casos de uso deve definir e esgotar toda a funcionalidade possível do sistema. Wazlawick (2011) 
  • A resposta é a letra B, ou seja, de acordo com a questão, casos de uso são cenários de utilização do sistema pelos usuários. 

  • b)cenários de utilização do sistema por usuários.

    use cases são documentações do workflow que demonstram como os processos agregam valor ao negócio. No contexto do RUP, explicam para quê o software/sistema serve, ou como ele pode ajudar a empresa, o que se traduz como o sistema/software pode resolver algum problema do usuario

  • O RUP recomenda a utilização de Casos de Uso como método para a organização dos requisitos funcionais. Em vez de fazer uma lista de requisitos, organize-os na visão de como o usuário poderá utilizar o sistema.

    DECORE!  -->(Por isso se diz que o RUP é guiado por Casos de Uso.)


ID
814165
Banca
FAPERP
Órgão
TJ-PB
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Diagrama UML que por meio de uma linguagem simples possibilita a compreensão do comportamento externo do sistema (em termos de funcionalidades oferecidas por ele) por qualquer pessoa, tentando apresentar o sistema por intermédio de uma perspectiva do usuário.

Alternativas
Comentários
  • 1.  Diagrama de caso de Uso: É o diagrama mais geral e informal da UML, utilizado normalmente nas fases de levantamento e análise de requisitos do sistema, embora venha ser consultado durante todo o processo de modelagem e possa servir de base para outros diagramas. Apresenta uma linguagem simples e de fácil compreensão para que os usuários possam ter uma ideia geral de como o sistema irá se comportar. Procura identificar os atores(usuários, outros sistemas ou até mesmo algum hardware especial) que utilizarão de alguma forma o software, bem como os serviços, ou seja , as funcionalidades que o sistema disponibilizará aos atores, conhecidas nesse diagrama como casos de uso.



ID
814168
Banca
FAPERP
Órgão
TJ-PB
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Analise as afirmativas sobre diagramas de caso de uso.

I. O diagrama de casos de uso concentra-se em dois itens principais: atores e casos de uso.

II. Eventualmente, um ator pode representar algum hardware especial ou mesmo um software que interaja com o sistema.

III. Um caso de uso é considerado primário quando se refere a um processo que enfoca um requisito não-funcional do software.

Assinale a alternativa que contém todas e somente as afirmativas corretas,

Alternativas
Comentários
  • Casos de uso estão voltados para os requisitos funcionais do software que está sendo produzido, não levando em consideração requisitos não funcionais.

     

    Corresponde uma visão externa do sistema e representa graficamente os atores, caso de usos e relacionamentos entre esses elementos. Seu objetivo é ilustrar em um nível  alto de abstração quais elementos externos interagem com que funcionabilidades do sistema. Pode-se também representar a fronteira  do sistema que é representada por um retângulo, os atores são posicionados do lado de fora do retângulo, para enfatizar a divisão entre o interior e o exterior do sistema.

     

    Casos de uso primários são os que representam os objetivos dos autores, representa os processos da empresa que estão sendo automatizados. Já os secundários são aqueles que não trazem benefícios direto para os autores, mas que são necessários para que o sistema funcione adequadamente.

     

    Fonte: http://resumindoall.blogspot.com.br/2012/05/uml-modelagem-de-casos-de-uso-parte-2.html


ID
868735
Banca
CESPE / CEBRASPE
Órgão
TRE-MS
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Por meio de diagramas da UML, é possível capturar diferentes visões do sistema. Assinale a opção que apresenta o diagrama de um comportamento dinâmico do sistema.

Alternativas
Comentários
  • Diagramas de aspecto estático: Classes, Objetos, Implantação, Pacotes e Estrutura Composta.
    Diagramas de aspecto dinâmico: Atividades, Interação, Máquina de Estados, Casos de Uso, Sequência, Comunicação, Temporal e Visão Geral.

    Bons estudos.
  • Diagramas de casos de uso mostram os relacionamentos/interações entre os atores e os casos de uso (Daí a dinamicidade)
     
    Já os outros tipos de diagramas, citados nas demais alternativas só apresentam características estáticas:
    Diagrama de Objetos: representa a instância (objeto) de uma classe contendo somente atributos;
    Diagrama de Componentes: representa os "componentes de software" do projeto (O Diagrama de Componentes está muito ligado à linguagem de programação);
    Diagrama de Implantação: representa a parte de hardware envolvida no projeto;
    Diagrama de Classe: representa, literalmente, uma classe com todos seus métodos, atributos etc.
  • Estrutural: COCIMPEC

    Classe

    Objeto

    Componente

    Implantação

    Pacote e 

    Estrutura Composta

    Comportamental: Os outros que sobraram.

    Sem falar no novo, o diagrama de perfil. Esse é estrutural.



ID
943210
Banca
CESPE / CEBRASPE
Órgão
INPI
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Acerca de análise e projeto de sistemas, julgue os próximos itens.

O diagrama de casos de uso é utilizado para mostrar o fluxo de trabalho, detalhando as decisões do caminho tomado durante a execução das tarefas.

Alternativas
Comentários
  • A descrição apresentada está relacionada ao diagrama de atividade.
  • GABARITO: ERRADO

    Diagrama de Sequência É usado para mostrar uma seqüência de atividades. Mostra o fluxo de trabalho (workflow) a partir de um ponto inicial até um ponto final, detalhando as decisões do caminho tomado durante a execução das tarefas. Este diagrama possui várias aplicações, desde a definição do fluxo básico de um programa até a definição de um processo com as suas tomadas de decisões e ações. Diagramas de Sequência mostram a troca de mensagens (isto é chamada de método) entre diversos Objetos, numa situação específica e delimitada no tempo. Objetos são instâncias de classes. Diagramas de Sequência colocam ênfase especial na ordem e nos momentos nos quais mensagens para os objetos são enviadas. Em Diagramas de Sequência objetos são representados através de linhas verticais tracejadas, com o nome do Objeto no topo. O eixo do tempo é também vertical, aumentando para baixo, de modo que as mensagens são enviadas de um Objeto para outro na forma de setas com a operação e os nomes dos parâmetros. 

    Diagrama de Sequência
    Fonte: http://www.diegomacedo.com.br/introducao-a-uml-e-seus-diagramas/
    Bons Estudos!!!!
  • teimo em errar essa questão
    de um certa forma associo fluxo de trabalho com cenário.
  • Não se fala em detalhamento das decisões em diagrama de casos de usos. Nesses se tem relacionamentos entre atores, casos de usos. Além da apresentação das funcionalidades dos software em nível de usuário.

    Um diagrama de atividade exibe a estrutura de um processo ou outra computação, como o fluxo de controle e os dados de cada etapa de uma computação.
    Abrange a visão dinâmica do sistema e é importante principalmente para a modelagem da função de um sistema e dá ênfase ao fluxo de controle entre objetos.

    Já no diagrama de sequência tem-se uma ênfase na abordagem temporal.
  • O diagrama de casos de uso correspondeao diagrama que modela a dinâmica do sistema (em relação aosquatro pontos de vista) no mais alto nível de abstração propiciadopor UML. Relaciona as funcionalidades do sistema modelado, atravésdo elemento caso de uso, e os elementos externos que interagem como sistema modelado, através do elemento sintático ator. O diagramaé composto por esses elementos e relações envolvendo pares desseselementos.

    Fonte: UML2 em Modelagem Orientada a Objetos - Ricardo Pereira e Silva Pg91.

  • Esse é o diagrama de atividades.


ID
966127
Banca
Marinha
Órgão
Quadro Técnico
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Segundo Pressman (2011), cada elemento do modelo de requisi­tos apresenta o problema segundo um ponto de vista. Os elementos baseados em cenários representam como o usuário interage com o sistema e a seqüência específica de atividades que ocorre à medida em que o software é utilizado.
O trecho acima refere-se a que elemento do modelo de requisitos?

Alternativas
Comentários
  • Caso de Uso


ID
966229
Banca
Marinha
Órgão
Quadro Técnico
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Os diagramas comportamentais da UML são utilizados para visualizar, especificar, construir e documentar os aspectos dinâmicos de um sistema. Qual opção apresenta três diagramas comportamentais?

Alternativas
Comentários
  • seqência é um diagrama de interação, comportamentais seriam casos de uso, máquina de estados e atividades

  • Diagramas estruturais ou estáticos:

     

    - Classes

    - Objetos

    - Componentes

    - Perfil

    - Estruturas Compostas

    - Implantação

    - Pacotes

     

    Diagrama Dinâmicos ou Comportamentais são:

     

    - caso de uso

    - atividade

    - estado

    - interação (sequencia, comunicação, tempo e visão geral da interação)


ID
977410
Banca
CETRO
Órgão
ANVISA
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Em relação à UML (Unified Modeling Language), marque V para verdadeiro ou F para falso e,em seguida,assinale a alternativa que apresenta a sequência correta.

( ) O primeiro passo ao escrever um caso de uso é definir o conjunto de atores que estarão envolvidos na história; alguns atores representam papéis que as pessoas desempenham quando o sistema está em operação.
( ) Um ator e um usuário final são necessariamente a mesma coisa.
( ) O caso de uso básico representa uma história de alto nível que descreve a interação entre o ator e o sistema.
( ) Um caso de uso conta uma história estilizada sobre como um usuário final interage com o sistema sob um conjunto específico de circunstâncias.

Alternativas
Comentários
  • Um caso de uso conta uma história estilizada sobre como um usuário final interage com o sistema sob um conjunto específico de circunstâncias.


    Não entendi..

  • "Um caso de uso conta uma história estilizada sobre como um usuário final interage com o sistema sob um conjunto específico de circunstâncias."

    Tem que ser necessariamente um usuário final? Não pode ser outro sistema?


  • a parte do "conjunto específico de circunstâncias" me deixou na dúvida.

  • A alternativa E parece que foi mal formulada, visto que atores interagem com o sistema e não somente usuário final. O conceito de atores é mais amplo do que usuário final, ele pode ser outros sistemas. 

    A questão estaria melhor formulada se não fosse tão delimitadora. Poderia incluir um "pode contar uma história... sobre um usuário final..."

  • A questão se contradiz. No item 2 quando ela diz que é falso deixa claro que um ator não necessariamente é um usuário final. Mas no item 4 ele diz que um caso de uso conta uma história sobre um usuário final, o que dá a entender que usuário final e atores são a mesma coisa. Além disso um caso de uso pode ser abstrato segundo a uml, onde sequer há a participação de um ator, caso no qual obviamente um caso de uso não poder ser sobre como um ator se comporta, pois ele sequer participa. 

    A questão deveria ser anulada, ou o gabarito deveria mudar. 

  • Ricardo Saboia, pode sim ser um sistema.

  • Questão muito mal formulada.

    Criam questões assim para atrapalhar um bom entendimento...


  • Agora entendo o porquê desta prova ter sido anulada...

  • Questão fraca. Concordo com o Bruno Renan.

  • Questão mal formulada, pff.

  • "Um caso de uso conta uma história estilizada ...."Em relação a UML está errado, agora em relação, por exemplo, ao RUP está corrreto. Na UML é só uma Elipse com o nome do caso de uso. Tudo visual!!!! Não tem nada textual. Como a questão falou com relação à UML isso está incorreto. Dificil desse jeito!!!

  •  "Um caso de uso conta uma história estilizada sobre como um usuário final interage com o sistema sob um conjunto específico de circunstâncias."

    Acho que o pior não é nem a "história estilizada" (alguém sabe dizer a definição correta disso?), mas falar que um caso de uso conta COMO (pois seria O QUE o usuário pode fazer num sistema) e dizer que isso é correto é o fim.

    Questão horrível!


ID
977701
Banca
FUNRIO
Órgão
MPOG
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Geralmente, um caso de uso tem diversas maneiras de ser realizado. Qual é a denominação dada à descrição de uma das maneiras pelas quais o caso de uso pode ser realizado, também chamado de instância de um caso de uso?

Alternativas
Comentários
  • Resposta Baseada no Livro Princípios  de Análise e Projeto de Sistemas com UML. 2 .
    Cenário: é a descrição de uma das maneira pelas quais um caso de uso pode ser realizado . Relacionado a Forma como ele pode ser realizado. 
     - Um cenário é uma execução específica do caso de uso; Pode ser visto como uma instância de um Caso de Uso
  • Eu pensei como em orientação a objetos. Tem o caso de uso que seria uma classe e a instância desta classe só poderia ser um acontecimento, uma "cena", um "episódio" tipo "comprar chiclete", uma cena vc comra chiclete feliz, na outra triste, na outra sem dinheiro, na outra compra todos os chicletes e cada uma vez desta pode ser considerada um cenário.

    Ajudei alguém? Então dá um OK!


ID
1042612
Banca
CESPE / CEBRASPE
Órgão
MPU
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

De acordo com os conceitos, modelos e diagramas da UML (unified modeling language), julgue os próximos itens.

Diagrama de caso de uso, diagrama de sequência, diagrama de comunicação, diagrama de atividades e diagrama de classes são diagramas comportamentais da UML.

Alternativas
Comentários
  • Diagramas da UML 2.0 editar
    Diagramas Estruturais
    Diagramas Comportamentais

    fonte: http://pt.wikipedia.org/wiki/UML
  • Para nunca mais esquecer.
    Diagramas Comportamentais (Dinâmico)
    CAUMATIN = Caso de Uso, Máquina de Estados, Atividades e Interação.

    Diagramas Estrutural (Estático)
    EI PAPER CLOC = Estrutura Composta, Implantação, Pacotes, Perfis, Classes, Objetos e Componentes.
  • Erro da questão é que o diagrama de classe  não é comportamental e sim estrutural.

  • Para nunca mais esquecer.

    Diagramas Comportamentais (Dinâmico)CAUMATIN = Caso de Uso, Máquina de Estados, Atividades e Interação.
    Diagramas Estrutural (Estático)EI PAPER CLOC = Estrutura Composta, Implantação, Pacotes, Perfis, Classes, Objetos e Componentes.Posso ajudar?

    Já o fiz heheh

    Caso de atividade de interação com a máquina?-> Caso de Uso, Máquina de Estados, Atividades e Interação. Comportamentais.

     

  • Pode-se memorizar da seguinte maneira:

    1) ESTRUTURAIS - ESTÁTICOS (PPECICO)

    P perfil

    P pacotes

    E estrutura composta

    C classes

    I implantação

    C componentes

    O objetos

    2) COMPORTAMENTAIS - DINÂMICOS (MACI->TICS)

    M máquina de estado

    A atividades

    C caso de uso

    INTERAÇÃO -> T tempo

                               I interação geral

                              C comunicação

                              S sequência

    * Os 4 últimos são comportamentais e de interação

  • e-

    cocipe - classe, objeto, componentes, implantação, package, estrutura composta. Lembra essa palavra e o que nao for isso, sera comportamento


ID
1044130
Banca
CETRO
Órgão
ANVISA
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Assinale a alternativa que apresenta o principal diagrama da UML na análise de requisito.

Alternativas
Comentários
  • O diagrama de casos de uso é uma das principais ferramenta para o levantamento de requisitos funcionais de um sistema. 
  • e-

    O diagrama de C.U. é para agrupar as funcionalidades mais importantes. Sobre tais funcionalidades criamos o Diagrama de Classes, que será a estrutura de nossa aplicação.


ID
1045612
Banca
CESPE / CEBRASPE
Órgão
SERPRO
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens seguintes, acerca de prototipação, especificação e técnicas de validação de requisitos.

As notações gráficas, como o diagrama de casos de uso da UML, são úteis para a especificação dos requisitos funcionais e não funcionais de um sistema de informação

Alternativas
Comentários
  • Errada, pois o diagrama de caso de uso é utilizado para especificar os requisitos funcionais. A finalidade desse diagrama é descrever a visão externa do sistema e suas interações com o mundo exterior, representando uma visão de alto nível da "funcionalidade" do sistema mediante uma requisição do usuário. 

  • Quem quiser saber quais são os requisitos não funcionais, visite: http://www.dsc.ufcg.edu.br/~jacques/cursos/proj/gerenciadesenv/naofuncionais.htm

     

    @Ana Alves (obrigado pelo comentário), acredito que a palavra que mais combina com casos de uso é Ator. Usuário seria um papel.

  • errado - use case diagrams é a representação direta da interação usuário-sistema. Porque nfr( requisitos nao-funcionais) descreve comportamento do sistema e features que sustentam requisitos funcionais, não faz parte deste diagrama

  • Os casos de uso são uma técnica de descoberta de requisitos introduzida inicialmente no método Objectory (JACOBSON et al., 1993).

     

    Sommerville; Casos de uso; pag 74.

  • o diagrama de implantação da UML não pode ser usado para mostrar requisitos não funcionais?


ID
1049467
Banca
FCC
Órgão
AL-RN
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

A especificação UML 2.5 define dois tipos principais de diagramas UML: structure diagrams e behavior diagrams. Behavior diagrams mostram o comportamento dinâmico dos objetos em um sistema, que pode ser descrito como uma série de mudanças no sistema no decorrer do tempo. São exemplos de Behavior diagrams os diagramas de

Alternativas
Comentários
  • http://pt.wikipedia.org/wiki/Ficheiro:UML_diagrams_overview.svg
    Sequência, caso de uso e Atividade.  Letra D


  • O diagrama de cada item que não seja um diagrama comportamental está sublinhado, sendo um diagrama que torna a acertiva errada.

    a) Comunicação, Fluxo de Informação e Objeto.

    b) Comunicação, Deployment e Máquina de Estado.

    c) Temporização, Componente e Atividade.

    d) Sequência, Caso de Uso e Atividade. Correto, todos são diagramas comportamentais.
    e) Classe, Atividade e Sequência. 

  • Diagramas estruturais:

      Diagrama de classe

      Diagrama de objetos

      Diagrama de componentes

      Diagrama de instalação

      Diagrama de pacotes

      Diagrama de estrutura composta


    Diagramas comportamentais:

      Diagrama de casos de uso

      Diagrama de atividades

      Diagrama de transição

      Diagrama de interação

            Diagrama de sequencia

            Diagrama de interação

            Diagrama de comunicação

            Diagrama de tempo

  • Behaviour diagrams são os que modelam os componentes dinamicos de um sistema. Behaviour Diagrams sao: atividade, sequencia, use case & diagramas de estado.


ID
1049518
Banca
FCC
Órgão
AL-RN
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Os diagramas UML podem ser divididos em dois grandes grupos, Diagramas Estruturais e Diagramas Comportamentais. Analise a lista de diagramas abaixo:

I. Componentes.
II. Comunicação.
III. Implantação.
IV. Caso de Uso.
V. Classes.
VI. Estados.

São Diagramas Comportamentais APENAS os descritos em

Alternativas
Comentários
  • I. Componentes.  => Diagrama Estrutural
    II. Comunicação. => Diagrama Comportamental
    III. Implantação. => Diagrama Estrutural
    IV. Caso de Uso. => Diagrama Comportamental
    V. Classes.  => Diagrama Estrutural
    VI. Estados. => Diagrama Comportamental

    Diagrama detalhado > http://pt.wikipedia.org/wiki/Ficheiro:UML_diagrams_overview.svg

    Resposta Letra E. 

  • Essa você lembrando que o de classes é estrutural matava a questão, pois a única alternativa que não possuí esse diagrama é a letra E. 

  • Diagramas Estruturais: priorizam a descrição estática de estruturas de um sistema, como classes, atributos e operações destas últimas, além de prováveis relacionamentos entre tais construções.

    Diagrama de classes

    Diagrama de objetos

    Diagrama de componentes

    Diagrama de instalação

    Diagrama de pacotes

    Diagrama de estrutura Composta

    Diagrama de Perfil


    Diagramas Comportamentais: detalha o funcionamento (comportamento) de partes de um sistema ou processos de negócio relacionados a tal aplicação.

    Diagrama de Caso de Uso

    Diagrama de Estados

    Diagrama de atividade


    Diagramas de Interação: considerados um subgrupo dos diagramas comportamentais, sendo normalmente utilizados na representação de interações entre objetos de uma aplicação.

    Diagrama de sequência

    Diagrama de Interatividade

    Diagrama de colaboração ou comunicação

    Diagrama de tempo

  • Pessoal, tem um macete/dica que li em um blog de outro concurseiro e deu certo para mim, então vou compartilhar e espero que ajude na memorização (infelismente não achei/anotei o blog do autor para citar como referencia). 

    - Você pode gravar os diagramas comportamentais pela frase: "o ativista internacional comunicou o tempo do casório ao maquinista sequelado". Os demais diagramas serão estruturais !

    Para quem ficar em dúvida:

    ativista = diag. atividade

    internacional = diag. interação geral

    comunicou = diag. de comunicação

    tempo = diag. de tempo

    casório = diag. caso de uso

    maquinista = diag. máquina de estados

    sequelado = diag. de sequência.

  • e-

    cocipe (classe, objeto, componente,implantação, package, estrutura composta) o que nao for, sera comportamental.


ID
1096012
Banca
CAIP-IMES
Órgão
Câmara Municipal de São Caetano do Sul - SP
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

A UML (Unified Modeling Language) é uma linguagem padrão para descrever/documentar projetos de software. Nesta linguagem, os diagramas de __________________ ajudam a determinar a funcionalidade e as características do software sob o ponto de vista do usuário.

Alternativas
Comentários
  • c-

    Diagramas de caso de uso sao flexiveis e abstratos, usados no inicio da modelagem por serem alto nivel para levantamento e analise de requisitos. Usa atores (usuarios) e casos de uso (servicos, funcoes etc). Um caso de uso pode ter varios atores e 1 ator pode fazer muitos casos uso. 


ID
1100584
Banca
MS CONCURSOS
Órgão
CRM-MS
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Representa o conjunto de comportamentos de alto nível que o sistema deve executar para um determinado ator. É o diagrama mais simples, e não há necessidade de grandes detalhamentos. Trata-se do

Alternativas
Comentários
  • Diagrama de casos de uso demonstra as interacoes entre os atores, fornecendo uma visao global do comportamento funcional do sistema.


ID
1101373
Banca
UNIRIO
Órgão
UNIRIO
Ano
2012
Provas
Disciplina
Engenharia de Software
Assuntos

Em relação ao uso de casos de uso para desenvolvimento de sistemas, é CORRETO afirmar que casos de uso .

Alternativas
Comentários
  • Um 'Caso de Uso' é uma técnica para capturar os requisitos funcionais de um novo sistema ou manutenção de software. Cada caso de uso provê um ou mais cenários que indicam como o sistema deve interagir com o usuário final ou outro sistema para atingir um objetivo de negócio específico. Casos de uso tipicamente evitam o jargão técnico, preferindo ao invés disto a linguagem do usuário final ou de um expert no domínio. Os casos de uso são frequentemente de co-autoria dos desenvolvedores de software e usuários.

    Casos de usos são ferramentas enganosamente simples para descrever o comportamento de um software. Um caso de uso deve conter uma descrição textual de todos os passos que o usuário futuramente poderá vir a utilizar no software através de sua interface. Casos de uso não descrevem nenhum comportamento interno do software, nem fazem explanações de como o software será implementado. Eles simplesmente mostram os passos que o usuário deve seguir para usar o software no seu trabalho. Todas as formas com que o usuário irá interagir com o software deverão ser descritas por este meio.


ID
1115314
Banca
CESPE / CEBRASPE
Órgão
SUFRAMA
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir acerca de UML.

Para criar o diagrama de sequência, utilizam-se os diagramas de caso de uso de mesmo nome e o diagrama de classes a fim de se determinar quais objetos estarão envolvidos no processo.

Alternativas
Comentários
  • Diagramas de caso de uso de mesmo nome? #boiei

  • Essa expressão "de mesmo nome" ficou nojenta mesmo! Vai entender o que eles queriam dizer com isso!!


    Mas enfim, no geral, faz sentido usar o digrama de classes e casos de uso para criação do de sequência

  • É que para usar um diagrama de sequência é preciso ter o diagramas de caso de uso. para conseguir construir um de sequencia. o mesmo nome quer dizer caso de uso que são vários inter-relacionados. Eles tem uma certa dependencia.

  • Se esse "utilizam-se" der ideia de obrigatoriedade, a questão é falsa !!! Diagramas UML são modelos, são simplificações. Não é necessário, obrigatoriamente, gerar diagramas anteriores para depois gerar outros diagramas. Tudo depende do nível de detalhe que se quer adicionar aos modelos. QUESTÃO NOJENTA !!!

  • Para clarificar o entendimento, deixo um trecho retirado do livro UML Destilled:  "Typically, a sequence diagram captures the behavior of a single scenario. The diagram shows a number of example objects and the messages that are passed between these objects WITHIN THE USE CASE." 

    Em tradução livre: "Tipicamente, um diagrama de sequência captura o comportamento de um único cenário. O diagrama mostra um número de objetos de exemplos e as mensagens que são passadas entre esses objetos DENTRO DE UM CASO DE USO." Para mim, essa questão é o ponto-chave sobre o diagrama de sequência.
  • c-

    Diagrama de sequencia: detalham sequencia do processo, com atores e objetos e troca de msg. E` feito a partir do diagrama de casos de uso e permite identificar os metodos e atributos de cada classe.

  • Só lembrando que  cada caso de uso vai virar um diagrama de sequência.

  • O diagrama de sequencia baseia-se no diagrama de casos de uso, havendo normalmente um diagrama de sequência para cada casso de uso declarado.

    Obviamente, o diagrama de sequência depende também do diagrama de classes, uma vez que as classe dos objetos utilizados no diagrama de sequência estão descritas nele.

    Gilleanes T. A. Guedes. UML 2 - Uma abordagem prática 3 ed. pag. 215


ID
1115458
Banca
CESPE / CEBRASPE
Órgão
SUFRAMA
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Julgue os itens a seguir no que se refere à engenharia de requisitos.

Em uma especificação de requisitos, deve-se evitar utilizar, com outro sentido, termo já definido em determinado caso de uso.

Alternativas
Comentários
  • Correto.

    O uso de um termo já definido em outro caso de uso com outro sentido poderia causar ambiguidade na especificação. Sabendo que a especificação deve ter as características de completude e clareza, deve ser tomada medidas para reduzir ao máximo a ambiguidade, contribuindo, assim, para a clareza da especificação.

    O termo poderia constar também em um glossário. Seria complicado especificar no glossário que no caso de uso A o termo X significa uma coisa e no caso de uso Y significa outra. 


    Embasamento teórico:

    Para realização da Validação de Requisitos, temos que a validação de requisitos dedica-se a mostrar que os requisitos realmente definem o sistema que o usuário deseja. A validação de requisitos está relacionada à descoberta de problemas com os requisitos.
    Summerville, diz que durante o processo de validação de requisitos, devem ser realizadas verificações nos requisitos do documento de requisitos. Essa verificações inclue a Verificação de consistência que define que os requisitos em um documento não devem ser CONFLITANTES. Isso significa que não devem existir restrições ou DESCRIÇÕES CONTRADITÓRIAS para a mesma função do sistema.
    Engenharia de Software, Summerville, 8ed, pg 106

  • Apenas mais uma fonte para ratificar o comentário do colega Clark:

    Guia Babok, versão 2.0, pgs 120 e 121.

    6) Análise de requisitos
    6.5) Verificar requisitos
    6.5.1) Propósito: A verificação de requisitos garante que as especificações e modelos de requisitos atendam ao padrão necessário de qualidade para permitir que sejam usados de forma efetiva para guiar o trabalho futuro.
    6.5.4) Elementos, características da Qualidade dos Requisitos:

    Coesão, Completude, Consistência, Correção, Viabilidade, Ajustabilidade/adaptação, Testabilidade..


    Não Ambiguidade: Requisitos individuais nunca podem ser pouco claros. Um requisito não pode permitir a formação de múltiplas e divergentes interpretações válidas.

    A questão "Em uma especificação de requisitos, deve-se evitar utilizar, com outro sentido, termo já definido em determinado caso de uso." afirma o dever de utilizar mesmo termo com múltiplos sentidos, o que é claramente vedado, pois vai de encontro com a característica da Não Ambiguidade.


ID
1117489
Banca
CESGRANRIO
Órgão
FINEP
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

O sistema de informação responsável pelo registro civil de um estado brasileiro possui uma função para registrar as informações necessárias sobre um cidadão que precisa obter uma carteira de identidade. Através dessa função, são registrados no sistema informações tais como: o nome, a data de nascimento, os nomes dos pais e o local de nascimento desse cidadão.
No ato do cadastramento descrito acima, o funcionário que opera o sistema pergunta ao cidadão se ele deseja registrar que ele é doador de órgãos para transplante. Caso a resposta seja afirmativa, o funcionário seleciona essa opção no formulário de registro, o que fará com que o sistema abra um formulário para que o funcionário registre informações fornecidas pelo cidadão, tais como: tipo sanguíneo, doenças preexistentes, etc.
Baseado apenas no que foi descrito acima, qual diagrama de casos de uso descreve adequadamente as funcionalidades disponibilizadas pelo sistema de informação em questão?

Alternativas
Comentários
  • O formulário de doador "carrega" no formulário original.

  • O Funcionário é o ator do Caso de Uso "Registra Cidadão" pois é o "que o opera o sistema" de registro. A ação de Registrar o doador ocorre "caso a resposta seja afirmativa", ou seja: é opcional. Por isso utiliza-se o estereótipo extends.

  • Entre casos de uso

    Include

    Um relacionamento include de um caso de uso A para um caso de usoB indica que B é essencial para o comportamento de A. Pode ser dito também que B is_part_of A.

    Extend

    Um relacionamento extend de um caso de uso B para um caso de usoA indica que o caso de uso B pode ser acrescentado para descrever o comportamento de A (não é essencial). A extensão é inserida em um ponto de extensão do caso de uso A.

    Ponto de extensão em um caso de uso é uma indicação de que outros casos de uso poderão ser adicionados a ele. Quando o caso de uso for invocado, ele verificará se suas extensões devem ou não serem invocadas.

  • Comentando sobre as letras: "A" e "E". Mas antes uma breve introdução sobre algo que julgo ser essencial para a explicação.

    >>>Introdução<<<

    • Ao meu ver, essa questão contém dois níveis de dificuldade: (1) caso você já saiba a diferença entre: inclusão (obrigatório), generalização/especialização (herda/faz mais coisas), e extensão (opcional), você chegará as letras "A" e "E"; (2) qual é a posição correta da seta?
    • A seta é usada para apontar uma direção, mas como é formada? R.: segmento de reta (pontilhada ou contínua - na questão o segmento de reta é pontilhado) com um triângulo fixado em um dos finais.

    >>>Vamos à questão<<<

    • O triângulo fixado na elipse é o objeto essencial e onde está a reta pontilhada mostra o objeto estendido (não essencial) que seu uso dependerá. Obs.: essa ideia da forma da seta pode-se aplicar a generalização/especialização: o triângulo sem ser preenchido imediatamente após a elipse aponta para o mais genérico.
    • Erro da letra E: dá a entender que toda pessoa que entra no departamento é um Doador, sendo que não é verdade. Toda a pessoa que entra no departamento é um cidadão e ser doador é opcional. Logo, o correto é o triângulo aberto da seta imediatamente após a elipse do cidadão (letra A).

    Em frente e enfrente.


ID
1141339
Banca
FUNRIO
Órgão
INSS
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Na modelagem de casos de uso, em sistemas complexos, em vez de representar todos os casos de uso num único diagrama, pode-se adotar a abordagem de criar vários diagramas, de acordo com as necessidades de visualização.
Analise as três opções abaixo:

I – Diagrama exibindo um caso de uso e seus relacionamentos.
II – Diagrama exibindo todos os casos de uso para um ator.
III – Diagrama exibindo todos os casos de uso a serem implementados em um ciclo de desenvolvimento.

Quais dessas opções podem ser consideradas como modelos de particionamento do diagrama de casos de uso?

Alternativas
Comentários
  • "Um caso de uso e seus relacionamentos" não está particionado em nada... Não entendi o gabarito

  • Chutei letra E mesmo!

    Questão muito loka!

  • Chutei letra E mesmo!

    Questão muito loka! (2)

    Que banca horrível, o nível das questões de TI são terríveis.


ID
1142326
Banca
FUMARC
Órgão
PC-MG
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Sobre os tipos de relacionamento entre Casos de Uso, analise as seguintes afirmativas:

I. Um relacionamento de inclusão (include) significa que o caso de uso base incorpora, explicitamente, o comportamento de outro caso de uso em uma localização especificada na base.

II. Um relacionamento estendido (extend) significa que o caso de uso base inicia, obrigatoriamente, a execução de outro caso de uso em uma localização especificada na base.

III. Um relacionamento de generalização entre casos de uso significa que o caso de uso filho herda o comporta- mento do caso de uso pai.

Estão CORRETAS as afirmativas:

Alternativas
Comentários
  • Gabarito: B.

     

    Include - obrigatório

    Extend - opcional

  • b-

    extends é quando ha condição, o que significa possivel comportamento.


ID
1151101
Banca
FUMARC
Órgão
AL-MG
Ano
2014
Provas
Disciplina
Engenharia de Software
Assuntos

Analise as seguintes afirmativas sobre o Diagrama de Casos de Uso da UML.

I. Um relacionamento estendido entre casos de uso significa que o caso de uso base incorpora implicitamente, sob alguma condição, o comportamento de outro caso de uso.
II. Um relacionamento de inclusão entre casos de uso significa que o caso de uso base incorpora explicitamente o comportamento de outro caso de uso.
III. Relacionamentos de inclusão e extensão são representados pela mesma notação do relacionamento de dependência, com a seta apontada para o caso de uso base.

Estão CORRETAS as afirmativas:

Alternativas
Comentários
  • Sabendo que a  afirmativa  III está errada, você consegue acertar a questão ,já que, ela está em 3 alternativas

    Letra A

  • Pensei o mesmo Rodrigo, não tinha ideia do que a banca quis dizer com implicitamente/explicitamente porém sabia que a III é incorreta já que a extensão não aponta do C.U. base para o C.U. estendido, mas sim do estendido para o base. Apenas a A não a contém a III...