1
Unidad 2: El modelo de negocio
Vivimos en una era de constante transformación, donde los modelos de negocio
evolucionan rápidamente y las empresas emergentes desafían las estructuras
tradicionales con nuevas formas de operar. En este contexto, la ingeniería de software
no es la excepción, ya que el desarrollo de aplicaciones y sistemas exige herramientas
que permitan representar, analizar y mejorar estos modelos en un entorno cada vez más
competitivo.
Para hacer frente a este desafío, es fundamental contar con herramientas que faciliten
la visualización, planificación y diseño de soluciones eficientes. Aquí es donde entra en
juego UML (Unified Modeling Language o Lenguaje Unificado de Modelado), una
notación visual que permite representar distintos aspectos de un sistema de software.
Así como un mapa de transportes nos ayuda a entender la movilidad dentro de una
ciudad, UML proporciona modelos que permiten estructurar y comunicar ideas sobre el
desarrollo de software, facilitando su comprensión y construcción.
A lo largo de este material, exploraremos la importancia de los modelos en el software,
el propósito del modelado y cómo UML se ha convertido en un estándar esencial para la
industria. Desde su origen como una síntesis de las mejores notaciones previas hasta su
adopción como lenguaje formal de visualización y especificación, UML ha sido clave para
mejorar la comunicación en los equipos de desarrollo y garantizar la construcción de
sistemas sólidos y escalables.
Este estudio no solo nos permitirá comprender el impacto del modelado en el desarrollo
de software, sino que también nos dará las herramientas para visualizar el futuro de
nuestros propios proyectos, enfrentando con éxito los desafíos de la industria tecnológica
actual.
2
Objetivo de la Unidad:
Comprender la importancia de los modelos de software y la aplicación de UML como
herramienta fundamental para la visualización, diseño y comunicación en el desarrollo
de software, permitiendo así la creación de soluciones eficientes y adaptadas a las
necesidades del entorno tecnológico actual.
• Profundizar en una visión general de temas relacionados con modelos de negocio.
• Analizar la naturaleza de los modelos de software, sus elementos y su relevancia
en el desarrollo de sistemas.
• Comprender la necesidad de los modelos en la ingeniería de software debido a la
intangibilidad y complejidad del software.
• Identificar los componentes y la estructura de UML, incluyendo sus diagramas y
notaciones.
• Distinguir los diferentes tipos de diagramas UML y su aplicación en la
modelización de aspectos estructurales y de comportamiento del software.
3
La mejor forma de empezar algo es dejar de
hablar de ello y ponerse a hacerlo.
– Walt Disney
Conceptos básicos
Antes de adentrarnos en la práctica, revisemos algunos conceptos clave sobre modelos
de negocios. Es posible que algunos de estos términos te resulten familiares, mientras
que otros sean completamente nuevos para ti. No te preocupes si al principio no los
comprendes del todo. A medida que avancemos en esta unidad y comiences a aplicarlos
en casos reales, todo cobrará sentido.
Piensa en esta sección como un mapa inicial: una guía que te ayudará a orientarte en el
mundo de los modelos de negocios. Los conceptos que exploraremos aquí son la base
sobre la que construirás tu conocimiento y comprensión sobre cómo funcionan las
empresas y cómo pueden innovar para alcanzar el éxito.
Más allá de conocer estos términos, comprenderlos y aplicarlos te permitirá aportar valor
a cualquier equipo de trabajo. No se trata solo de aprender teoría, sino de desarrollar la
capacidad de proponer soluciones, innovar y dirigir proyectos con una visión estratégica.
Esta comprensión será clave tanto si trabajas en una empresa establecida como si te
involucras en el mundo del emprendimiento y las startups, que son las organizaciones
más dispuestas a explorar lo desconocido y desafiar los modelos de negocio
tradicionales.
Así que, ¡adelante! Familiarízate con estos términos y prepárate para transformar el
conocimiento en herramientas estratégicas que te ayuden a enfrentar retos, tomar
decisiones fundamentadas y contribuir al crecimiento y éxito de cualquier negocio.
→ Modelo UML: Lenguaje unificado de modelado que permite representar
visualmente sistemas y estructuras.
→ Modelado: Proceso de crear representaciones simplificadas de un sistema para
su análisis y comprensión.
4
→ Modelos de software: Representaciones de software que permiten visualizar su
estructura y comportamiento antes de su implementación.
→ Propósito del modelado: Facilitar la comunicación, el desarrollo y la
documentación de sistemas.
→ Diagrama UML: Representación gráfica utilizada en UML para modelar distintos
aspectos de un sistema.
→ Modelos estructurales en UML: Diagramas que muestran la composición y
relaciones estáticas de un sistema.
→ Modelos de comportamiento en UML: Diagramas que representan la evolución y
dinámicas de un sistema a lo largo del tiempo.
→ Meta-modelo: Modelo de un modelo, utilizado para representar estructuras
abstractas de modelado.
→ Model Driven Development (MDD): Desarrollo basado en modelos que permite
generar código automáticamente.
→ Object Management Group (OMG): Consorcio responsable de la estandarización
de UML.
→ Meta Object Facility (MOF): Marco para definir metamodelos como UML.
→ Object Constraint Language (OCL): Lenguaje para definir restricciones en
modelos UML.
→ Modelos de negocio: Estructuras que describen cómo una organización crea,
entrega y captura valor.
→ Propuesta de valor: Beneficio clave que una empresa ofrece a sus clientes.
→ Segmentos de clientes: Grupos de clientes a los que se dirige una empresa.
→ Canales de distribución: Medios a través de los cuales una empresa entrega su
propuesta de valor.
→ Relaciones con clientes: Estrategias utilizadas para interactuar con los clientes y
retenerlos.
→ Fuentes de ingresos: Formas en las que una empresa genera ingresos a partir de
su propuesta de valor.
5
→ Recursos clave: Activos necesarios para la operatividad del modelo de negocio.
→ Socios clave: Empresas o personas externas que ayudan a la operatividad del
modelo de negocio.
→ Estructura de costos: Gastos involucrados en la operación del modelo de negocio.
→ Lean Canvas: Modelo simplificado para startups basado en el Business Model
Canvas.
→ Business Model Canvas: Herramienta visual que permite describir y analizar
modelos de negocio.
→ Modelos de negocio digitales: Estrategias empresariales basadas en plataformas
y tecnología digital.
→ Plataformas de dos lados: Modelos donde dos grupos de usuarios se benefician
mutuamente a través de una plataforma.
→ Freemium: Modelo donde el servicio básico es gratuito y se cobran funciones
avanzadas.
→ Marketplace: Modelo basado en conectar vendedores y compradores en una
plataforma.
→ Modelos de sistemas: Representaciones del negocio desde la perspectiva de los
requerimientos de software.
→ Representación gráfica: Visualización del proceso de negocio.
→ Base para la especificación técnica y desarrollo: Fundamento para las etapas
posteriores.
→ Modelo funcional y de datos: Aspectos que representan los modelos.
MODELOS
6
Los modelos de sistemas son representaciones del negocio que se crean desde la
concepción de las necesidades de software. Estos modelos ilustran gráficamente el flujo
de trabajo del negocio, sirviendo como base para la especificación técnica y el posterior
desarrollo del software. Los modelos que se describirán detalladamente representan los
aspectos funcionales y de datos de los sistemas. La elección del modelo más adecuado
dependerá del ciclo de vida o la metodología de desarrollo que se decida utilizar.
• Descripción analógica: Un modelo no es la realidad misma, sino una abstracción
que captura los aspectos relevantes.
• Representación de lo invisible: Los modelos nos permiten visualizar conceptos
abstractos o sistemas complejos que escapan a la observación directa.
• Propósito definido: Cada modelo se crea con un objetivo específico, ya sea
comunicar una idea, diseñar un sistema o documentar un proceso.
• Público objetivo: Los modelos se adaptan a las necesidades y conocimientos
del público al que se dirigen.
Modelos de contexto
Para definir los límites de un sistema en las etapas iniciales de la recopilación de
requerimientos, se utilizan los modelos de contexto. Estos modelos, tal como señala
Sommerville en "Software Engineering", se elaboran en colaboración con los interesados
para distinguir entre el sistema y su entorno. Los modelos de contexto son valiosos en
las fases tempranas del análisis del proceso de negocio para comprender la
funcionalidad y los requerimientos del usuario a un nivel general. Este diagrama inicial
permite validar el primer requisito funcional con el usuario y obtener una visión
panorámica del sistema. A medida que se explora y detalla el diagrama de contexto, se
pueden incorporar más requisitos funcionales utilizando otros diagramas de modelos
estructurados o orientados a objetos.
7
Modelado para el Desarrollo estructurado
El enfoque del modelado estructurado se centra en analizar el sistema dividiéndolo en
funciones más pequeñas y manejables. Su meta principal es obtener una definición
completa del software a través de la identificación detallada de los requerimientos. Para
el desarrollo, esta definición se desglosa en funciones, que son consideradas la unidad
fundamental de construcción en este modelo. Además, se especifican claramente los
datos que entran y salen de cada función. Los diagramas clave utilizados son el
Diagrama de Flujo de Datos (DFD), el Diagrama Entidad-Relación (DER) y el Diagrama
de Transición de Estados (DTE). Cada uno de estos diagramas cumple un rol específico
en el modelado del sistema: el DFD ilustra la funcionalidad, el DER se concentra en la
organización de los datos, y el DTE describe cómo el sistema cambia su comportamiento
8
con el tiempo. El Diccionario de Datos actúa como un complemento, proporcionando
detalles precisos sobre cada dato utilizado.
→ Diagrama de flujo de datos El diagrama de flujo de datos muestra una perspectiva
funcional de un proceso, es útil en el análisis de los requerimientos porque
muestran el proceso de negocio de inicio a fin. Si el proceso global contiene
subprocesos, el modelo de flujo de procesos se descompone en subprocesos, con
el objetivo de otorgar al usuario una visión más detallada del negocio.
Modelos de datos
En el desarrollo de software, la implementación de una base de datos para almacenar la
información relevante de los usuarios en un lugar digital centralizado es una práctica
común. Frecuentemente, los sistemas interactúan con otros, pudiendo guardar datos en
bases de datos ya existentes o utilizar información de bases de datos de otros sistemas.
Los diagramas de datos más comunes son el diagrama relacional y el diagrama entidad-
relación, ambos ofreciendo una representación gráfica de la estructura de los datos de
la aplicación. Es importante destacar que el diagrama entidad-relación es el preferido en
el modelado estructurado.
9
→ Modelo entidad-relación Describe las necesidades de información del proceso de
negocio del usuario mediante un conjunto de entidades y relaciones entre ellas.
Asimismo, detalla las descripciones de los datos y restricciones que los datos
deben cumplir.
→ Entidades: la entidad producto, la entidad libro, la entidad autor y la entidad cliente;
cada una de ellas puede representar en la base de datos una tabla, ya que poseen
atributos diferentes; dependiendo del contexto del negocio y la necesidad del
usuario se deberán asignar los atributos a cada entidad.
Diccionario de datos
El Diccionario de Datos es un inventario exhaustivo de todos los datos que forman parte
de una aplicación. Incluye definiciones claras de cada dato, asegurando una
comprensión unificada de la información por parte de todos los involucrados. Además,
documenta los procesos, los lugares donde se almacenan los datos, el flujo de datos y
los elementos de datos básicos. El Diccionario de Datos requiere una actualización
constante por el equipo de desarrollo a medida que se realizan modificaciones al sistema.
Esta información es crucial durante las fases de análisis, diseño y construcción del
sistema.
Para cada dato dentro del sistema, el diccionario de datos especifica: su nombre como
entidad, sus atributos o propiedades, y cómo se organizan y transfieren los datos
(flujos y almacenes, que son tipos de estructuras).
Para que cada dato sea claramente entendido, se define: un nombre significativo dentro
del sistema, una explicación sencilla de su significado y uso, los otros nombres con
10
los que se le puede conocer, el tamaño máximo que puede tener, los valores
permitidos (ya sean muchos dentro de un límite o solo unos pocos definidos), y su
formato específico (numérico, texto, etc.).
Un lenguaje para visualizar la complejidad
UML, acrónimo de "Unified Modeling Language", se erige como un lenguaje estándar
para la visualización, especificación, construcción y documentación de los artefactos que
componen un sistema de software. Su alcance, sin embargo, trasciende el mero ámbito
del software, extendiéndose a la modelización de procesos de negocio y otros sistemas
de naturaleza compleja.
Unificación de visiones
La historia de UML se revela como un relato fascinante. A mediados de la década de
1990, el panorama del modelado de software se encontraba fragmentado, con una
multiplicidad de notaciones y metodologías en competencia. La necesidad de un
estándar unificado se manifestaba como una demanda apremiante.
Fue en este contexto que tres pioneros de la ingeniería de software, Grady Booch, James
Rumbaugh e Ivar Jacobson, aunaron esfuerzos para dar vida a UML. Cada uno de ellos
había desarrollado sus propias notaciones y metodologías, y UML surgió como una
síntesis de sus mejores ideas.
Grady Booch: Reconocido por su método de diseño orientado a objetos (BOOCH).
James Rumbaugh: Creador de la técnica de modelado de objetos (OMT).
Ivar Jacobson: Desarrollador de la ingeniería de software orientada a objetos (OOSE).
En 1997, la versión 1.0 de UML fue adoptada por el Object Management Group (OMG),
un consorcio de la industria que establece estándares para la tecnología orientada a
objetos. Desde entonces, UML ha experimentado una evolución constante,
consolidándose como el estándar de facto para el modelado de software orientado a
objetos.
11
Ahora si hablemos, pero referente al Software
Los modelos de software presentan una complejidad adicional. El software, en sí mismo,
constituye una abstracción, una representación de la realidad. Por lo tanto, un modelo
de software es, en cierto sentido, un modelo de un modelo.
¿Por qué el Software Necesita Modelos?
El software es inherentemente complejo. Se caracteriza por su invisibilidad, intangibilidad
y alta modificabilidad. Los modelos nos brindan la posibilidad de:
• Visualizar la estructura y el comportamiento del software.
• Comunicar ideas y diseños entre los miembros del equipo.
• Documentar el software para facilitar su mantenimiento.
• Gestionar la complejidad de los proyectos de desarrollo.
La palabra "lenguaje" puede resultar inusual en el contexto de la ingeniería de software,
pero es una designación precisa. UML es, en efecto, una herramienta de comunicación
formal, dotada de construcciones, sintaxis y semántica bien definidas. Los diagramas y
sus componentes constituyen los elementos constructivos, la sintaxis describe cómo
deben elaborarse estos diagramas, y la semántica define el significado de cada diagrama
y sus elementos.
Aplicaciones de UML
UML tiene dos aplicaciones principales:
Herramienta de comunicación entre humanos: UML facilita la comprensión y el
intercambio de ideas entre los miembros del equipo de desarrollo, los clientes y otros
interesados. En este contexto, el énfasis se centra en la claridad y la legibilidad de los
diagramas. Se deben evitar los detalles innecesarios y se deben utilizar colores y otros
recursos visuales para mejorar la comprensión. Además, se recomienda mantener
actualizados solo los diagramas esenciales.
12
Herramienta de desarrollo: En proyectos grandes o en metodologías formales, UML se
utiliza como herramienta de desarrollo en sí misma. La metodología MDD (Model Driven
Development) es un ejemplo extremo, en el que los diagramas UML se utilizan para
generar automáticamente el código fuente. Aunque esta práctica ha sido objeto de
críticas, sigue siendo válida la exploración de la automatización del desarrollo de
software. En este enfoque, los diagramas deben ser lo más detallados posible, ya que
"los diagramas son el código".
¿Qué no es UML?
Es importante aclarar que UML no es una metodología o proceso. Aunque su nombre
pueda sugerir una relación con el Proceso Unificado (UP), UML es un lenguaje de
modelado, mientras que UP es una metodología de desarrollo de software.
Perspectivas de diagramas UML
UML 2.2 define modelos estructurales y de comportamiento. Los modelos estructurales
representan la estructura estática de un sistema, mientras que los modelos de
comportamiento representan su dinámica.
• Modelos estructurales: Estos modelos describen la estructura de un sistema,
incluyendo clases, objetos, relaciones y componentes. Los diagramas
estructurales más comunes son:
o Diagrama de casos de uso.
13
Elementos Fundamentales:
Actor: Representa una entidad externa que interactúa con el sistema.
Puede ser un usuario humano, otro sistema o cualquier entidad que
intercambie información con el sistema que se está modelando. El actor
define un rol, no necesariamente una persona física.
Caso de Uso: Describe una secuencia de acciones que el sistema realiza
para proporcionar un resultado valioso a un actor. Representa una
funcionalidad específica del sistema, como "realizar un pedido", "generar
un informe" o "actualizar información". Un caso de uso detalla qué hace el
sistema, pero no cómo lo hace.
Relación: Define la conexión entre un actor y un caso de uso, o entre dos
casos de uso. Existen varios tipos de relaciones:
Asociación: Indica una interacción entre un actor y un caso de uso.
Muestra que el actor participa en el caso de uso.
Dependencia: Señala que un caso de uso utiliza o depende de otro caso
de uso. Esto puede incluir relaciones de "inclusión" (include) o "extensión"
(extend).
Inclusión (include): Este tipo de relación se usa cuando un caso de uso
usa la funcionalidad de otro caso de uso. Es decir, un caso de uso base
utiliza la funcionalidad de un caso de uso incluido.
Extensión (extend): Este tipo de relación se usa cuando un caso de uso
extiende la funcionalidad de otro caso de uso. Es decir, un caso de uso
base puede ser ampliado por un caso de uso de extensión.
Generalización: Este tipo de relación se usa cuando un Actor o Caso de
uso hereda las caracteristicas de otro Actor o Caso de uso.
o Diagrama de objetos.
14
o Diagrama de clases.
o Diagrama de paquetes.
o Diagrama de componentes.
15
o Diagrama de despliegue.
o Diagrama de estructuras compuestas.
16
• Modelos de comportamiento: Estos modelos describen la dinámica de un
sistema, incluyendo interacciones, estados y actividades. Los diagramas de
comportamiento más comunes son:
o Diagrama de secuencia.
o Diagrama de comunicación.
17
o Diagrama de máquina de estados.
o Diagrama de actividades.
o Diagrama de visión global de la interacción.
18
o Diagrama de tiempos.
19
¡Y así llegamos al final de este recorrido!
Hemos desentrañado los fundamentos de los modelos de negocio y su aplicación en la
ingeniería de software, explorando cómo herramientas como UML nos permiten
visualizar y diseñar soluciones innovadoras. Recuerda, la comprensión de estos
conceptos es esencial para tu desarrollo como ingeniero de software y emprendedor en
la era digital.
¡Ahora es el momento de aplicar lo aprendido! Completa las actividades propuestas,
utilizando el lienzo de modelo de negocio y las técnicas de modelado UML, para que
puedas solidificar tu conocimiento y prepararte para crear soluciones de software que
generen un impacto real en el mercado.
M.T.E. Karla Vázquez Ascención
ÚNICA TAREA:
Actividad 1. Diseñando el Futuro: Modelos de Negocio
Actividad 3: Infografía de modelos.
20