Objeto.

Concepto, abstracción o cosa con fronteras bien definidas y significado para

el manejo del problema.
Clase. Una clase representa a un conjunto de objetos que comparten estructura y
comportamiento común.
Herencia. Es el proceso por el cual un objeto adquiere las propiedades de otro.
Encapsulamiento. Permite unir el código junto con los datos que manipula y los
mantiene a salvo de las interferencias externas.
Polimorfismo. Mecanismo que permite tener varios métodos o constructores con
el mismo nombre.
Clase Abstracta. Son clases definidas que no pueden instanciarse y que sólo
recogen las características de otro conjunto de clases, tampoco crean objetos, pero
pueden incluir variables y métodos no abstractos. Se utilizan cuando dos o más
subclases cumplen un papel similar a través de distintas implementaciones.
Relación entre clases.

Asociación. Es una relación estructural que expresa la conexión recíproca entre dos
clases entre objetos de dos clases distintas. Tipo débil de conexión y ocurre cuando
los objetos son parte de un grupo pero no dependen completamente entre ellos. Ej.
Automóvil y dos pasajeros.

NICOLÁS SANTIAGO J. FERNANDO | MAT. 2153045617 | LIC. COMPUTACIÓN | UEA: PÁG.

Agregación. Relación todo/partes en donde una clase representa el todo y otra una
de sus partes, se realiza declarando referencia dentro de los atributos además
implica que un objeto contiene a otros objetos. Es una relación más fuerte que la
asociación. Ej. Casa y sus habitantes.

Composición. Es una forma de agregación pero más fuerte, el todo y las partes
tienen tiempos de vida paralelos: el todo y las partes no puede existir de forma
independiente, las partes sólo pueden estar agregados a un todo. Ej. Coche-Partes

Dependencia. Relación más débil que asociación, éste ocurre cuando dos objetos
de clases distintas interaccionan de forma temporal, en el código ocurre cuando un
objeto invoca a otro al interior de uno de sus métodos. Ej. Ticket-Producto,
Espectáculo-Fecha, Curso-Horario.
 <<créate>> Crea una instancia de la clase a la cual apunta.
 <<call>> Invoca métodos del objetos (de la clase) que apunta.

NICOLÁS SANTIAGO J. FERNANDO | MAT. 2153045617 | LIC. COMPUTACIÓN | UEA: PÁG.

LENGUAJE DE MODELO UNIFICADO (UML)
Modelo. Es una abstracción semántica muy cercana al sistema que se va a
construir. El modelo también tiene que describir las interacciones entre el sistema y
su ‘alrededor’
UML. Es un lenguaje gráfico para especificar el modelo de un sistema. Se detallan
los artefactos en el sistema, se documenta y se especifica la construcción
Diagrama de clases.
Describe la estructura del sistema por medio de las clases del sistema, sus atributos
y las relaciones entre las clases.

Diagrama de objetos.
Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama
de clase, no muestran la multiplicidad ni los roles, aunque su notación es similar a
los diagramas de clase.
Son muy útiles en la comprensión de diagramas de clases complejos, al crear
diferentes casos en los que se aplican las relaciones y las clases.

NICOLÁS SANTIAGO J. FERNANDO | MAT. 2153045617 | LIC. COMPUTACIÓN | UEA: PÁG.

Diagrama de Componentes
Un diagrama de componentes representa cómo un sistema de software es dividido
en componentes y muestra las dependencias entre estos componentes. Los
componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas,
módulos, ejecutables, paquetes, tablas, archivos, y documentos que formen parte
del sistema.
Los diagramas de Componentes prevalecen en el campo de la arquitectura de
software pero pueden ser usados para modelar y documentar cualquier arquitectura
de sistema.

NICOLÁS SANTIAGO J. FERNANDO | MAT. 2153045617 | LIC. COMPUTACIÓN | UEA: PÁG.

Diagrama de paquetes.
Muestra cómo un sistema está dividido en agrupaciones lógicas mostrando las
dependencias entre esas agrupaciones. Normalmente un paquete está pensado
como un directorio suministran una descomposición de la jerarquía lógica de un
sistema.
Los Paquetes están
normalmente organizados
para maximizar la coherencia
interna dentro de cada
paquete y minimizar el
acoplamiento externo con los
otros paquetes. Los paquetes
son buenos elementos de
gestión, cada paquete puede
asignarse a un individuo o a
un equipo, las dependencias
entre ellos pueden indicar el
orden de desarrollo requerido.

