Classe é uma descrição de um conjunto de objetos que compartilham as mesmas responsabilidades, relacionamentos, operações, atributos e semântica.  
Outros Relacionamentos:  Parte de Modelo de Design
Função:  Designer  
Opcionalidade/Ocorrência:  Classes de Design são uma parte fundamental de uma abordagem de design orientada a objetos.
Gabaritos e Relatórios: 
     
Exemplos: 
     
Representação em UML:  Classe.
Informações Adicionais:   
Entrada de Atividades:    Saída das Atividades:   

Finalidade Para o início da página

As seguintes pessoas usam as classes:

  • Implementadores, para obter uma especificação quando implementam as classes.
  • Designers de outras partes do sistema, para compreender como sua funcionalidade pode ser utilizada e o que significam suas relações.
  • Designers de casos de uso, para instanciá-las nas realizações de casos de uso.
  • Aqueles que projetam a próxima versão do sistema, para entender a funcionalidade no modelo de design.
  • Aqueles que testam as classes, para planejar atividades de teste.

Propriedades Para o início da página

Nome da Propriedade 

Breve Descrição 

Representação em UML 

Nome  O nome da classe.   O atributo "Nome" no elemento do modelo. 
Breve Descrição  Uma breve descrição do papel e da finalidade da classe.   Valor ativado, do tipo "texto curto". 
Responsabilidades  As responsabilidades definidas pela classe.   Um valor marcado (predefinido) na superclasse "Tipo". 
Relacionamentos  Os relacionamentos (como generalizações, associações e agregações) dos quais a classe participa.   Adquiridos por um pacote limitado, por meio da agregação "possui". 
Operações  As operações definidas pela classe.   Adquiridas pela superclasse "Tipo" por meio da agregação "membros". 
Atributos  Os atributos definidos pela classe.   - " - 
Requisitos Especiais  Uma descrição textual que reúne na classe todos os requisitos (como os não-funcionais, por exemplo), que não são considerados no modelo de design mas precisam ser observados durante a implementação.   Valor ativado, do tipo "texto curto". 
Diagramas  Qualquer diagrama local para a classe, como diagramas de interações, classes ou de estados.   Adquiridos por um pacote limitado, por meio da agregação "possui". 

Sincronização Para o início da página

As classes de design significativas do ponto de vista da arquitetura são identificadas e descritas durante a fase de elaboração. As classes de design restantes são identificadas e descritas durante a fase de construção.

Responsabilidade Para o início da página

O designer é responsável pela integridade da classe, garantindo que:

  • A classe atenda aos respectivos requisitos, provenientes das realizações de casos de uso das quais participa.
  • A classe seja o mais independente possível das outras classes.
  • As propriedades da classe (inclusive suas responsabilidades, relacionamentos unidirecionais, operações e atributos) estejam justificadas e consistentes entre si.
  • O papel da classe nos relacionamentos bidirecionais em que está envolvida seja claro e intuitivo.
  • As visibilidades de seus participantes, principalmente operações e atributos, estejam corretas. Uma visibilidade pode ser "pública", "privada" e assim por diante.
  • O escopo de seus participantes, principalmente operações e atributos, estejam corretos. Um escopo será "verdadeiro" se for de tipo/classe e "falso" se for de objeto/instância.
  • Os Requisitos Especiais sejam legíveis e adequados às suas finalidades.
  • Os diagramas que descrevem a classe sejam legíveis e consistentes com as outras propriedades.

É recomendável que o designer responsável por uma classe também seja responsável por seu pacote de design incluído; para obter informações adicionais, consulte Pacote de Design.

Adaptação Para o início da página

Estereótipos podem ser utilizados para qualificar classes de design ou para limitar a implementação de alguma forma. Por exemplo, um estereótipo pode ser utilizado para indicar que a classe representa a construção de uma determinada linguagem de programação.

Consulte Diretrizes: Classe de Design para obter informações adicionais.



Rational Unified Process   2003.06.15