Clasificación de clases



Descargar 6,75 Kb.
Fecha de conversión07.05.2017
Tamaño6,75 Kb.

CLASIFICACIÓN DE CLASES

<> (entidad)

  • Representan una situación de dominio específico u objeto del mundo real.
  • Gran número de atributos.
  • Muchas propiedades primitivas. (getAttr(), setAttr(), etc.).
  • No muchas operaciones complejas.
  • Pocos estados de ciclo de vida o secuencias de estado simples.
  • Ej. Cliente, Contrato, Dirección, etc.

<>

  • Representan un proceso laboral, de control o de cálculo.
  • Pocos o ningún atributo propio.
  • Poco tiempo de vida transitorio (ej. durante el tiempo del proceso que controlan).
  • Acceso a un conjunto de clases entidad, de las cuales solicitan datos o llaman operaciones elementales y les regresan los resultados.
  • A veces no tienen estados.
  • A veces tienen modelos de estado complejos.

<> (interfaz)

  • Definiciones abstractas de interfaces puramente funcionales.
  • No atributos ni asociaciones.
  • No tienen instancias.
  • Definen conjunto de operaciones abstractas.
  • Definen precondiciones y poscondiciones, invariantes y excepciones para estas operaciones.
  • Ayuda a dividir desarrollo de software entre diferentes equipos.
  • Mismos nombres que las clases entidad y control, y generalmente implementadas por éstas.

<> (interface object) (frontera – objeto de interfaz)

  • Representan una compilación de propiedades de otros objetos que son frecuentemente requeridos en común o que de otra manera tendrían que ser distribuidas sobre un gran número de objetos individuales.
  • Ej. VistadeCliente (como resumen de Cliente, Cliente.Dirección, Cliente.DestallesdeBanco, etc.).

<> (interface object) (frontera – objeto de interfaz)

  • Tienen atributos que casi todos son y pueden ser derivados.
  • Los atributos son solo para almacenamiento intermedio de atributos de entidades o resultados de control.
  • No persistentes.
  • Ninguna operación propia, hacen llamadas de operación.
  • No tienen estado.

<> (tipo)

  • Definen un conjunto de operaciones y atributos. Como las interfaces, son definiciones abstractas, pero también pueden contener atributos y relaciones.
  • Definen atributos y operaciones abstractas.
  • Asociaciones a otros tipos.
  • Mismos nombres que las clases entidad y generalmente implementadas por éstas.
  • Modelos de análisis consisten de los tipos.
  • Convenientes para describir roles de objetos dinámicos.

<
> (primitiva)

  • Representan clases elementales del lenguaje de programación en uso.
  • Representan clases estándar de los frameworks en uso.
  • No persistentes.
  • Pocas operaciones simples para leer y escribir.
  • A veces con algunas funciones de cálculo simples.
  • Pueden contener operaciones de conversión a otras primitivas.
  • Aparecen en la declaración de atributos.
  • No asociaciones a o de clases primitivas.

<
> (primitiva)

  • <
    >
  • Money
  • amount: Double
  • currency: Currency
  • ConvertTo(otherCurrency): Money
  • getAmount(): Double
  • getCurrency(): Currency
  • setAmount(amount: Double)
  • setCurrency(currency: Currency)
  • Clase primitiva:

<> (enumeración)

  • Conjunto de valores que pueden expresarse como listas.
  • Configurables. Modificados rara vez.
  • Usados en la declaración de atributos (como las clases primitivas). Guardan solo la referencia a un valor específico.
  • Validez limitada en términos de tiempo.
  • Tienen una secuencia configurable de valores individuales, visible en listas de selección. A veces consisten en un solo valor tratado como enumeración por su simplicidad.

Enumeración:

  • <>
  • MaritalStatus
  • single
  • married
  • cohabiting
  • divorced
  • widowed
  • asString(): String
  • <> (enumeración)

<> (estructura)

  • Las estructuras de datos son empleadas para intercambiar datos con otros (sub)sistemas. Para definir tales formatos de intercambio de datos, las clases pueden ser usadas con el estereotipo <>.
  • Contienen solo atributos y no operaciones (similares a los tipos sin operaciones).

Bibliografía:

  • Developing software with UML.
  • Object-oriented analysis and design in practice.
  • Bernd Oestereich.
  • pág. 50 - 56


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal