Glosario de Conceptos TRAD (Taller de Requerimientos Análisis y Diseño) © Vilalta Consultores 2000 Arquitectura de aplicaciones centrada en Casos de Uso Notación UML 1.3 Rev.: 3.4 Junio 2000

Concepto	Concept	Descriptor
Actor	Actor	Agente o sistema externo que interactua con el sistema. Entra, manipula o recibe información del sistema, pero es externo al sistema. Puede ser una persona o una aplicación externa que intercambia datos con el sistema.
Análisis	Analysis	Proceso que mapea la percepción de una realidad hasta su representación formal en modelos siguiendo una metodología concreta.
Atributo	Attribut	Característica que describe la naturaleza esencial de un objeto describiendo sus propiedades intrínsecas (la esencia) y sus propiedades variables (la contingencia). Un documento requiere disponer de una identidad concreta para reconocerlo como tal (forma parte de su esencia), también puede disponer de un determinado número de páginas, pero este atributo forma parte de su contingencia.
Caso de Uso	Use Case	Es una pieza de funcionalidad bien delimitada y reutilizable que da valor a n Actores que interactuan con el sistema.
Caso de Uso: Actividad	Activity	Unidad de trabajo dentro del flujo principal de eventos de un Caso de Uso que dispone de variaciones y excepciones.
Caso de Uso: Arquitectura centrada en	Use Case architecture driven	En una arquitectura centrada en Casos de Uso podemos definir la granularidad del sistema a desarrollar, es decir, podemos organizar visualmente su complejidad y establecer una trazabilidad efectiva desde el modelo de funcionalidad hasta el despliegue de componentes por una red.
Caso de Uso: Estados	Use Case state	Un Caso de Uso puede disponer de los siguientes estados: Identificado Certificado Planificado Programado Implementado
Caso de Uso: Ficha LIMIT®	LIMIT® Card	Plantilla de ficha diseñada para documentar los distintos elementos y estados de un Use Case.
Caso de Uso: Factor de ajuste para su implementación (FACA)	Use Case implementation hours adjusted (UCIHA)	Elementos necesarios para ajustar las horas calculadas para implementar un Caso de Uso. TRAD pondera tres factores: Plataforma de desarrollo Framework de servicios comunes Nivel de experiencia del equipo de desarrollo
Caso de Uso: Flujo de Eventos	Event Flow	Secuencia determinada de actividades con sus variaciones posibles y sus excepciones probables.
Caso de Uso: Granularidad	Granularity	Nivel de descomposición de un Caso de Uso principal en Casos de Uso secundarios: <<Include>> UC secundarios que se utilizan de manera sistemática <<Extend>> UC secundarios que se utilizan de manera opcional cuando se cumplen ciertas condiciones. <<Generalization>> UC secundarios que son especializaciones de otro UC con alguna variación concreta
Caso de Uso: Lote	Build	Agrupación de Casos de Uso que forma parte de una iteración y dispone de una prioridad de implentación.
Caso de Uso: Modelo	Use Case Model	Misión del modelo Caso de Uso: Comunicar, describir y verificar el conjunto de requerimientos y reglas de negocio que expresan la funcionalidad y el valor de un sistema para los actores que interactuan con el Compartir un lenguaje común entre todos los agentes involucrados en el desarrollo del sistema Organizar la complejidad de un sistema para una mejor comprensión de su naturaleza y dinámica
Caso de Uso: Ejemplos de nombres	Use Case naming	UC Definir Cliente UC Localizar Cliente UC Definir Perfil de Cliente UC Consultar Situación de Cliente UC Realizar un Pedido UC Actualizar Perfil de Cliente UC Generar Documento de Venda UC Abrir Arqueo UC Cerrar Arqueo UC Validar Requisitos Admisión UC Calcular Importe de Matrícula
Caso de Uso: Elementos	Use Case Elements	Propósito Actores Activadores Precondiciones Actividades (dentro de un flujo de eventos) Escenarios (instancias de un Caso de Uso en función de los distintas variaciones posibles) Interfaces (sistemas externos e interfaces gráficas de usuario) Objetos Clases de dominio Clases de diseño
Caso de Uso: Estimación de horas de implementación (HICA)	Use Case implementation hours estimate (UCIH)	Elementos necesarios para calcular las horas requeridas para implementar un Caso de Uso. TRAD pondera tres factores: Factor del Flujo de Eventos Factor de la Interface Gráfica de Usuario Factor de las Clases de Dominio
Casos de Uso: Censo	Use Case check list	Relación de Casos de Uso por proceso con su prioridad de implementación y recursos asignados.
Clase	Class	Es una plantilla que nos permite definir propiedades y comportamientos de determinados objetos. Todos los objetos que proceden de una determinada Clase son idénticos en la forma y en su comportamiento, pero contienen diferentes datos en sus variables. Permite implementar herencia dentro de una jerarquía de clases.
Clase de diseño	Design classes	Muestra los mecanismos de implementación de la Clase de dominio modelada en un Caso de Uso.
Clase de dominio	Domain classes	Conjunto de Objetos que comparten: Las mismas propiedades (Atributos) Mismo comportamiento (Operaciones/Métodos) Mismas relaciones con otros objetos (Asociaciones y agregaciones) Misma semántica dentro del dominio Una Clase representa una plantilla para crear Objetos. Cada Objeto es una instancia de alguna Clase. Los Objetos no pueden ser instancias de más de una Clase. Una buena Clase captura una única y exclusiva abstracción.
Clases: Ejemplos	Class samples	CLIENTE VENTA PAGO PERSONA INTERFACE DE USUARIO RECIBO FACTURA PEDIDO LINEA DE PEDIDO ARQUEO DE CAJA
Componentes principales del Taller	Workshop rules, representations and framework	Unidad de Conocimiento (Package – building block) Casos de Uso Objetos Mensajes Clases Reglas de representación (UML) Reglas de juego (Magister Ludi)
Concepto	Concept	Configura nuestra percepción de la realidad. Es una unidad de conocimiento que dispone de dos propiedades: Intensión.- Es la definición completa de un concepto y el test que determinará si un concepto representa a un objeto concreto (una buena abstracción). Extensión.- Es el conjunto de todos los objetos a los que un concepto es aplicable.
Diseño	Design	Proceso que mapea la representación de una realidad a la expresión de su implementación, es decir, desde la formulación de un problema a la solución.
Escenario	Scenario	Instancia de un Caso de Uso donde se muestran las responsabilidades e interacciones de los Objetos que participan en una secuencia concreta de actividades.
Evento	Event	Cambio digno de mención de un estado a otro.
Herencia	Inheritance	Mecanismo por el cual ciertas Clases pueden hacer uso de métodos y atributos definidos en otras Clases que comparten distintos niveles de su jerarquía.
Iteración	Iteration	Conjunto de tareas y entregables que producen la versión de un ejecutable.
Mensaje	Message	Señal enviada desde un objeto emisor a otro objeto receptor para que éste lleve a cabo uno de sus métodos. Un mensaje consta de tres partes: El mombre del objeto receptor. El nombre del método que tiene que activarse. Los parámetros necesarios para llevar a buen término la operaciones del método.
Método	Method	Operación o procedimiento definido que puede llevar a cabo una Clase. El conjunto de métodos de una Clase configura sus responsabilidades dentro del dominio.
Metodología	Methodology	Una metodología dispone de los siguientes elementos: Proceso.- Guía paso a paso de las actividades a realizar. Criterios.- Reglas básicas que son necesarias para evaluar el resultado del proceso. Notación.- Especificaciones para modelar visualmente el resultado del proceso.
Objeto	Object	Representación de una entidad del mundo real o inventada. Un objeto es un concepto, una abstracción de algo que dispone de unos límites bien definidos y tiene una significación para el sistema que se pretende desarrollar. Un objeto es una instancia de una Clase (Dicha Clase actua como una plantilla para fabricar objetos). Un objeto encapsula datos (atributos) y procedimientos (operaciones y métodos)
Objeto: Definición	Object definition	Para cada objeto identificado tiene que definirse: Identidad (¿Quién soy?) Propósito (¿Cual es mi misión?) Responsabilidades (¿Qué debo hacer?) Procedencia (¿De que estructura de Clases provengo?) Relaciones con otros objetos (¿Qué mensajes intercambio con otros objetos?)
Objeto: Estrategias de identificación	Object find out strategies	Actores y agentes participantes.- Cajero Cliente Usuario Supervisor Proveedor Transportista Comisionista Lugares.- Establecimiento (Tienda, Restaurante, etc.) Oficina de atención al público Almacen de artículos de venta Centro académico Organizaciones.- Compañía aerea Universidad Entidad Bancaria Departamento Comercial Cosas tangibles.- Terminal Punto de Venta Cajón de la máquina registradora Producto Cajero automático Cosas no tangibles, servicios.- Linea de crédito Acción de bolsa Discriminador de urgencias Puja de subasta Beca Calificación Visita médica Cambio de aceite Escandallo Documentos físicos o virtuales.- Catálogo de artículos Lista de Alumnos Plan Contable Tira de Arqueo Cuenta corriente Diario de IVA Cartera de efectos Recibo Contrato laboral Carnet de estudiante Diario de incidencias Historial de versiones de un Acta Especificaciones, reglas, diseños o descripciones.- Especificación de un producto Reglas de negocio (Devoluciones, Cancelaciones, etc.) Reglas de creación de un producto/servicio Reglas de estructura Requisitos de admisión Reglas de comportamiento Manual de procedimientos Manual de seguridad Transacciones.- Venta Pago Reserva Préstamo Traslado de almacen Subscripción Subasta Items de una transacción.- Item linea de venta Item linea de traslado de almacen Importe de matrícula Eventos.- Venta Retirada de efectivo Error de sistema Compra Autorización de pago Cancelación del vuelo Programación de una cita Realización de una cita Certificación académica Ingreso hospitalario Conceptos ligados a procesos.- Actualizador de expediente Actualizador de perfil de cliente Controlador de requisitos Asignador de recursos planificados Marcador de artículos, apuntes, etc. Agrupador de diagnósticos y procedimientos Alergia Contenedores de otras cosas.- Recipiente Autocar Camión de transporte Unidad de Urgencias Items de un contenedor.- Elemento de un recipiente Pasajero Paquete Box de Urgencias Categorías de cosas.- Caducidad de un producto Tipo de impuesto aplicable Alimento congelado (Tipo de conservación) Tipo de Préstamo Tipo de trabajo Tipo de subasta Diagnóstico médico (Interpretación de una realidad) Procedimiento quirúrgico Procedimiento terapéutico
Objeto: características	Object characteristics	Estado.- Indica una de las posibles condiciones en que puede existir. El estado de un objeto varía con el tiempo y se define por un conjunto de propiedades que denominamos atributos o variables. Comportamiento.- Indica cómo reacciona en la interacción con otros objetos. Identifica las operaciones o métodos que puede realizar un objeto. Identidad.- Indica que aquel objeto es único, aunque disponga de un estado idéntico a otros objetos.
Objetos: Ejemplos	Object samples	Cliente xxx Pago en metálico xxx Establecimiento xxx Sesión de arqueo xxx Recibo de venta xxx Ventana para registrar venta xxx Usuario xxx Transacción de Venta xxx Categoria de impuesto Matrícula Curso xxx Importe de la venta xxx Item de venta xxx Factura de venta xxx Pedido xxx Linea de pedido xxx Tira de arqueo xxx
Polimorfismo	Polymorphism	Capacidad de esconder diferentes implementaciones detrás de un mismo interface, simplificando así las comunicaciones entre objetos. Por ejemplo: Si definimos un único método de <<Imprimir>> para cada tipo de documento en un sistema, esto implicará que podremos ordenar la impresión de cualquier documento enviando sólo el mensaje <<Imprimir>>, sin preocuparnos de cómo se llevará a cabo dicho método para un documento dado.
Proceso	Process	Conjunto relacionado de Casos de Uso que da valor a n Actores.
Recurso	Resource	Elemento que se usa o consume para dar soporte a la realización de un proceso. Las actividades consumen o utilizan recursos de: Información Tiempo Personas Tecnología Infraestructura
Requerimiento funcional	Functional Requirement	Funcionalidad que el sistema ha de cumplir para dar valor y satisfacer las necesidades de un Actor. Ej.- Validar requisitos de matrícula Localizar artículos ABC Bloquear facturas Conciliar apuntes bancarios pendientes
Requerimiento no funcional	Non Functional Requirement	Condiciones que el sistema ha de cumplir para dar valor y satisfacer las necesidades de un Actor. Ej.- Rendimiento Seguridad Portabilidad Interoperabilidad
Rol de aplicación	Application Rol	Papel que desarrolla un Actor cuando interactua con el sistema: Competencias.- Privilegios de acceso Habilitaciones Limitaciones Funciones.- Autor de información Lector de información Manipulador de información Responsabilidades.- Sobre la información Sobre el flujo de trabajo Sobre el sistema
Taller (Esquema didáctico)	Workshop	Unidad Didáctica (x) Sección (x) Fundamentos (Rationale) Materiales necesarios (Materials Needed) Conocimientos necesarios (Skills Involved) Glosario de conceptos (Important Vocabulary) Ejemplos (Examples) Procedimiento (Procedure) Prácticas (Practice) Tareas (Tasks) Situación (Situation)
UML	Unified Modelling Language	Unified Modelling Language. Notación estandar que permite modelar visualmente todos los procesos implicados en el análisis, diseño y desarrollo orientado a objetos de un sistema. Última revisión en uso: 1.3 (1999)