Concurso Caixa TI - Imersão Final - Rogério Araújo.pdf

TLP:CLEAR | Público
Professor Rogerão Araújo 1

CESGRANRIO 2024 Caixa
Técnico Bancário Novo – Tecnologia da Informação
Professor Rogerão Araújo

UML
3

É linguagem de modelagem visual
De propósito geral
Para que um sistema de software seja
Visualizado Especificado Construído Documentado
Conceituação

É poderosa o
suficiente
Para representar
todos os conceitos
que existem na
análise e projeto
orientados a
objetos
É uma linguagem
gráfica usada no
desenvolvimento
orientado a
objetos
Que inclui diversos
tipos de modelos
de sistema que
fornecem visões
diferentes de um
sistema
Tornou-se um
padrão de fato
Para modelagem
orientada a
objetos
Diagramas UML
São
representações
apenas de
conceitos
orientados a
objetos
Conceituação

Modelagem
Estrutural
Modelagem
Comportamental
Tipos de modelagens com UML

Captura
Os recursos
estáticos de um
sistema
Representa a
estrutura do sistema
Esta estrutura é
o local onde
todos os outros
componentes
existem
Nunca descreve
O
comportamento
dinâmico do
sistema
Modelagem Estrutural

Diagrama de Classes Diagrama de Objetos Diagrama de Pacotes
Diagrama de Estrutura
Composta
Diagramas de
Implementação
• Diagrama de Componentes
• Diagrama de Implantação
Diagramas Estruturais

Descreve
A interação
no sistema
Representa
A interação
entre os
diagramas
estruturais
Mostra
A natureza
dinâmica
do sistema
Modelagem Comportamental

Diagrama de Atividades Diagrama de Casos de Uso
Diagrama de Estados
Diagramas de Interação
• Diagrama de Sequência
• Diagrama de Tempo
• Diagrama de Comunicação
• Diagrama de Visão Geral de
Interação
Diagramas Comportamentais

Serve de apoio para a maioria
dos outros diagramas
Define a estrutura das classes
do sistema
Estabelece como as classes se
relacionam
Tem o objetivo de modelar a
visão estática de um aplicativo
É o único diagrama
Que pode ser mapeado
diretamente com alguma
linguagem orientada a objetos
Diagrama de Classes

Exemplo

Modificador
Public +
Protected #
Package ~
Private -
Modificador
Público
Protegido
Pacote
Privado
Classe
✓
✓
✓
✓
Subclasse
✓
✓


Pacote
✓

✓

Todos
✓



Modificadores de acesso

[CESGRANRIO 2024 UNEMAT – Analista de Sistemas] Considere
um tipo de visibilidade que pode ser usado em um método de
objeto de uma classe P para permitir acesso nas seguintes
situações:
• (i) quando uma classe Q estender da classe P; e
• (ii) quando uma classe R faz parte do mesmo pacote da classe
P.
Questões de concursos

[CESGRANRIO 2024 UNEMAT – Analista de Sistemas] Assim,
tanto objetos do tipo da classe Q como da classe R poderão
acessar o método que está na classe P. Na situação descrita, o
tipo de visibilidade a ser usado é o
• [A] static
• [B] public
• [C] private
• [D] package
• [E] protected

[CESGRANRIO 2024 UNEMAT – Analista de Sistemas] Assim,
tanto objetos do tipo da classe Q como da classe R poderão
acessar o método que está na classe P. Na situação descrita, o
tipo de visibilidade a ser usado é o
• [A] static
• [B] public poderia ser também
• [C] private
• [D] package
• [E] protected

Descrevem
Como as classes interagem
umas com as outras
Responsabilidades das
classes
Relacionamentos
Dependência
Associação
Agregação
Composição
Herança
Relacionamentos entre classes

Significa que uma classe usa outra
Indica que um objeto
Depende da especificação de
outro objeto
Se a especificação mudar
É necessário a atualização da
classe do objeto dependente
Dependência

