Buscar

FMU ENGENHARIA DE SOFTWARE ATIVIDADE 2

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 3, do total de 7 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 6, do total de 7 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Prévia do material em texto

FMU – ENGENHARIA DE SOFTWARE – TRABALHO A2 
 
NOTA: 10,00 
 
PERGUNTA 1 
 
Para SZYPERSKI, “componentes de software são unidades binárias 
de produção, aquisição e implantação independentes que interagem para 
formar um sistema funcional” (Szyperski, 2002). 
 
Assim, é possível perceber que não é qualquer unidade do software 
que pode ser vista como um componente, uma vez que a característica de 
independência do componente é parte integrante da sua definição. 
 
 Diagramas de componentes são utilizados usualmente para apoiar na 
representação não somente dos componentes existentes em um sistema, mas 
principalmente dos relacionamentos entre eles que fazem com que uma 
funcionalidade específica do software seja realizada. Componentes de 
software e seu diagrama, é correto o que se afirma em: 
 
 
 .Componentes são representações independentes e não 
reutilizáveis do software. 
 
 .Interfaces são utilizadas para mostrar a conexão entre 
componentes independentes. 
 
 .Componentes e objetos estão em um mesmo nível de abstração. 
 
 .Diagramas de componentes é uma visualização particular para 
diagramas de classes. 
 
 .Componentes representam comportamentos do software. 
 
PERGUNTA 2 
 
Em sistemas web, o padrão de arquitetura MVC é o mais largamente 
utilizado para organização das partes constituintes do software. 
 
Ele tem como objetivo separar informações de apresentação, de suas 
validações frente as regras de negócio e das manipulações de dados na base 
de dados da aplicação. 
 
 A simplicidade na separação de responsabilidades dentro do software 
fez com que diferentes frameworks para diferentes linguagens de 
programação implementassem o MVC o que levou a popularização do 
padrão ao redor do globo. Sobre o modelo MVC é correto o que se afirma 
em: 
 
 
.O MVC, assim como outros padrões de projeto, surgiu como 
forma a contornar problemas comuns existentes em projetos de 
software. 
 
 .O MVC possui variações como o HMVC (hierarchical model-
view-control) e o MVVM (model-view-viewmodel). 
 
 .A parte representada pelo Model é responsável por validar os 
dados inseridos pelo usuário. 
 
 .A parte representada pelo View é responsável por gerenciar os 
dados da aplicação. 
 
 .A parte representada pelo Controler é responsável por controlar 
as informações inseridas no banco de dados da aplicação. 
 
PERGUNTA 3 
 
Durante a identificação de requisitos, também chamado de 
levantamento de requisitos, espera-se que haja um entendimento do 
problema e das necessidades do cliente que os levaram a iniciar um projeto 
de desenvolvimento de software. 
 
Para tanto, analistas de negócios e requisitos devem lançar mão de 
estratégias de coleta de informação que possam melhor auxiliá-los não 
somente a capturar informação, mas também a entendê-las. São exemplos de 
técnicas que podem ser utilizadas para identificar requisitos junto aos 
interessados pelo projeto: 
 
 
 .Brainstorm e Desenho Colaborativo. 
 
 .Questionários e Coaching. 
 
 .Entrevistas e Reuniões. 
 
 .Role Playing e Game Playing. 
 
 .Observação Indireta e Role Playing. 
 
PERGUNTA 4 
 
Ao elicitar requisitos, o analista necessita identificar, especificar, 
classificar e priorizar requisitos de software. 
 
Cada uma dessas tarefas requer boa relação e constante comunicação 
com os clientes do software em construção, já que essa fase inicial de 
conhecimento de problemas e identificação de necessidades dos clientes e 
usuários é fundamental para o sucesso do projeto. Sobre as tarefas que o 
analista deve realizar durante a elicitação de requisitos, é correto afirmar que: 
 
 
 
.A identificação de requisitos compreende a utilização de 
diferentes técnicas para identificar, junto aos clientes e 
interessados pelo projeto, o problema a ser solucionado via a 
construção de um software e as necessidades de funcionalidades 
do software em construção. 
 
 
.A especificação de requisitos compreende o registro do problema 
e das necessidades levantadas durante a identificação de 
requisitos, bem como a modelagem e codificação do software de 
modo materialiar os requisitos levantados anteriormente. 
 
 
.A classificação de requisitos compreende a utilização de técnicas 
para, junto aos clientes, classificar os requisitos em funcionais, 
não funcionais e em regras de negócio. 
 
 
.A priorização de requisitos compreende a organização dos 
requisitos em ordem de identificação, como forma a rastrear 
requisito e momento em que ele vou identificado. 
 
 
.A negociação de requisitos compreende a utilização de diferentes 
tipos técnicas de persuasão para dissuadir o cliente a implementar 
requisitos não adequados para o contexto do projeto. 
 
PERGUNTA 5 
 
Em orientação a objetos, os objetos podem sofrer mudanças de seus 
estados conforme a realização de comportamentos do sistema. 
 
Além disso, é possível que determinadas ações do sistema só possam 
ser realizadas mediante a conformidade dos objetos com estados requeridos 
para seus atributos. 
 
Diagramas de estados são então uma boa opção de uso para 
explicitação dessas regras de transição de estado dos objetos de um software. 
A alternativa que apresenta conceitos presentes em modelagem de estados 
de um objeto é: 
 
 
 .Estado intermediário, transição e ação. 
 
 .Estado inicial, estado final e ação. 
 
 .Estado inicial, estado intermediário e estado final. 
 
 .Ação, barra de sincronização e atividade. 
 
 .Classe, estado inicial e estado final. 
 
