RESUMEN DE LOS VIDEOS

variedad de dispositivos
adapta el sistema al usuario

dominio de la informacion

el cliente es aquel que consume los insumos

en informatica el cliente es el programa

entidades + relaciones de dominio

diccionario de entender, no es de base de datos

conjunto de datos que se espera encontrar

repetir con cada concepto

procesamiento
 crear y transformar
 definir y como cambia la informacion
 usuario
 accesos
 permisos
 usuario
 existe
 valido
 permisos

comportamiento
 escenarios
 funciones
 excepciones
 completo
 guardar
 exito
 definir el comportamiento
 definir si en caso el servidor se tarde
 interaccion
  tipo de accion que realizan los usuarios
 recordar no suponer
 tener claridad
 modelos de los participantes
 diagramas de flujo, uml
 diagramas de clases
 no realizar mucho detalle

ingeneria de requirimientos
modelado de negocio(rup)
planificacion(xp)
 recopilacion de informacion de la organizacion (contexto)
 contexto de sistema
 descripcion
 (m,u,ob,org)

descripcion de procesos
 tareas:
 participantes
 informacion
 proceso
 resultados
 para xp:
 definicion(cascada)
 analisis

determinacion de requerimientos
determinación de requerimientos de XP
La determinación de los requerimientos en XP (Extreme Programming) se realiza de forma
colaborativa entre el equipo de desarrollo y el cliente. Se utilizan "historias de usuario" para
describir los requerimientos del sistema. Estas historias son descripciones de alto nivel de
las funcionalidades requeridas por el sistema y son escritas por el cliente en tarjetas de
índice. Estas historias de usuario se utilizan para crear pruebas de aceptación y para
planificar las iteraciones de desarrollo.
Requerimientos de Usuario
Los requerimientos de usuario se refieren a las necesidades, deseos y expectativas del
usuario final del sistema en desarrollo. Estos requerimientos se capturan a través de
diversas técnicas, como entrevistas, cuestionarios, observaciones y talleres de trabajo. A
menudo se presentan en un lenguaje sencillo y comprensible para los usuarios, evitando la
jerga técnica.

Los requerimientos de usuario pueden incluir:

 Funcionalidades: Lo que el usuario necesita que el sistema haga. Esto puede incluir
tareas específicas, características o funciones.
 Interacción: Cómo el usuario espera interactuar con el sistema. Esto puede incluir
la interfaz de usuario, la facilidad de uso y la accesibilidad.
 Rendimiento: Cómo de rápido o eficiente debe ser el sistema.
 Seguridad: Qué medidas de seguridad necesita el sistema para proteger la
información del usuario.
 Soporte y mantenimiento: Qué tipo de soporte y actualizaciones necesita el
usuario después de que el sistema esté en funcionamiento.

Recordar que los requerimientos de usuario deben ser específicos, medibles, alcanzables,
relevantes y limitados en el tiempo (SMART, por sus siglas en inglés).

La determinación de los requerimientos es un paso crucial en el desarrollo de cualquier

sistema o software. Esto se debe a varias razones:

1. Entender las necesidades del usuario: La recopilación de requerimientos permite

a los desarrolladores comprender qué es lo que realmente necesitan y desean los
usuarios. Esto a su vez asegura que el sistema final cumpla con estas necesidades y
expectativas.
2. Evitar malentendidos: Los requerimientos claros y bien definidos ayudan a evitar
malentendidos entre el equipo de desarrollo y los usuarios. Esto puede prevenir
errores costosos y retrasos en el proyecto.
3. Planificación y programación efectiva: Los requerimientos ayudan a los
desarrolladores a planificar y programar el trabajo de manera eficiente. Esto puede
resultar en un desarrollo más rápido y menos problemas en el camino.
4. Base para pruebas: Los requerimientos proporcionan una base para las pruebas de
aceptación, lo que puede ayudar a asegurar que el sistema final cumpla con las
expectativas de los usuarios.

No se deben incluir conceptos técnicos en los requerimientos de usuario debido a que estos
deben estar escritos en un lenguaje que los usuarios finales puedan entender fácilmente. Si
se usan términos técnicos, puede haber malentendidos, ya que los usuarios pueden
interpretarlos de manera diferente a los desarrolladores. Esto podría llevar a errores y
retrasos en el desarrollo del sistema. Además, los requerimientos de usuario son a menudo
la base para las pruebas de aceptación, y si los usuarios no comprenden los requerimientos,
podrían tener dificultades para realizar estas pruebas de manera efectiva.

Descripción Detallada
La descripción detallada de los requerimientos es una parte fundamental del proceso de
desarrollo de software. En esta etapa, cada requerimiento se desglosa en detalles más
específicos. Se describen las características y funcionalidades esperadas, así como cualquier
regla o restricción que pueda aplicarse.

Los detalles pueden abordar cómo se espera que funcione una característica en particular,
cómo los usuarios interactuarán con ella, qué datos necesitará y producirá, y cómo debería
responder a situaciones excepcionales o errores.

Además, la descripción detallada de los requerimientos también puede considerar las

consideraciones de rendimiento, seguridad y cumplimiento que deben tenerse en cuenta.
Esto incluye detalles sobre cómo el sistema debe proteger la información del usuario y
cumplir con las regulaciones relevantes.

La descripción detallada de los requerimientos es clave para el diseño y desarrollo exitoso

del sistema ya que proporciona una guía precisa y completa para el equipo de desarrollo.
Además, también sirve como un punto de referencia para todas las partes interesadas, para
garantizar que todos tengan una comprensión clara y consistente de lo que se espera del
sistema.

Los usuarios desean que el software les permita realizar ciertas actividades o tareas,
conocidas como funcionalidades, que deben estar claramente especificadas en los
requerimientos de usuario. Además, esperan poder interactuar con el software de una
manera específica, que debe ser fácil de usar y accesible. También tienen expectativas
sobre el rendimiento del software, como la velocidad y la eficiencia, y requieren que tenga
medidas de seguridad para proteger su información. Por último, los usuarios necesitan
soporte y actualizaciones después de que el sistema esté en funcionamiento.