Pode ser gerada pelos seguintes
tipos de uso
Parâmetro
de
métodos
Tipo de
retorno de
métodos
Utilização
dentro dos
métodos
Exceções
lançadas
Dependência

Exemplo

Significa que uma classe tem outra
É um relacionamento estrutural
Nome da associação
Descreve o relacionamento
Cada objeto em uma
associação
Tem um papel
Multiplicidade
Indica quantos objetos podem
tomar parte em uma associação
Associação

Exemplo

Cardinalidade
É o número de instâncias
de uma classe
Relacionada com uma
instância de outra classe
Para cada associação
Há uma multiplicidade
em cada direção
Multiplicidade de associação

Exemplo

Notação de associação

Notação textual de atributo

que uma classe P possui nela uma propriedade de objeto que
guarda a instância de uma classe Q. Nesse caso, o tipo de
relacionamento entre as classes P e Q que deve ser modelado em
um diagrama de classe da UML é o relacionamento de
• [A] associação.
• [B] herança de interface.
• [C] herança entre classes.
• [D] dependência, em que P depende de Q.
• [E] dependência, em que Q depende de P.

[CESGRANRIO 2024 IPEA – Técnico de Planejamento e Pesquisa –
Desenvolvimento de Sistemas] Em um diagrama de classes
criado por uma equipe, há uma classe P que possui um
relacionamento de associação com a classe Q.

Desenvolvimento de Sistemas] Qual situação, em código, representa,
de maneira adequada, tal ideia de relacionamento entre essas classes?
• [A] A classe P possui um método que instancia um objeto da classe
Q.
• [B] A classe P possui um método que recebe como parâmetro um
objeto da classe Q.
• [C] A classe P possui uma propriedade de objeto da classe Q.
• [D] A classe P herda da classe Q.
• [E] A classe Q herda da classe P.

É usado geralmente na fase de Especificação de
Requisitos
Mostra
Quais usuários realizam que
funcionalidades do sistema
Alguns relacionamentos
entre estas funcionalidades
Diagrama de Casos de Uso

É usado para reunir os
requisitos de um
sistema
Incluindo
influências
internas e
externas
Esses requisitos
são
principalmente
requisitos de
projeto
Quando um sistema é
analisado para reunir
suas funcionalidades
Os casos de uso
são preparados
Os atores são
identificados

Representa as principais
funcionalidades do
sistema
Sob o ponto de vista dos
atores
Indica O QUE fazer
Não indica COMO fazer

• As metas de interações entre sistemas e usuários
Representa
• Requisitos funcionais no sistema
Define e organiza
• O contexto e os requisitos do sistema
Especifica
• O fluxo básico de eventos no caso de uso
Modela

Especifica o
comportamento de um
caso de uso
É uma sequência de
comandos
declarativos
Que descreve as
etapas de execução
de um caso de uso
Permanece focado no
domínio do problema
Não em sua
solução
Pode conter
Testes condicionais
Iterações
Fluxo de eventos

É composto por
Um fluxo básico
Descreve a funcionalidade principal
do caso de uso
Quando nenhum desvio é tomado
Zero ou mais fluxos alternativos
Descrevem desvios pré-definidos
Do fluxo básico
Fluxo de eventos

Include
É aquele no qual um caso de uso
base inclui a funcionalidade de outro
caso de uso
O caso de uso de inclusão
Suporta a reutilização da
funcionalidade
Em um modelo de caso de uso
Relacionamento de Inclusão

O caso de uso A “inclui” o caso de uso B
Sempre que o caso de uso A for
executado
O caso de uso B também será
executado
A direção do relacionamento é do
caso de uso que está incluindo para
o caso de uso incluído
A → B
Relacionamento de Inclusão

Extend
É possível de ser utilizado para especificar que um caso de uso (extensão)
estende o comportamento de outro caso de uso (base)
Revela detalhes sobre um sistema ou aplicativo
Que normalmente estão ocultos em um caso de uso
Relacionamento de Extensão

