3. Plataformas online, sistemas de control de tráfico ferroviario
o aéreo, el conjunto de leyes que rige el funcionamiento de
una democracia, son sistemas. Por lo tanto, los sistemas
suelen tener tanto una parte social como una parte técnica.
Parece extraño que estas cosas puedan ser entendidas de la
misma manera. Pero con el pensamiento sistémico, podemos
analizar estos problemas, descomponerlo en problemas mas
pequeños, y, poco a poco, ir creando un conjunto de
elementos y relaciones que puedan ser descritos y
expresados en un lenguaje común (tal como UML.)
4. Los sistemas son difíciles de construir, y muchas veces, sólo
detectamos sus carencias cuando dejan de funcionar bien,
por ejemplo, cuando nuestro tren llega tarde o cuando
notamos incoherencias en la política de un país. Éstos son
signos de un sistema mal diseñado.
Un sistema se puede definir simplemente como un conjunto
de elementos separados pero interdependientes. Diseñando
un sistema significa definir cuales son estos elementos, qué
hacen, y cómo se relacionan entre si.
5. Veámoslo a través de un ejemplo de un sistema de control
ferroviario, que contiene:
Trenes
Conductores
Estaciones
Pasajeros
Vías
Viajes
Asientos
Podemos definir relaciones entre estos elementos. Las
relaciones se suelen describir con verbos, y los elementos
de nuestro sistema con nombres.
6. Los trenes tienen asientos. Los pasajeros reservan viajes.
Los viajes involucran estaciones. A los pasajeros se les
asignan asientos. Las estaciones tienen vías. A cada viaje
le corresponde un conductor.
También nos puede interesar definir cuántas unidades hay
de cada uno de estos elementos. Por ejemplo cada tren
tendrá al menos un conductor. Cada tren tiene un número
limitados de asientos, y por lo tanto de pasajeros. Un
pasajero no puede estar viajando en más de un tren a la
vez.
7. Es necesario, por tanto, definir cuántos de cada elemento
corresponde a cada uno de los otros.
También podemos definir reglas dentro de este sistema. Un
viajero no se puede subir a un tren si no ha reservado un
asiento. Ciertos conductores no serán disponibles para
cualquier viaje. Un tren no puede llegar a una vía si esta ya
está ocupada.
Creando estas reglas, basándonos en situaciones reales, se
consigue evitar problemas que conllevarían el mal diseño
del sistema.
10. El diagramas de clase es un diagrama estructural, y es sin
duda el más común de ellos. Permite describir la
arquitectura de un sistema con bastante detalle. Es muy
recomendable tener un diagrama de clase antes de empezar
a escribir código para una base de datos o una aplicación.
Un diagrama de clase, describe cómo se relacionan los
elementos de un sistema, qué atributos les caracterizan.
Después tendremos las cosas lo suficientemente despejadas
como para poder ir diseñando la arquitectura del sistema.
11. Se trata de
entender el
sistema
como una
historia. Una
historia tiene
personajes,
unas
acciones, y
un contexto.
12. Este diagrama es fundamental para el modelado orientado a
objetos. Describe los distintos componentes de un sistema,
sus atributos, y las relaciones entre ellos.
13. Veamos el caso:
Un vendedor de libros se conecta a la web para subir el
articulo que tiene a la venta.
Un cliente se conecta a la página web de una tienda online
para comprar un libro. Escribe el título del libro en la barra
de búsqueda y busca el mejor precio entre los resultados.
Cuando encuentra una oferta que le interesa, la añade al
carrito de la compra. Tiene que haber iniciado una sesión
para poder hacerlo.
Identificamos los elementos principales del sistema:
compradores, vendedores, y artículos.
14. Veamos el caso:
Añadiremos los artículos como el primer elemento en
diagrama de clase.
Debajo del titulo, colocamos los atributos de un articulo.
¿Qué tiene un articulo? ¿Qué características tiene que
permite diferenciarlo de otros artículos? Lo importante es
nos quedemos con lo relevante para nuestra aplicación.
Trata de imaginarlo en una página web. ¿Qué información
esperarías que ponga?
15. Veamos el caso:
A continuación detallamos las otras clases de nuestro
Hemos añadido el comprador, el vendedor, el envío y el
de un articulo.
16. Establezca la cardinalidad de las relaciones.
Ahora toca averiguar cómo se relacionan los elementos
entre ellos. Una pregunta que tenemos que hacer cada vez
que estudiamos la relación entre dos elementos es:
elementos A por cada elemento B? ¿Y Cuántos B por cada
A?
Este proceso lo llamamos establecer la cardinalidad de las
relaciones. Además es recomendado añadir verbos a las
relaciones para ayudar a cubrir mejor la semántica de las
relaciones.
17. Establezca la cardinalidad de las relaciones:
Relaciones de uno a varios.
Por ejemplo, ¿Cuántos artículos por cada envío? La
respuesta es bastante intuitiva: un envío solo puede existir si
contiene como mínimo un articulo. Además, no se puede
definir un número máximo de artículos en un envío. Esto lo
representamos escribiendo 1..* en la línea entre artículos y
envíos, al lado de la caja de artículos. Significa que
entre 1 y un número indeterminado de articulo por envío.
18. Relaciones de varios a varios
¿Cuántos artículos puede vender un vendedor? Puede ser
que se quede sin artículos para vender, por lo tanto el
mínimo sería 0. No impondremos máximo de artículos que
pueda vender alguien. Entonces pondremos 0..* del lado del
articulo.
¿Cuántos vendedores venden un mismo articulo? Depende
considera que los artículos son únicos o si varios pueden
vender el mismo tipo de artículo. Puede ser que en algún
momento no haya más vendedores vendiéndolo o que lo
venden un número indeterminado de personas. Pondremos
0..* del lado de los vendedores.
19. Relaciones de uno a uno
Observemos la relación entre Envíos y Pagos. En este caso,
consideramos que a cada envío le corresponde un solo
y viceversa. Un envío se creará en cuánto se realice el pago
del articulo. Es casi cómo si fuesen la misma entidad. Los
separamos para mantener la semántica de lo que
representan. Así podemos diferenciar mas fácilmente la
fecha de envío de la fecha de pago, y la dirección de envío
de la dirección de pago.
Entonces, lo que aquí acabamos de definir es una relación
uno a uno.
20. Diagrama completo del sistema.
Hemos añadido las relaciones comprador-envío (uno a
y vendedor-envío (uno a varios). Añadimos unos verbos en
líneas entre entidades.
No todas las entidades tienen relaciones directas con otras.
Por ejemplo, no hay relaciones directas entre un artículo y
comprador. Sería redundante, porque ya hay una definida
entre el comprador y el vendedor a través de un envío. Por
el mismo motivo, no hay una directa entre comprador y
vendedor ya que se contempla a través de un envío.