Historias de Usuario
Las historias de usuario son una forma efectiva de capturar los requerimientos de los
usuarios en el desarrollo de software. Son descripciones cortas y simples de una
característica contada desde la perspectiva del usuario final.

Una historia de usuario típica sigue el formato: "Como [tipo de usuario], quiero [una
acción] para que yo pueda [beneficio/resultado]". Esta estructura ayuda a centrar el
desarrollo en las necesidades del usuario en lugar de en las especificaciones técnicas.
Por ejemplo, una historia de usuario para un sistema de comercio electrónico podría ser:
"Como cliente, quiero poder buscar productos por nombre para que pueda encontrar
rápidamente lo que estoy buscando".

Las historias de usuario son útiles para:

 Definir claramente lo que los usuarios necesitan y esperan del sistema.

 Facilitar la comunicación entre el equipo de desarrollo y los usuarios.
 Servir como base para las pruebas de aceptación.
 Ayudar a planificar y programar el desarrollo de software.

Es importante recordar que las historias de usuario son solo una herramienta en la caja de
herramientas de requerimientos y deben usarse junto con otras técnicas y documentación
para capturar completamente los requerimientos del sistema.

Ambiente donde operará el software

Es fundamental entender el ambiente en el que operará el software, ya que esto puede
influir en el diseño, las funcionalidades y los requerimientos del sistema. Esto puede incluir
la infraestructura tecnológica existente, el entorno operativo (por ejemplo, sistemas
operativos, navegadores web), la red y las condiciones de seguridad. También se debe tener
en cuenta la ubicación geográfica de los usuarios, la cultura y las normativas locales, así
como cualquier otra característica específica del entorno que pueda afectar al
funcionamiento del software.

Las redes de comunicación son sistemas que permiten la interconexión de varios

dispositivos para compartir información y recursos. Sus características principales incluyen:

 Topología: Se refiere a la forma en que los nodos o dispositivos de la red están

conectados entre sí. Puede ser en estrella, anillo, malla, árbol, entre otras.
 Alcance: Puede ser LAN (Red de Área Local) si se limita a una zona geográfica
pequeña como una oficina, MAN (Red de Área Metropolitana) si cubre una ciudad,
y WAN (Red de Área Amplia) si se extiende a nivel nacional o internacional.
 Transmisión de datos: Los datos pueden transmitirse de diferentes formas, como
en serie (un bit a la vez) o en paralelo (varios bits a la vez). Los datos también
pueden transmitirse de forma unidireccional (simplex), bidireccional alternante
(half-duplex) o bidireccional simultánea (full-duplex).
 Protocolos: Son las reglas que rigen la transmisión de datos en la red. Los
protocolos definen aspectos como el formato de los datos, la velocidad de
transmisión, los métodos de control de errores, etc. Ejemplos de protocolos incluyen
TCP/IP, HTTP, FTP, entre otros.
  Arquitectura: Se puede basar en una arquitectura cliente-servidor, donde un
servidor central proporciona servicios a los clientes de la red, o en una arquitectura
peer-to-peer (P2P), donde todos los nodos de la red pueden actuar como clientes o
servidores.

Interfaces de Hardware y Software

Las interfaces de hardware y software son esenciales para el funcionamiento del sistema.
Estas interfaces permiten la interacción entre diferentes componentes del sistema y facilitan
la transferencia y el intercambio de datos.

Las interfaces de hardware se refieren a los puntos de conexión físicos que permiten a los
dispositivos interactuar entre sí. Esto puede incluir puertos USB para conectar dispositivos
externos, tarjetas de red para conectar el sistema a una red, o interfaces de video para
conectar monitores.

Las interfaces de software, por otro lado, se refieren a los puntos de interacción entre
diferentes programas o entre un programa y el sistema operativo. Esto puede incluir APIs
(interfaces de programación de aplicaciones) que permiten a los programas interactuar con
otros programas o con el sistema operativo, o GUIs (interfaces gráficas de usuario) que
permiten a los usuarios interactuar con el programa.

Es importante considerar estas interfaces al desarrollar un sistema para asegurarse de que el

sistema puede interactuar correctamente con otros dispositivos y programas. Esto puede
afectar a las funcionalidades del sistema, su rendimiento, así como a su seguridad y
confiabilidad.

Restricciones Tecnológicas
Las restricciones tecnológicas son limitaciones que pueden afectar el desarrollo y la
implementación de un sistema. Estas pueden incluir:

 Infraestructura existente: El sistema debe ser compatible con la tecnología y los

sistemas existentes. Esto puede limitar las opciones de diseño y desarrollo.
 Recursos disponibles: Los recursos disponibles, como la memoria, el
procesamiento y el almacenamiento, pueden limitar las capacidades y el
rendimiento del sistema.
 Seguridad y privacidad: El sistema debe cumplir con las normativas y estándares
de seguridad y privacidad. Esto puede requerir la implementación de ciertas
características o tecnologías.
 Accesibilidad y usabilidad: El sistema debe ser accesible y fácil de usar para todos
los usuarios. Esto puede requerir la implementación de tecnologías o características
específicas.
 Compatibilidad: El sistema debe ser compatible con una variedad de dispositivos y
sistemas operativos. Esto puede limitar las opciones de diseño y desarrollo.
Los requerimientos no funcionales son aquellos que no están directamente relacionados con
la funcionalidad específica del sistema, sino con características como la seguridad, el
rendimiento, la usabilidad, entre otros. Son esenciales para garantizar que el sistema sea
eficiente, seguro, fácil de usar y cumpla con las normativas y estándares relevantes. Aquí
una evaluación de los requerimientos no funcionales:

1. Seguridad: El sistema debe proteger la información del usuario y cumplir con las
regulaciones relevantes. Es necesario implementar medidas de seguridad adecuadas
para evitar el acceso no autorizado, la pérdida de datos y otros riesgos de seguridad.
2. Rendimiento: El sistema debe ser lo suficientemente rápido y eficiente para
satisfacer las necesidades de los usuarios. Esto puede incluir la velocidad de
procesamiento, el tiempo de respuesta, la capacidad de manejar múltiples usuarios o
transacciones simultáneamente, entre otros.
3. Usabilidad: El sistema debe ser fácil de usar y accesible para todos los usuarios.
Esto puede implicar el diseño de una interfaz de usuario intuitiva, la
implementación de funciones de accesibilidad para usuarios con discapacidades, la
provisión de documentación y soporte, entre otros.
4. Compatibilidad: El sistema debe ser compatible con la infraestructura tecnológica
existente, incluyendo hardware, software, redes y sistemas operativos. También
debe ser capaz de integrarse con otros sistemas y aplicaciones según sea necesario.
5. Mantenibilidad: El sistema debe ser fácil de mantener y actualizar. Esto puede
incluir la facilidad para corregir errores, implementar nuevas funciones, adaptarse a
los cambios en el entorno operativo, entre otros.

Es importante recordar que los requerimientos no funcionales son igual de importantes que
los requerimientos funcionales. Un sistema puede tener todas las funciones necesarias, pero
si no es seguro, eficiente o fácil de usar, es probable que no sea exitoso.

La notación UML (Lenguaje de Modelado Unificado) es una metodología estándar

utilizada en ingeniería de software para visualizar el diseño de un sistema. UML puede ser
utilizado para modelar una variedad de sistemas, desde sistemas de software hasta sistemas
de flujo de trabajo.

La notación UML se compone de varios tipos de diagramas para representar diferentes

aspectos de un sistema. Algunos de estos diagramas incluyen:

 Diagramas de clases: muestran las clases en un sistema, sus atributos, métodos y

relaciones entre ellas.
 Diagramas de secuencia: muestran cómo las operaciones se realizan en el tiempo.
 Diagramas de estado: muestran los diferentes estados de un objeto y cómo cambia de un
estado a otro.
 Diagramas de actividades: muestran el flujo de control de una actividad a otra.

UML es una herramienta poderosa y flexible que puede ayudar a los equipos de desarrollo
a comunicar sus ideas de manera clara y efectiva.
ABSTRACCION
La abstracción nos permite crear un modelo conceptual de un objeto o concepto y luego
utilizar ese modelo para crear objetos más específicos que heredan las características y
comportamientos del modelo conceptual. Esto nos permite reutilizar código y simplificar la
creación de objetos complejos.

UML, lenguaje de modelado gráfico

El lenguaje de modelado unificado (UML) es un estándar para la representación visual de
objetos, estados y procesos dentro de un sistema. Por un lado, el lenguaje de modelado
puede servir de modelo para un proyecto y garantizar así una arquitectura de información
estructurada; por el otro, ayuda a los desarrolladores a presentar la descripción del sistema
de una manera que sea comprensible para quienes están fuera del campo. UML se utiliza
principalmente en el desarrollo de software orientado a objetos. Al ampliar el estándar en la
versión 2.0, también es adecuado para visualizar procesos empresariales.

Desarrollo del Lenguaje Unificado de Modelado

Antes de que UML se introdujera en el desarrollo de software, el campo de
la programación orientada a objetos (OOP) había crecido. Este estilo de programación
se basa en el concepto de que todo es un objeto: los bloques de construcción de un
programa son objetos que interactúan entre sí, los mensajes que se envían de un lado a otro
entre los componentes también constan de objetos. Cada objeto individual es un ejemplo de
su clase superior. La clase misma también actúa como un objeto y también determina el
comportamiento de las instancias de objetos que contiene. Los objetos consisten en datos y
código. El objeto organiza los datos en campos, también llamados atributos. El código
determina su procedimiento o método.

Desde finales de la década de 1980 hasta la de 1990 se desarrolló un gran número de

métodos y lenguajes para la representación de la programación orientada a objetos. El
resultado fue una confusa abundancia de métodos que apenas eran comparables entre sí.
Para unificarlos, los tres desarrolladores James Rumbaugh, Grady Booch e Ivar
Jacobson decidieron fusionar varios lenguajes existentes en un estándar común.

Los tres ya habían creado sus propios métodos de desarrollo de software orientado a
objetos:

 el método Booch
 la técnica de modelado de objetos (OMT)
 el método de Ingeniería de Software Orientado a Objetos (OOSE)

Como lenguaje de modelado, UML debía definir la semántica para la representación de

estos métodos. Bajo el nombre de "Socios UML", los desarrolladores comenzaron a
trabajar con un equipo para completar UML en 1996. Luego se lo entregaron a la , que
introdujo la versión 1.1 de Unified Modeling Language como estándar en 1997.

No satisfechos, los desarrolladores crearon un grupo de trabajo para mejorar el lenguaje a

través de múltiples versiones. Las críticas existentes incluían una semántica imprecisa e
innecesariamente compleja, la falta de adaptabilidad y una estandarización inadecuada. Por
lo tanto, se llevó a cabo una revisión a fondo. El resultado fue finalmente UML 2.0, que
definió el nuevo estándar en 2005. La versión 2.4.1 constituye la base de la normalización
ISO 19505-1 (Infraestructura) y 19505-2 (Superestructura) de 2012. La UML apareció en
diciembre de 2017.

UML: conceptos básicos

El Lenguaje Unificado de Modelado es referido por algunos como la lingua franca entre los
lenguajes de modelado. Como se mencionó al principio, el UML visualiza los estados y las
interacciones entre objetos dentro de un sistema. Su extensa popularidad se debe
probablemente a la fuerte influencia que ejercen los miembros del OMG (IBM, Microsoft y
HP entre otros). La semántica estructurada hace el resto. Los diagramas UML se utilizan
para representar los siguientes componentes del sistema:

 Objetos individuales (elementos básicos)

 Clases (combina elementos con las mismas propiedades)
 Relaciones entre objetos (jerarquía y comportamiento/comunicación entre objetos)
 Actividad (combinación compleja de acciones/módulos de comportamiento)
 Interacciones entre objetos e interfaces