O caso de uso B estende o caso de uso A
Quando o caso de uso A for
executado
O caso de uso B poderá ou não ser
executado também
A direção do relacionamento é do
caso de uso extensor para o caso de
uso estendido
B → A
Relacionamento de Extensão

Exemplo 1

Exemplo 2

[CESGRANRIO 2024 UNEMAT – Analista de Sistemas] Ciente de
que, no âmbito da iniciação do desenvolvimento de um projeto
de software, um dos passos mais importantes da Engenharia de
Requisitos é a modelagem do escopo do sistema, um gerente
avaliou o uso do Diagrama de Casos de Uso.

[CESGRANRIO 2024 UNEMAT – Analista de Sistemas] Entre as
características que tornam o Diagrama de Casos de Uso adequado
para essa modelagem está a de representar a(s)
• [A] sequência em que os passos do processo modelado são
executados
• [B] sequência que deve ser usada para prover uma resposta a uma
ação do usuário
• [C] interfaces, os controladores e as entidades do sistema
• [D] regras de negócio de cada atividade
• [E] relações entre entidades externas e funcionalidades do sistema

Desenvolvimento de Sistemas] Uma empresa aérea regional
instalou um serviço de despacho de bagagens nos principais
aeroportos brasileiros. Esse serviço funcionará da seguinte
maneira:
• o passageiro entregará o seu bilhete a um atendente;
• o atendente procurará por um computador disponível para
buscar os dados do bilhete no sistema e iniciará o despacho;
• o atendente solicitará ao passageiro que ponha uma bagagem
sobre a balança;

maneira:
• a balança digital pesará a bagagem e transmitirá os dados da
pesagem para o sistema;
• o sistema emitirá uma etiqueta, que será presa à bagagem pelo
atendente;

maneira:
• o processo de pesagem será repetido até que não haja mais
bagagens a serem despachadas;
• nenhum recibo será entregue ao passageiro.

Desenvolvimento de Sistemas] Qual diagrama de casos de uso
retrata adequadamente o cenário descrito?
• [A]

• [B]

• [C]

• [D]

• [E]

• [D]

Foca na ordem
temporal em que
as mensagens são
trocadas
Pode se basear
em um Caso de
Uso
Identifica
Os eventos
associados a
funcionalidade
modelada
O ator
responsável por
este evento
Diagrama de Sequência

Atores Objetos
Linha do
tempo
Comunicação
Interpretação
das
mensagens
Elementos básicos

Exemplo

um diagrama de interação da UML que permite visualizar como
um conjunto de objetos/classes interagem em um processo ao
longo do tempo. Tal diagrama mostra as mensagens, como, por
exemplo, as chamadas de métodos que ocorrem entre atores e
objetos/classes no sistema, e a ordem em que ocorrem.

[CESGRANRIO 2024 UNEMAT – Analista de Sistemas]vO diagrama
descrito é o de
• [A] Atividade
• [B] Caso de Uso
• [C] Estado
• [D] Pacotes
• [E] Sequência

Engenharia de requisitos
61

São
Cortes no
espaço de
solução
O entendimento
do que o
usuário quer
Seu
resultado
É uma promessa
para o cliente
Requisitos

Requisitos de usuário
• Expressa os requisitos abstratos de
alto nível
Requisitos de sistema
• Expressa a descrição detalhada do
que o sistema deve fazer
Requisitos de usuário e de sistema

São declarações
Em uma linguagem
natural com
diagramas
De quais os
serviços o sistema
deverá fornecer a
seus usuários
Com quais as
restrições o
sistema deverá
operar
Requisitos de usuário

São descrições mais detalhadas
Das funções, serviços e restrições operacionais
Do sistema de software

Documento de requisitos do sistema
Especificação funcional
Deve definir
Exatamente o que deve
ser implementado
Pode ser parte do contrato entre
O comprador do
sistema
Os desenvolvedores de
software