PERGUNTA 6 
 
Diagramas de Casos de Uso são diagramas que apresentam de maneira 
visual as diferentes funcionalidades do sistema, o relacionamento entre elas 
e a participação de diferentes atores humanos e não-humanos com as 
funcionalidades do sistema. 
 
O diagrama é comumente utilizado em fases iniciais do processo de 
desenvolvimento do software, isso porque por apresentar uma sintaxe 
simples, o diagrama acaba sendo de fácil entendimento para os interessados 
do projeto. Sobre o diagrama de Casos de Uso, leia as afirmações a seguir e 
escolha a alternativa correta. 
 
I) Diagramas de Casos de Uso são diagramas comportamentais da UML. 
 
II) O relacionamento de inclusão (include) de um Caso de Uso em outro faz 
com que o Caso de Uso incluído tenha seus passos executados também na 
chamada do Caso de Uso que o incluiu. 
 
III) A herança entre atores no diagrama de Casos de Uso diz respeito a 
herança de participação (relacionamento) do ator herdado com outros Casos 
de Uso com os quais se relaciona. 
 
IV) Em um diagrama de Casos de Uso, a delimitação da fronteira do sistema 
é realizada com o uso de um retângulo que envolve os Casos de Uso 
representados e exclui os atores. 
 
 
 .Apenas I e III são falsas. 
 
 .Apenas I, II e III são verdadeiras. 
 
 .I, II, III e IV são verdadeiras. 
 
 . Apenas I e IV são falsas. 
 
 .Apenas I é falsa. 
 
PERGUNTA 7 
 
Diagramas de Casos de Uso são diagramas comportamentais da UML 
que representam de forma fácil as diferentes funcionalidades do software, 
seus atores e interações entre eles. 
 
 Por ser de fácil assimilação é comum que clientes tenham acesso aos 
diagramas de Casos de Uso do sistema e consigam entender e mesmo fazer 
ajustes no que é representado. Observe o diagrama abaixo e assinale a 
alternativa correta em relação ao representado. 
 
Fonte: Autora 
 
 .Professor participa de todos os casos de uso representados. 
 
 .Professor e aluno fazem parte da fronteira do software. 
 
 .Professor e aluno participam do caso de uso de “visualizar notas”. 
 
 .Professor participa do caso de uso de “inscrever-se em 
disciplinas”. 
 
 .Aluno participa de todos os casos de uso representados. 
 
 
PERGUNTA 8 
 
A modelagem de sistemas pode ser realizada utilizando diferentes 
tipos de modelos. Durante muitos anos DFD (data-flow diagrams) foi 
utilizado para apoiar a modelagem de programas estruturados.Com o surgimento de diferentes paradigmas de programação, as 
necessidades por modelos diferenciados surgiram e, outras formas de 
modelagem torna-se mais adequadas para softwares baseados em OO 
(orientação a objetos). 
 
Sobre os diferentes tipos de classificação de modelos de software, 
assinale a opção com a correta correspondência entre classificação e 
definição: 
 
(1) Modelo de 
Contexto 
A) representa o ambiente de negócio e 
tecnológico no qual o sistema irá funcionar 
(2) Modelo de 
Interação 
B) representa o comportamento do sistema 
em relação a eventos aplicados em sua 
utilização 
(3) Modelo 
Estrutural 
C) representa a interação entre sistemas, 
componentes, módulos, usuários e negócio 
(4) Modelo 
Comportamental 
D) representa a estrutura de arquivos, dados 
e processos dentro do sistema 
 
 
 
 
.1-A; 2-B; 3-C e 4-
D. 
 
 .1-A; 2-C; 3-D e 4-
B. 
 
 .1-B; 2-A; 3-C e 4-
D. 
 
 .1-B; 2-C; 3-A e 4-
D. 
 
 .1-D; 2-C; 3-B e 4-
A. 
 
PERGUNTA 9 
 
Muitas vezes os diagramas de classes são utilizados para descrever 
conceitos do negócio. Essa utilização visa traduzir a comunicação advinda 
dos clientes para os responsáveis por implementar de fato as funcionalidades 
do sistema. 
 
Sendo utilizadas com esse propósito, detalhes de implementação são 
muitas vezes suprimidos do diagrama e o enfoca torna-se maior para as 
entidades significativas para o negócio, bem como para seus atributos e 
relacionamentos com demais entidades. 
 
Veja o exemplo abaixo de um diagrama sendo utilizado com o 
propósito de descrever um negócio de vendas de uma empresa. 
 
Fonte: Autora 
Sobre o diagrama, é correto afirmar que: 
 
 
 .Produto e Embalagem estão relacionados com uma associação de 
agregação. 
 
 .Produto possui um relacionamento de 
especialização/generalização com Setor. 
 
 .nome e capacidadeProduto são métodos da classe Setor. 
 
 .Os atributos representados no diagrama possuem visibilidade 
pública. 
 
 .Um Produto pode estar localizado em mais de um Setor. 
 
 
 
PERGUNTA 10 
 
Diagramas de classes representam classes do software, seus atributos, 
métodos e relacionamentos que levam, de certa forma, a entender um pouco 
do próprio negócio e das entidades importantes e presentes no dia a dia da 
organização para o qual o software se destina. 
 
As classes do diagrama podem se relacionar uma com as outras a partir 
do uso de diferentes tipos de relacionamentos. A alternativa com o nome do 
relacionamento responsável por indicar que as informações de um objeto de 
uma classe precisam ser complementadas por informações de um objeto de 
outra classe é: 
 
 .Associação. 
 
 .Especialização. 
 
 .Multiplicidade. 
 
 .Agregação. 
 
 .Generalização.

Continue navegando