Metamodelismo

UML 2.0 define unidades de lenguaje que operan en diferentes niveles. Se utilizan para
expresar la estructura y el comportamiento de un sistema. Algunos elementos utilizan el
lenguaje de modelado para definirse. La metamodelación incluye todos los elementos de
UML, incluyendo aquellos que describen el propio UML. Para ello utiliza cuatro niveles
dispuestos jerárquicamente (M0 a M3).

El nivel meta-meta M3 especifica los metadatos del lenguaje de modelado y sus relaciones
usando la Meta Object Facility (MOF). Define el metamodelo. También le permite
transferir metadatos. El formato XMI definido por el OMG es una herramienta para
compartir datos orientados a objetos a nivel meta-meta entre herramientas de desarrollo.
El Object Constraint Language (OCL), un lenguaje de programación declarativo,
complementa el UML y regula las condiciones de contorno de los respectivos modelos.
Como lenguaje de texto, sin embargo, solo tiene un efecto de apoyo, en lugar de estar
disponible para el modelado en sí mismo.

El metamodelado muestra la relación jerárquica entre los niveles de lenguaje.

El gráfico superior muestra el metamodelado de UML 2.0. El nivel M0 es el nivel básico.
Representa objetos reales y concretos y registros de datos individuales, por ejemplo, un
objeto o un componente. El nivel M1 comprende todos los modelos que describen y
estructuran los datos del nivel M0. Estos son diagramas UML como el Diagrama de
Actividad o el Diagrama de Paquete (explicado a continuación). Para definir la estructura
de estos modelos, los metamodelos de nivel M2 definen las especificaciones y la
semántica de los elementos del modelo.

Si deseas crear un diagrama UML comprensible, necesitas conocer el metamodelo UML y

sus reglas. El nivel más alto, M3, es un metamodelo del metamodelo. El mencionado
Meta Object Facility trabaja a un nivel abstracto que define los metamodelos. Este nivel se
define a sí mismo, porque de lo contrario surgirían metaniveles más altos.

Unidades lingüísticas

UML (nivel M2) define las reglas de su propia semántica. Las unidades de lenguaje son
términos definidos en la superestructura UML 2.0. Esto permite una representación formal
que todos los participantes pueden entender. Las unidades lingüísticas, en inglés language
units, abstraen objetos y procesos de estructura y funcionamiento similares y les dan una
forma visualmente representable. Según el nivel jerárquico dentro del modelo, los
elementos asumen tareas más especializadas o definen más estrechamente otros elementos.

Clase: como unidad lingüística, las clases son un aspecto central de UML. Definen lo que
constituye una clase y cómo las clases interactúan entre sí. Esta language unit tiene cuatro
niveles, que van desde elementos simples hasta relaciones más complejas:

 Núcleo (describe elementos de la infraestructura UML 2.0 como paquetes, espacios de

nombres, atributos, etc.)
 AssociationClasses (define clases de asociación)
 Interfaces (define las interfaces)
 Powertypes (clase cuyas instancias son subclases dentro de esta clase)

Componente: los componentes son elementos que separan su contenido del sistema
externo. Solo existe una conexión con el exterior a través de interfaces o puertos. Un
conector de composición establece una conexión con otro componente a través de la
interfaz. El conector de delegación une los elementos interiores con una interfaz en el borde
exterior. Los componentes son modulares e intercambiables.

Estructura de la composición: la estructura de la composición de la unidad de lenguaje

describe los elementos, que están blindados como componentes hacia adentro y hacia
afuera. Solo los puertos conectan el contenido con el sistema externo. Los
llamados clasificadores encapsulados consisten en elementos llamados partes. Las piezas
se comunican a través de conectores.

Perfil: un perfil configura UML 2.0 para necesidades específicas. Los términos abstractos
como actividad u objeto deben ser especificados para algunos proyectos con el fin de
aumentar la comprensión. La semántica y las notaciones que están colocadas en lugares
sueltos se pueden adaptar con un perfil.

Modelo: el modelo comprende todos los elementos necesarios para presentar una visión
específica de la estructura o el comportamiento de un sistema. Esto también incluye las
influencias externas, como los actores.

Acción: cuando se trata de representar el comportamiento, las acciones son de importancia

central. Los valores se aceptan a través de los pines de entrada y se envían a los pines de
salida. Estos son los grupos temáticos que UML define para las acciones:

 Manipular objetos
 Manipular relaciones de objetos
 Manipular características estructurales
 Acciones de llamada
 Generar valores
 Acciones sobre objetos
 Recibir eventos

Comportamiento: la unidad de lenguaje Comportamiento se refiere a la modelización de

aspectos dinámicos dentro de un sistema. Consta de tres especificaciones:

 Actividad: las acciones interactúan a través flujos de datos y control. Esto resulta en un
sistema complejo de comportamientos, las actividades.
 Interacción: este metamodelo describe cómo se intercambian los flujos de mensajes entre
objetos, cuándo se envía un mensaje a qué objeto y qué otros elementos se ven afectados
por él.
 Estado de las máquinas: en un diagrama de estado, este modelo de metamodelo muestra
tanto estados (situaciones con propiedades inmutables) como semiestados (estados sin
asignación de valor) y sus transiciones. Los objetos de un estado pueden asignarse a
acciones o actividades.

Distribución: una red está formada por objetos que están conectados entre sí en mallas. Se
da un caso especial de uso si estos elementos representan software ejecutable o artefactos.
Estos artefactos se ejecutan en entornos de ejecución o dispositivos clasificados como
nodos por UML 2.0. Por lo tanto, el artefacto depende del nodo. La distribución representa
esta relación de dependencia que surge durante la instalación.

