CLASIFICACIÓN DE CLASES Orientación a objetos UNIVERSIDAD DEL VALLE DEL FUERTE Análisis y Diseño Orientado a Objetos Cañedo Encinas Fernando Onorat. Ingeniería en Sistemas Computacionales 3° Semestre

> (entidad) > (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.

<<control>> 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) > (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) > (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) > (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) > (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) > (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.

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

> (enumeración) > (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) > (enumeración)

> (estructura) > (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