Comportamiento. Describe la funcionalidad proporcionada por el sistema en

términos de sus actores, sus metas representadas como casos de uso y las
dependencias entre ellos.
Caso de uso. Representa las
actividades que los actores
realizan con la ayuda del
sistema. Es la representación
más simple de la interacción
de un usuario con el sistema,
es decir, un ‘uso’ que hace el
usuario del sistema.

NICOLÁS SANTIAGO J. FERNANDO | MAT. 2153045617 | LIC. COMPUTACIÓN | UEA: PÁG.

 1. Actor. Es una clase de usuario, organización, dispositivo, componente de
software o sistema externo que interactúa con el sistema. Los actores del
ejemplo son Cliente, Restaurante, otros: Sensor de temperatura o Titular de
tarjeta de crédito.
2. Caso de uso. Representa las acciones que uno o varios de los actores
realizan a fin de conseguir un objetivo determinado. “Uso” de la funcionalidad
que debe ofrecer el sistema/aplicación. Los casos de uso del ejemplo son
Pedir menú, Actualizar menú y Procesar pago.
3. Asociación. En un diagrama de casos de uso, están asociados a los actores
que los realizan.
4. Sistema. Es aquello que se está desarrollando (un pequeño componente de
software, cuyos actores simplemente fueran otros componente de software,
un gran conjunto de aplicaciones que se implementan en muchos equipos y
dispositivos).
Un caso de uso es acompañado de:
 Caso de uso en texto natural.
 Otros diagramas – estado y actividades.
Modelo de casos de uso. Describe la funcionalidad proporcionada por el sistema
en términos de:
 Sus actores.
 Sus metas representadas como caso de uso.
 Las dependencias entre los casos de uso.
Su objetivo es resumir quién usa el sistema y qué pueden hacer con él, apoyan al
analista en decidir:
 Los escenarios en los que el sistema o aplicación interactúa con personas,
organizaciones o sistemas externos.
 Las actividades que el sistema o aplicación ayuda a realizar.
 El ámbito del sistema.
Multiplicidad entre actores y casos de uso.
 La asociación entre un actor y un caso de
uso puede mostrar una multiplicidad en
cada extremo.
 Las multiplicidades de una asociación de un
diagrama de casos de uso se ocultan si las
dos tienen el valor1.

NICOLÁS SANTIAGO J. FERNANDO | MAT. 2153045617 | LIC. COMPUTACIÓN | UEA: PÁG.

Herencia entre actores.
 Se dibuja un vínculo de generalización
entre actores.
 La punta de flecha apuntaría al actor más
general.
 Actor especializado
 Hereda los casos de uso del actor
general.
 Pueden tener casos de uso propios
que no están disponibles a otros
actores.
Generalización: Compartir los objetivos del caso de uso
Generalización. Expresa que un caso de uso especializado
constituye un mecanismo específico para conseguir los
objetivos expresados por otro caso de uso general. La punta
de flecha abierta debe apuntar al caso de uso más general.
 Los casos de uso especializados heredan los objetivos y actores del caso de
uso general.
 El caso de uso general no tiene que tener escenarios propios:
 Sus especializaciones describen diferentes mecanismos para
conseguir los objetivos.
Inclusión. Representa que en un caso de uso se describen algunos detalles de otro
caso de uso.

NICOLÁS SANTIAGO J. FERNANDO | MAT. 2153045617 | LIC. COMPUTACIÓN | UEA: PÁG.

Inclusión: Mostrar detalles del caso de uso.
 Cada uno de los casos incluidos, son más detallados y constituyen un paso
que el actor o actores tendrán que llevar a cabo para conseguir el objetivo
global del caso de uso que los contiene.
 La flecha debería apuntar al caso de uso más detallado, que es el que está
incluido en otro. En la ilustración, “Pedir un menú” incluye “Pagar”, “Elegir
menú” y “Elegir elemento del menú”.
 Se puede compartir casos de uso incluidos.
El objetivo y los escenarios de un caso de uso incluido deberían tener sentido por
sí mismos:
 Podrían incluirse en otros casos de uso.