Aplicación: el caso de uso (como unidad de idioma) representa los requisitos del sistema.
El actor (una persona o un sistema) es un elemento que describe quién o qué debe realizar
una actividad concreta utilizando el sistema. El sistema también puede ser una clase o un
componente y, por lo tanto, se describe como un tema. El caso de uso (como elemento
modelo) simplemente indica que se espera un comportamiento que sea visible para el
mundo exterior, pero no suele representar qué acciones concretamente. Dentro de una
descripción de comportamiento, el modelado asigna los requisitos detallados al caso de uso.
Flujos de información: esta unidad de lenguaje UML describe los elementos unidad de
información y flujo de información. Estos elementos del modelo son técnicas abstractas de
descripción del comportamiento que pueden estar muy orientadas al detalle, como
actividades o interacciones. Esta representación simplificada permite el uso universal de
estos elementos de modelado en todos los tipos de diagramas UML. Por lo tanto, a
diferencia de la clase, la unidad de información nunca se describe con más detalle por
atributos ni se incluye en los métodos. Por lo tanto, el flujo de información también conecta
todos los elementos posibles que intercambian cualquier tipo de información entre sí.

Diagramas UML: campos de aplicación y breve

introducción
El lenguaje de modelado define 14 tipos de diagramas que se dividen en dos categorías. Las
principales categorías de estructura y comportamiento representan los conceptos básicos
representados por los diagramas UML. Dentro del grupo de diagramas de comportamiento,
UML especifica la subcategoría de diagramas de interacción. Existe una cuarta
especificación parcial desde UML 2.0. Determina el diseño de los diagramas del modelo.

Diagramas de estructura

Los diagramas de estructura representan los elementos individuales de un sistema. Por lo

tanto, son especialmente adecuados para la representación de la arquitectura de software.
La representación estática no representa un cambio, sino estados y dependencias en un
momento determinado. Los elementos individuales u objetos están relacionados entre sí.
Por ejemplo, un objeto pertenece a una clase. Otros componentes son nodos de ordenador o
artefactos –un artefacto representa un resultado, por ejemplo, un archivo de script
terminado.

Los diagramas UML de esta categoría representan un sistema completo o una

subestructura. Esto último ayuda, por ejemplo, a clarificar la estructura en detalle. En UML
2.x, el lenguaje asigna siete tipos de diagramas a la categoría Estructura:

 Diagrama de clases: si los objetos tienen un comportamiento común o la misma

estructura, pueden clasificarse (asignarse a una clase). La clase es, por tanto, un elemento
simplificador (abstracción) para la representación visual. Las clases y los objetos están
conectados entre sí mediante interfaces. El diagrama de clase muestra todos estos
componentes y sus interrelaciones. Una clase representa el diagrama con un rectángulo.
Contiene el nombre de la clase en negrita, como se muestra a continuación.

La clase "Persona" tiene los atributos nombre y apellido. Las operaciones determinan si la
instancia se muestra (display) u oculta (hide).

 Diagrama de objetos: el diagrama de objetos tiene una estructura similar a la del

diagrama de clases. Cuando el nombre aparece en el diagrama de clase (ver Persona
arriba), el diagrama de objeto especifica el nombre de la instancia junto con el nombre del
 clasificador/categoría. De acuerdo con el pliego de condiciones, se subraya lo siguiente
(por ejemplo: Helga:Persona)
 Diagrama de componentes: un componente es un módulo que está aislado del sistema
externo e interactúa con otros componentes mediante interfaces definidas. Es un
subformulario de la clase. Por lo tanto, las características estructurales, como las
operaciones y los atributos, definen el componente con mayor precisión. El componente
contiene varios componentes. Estos pueden ser de nuevo componentes, pero también
clases, subsistemas o partes. Hay dos opciones de visualización diferentes para el
modelado: Black Box o caja negra ****(el contenido está oculto) y White Box o caja
blanca (el contenido es visible).

Vista de caja blanca en un componente. Las interfaces necesarias se muestran como cajas
("Socket") y se ofrecen como círculos ("Lollipop").

 Diagrama de estructura compositiva: los objetos pertenecen a clases. Estos, a su vez,

también pueden clasificarse. Estas metaclases se denominan clasificadores en UML. El
diagrama de estructura de la composición representa las partes y conectores de un
clasificador. Las partes son siempre parte del todo, incluso si no son necesarias para
completar el clasificador. Los conectores son las conexiones entre las partes. Las
características o servicios que requieren componentes externos al clasificador envían las
piezas a través de una interfaz.
 Diagrama de paquete: un paquete agrupa elementos como interfaces o clases en un
espacio de nombres. Los paquetes (packages) también pueden fusionarse con otros
paquetes (fusión de paquetes), importarlos (importación de paquetes) o contener otros
paquetes (subpaquetes). Los paquetes estructuran el contenido del diagrama
jerárquicamente como en un diagrama de árbol. El diagrama de paquete se utiliza, por
ejemplo, en el metamodelo de UML 2. En los sistemas de software representa las subáreas
de forma modular. Según la especificación, un paquete consta de una cabecera y un área
de contenido

 Diagrama de distribución: el diagrama de distribución modela la distribución física de los

artefactos en nodos. Los nodos pueden ser hardware (device nodes), que puede
proporcionar memoria, o software (execution environment nodes), que proporciona un
entorno para ejecutar procesos. Se representan como cuboides tridimensionales.
Los artefactos se dibujan como rectángulos conteniendo el nombre del archivo. Para
distinguirlo de una clase, añade el estereotipo <<artefact>>. El diagrama es adecuado para
visualizar dependencias entre nodos y artefactos, las llamadas relaciones de distribución.
 Gráfica de perfil: los diagramas de perfil se utilizan a nivel de metamodelo. Se utilizan
para asignar un estereotipo a las clases o un perfil a los paquetes. En el metanivel tienes
la posibilidad de adaptar el modelo para otra plataforma o dominio. Por ejemplo, si
restringes la semántica UML dentro de un perfil, transfieres las especificaciones a las
clases subordinadas.

Diagramas de comportamiento

Los diagramas de comportamiento cubren las especificaciones restantes bajo UML. A

diferencia de los diagramas estructurales, no son estáticos, sino que representan procesos
y situaciones dinámicas. Los diagramas de comportamiento también incluyen los
diagramas de interacción (ver abajo).

Diagrama de casos de uso: el diagrama de casos de uso muestra el comportamiento que se