• Descrevem explicitamente as funcionalidades e serviços do
sistema
• Documenta:
• Como o sistema deve:
• Reagir a entradas específicas
• Comportar-se em determinadas situações
• O que o sistema não deve fazer
Requisitos Funcionais

• Atributos:
• Completude
• Quando todos os serviços devem estar definidos
• Consistência
• Quando todos os requisitos não devem ter definições contraditórias
• Na prática:
• É quase impossível atingir completude e consistência dos requisitos

• Exemplos:
• O usuário pode pesquisar todo ou um sub-conjunto do banco de dados
• O sistema deve oferecer telas apropriadas para o usuário ler
documentos armazenados
• Cada pedido deve ser associado a um identificador único (PID)
• O qual o usuário pode copiar para a área de armazenamento permanente da
conta

• RNF
• Definem propriedades e restrições do sistema
• Exemplos: segurança, desempenho, espaço em disco
• Podem ser:
• Do sistema todo
• De partes do sistema
• Mais críticos que requisitos funcionais
• Se o sistema não satisfaz:
• Ele é inútil
Requisitos Não-Funcionais

Requisitos do
Produto
Especificam o comportamento
do software
Exemplo:
Desempenho
A interface do usuário deve
ser implementada como
simples HTML
Requisitos
Organizacionais
São consequentes de políticas
e procedimentos das
empresas
Exemplo:
Padrões do cliente
Todos os documentos
entregues devem seguir o
padrão de relatórios XYZ-00
Requisitos
Externos
São derivados do ambiente ou
fatores externos ao sistema
Exemplo:
Legislação
Informações pessoais dos
usuários não podem ser vistas
pelos operadores do sistema

Concepção
Levantamento
Elaboração Negociação
Especificação
Validação
Gestão de
requisitos

Estudo de
viabilidade
Levantamento
e análise de
requisitos
Documentação
dos requisitos
Validação dos
requisitos
Documento de
Requisitos

Refinar casos de
uso
Refinar modelo
conceitual
Refinar glossário
Definir diagramas
de sequência
(opcional)
Definir contratos
de operação
(opcional)
Definir diagramas
de estado
(opcional)
Atividades típicas

Elicitação dos
requisitos
É a tarefa de comunicar-se
com os usuários e clientes
Para determinar quais são
os requisitos de sistema
Análise de
requisitos
Determina se o estado do
requisitos é obscuro,
incompleto, ambíguo, ou
contraditório
Resolve estes problemas
Registros dos
requisitos
Os requisitos podem ser
documentados de várias
formas
Tais como documentos de
linguagem natural, casos
de uso, ou processo de
especificação
Resumo

Elicitação ou
identificação
Requisitos
descobertos e
levantados
Análise e
negociação
Requisitos
analisados e
ordenados
Especificação e
documentação
Requisitos
documentados
Validação
Requisitos
validados
Resumo

Desenvolvimento de Sistemas] A engenharia de requisitos pode
ser dividida em gerenciamento de requisitos e desenvolvimento
de requisitos, e este, por sua vez, pode ser subdividido em
elicitação, análise, especificação e validação. Cada um desses
quatro componentes do desenvolvimento de requisitos possui
um conjunto de boas práticas.

Desenvolvimento de Sistemas] Uma das boas práticas associadas
à validação de requisitos é
• [A] priorizar os requisitos.
• [B] registrar as regras de negócio.
• [C] alocar requisitos aos subsistemas.
• [D] definir critérios de aceitação do produto.
• [E] especificar os atributos de qualidade do produto.

Concurso Caixa TI - Imersão Final - Rogério Araújo.pdf

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Concurso Caixa TI - Imersão Final - Rogério Araújo.pdf

Semelhante a Concurso Caixa TI - Imersão Final - Rogério Araújo.pdf (20)

Último

Último (6)

Concurso Caixa TI - Imersão Final - Rogério Araújo.pdf