Resulta útil para conseguir los siguientes objetivos:
 Estructurarlas descripciones del caso de uso en diferentes niveles de detalle.
 Evitar repetir escenarios que distintos casos de uso comparten.
Extensión: Descomponer un caso de uso.
 Describe cuando un caso de uso agrega funcionalidad a otro.
 La flecha debería apuntar al caso de uso principal extendido.
 Incluye los pasos del escenario que formarían parte de los escenarios del
caso de uso principal.
El caso de uso ‘Inicio de sesión’ de un sitio web normal puede incluir ‘Registrar
nuevo usuario’ (Solamente cuando el usuario todavía no tiene una cuenta)

Utilice ‘Extensión’ cuando:

 Actores adicionales que solamente están implicados en el caso de uso de
extensión (Ej. Cuando es necesario que un administrador apruebe el registro
de un cliente en el sitio web).
 Un subsistema independiente se ocupará del caso de uso de extensión.
Cómo descomponer un caso de uso en elementos principales y de extensión:
 Crear el nuevo caso de uso de extensión y asígnele un nombre.
 Crear una relación de extensión; la flecha deberá apuntar al caso de uso
extendido.

NICOLÁS SANTIAGO J. FERNANDO | MAT. 2153045617 | LIC. COMPUTACIÓN | UEA: PÁG.

  Si ya se ha creado los escenarios del caso de uso extendido, transferir los
pasos pertinentes al escenario de la extensión.
 La descripción de la extensión debe incluir los detalles acerca de en qué lugar
de los escenarios de caso de uso principal va a producirse y en qué
circunstancias: Entendida como una modificación de la descripción del caso
principal.
Límites del sistema.
 Utilizar un límite de subsistema para mostrar qué casos de uso están dentro
del ámbito del sistema.
 Útil incluir en el diagrama los casos de uso que forman parte del negocio pero
NO tienen relación con el sistema que se está desarrollando: Ej. Enviar menú,
fuera del alcance del sistema web

¿Cómo definir un caso de uso?

 Cree casos de uso para cada uno de los objetivos que los actores pretendan
conseguir con el sistema.
 Identifique los actores en función de su tipo o rol.
o Los roles son distintos de persona físicas: empleado, administrador
pueden ser la misma persona física.
o No utilizar títulos que tengan relación con el código (Ej. Pedir menú,
Pagar menú, Entregar menú)

NICOLÁS SANTIAGO J. FERNANDO | MAT. 2153045617 | LIC. COMPUTACIÓN | UEA: PÁG.

  Comenzar con las transacciones principales, como Pedir menú.
o Posponga para más adelante las transacciones más pequeñas, como
Elegir elemento del menú.
 Puede dibujar un caso de uso fuera del límite de sistema.
 Utilice las asociaciones para vincular los actores con los caso de uso.
 Estructure los casos de uso con las relaciones Include, Extend y
Generalization.
 Describa los caso de uso con más detalle (Utilice la plantilla de
documentación de caso de uso).
 Deben empezar por los más simples y en el nivel más alto posible
(únicamente pueden ser refinados y detallados más adelante).
 Los diagramas de casos de uso son basados en funcionalidades y por tanto
deben centrarse en el ‘qué’ y no en el ‘cómo’.
Regla de Negocio.
Es una declaración que rige el funcionamiento de algún aspecto del negocio como
política a cumplirse, condición a satisfacer, restricción a cumplir o evitar. Ej.
 El cliente debe ser titular de la cuenta para retirar dinero por ventanilla.
 El otorgamiento de las becas se da si el alumno ha obtenido un promedio
superior a 15 puntos.
 El alumno se puede inscribir una asignatura si no ha reprobado la asignatura
previa en el árbol de seriación (2 ° Examen).
Objetivo de Negocio.
 Mejorar el seguimiento de los estudiantes para incrementar para incrementar
la comunicación entre la universidad y el alumno (2° Examen).
 En el sitio de TicketMaster: Incrementar promociones.
Pre-Condiciones.
Describir aquellas condiciones que deben ser verdaderas antes de la ejecución del
caso de uso. Ej. (CU. Elegir Evento) El sistema ha desplegado una ventana
mostrando las categorías de los eventos, permitiendo la selección de alguna
categoría.
Post-Condiciones.
Describir aquellas condiciones que deben ser verdaderas después de la ejecución
(exitosa) del caso de uso.