esperará de un sistema más adelante. Este modelo no solo es adecuado para sistemas de
software, sino también, por ejemplo, para procesos esperados en las relaciones comerciales.
El caso de uso involucra a un actor (humano o sistema) con un objetivo. El diagrama
normalmente tiene como nombre el objetivo. Los diferentes casos de uso dentro del sistema
cumplen el objetivo del actor.

El diagrama del caso de uso representa a UML con un rectángulo con la etiqueta use case.
El remitente es el actor (esto se representa como una figura de palo, como en el caso
anterior, incluso si se trata de un sistema). El actor está conectado por una relación de
dependencia (representada como un guion) con el caso de uso (elipse con etiqueta) dentro
de un sistema (rectángulo con etiqueta <<sistema>> y nombre del sistema).

El diagrama de casos de uso en el ejemplo tiene un actor que puede esperar dos casos de
uso dentro del sistema “red social XYZZY”

!https://www.ionos.es/digitalguide/fileadmin/DigitalGuide/Screenshots_2018/EN-UML-
use-case-diagram.png

 Diagrama de actividades: las actividades consisten en una red de acciones que se

relacionan entre sí mediante flujos de datos y de control. Mientras que el Diagrama de
casos de uso muestra los requisitos del sistema, el Diagrama de actividades muestra cómo
funcionan estos casos de uso. En este tipo de diagrama, por ejemplo, el token juega un
papel importante: en los procesos paralelos, es un marcador para el cual se priorizan los
procesos y, por lo tanto, se reciben los recursos (por ejemplo, la memoria de trabajo).
 Diagrama de máquina de estados: una máquina de estados, también llamada autómata
finito, representa un conjunto finito de estados en un sistema. Si se cumple una
condición definida en el sistema (se detona un desencadenante), se produce
una situación correspondiente. Esto puede incluir actividades o interacciones. Bajo UML
2.0, un estado representa esta situación. Los estados se consideran como nodos (inglés:
vértices) y se muestran como rectángulos con esquinas redondeadas. Además, el diagrama
de máquina de estados modela las transiciones de un estado (nodo fuente) a otro (nodo
destino). Los modelos UML presentan las transiciones de estado como bordes. Las
acciones son la última piedra angular. Se asignan especificaciones de comportamiento al
estado.

El comportamiento está ligado a ciertas situaciones o eventos. El diagrama de máquina de

estados UML tiene 4 especificaciones:

 Comportamiento de entrada (entry behavior)

 Comportamiento en el estado (doActivity)
 Comportamiento que ocurre en caso de un evento (event behavior)
 Comportamiento de salida (exit behavior)
Además, un estado puede ser interrumpido y continuado en el mismo punto. Esta propiedad
se llama estado de la historia.

Diagramas de interacción

Los diagramas de interacción son un subtipo de los diagramas de comportamiento. Por lo

tanto, también representan situaciones dinámicas. En particular, son adecuados para
modelar el comportamiento en el que los elementos intercambian información. Los
diagramas definen el papel de los objetos implicados. También nombran y priorizan los
mensajes que se envían de un lado a otro entre los objetos. Los diagramas de interacción
también muestran cómo estos mensajes afectan a los elementos del comportamiento. Por
ejemplo, puede iniciar o detener actividades.

 Diagramas de secuencia: como diagrama de interacción, el diagrama de secuencia

representa el intercambio de mensajes entre objetos. El tipo de diagrama UML modela
estos objetos como las llamadas líneas de vida. En este sentido, es similar a otros
diagramas de comportamiento como el diagrama de actividad. Sin embargo, a diferencia
de estos, el diagrama de secuencia no se utiliza para obtener una visión general del
comportamiento de un sistema, sino para presentar un posible comportamiento entre
muchos otros en detalle. Prescribe una cronología. Una línea discontinua representa el
curso del tiempo.UML 2.0 muestra mensajes síncronos (UML: flecha con la punta llena)
y mensajes asíncronos (UML: flecha con la punta abierta). Los mensajes síncronos son
aquellos que bloquean un canal hasta que reciben una respuesta del objeto de destino.
Determinan las características de comportamiento en forma de operaciones sincrónicas.
Los mensajes asincrónicos controlan el objeto fuente de llamada. Éstas incluyen tanto las
operaciones asíncronas como las señales (paquetes de datos enviados entre acciones).
 Diagrama de comunicación: al igual que el diagrama de secuencia, el diagrama de
comunicación modela una transferencia de mensajes. Sin embargo, este diagrama UML
no utiliza líneas discontinuas para la secuencia de tiempo, sino que numera las secuencias
con números y letras. Estos llamados términos de secuencia se encuentran encima de una
flecha con la punta apuntando hacia el receptor. Los números representan el orden en
que se envían los mensajes, las letras representan el nivel jerárquico (como se muestra en
la figura siguiente).

Los mensajes asíncronos 1a y 1b se envían en paralelo. El objeto :B envía el mensaje con la

etiqueta 1a.1 antes del mensaje 1a.2b. El objeto :D envía el mensaje 1a.2b.1 solo después
de recibir el mensaje 1a.2b.

!https://www.ionos.es/digitalguide/fileadmin/DigitalGuide/Screenshots_2018/EN-UML-
communication-diagram.png

 Diagrama de tiempos: el diagrama de tiempos permite mostrar el comportamiento de los

sistemas en detalle en función de la secuenciación temporal. Los sistemas en tiempo real,
por ejemplo, tienen que manejar ciertos procesos dentro de un cierto período de tiempo.
UML 2.0 modela el diagrama de temporización como un diagrama bidimensional con un
eje x y un eje y para representar mejor el plano temporal. Con este subformulario del
 diagrama de secuencia, los estados de los objetos se encuentran en el eje y y
las secuencias de tiempo asignadas a ellos se ejecutan a lo largo del eje y.

Diagrama de temporización de una lámpara LED con cambiador de color: las instancias de
color se alternan y están activas durante el mismo intervalo de tiempo.

