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.

Exemplos de diagramas de modelagem UML que expressam partes estáticas de um sistema são: diagrama de classes e diagrama de atividades.

Exemplos de diagramas de modelagem UML que expressam partes dinâmicas de um sistema são: diagrama de caso de uso e diagrama de implantação.

Um diagrama de componentes é do tipo estrutural, e mostra partes internas, conectores e portas que implementam um componente.

O diagrama de comunicação enfatiza a ordem temporal de mensagens, que reagem a eventos externos e internos.

A UML é uma linguagem de programação orientada a objetos.

A manutenção de software é um processo geral de mudanças que ocorre antes ou depois que um sistema é entregue.

A manutenção corretiva para reparar defeitos de software diz respeito à mudança em um sistema para corrigir erros, que podem ser somente de codificação. Erros de projeto e de lógica não estão incluídos nessa categoria.

A manutenção adaptativa para adaptar o software a mudanças ambientais se refere a mudanças de diversos tipos, como uma nova plataforma de hardware. Mudanças de sistemas operacionais ou software em geral não estão incluídas nessa categoria.

A manutenção perfectiva tem como objetivo tornar o software perfeito, melhorar seu desempenho e sua manutenibilidade ou adicionar-lhe funcionalidade para satisfazer a novos requisitos.

A manutenção preventiva tem como objetivo detectar e corrigir falhas latentes no produto antes que elas virem falhas efetivas.

Requisitos funcionais descrevem as propriedades emergentes do sistema, como segurança e tempo de resposta.

Requisitos não funcionais são descritos de forma qualitativa e não quantitativa.

Requisitos são provenientes de pessoas relevantes para o sistema, e não de outros sistemas que interagem com o sistema que está sendo especificado.

A matriz de rastreabilidade não oferece suporte para requisitos funcionais.

Revisão de requisitos, prototipação e geração de casos de teste são exemplos de técnicas de validação de requisitos.

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.

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 modelo em cascata é apropriado para software em que os requisitos ainda não foram bem compreendidos, pois é focado na criação de incrementos.

Os processos de desenvolvimento ágil de software valorizam mais: indivíduos e interações do que processos e ferramentas; software funcionando do que documentação compreensível; colaboração do cliente do que negociação contratual; e respostas a mudanças do que planejamento seguido.

Desenvolvimento incremental é sinônimo de desenvolvimento iterativo.

A programação extrema (eXtreme Programming, ou XP) é um processo de desenvolvimento ágil que permite a ausência do cliente em fases iniciais, como nas reuniões de planejamento de versão e planejamento de iteração.

A programação em pares é uma característica presente em todos os processos de desenvolvimento ágil, como XP e Scrum.

Interoperabilidade.

Compartilhamento de dados.

Intercâmbio de dados.

Acessibilidade.

Cada mensagem entre objetos é representada com uma expressão de mensagem em linha sólida, com seta cheia, entres as linhas de vida verticais.

A notação UML para chamadas assíncronas é uma mensagem com seta traçada.

Os participantes da linha da vida devem representar um objeto, não uma coleção.

A ordem das mensagens é ilustrada com números de sequência.

descreve a interação de sequência de tempo dos objetos e classes percebida por atores externos.

descreve a funcionalidade do sistema.

mostra as sequências de estados que uma classe e objetos assumem em sua vida em resposta a estímulos recebidos, juntamente com suas respostas e ações.

denota a estrutura estática de um sistema.