NICOLÁS SANTIAGO J. FERNANDO | MAT. 2153045617 | LIC. COMPUTACIÓN | UEA: PÁG.

Ej. El cliente de TicketMaster ha elegido un evento y el sistema ha desplegado el
mapa del foro, el precio de boletos por defecto, descripción del evento, las ventanas
para selección de secciones y número de boletos, para el evento seleccionado. Y
debe mostrar una opción para cambiar de evento en el mismo foro.
Flujo Principal.
Describir la interacción que ocurre entre el actor y el sistema para alcanzar el
propósito explicado en la descripción. La descripción se realiza como una serie
consecutiva y numerada de acciones que son iniciadas ya sea por el actor o bien
por el sistema. Consideraciones:
 Generalmente, la primera acción la realiza el sistema si el usuario realizó una
acción en el disparador.
 Se sugiere evitar varias acciones consecutivas que sean iniciadas por la
misma entidad (actor o sistema).
 La descripción del flujo no debe detallar el diseño de la solución y tampoco
poner requerimientos muy detallados que más bien se ponen en la sección
de requerimientos funcionales detallados.
 Si se incluye otro caso de uso, hacer referencia a este a través de su
identificador
Flujos Alternativos.
En caso de que suceda algo inesperado en el flujo principal pero que al final permita
terminar el caso de uso de forma exitosa (alcanzar el objetivo), se documenta como
flujo alternativo. El flujo alternativo debe decir en qué punto del flujo principal inicia
y en qué punto del flujo principal retoma.
Flujos Excepcionales.
En caso de que suceda algo inesperado en el flujo principal y que no permita
terminar el caso de uso de forma exitosa (no se alcanza el objetivo), se documenta
como flujo excepcional. El flujo excepcional debe decir en qué punto del flujo
principal inicia.
REQUERIMIENTOS
Dominio del problema.
1. Identificar los objetivos de negocio (Ej. En el sitio de TicketMaster:
Incrementar promociones)
2. Identificar las necesidades (Ej. 1. Colectar métricas de ventas por tipo de
evento, por día de la semana, por temporada. 2. Planificar promociones. 3
Planificar descuentos).

NICOLÁS SANTIAGO J. FERNANDO | MAT. 2153045617 | LIC. COMPUTACIÓN | UEA: PÁG.

 3. Identificar las características del sistema (Ej. 1. El sistema debe calcular
métricas de ventas de tickets por: Evento, día de la semana, temporada del
año. 2. El sistema debe permitir gestionar promociones. 3. El sistema debe
desplegar promociones en el sitio web).
Requerimientos Funcionales (RF)
Describen las funciones que el software va a ejecutar, generalmente expresadas en
una declaración verbal. Algunas veces son llamados capacidades del software. Se
clasifican de la siguiente forma:
Requisitos de negocio.
Describen restricciones, reglas o políticas del negocio que deben ser respetadas
por el sistema a desarrollar. Ejemplos:
 Calcular el interés neto generado en un mes.
 Obtener promedio general del alumno.
 Calcular el IVA de todos los productos vendidos en un mes, etc.
Requisitos de conducta.
Describen los servicios que debe ofrecer el sistema para que los usuarios u otros
sistemas puedan realizar sus tareas de negocio. Si son servicios con una gran
interactividad se suelen describir como caso de uso. Ejemplos:
 El sistema deberá imprimir a petición de los usuarios, un listado de
contribuyentes cuyo resultado ‘a devolver’ del IRPF supere los 3000 euros.
 Formatear algún texto.
 Gestionar un usuario (alta, baja, cambio).
 Administrar un dispositivo.
Requisitos de información.
Describen qué información debe almacenar el sistema para poder ofrecer los
servicios necesarios, también deben identificar el concepto relevante sobre el que
se debe guardar información, además los datos específicos relativos al concepto.
Ejemplos:
 El sistema debe almacenar los movimientos generados en la cuenta.
 El sistema debe procesar el expediente del alumno.
 El sistema debe mantener el registro de los contribuyentes de los 5 años
anteriores.

NICOLÁS SANTIAGO J. FERNANDO | MAT. 2153045617 | LIC. COMPUTACIÓN | UEA: PÁG.