!https://www.ionos.es/digitalguide/fileadmin/DigitalGuide/Screenshots_2018/EN-UML-
time-course-diagram.png

 Diagrama de interacción: el nuevo diagrama de interacción añadido a UML 2.0 ayuda a

mostrar un sistema muy complejo primero en un esquema aproximado, si un diagrama de
interacción normal se vuelve demasiado confuso. Un diagrama de secuencia, por ejemplo,
es adecuado para la visualización detallada. El diagrama UML es similar al diagrama de
actividad con nodos. Representa los flujos de control entre interacciones. La diferencia
con el diagrama de actividad es que un diagrama de interacción completo puede anidarse
dentro de nodos que representan actividades. Estos nidos se pueden mostrar
directamente en el diagrama (en línea) o se puede hacer referencia (palabra clave: ref, del
inglés reference) al modelo, que se muestra en detalle en otra parte.

Diagramas UML: una visión general

El siguiente resumen muestra las categorías superiores y las posibles aplicaciones de los
tipos de diagrama individuales en forma abreviada. Si deseas representar visualmente un
sistema de software orientado a modelos, un caso de uso en la economía, etc., debes
seleccionar uno de los tipos de diagrama UML de antemano de acuerdo con la
recomendación del Grupo de Trabajo de UML. Solo entonces vale la pena elegir una de las
muchas herramientas UML, ya que estos a menudo prescriben un cierto método. A
continuación, crea el diagrama UML.

Categoría Tipo de diagrama Aplicación

Estructura Diagrama de clases Visualizar clases

Diagrama de objetos Estado del sistema en un momento dado

Diagrama de
Estructurar componentes y mostrar relaciones
componentes

Diagrama de estructura Divide los componentes o clases en sus

compositiva componentes y aclara sus relaciones.

Agrupa las clases en paquetes, muestra la

Diagrama de paquete
jerarquía y la estructura de los paquetes.

Diagrama de Distribución de componentes a los nodos

distribución informáticos
 Categoría Tipo de diagrama Aplicación

Ilustra contextos de uso a través de estereotipos,

Gráfica de perfil
condiciones límite, etc.

Diagrama de casos de
Comportamiento Representa varias aplicaciones
uso

Describe el comportamiento de diferentes

Diagrama de actividades
procesos (paralelos) en un sistema.

Diagrama de máquina Documenta cómo un objeto es movido de un

de estados estado a otro por un evento.

Comportamiento: Secuencia temporal de las interacciones entre

Diagrama secuencial
interacción objetos

Diagrama de Distribución de roles de los objetos dentro de

comunicación una interacción

Limitación de tiempo para los acontecimientos

Diagrama de tiempos
que conducen a un cambio de estado

Diagrama de interacción Secuencias y actividades interactivas

PARTE 2 DE LOS VIDEOS

hardware de la organizacion
1. Servidores: Pueden ser servidores físicos locales o servidores en la nube que alojan y
gestionan datos, aplicaciones y recursos de red para la empresa.
2. Ordenadores de escritorio y portátiles: Para los empleados, se necesitarán equipos
informáticos para realizar tareas diarias como procesamiento de texto, navegación por
internet, envío de correos electrónicos, etc.
 3. Dispositivos móviles: Teléfonos inteligentes y tabletas que pueden ser necesarios para
empleados que trabajan fuera de la oficina o que requieren movilidad en su trabajo.
4. Dispositivos de red: Esto incluye routers, switches, firewalls y puntos de acceso WiFi que
son necesarios para conectar los dispositivos de la empresa a la red local y al internet.
5. Almacenamiento de datos: Discos duros, unidades de estado sólido (SSD) o sistemas de
almacenamiento en red (NAS) para almacenar y respaldar datos importantes de la
empresa.
6. Impresoras y escáneres: Para imprimir documentos importantes y digitalizar documentos
en papel.
7. Sistemas de seguridad física: Cámaras de seguridad, cerraduras electrónicas y sistemas de
control de acceso para proteger las instalaciones de la empresa.
8. Dispositivos de seguridad informática: Antivirus, firewalls, sistemas de detección y
prevención de intrusiones (IDS/IPS), y otras herramientas de seguridad para proteger los
sistemas y datos de la empresa contra amenazas cibernéticas.
9. Dispositivos de copia de seguridad y recuperación de desastres: Unidades de copia de
seguridad locales o en la nube, así como software de copia de seguridad para proteger los
datos críticos de la empresa y facilitar la recuperación en caso de desastres.

software de la organizacion
1. Software de gestión empresarial (ERP): Permite integrar y gestionar procesos clave de
negocio, como contabilidad, recursos humanos, gestión de inventario, ventas y compras.
2. Software de gestión de relaciones con el cliente (CRM): Ayuda a gestionar las
interacciones con los clientes, seguimiento de ventas, marketing y servicios al cliente.
3. Software de contabilidad y finanzas: Facilita la gestión de las finanzas de la empresa,
incluyendo la contabilidad, facturación, nóminas y reportes financieros.
4. Software de gestión de proyectos: Ayuda a planificar, organizar y gestionar proyectos,
asignar recursos, realizar seguimiento del progreso y colaborar en equipo.
5. Software de recursos humanos (HRM): Automatiza procesos relacionados con la gestión
de empleados, como la contratación, la gestión del rendimiento, la nómina y el desarrollo
de habilidades.
6. Software de gestión de inventario y cadena de suministro: Permite controlar y optimizar
el flujo de productos y materias primas, desde la adquisición hasta la entrega al cliente
final.
7. Software de colaboración y comunicación: Facilita la comunicación interna y colaboración
entre empleados, ya sea a través de correo electrónico, mensajería instantánea,
videoconferencia o herramientas de gestión de documentos.
8. Software de análisis de datos y business intelligence (BI): Ayuda a recopilar, analizar y
visualizar datos para tomar decisiones empresariales informadas y estratégicas.

Es importante evaluar las necesidades específicas de tu empresa antes de seleccionar el

software adecuado. Además, ten en cuenta factores como el tamaño de la empresa, el
presupuesto disponible y la capacidad de integración con otros sistemas existentes.

