Em um modelo construído com a UML, estão corretas as seguintes características de diagramas de atividades: separações (forks) e junções (joins) são empregadas quando há atividades em paralelo; cada junção tem uma transição de entrada e várias de saída; cada separação tem várias transições de entrada e uma de saída; atividades estão agrupadas em raias separadas por linhas.

Na arquitetura cliente-servidor com três camadas (three tier), a camada de apresentação, a camada de aplicação e o gerenciamento de dados ocorrem em diferentes máquinas. A camada de apresentação provê a interface do usuário e interage com o usuário, sendo máquinas clientes responsáveis pela sua execução. A camada de aplicação é responsável pela lógica da aplicação, sendo executada em servidores de aplicação. Essa camada pode interagir com um ou mais bancos de dados ou fontes de dados. Finalmente, o gerenciamento de dados ocorre em servidores de banco de dados, que processam as consultas da camada de aplicação e enviam os resultados.

Inspeções e walkthroughs podem fazer parte de um processo de verificação e validação, sendo realizadas por equipes cujos membros têm papéis definidos. Quando da inspeção de um código, uma lista de verificação de erros (checklist) é usada. O conteúdo da lista tipicamente independe da linguagem de programação usada.

A arquitetura de um sistema de software pode se basear em determinado estilo de arquitetura. Um estilo de arquitetura é um padrão de organização. No estilo cliente-servidor, o sistema é organizado como um conjunto de serviços, servidores e clientes associados que acessam e usam os serviços. Os principais componentes desse estilo são servidores que oferecem serviços e clientes que solicitam os serviços.

No diagrama da figura III, há dois nós interligados, que representam duas unidades computacionais; há cinco componentes distribuídos entre os nós; um destes implementa uma interface e um outro depende dessa interface; ClienteAplicacao depende de Stub; ServidorAplicacao depende de Banco de dados.

No diagrama da figura II, telaA é o nome de uma instância de uma classe; três objetos são criados e dois são destruídos; há duas autochamadas e uma delas só é executada se uma condição de guarda for satisfeita; a mensagem da instância de TelaReserva para a de CntrReserva é assíncrona; a mensagem da instância de TelaResultado para a de CntrReserva é síncrona.

No diagrama da figura I, uma instância da classe Grupo pode ter ligações para mais de uma instância dessa mesma classe; a classe Grupo herda um atributo da classe Usuario; há uma agregação entre Grupo e Usuario; o método desconectar , na classe CntrPersistenciaRelacional, tem visibilidade pública; cada objeto da clas se TelaAutenticacao pode ter uma ligação com um objeto da classe Grupo.

De acordo com o diagrama da figura I, a classe CntrPersistenciaRelacional implementa IPersistencia; a classe Pessoa pode ser instanciada; a classe CntrAutenticacao é abstrata e implementa IRAutenticacao; Driver é uma classe da associação entre CntrPersistenciaRelacional e Conexao; o método conectar da classe CntrPersistencia é protegido e visível a partir de código que esteja presente no método desconectar da classe CntrPersistenciaRelacional.

O SOAP encapsula mensagens que podem ser transmitidas via HTTP; permite o modelo de interação cliente-servidor; define como usar XML para representar mensagens de requisição e resposta. Um documento XML é transportado no corpo de uma mensagem SOAP; no modelo cliente-servidor, o corpo de uma mensagem SOAP pode conter uma requisição, mas não uma resposta.

Se uma classe abstrata declara uma interface, essa classe tipicamente contém declarações de métodos, mas não corpos de métodos; a interface não pode ser implementada por classes que herdem da classe abstrata. Em diagramas UML, a classe abstrata pode ser identificada colocando-se seu nome em itálico, e relacionamentos de dependência podem ser representados por setas tracejadas entre clientes da interface e a classe abstrata.