Requerimientos No-Funcionales (RNF)
Son una característica del sistema, del proceso de desarrollo, o de cualquier
aspecto del desarrollo del software. Actúan como una restricción a la solución de
software que se realizará, son conocidos también como los requerimientos de
calidad. Son clasificados en:
Eficiencia.
Define aspectos que indican la proporción entre el nivel de cumplimiento del
software y la cantidad de recursos necesitados bajo condiciones establecidas. Las
sub-características son: Comportamiento en el tiempo, comportamiento según otros
recursos. Ejemplos:
 El sistema debe tener una disponibilidad de 99%.
 El sistema deberá tener un tiempo máximo de respuesta de 5 seg., para
cualquier operación de consulta.
Fiabilidad.
Define aspectos relacionados con la capacidad del software desarrollado para
mantener su nivel de prestación bajo condiciones establecidas y durante un período
de tiempo establecido.
Las sub-características son: Madurez, recuperabilidad, tolerancia a fallos. Ejemplos:
 El sistema debe soportar 100 usuarios concurrentemente.
 El sistema debe tener un plan de recuperación en caso de baja de la base de
datos.
 El sistema deberá tardar un máximo de 10 minutos para la recuperación de
un fallo de caída total, en el 95% de las ocasiones.
Usabilidad.
Define aspectos relacionados con las dificultades que pueden encontrar los
usuarios al enfrentarse al uso del nuevo software. Las sub-características son:
Aprendizaje, comprensión, operatividad, atractividad. Ejemplos:
 El sistema deberá permitir en el 80% de las veces que con un máximo de 5
clics sea suficiente para llegar a la información deseada.
 El sistema debe presentar un entorno gráfico con iconos relacionado al
dominio del problema.

NICOLÁS SANTIAGO J. FERNANDO | MAT. 2153045617 | LIC. COMPUTACIÓN | UEA: PÁG.

Mantenibilidad.
Define aspectos relacionados con la facilidad de ampliar la funcionalidad, modificar
o corregir errores en un sistema software. Las sub-características son: Estabilidad,
facilidad de análisis, facilidad de cambio, facilidad de pruebas. Ejemplos:
 El código fuente que se implemente en JAVA deberá cumplir las
recomendaciones de Code Conventions for the Java Programming
Language.
 El componentes de software deben ser auto-contenidos (modulares)
 El sistema debe presentar un 10% de dependencias entre componentes.
Portabilidad.
Define aspectos relacionados con la capacidad de un sistema software para ser
transferido desde una plataforma a otra. Las sub-características son: Capacidad de
instalación, capacidad de sustitución, adaptabilidad, coexistencia, compatibilidad
con hardware o software, etc. Ejemplos:
 El sistema deberá evitar el uso de extensiones propietarias al estándar SQL-
92 en el sistema de gestión de bases de datos que utilice.
 El sistema debe poder ser instalado en sistemas operativos Linux y Windows.
Seguridad.
Define aspectos relativos a las políticas de privacidad del sistema a desarrollar. Las
sub-características son: Accesos al sistema, identificación y autenticación,
protección de datos y privacidad.
Ejemplos:
 El sistema deberá ser capaz de evitar ataques de inyección de SQL
sistemáticos.
 El sistema deberá proporcionar un módulo de autenticación de usuarios.
 El sistema deberá proteger el dispositivo de almacenamiento de datos de
accesos externos.

NICOLÁS SANTIAGO J. FERNANDO | MAT. 2153045617 | LIC. COMPUTACIÓN | UEA: PÁG.

Restricciones técnicas.
Definen condiciones o limitaciones de diversa índole (industriales, tecnológicas,
metodológicas) que se imponen al proyecto y que impactan tanto en el desarrollo
como en el producto final. Algunas de ellas vienen limitadas por el entorno
tecnológico de la organización donde se va a implantar el software, otras vienen
impuestas directamente por el cliente. Ejemplos:

 El sistema deberá utilizar como sistema de gestión de bases de datos Oracle

11g.
 El sistema deberá ser compatible con los navegadores Internet Explorer 6 y
Mozilla Firefox 3.

NICOLÁS SANTIAGO J. FERNANDO | MAT. 2153045617 | LIC. COMPUTACIÓN | UEA: PÁG.