Questões sobre Engenharia de Software

O levantamento de requisitos tem como objetivo compreender o problema a ser resolvido e identificar necessidades. Os requisitos podem ser funcionais, que definem as funcionalidades do sistema, ou não funcionais, que não estão relacionados às funcionalidades.

A análise tem como foco construir uma estratégia de solução. Os modelos construídos nessa fase devem ser verificados e validados. A verificação tem como objetivo assegurar que as necessidades do cliente estão sendo atendidas pelo sistema, enquanto a validação tem o objetivo de analisar se os modelos estão em conformidade com os requisitos definidos.

O projeto produz uma descrição computacional do software sem restrições de tecnologia, ou seja, aspectos físicos e dependentes de implementação não são considerados.

Na fase de implementação, o sistema é codificado, ou seja, a descrição computacional obtida na fase de projeto é traduzida para código executável, por meio do uso de uma ou mais linguagens de programação.

Na fase de implantação, o sistema é testado, empacotado, distribuído e instalado no ambiente do cliente.

O RUP divide todo o projeto de software em três fases diferentes: concepção (ou iniciação), com ênfase no escopo do sistema; elaboração, com ênfase na arquitetura; e construção, com ênfase no desenvolvimento.

O RUP promove o uso de seis melhores práticas: desenvolva iterativamente; gerencie requisitos; use arquiteturas de componentes; modele visualmente (UML); verifique qualidade de software continuamente; e gerencie mudanças.

As disciplinas de suporte (apoio) do RUP são: gerenciamento de classes; gerenciamento de produto; e ambiente.

Um papel é uma definição abstrata de um conjunto de atividades executadas e dos respectivos artefatos. Exemplos de papéis no RUP são: analistas, desenvolvedores e testadores. Explicitamente, papéis de gerentes não fazem parte dos papéis possíveis no RUP.

As disciplinas de engenharia do RUP são: modelagem de negócios; requisitos; análise e projeto; implementação; teste; qualidade; e implantação.

Os diagramas de casos de uso são diagramas UML para modelagem de aspectos estáticos de sistemas.

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

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

Em diagramas de casos de uso, não é possível utilizar relacionamento de generalização entre atores nem entre casos de uso.

O uso de pacotes permite formar grupos de casos de uso e de atores, de modo a facilitar a compreensão de um sistema complexo. Pacotes de atores refletem os tipos de usuários do sistema.

A navegação em uma associação é unidirecional, da esquerda para direita e de cima para baixo, a menos que seja explicitado o procedimento contrário.

Em generalizações, atributos e operações são herdados pelas subclasses. Entretanto, relacionamentos de associação não são herdados.

Em uma associação entre duas classes, a própria associação pode ter atributos. Nesse caso, usa-se a classe de associação.

A agregação é um relacionamento particular de especialização, que especifica o relacionamento todo/parte entre o agregado e o componente.

A agregação é uma forma especial de composição com tempo de vida coincidente das partes pelo todo, ou seja, o objeto composto é responsável pela criação e destruição de suas partes.

Uma condição de guarda é uma expressão booleana que precisa ser falsa para que uma transição ocorra.

Diagramas de estados não podem ser aninhados e, portanto, não são capazes de expressar situações complexas.

Não há como expressar a concorrência entre objetos por meio de diagramas de estados.

Um estado é uma condição ou situação na vida de um objeto durante a qual o objeto satisfaz alguma condição, realiza alguma atividade ou aguarda um evento.

As combinações de eventos, estados e transições de estado para determinada classe não podem ser representadas em um único diagrama de estados.