requerimientos y validaciones
en ciertos casos pueden ocurrir donde nos equivocamos en el momento de entender los
requerimientos, es decir, tener un presupuesto excesivo que llegue al borde de la “quiebra”

Los requerimientos y validaciones en ingeniería de software son fundamentales para

garantizar que un producto cumpla con las expectativas del cliente y los estándares de
calidad. Aquí tienes una descripción general de ambos:

Requerimientos de Ingeniería de Software:

1. Requerimientos Funcionales:
o Describen las funciones específicas que el sistema debe realizar, como
operaciones, servicios o interacciones con el usuario.
o Ejemplo: "El sistema debe permitir a los usuarios iniciar sesión con su correo
electrónico y contraseña."
2. Requerimientos No Funcionales:
o Especifican atributos del sistema como su rendimiento, usabilidad, seguridad o
compatibilidad.
o Ejemplo: "El sistema debe ser capaz de manejar al menos 1000 usuarios
concurrentes sin degradación significativa del rendimiento."
3. Requerimientos de Interfaz:
o Definen cómo el sistema interactúa con otros sistemas o componentes, incluidas
interfaces de usuario, interfaces de hardware, etc.
o Ejemplo: "El sistema debe ser compatible con los navegadores Chrome, Firefox y
Edge."
4. Requerimientos de Usuario:
o Son declaraciones en lenguaje natural que describen lo que el usuario espera del
sistema.
o Ejemplo: "El sistema debe proporcionar un manual de usuario detallado en
formato PDF."

Validaciones en Ingeniería de Software:

1. Validación de Requerimientos:
o Verificar que los requerimientos capturados sean precisos, completos y
consistentes con las expectativas del cliente.
o Se utilizan técnicas como revisión por pares, prototipado y casos de uso para
validar los requerimientos.
2. Validación de Diseño:
o Asegurarse de que el diseño del sistema cumpla con los requerimientos
establecidos.
o Se pueden realizar revisiones de diseño y simulaciones para validar la arquitectura
y la estructura del sistema.
3. Validación de Código:
o Confirmar que el código implementado cumple con los requerimientos y está libre
de errores.
o Las pruebas de unidad, integración y sistema se utilizan para validar el código.
4. Validación de Usuario:
 o Evaluar si el sistema satisface las necesidades del usuario final.
o Se realizan pruebas de aceptación del usuario y se recopilan comentarios para
mejorar el producto.
5. Validación de Cumplimiento:
o Verificar que el sistema cumple con los estándares y regulaciones relevantes.
o Se pueden realizar auditorías y evaluaciones de cumplimiento para validar el
sistema.
6. Validación de Seguridad:
o Confirmar que el sistema es seguro y protegido contra amenazas y
vulnerabilidades.
o Pruebas de penetración y revisiones de seguridad se utilizan para validar la
seguridad del sistema.

TAREA DE INVESTIGACION
Arquitectura por Capas

¿Qué es?

La arquitectura por capas es un patrón de diseño que organiza una aplicación en capas
lógicas. Cada capa tiene una responsabilidad específica y se comunica solo con las capas
adyacentes.

Capas típicas:

Capa de Presentación (UI): Interfaz de usuario que maneja la interacción con el usuario.

Capa de Lógica de Negocio (BL): Procesa la lógica de negocio y reglas.

Capa de Acceso a Datos (DAL): Maneja las operaciones de acceso a la base de datos.

Capa de Persistencia (si está separada de DAL): Interactúa directamente con la base de
datos.

¿Para qué sirve?

Mantenimiento: Facilita la modificación y evolución de la aplicación.

Reutilización: Permite reutilizar componentes en diferentes proyectos.

Escalabilidad: Mejora la capacidad de la aplicación para manejar un aumento en la carga de

trabajo.

Separación de preocupaciones: Cada capa tiene una responsabilidad clara y definida, lo que
reduce la complejidad.

Objetivo y Función:

El objetivo principal es organizar y estructurar el código de manera que sea más fácil de
mantener, entender y escalar. La función de cada capa es manejar una parte específica de la
funcionalidad de la aplicación, evitando solapamientos y reduciendo la dependencia entre
partes del sistema.

Modelo Vista-Controlador (MVC)

¿Qué es?

MVC es un patrón de diseño que separa una aplicación en tres componentes

interconectados: Modelo, Vista y Controlador.

Componentes

Modelo: Gestiona los datos y la lógica de negocio. Responde a solicitudes para recuperar
información y puede realizar modificaciones en los datos.

Vista: Presenta datos al usuario y maneja la presentación. Se suscribe a cambios en el

modelo y actualiza la interfaz en consecuencia.

Controlador: Maneja la entrada del usuario, interactúa con el modelo y selecciona la vista
adecuada para presentar la información.

¿Para qué sirve?

Separación de preocupaciones: Cada componente tiene una responsabilidad específica.

Facilita las pruebas: La separación permite probar cada componente de forma aislada.

Desarrollo paralelo: Diferentes equipos pueden trabajar en el modelo, la vista y el

controlador simultáneamente.

Objetivo y Función:
El objetivo principal es mejorar la organización del código, facilitando el mantenimiento y
la escalabilidad de la aplicación. La función de cada componente es específica:

Modelo: Gestión de datos y lógica de negocio.

Vista: Presentación de datos.

Controlador: Manejo de la entrada del usuario y coordinación entre el modelo y la vista.

Comparación y Uso Conjunto

Aunque la arquitectura por capas y el MVC son diferentes en su enfoque, pueden utilizarse
conjuntamente. Por ejemplo, en una aplicación web, el modelo MVC puede implementarse
dentro de una arquitectura por capas donde:

La capa de presentación puede contener la vista y el controlador.

La lógica de negocio y la gestión de datos pueden estar en las capas de negocio y acceso a
datos, respectivamente.

Esta combinación permite aprovechar las ventajas de ambos paradigmas, proporcionando

una estructura robusta, mantenible y escalable para la aplicación.