Diseño de arquitectura de software y hardware para el sistema de información en

desarrollo.

Denisse K. Rodríguez, J. Marcos García y Claudia M. Velásquez

SENA

2104587: Análisis y desarrollo de sistema de información

Ing. juan Carlos Ramírez

Marzo 2021
 Introducción.

La empresa BLACKMOUNTAIN GROUP SAS se desempeña en la industria del

calzado y presenta falencias en cuanto a su sistema de inventarios, tiene por objeto
ejercer un control en cuanto a la información de conocer sus ventas, sus compras, la
solicitud de pedidos y el stock que manejan.

La implementación de herramientas informáticas para resolver las problemáticas

anteriormente mencionadas, lleva a que se minimicen estas falencias; una de estas
herramientas es el uso de sistemas de información, que se define como conjunto de
elementos que interactúan entre sí con el fin de apoyar las actividades de una empresa o
negocio, que tiene como principales objetivos mantener la información segura, veraz,
accesible y a tiempo.

La realización de un sistema de información para la empresa BLACKMOUNTAIN

GROUP SAS, va a tener funciones como entrada de información, almacenamiento
organizado de información, procesamiento de información y salida de información, con
este sistema se ahorrarán largas jornadas de inventarios y especialmente se podrá
determinar en forma oportuna la necesidad de adquirir los productos que se requieren y
mantener stocks controlados.
 Alcance del sistema de información

 En el planteamiento de este proyecto se busca que se logre alcanzar los

siguientes aspectos costo, tiempo y en forma con el objetivo que se cumpla.
 Se busca con este nuevo proyecto el desarrollo de nuevos métodos a la hora de

Elaborar inventarios ahorrando tiempo y dinero a la empresa.

 Con la implementación del software se espera que la empresa

BLACKMOUNTAIN de Bogotá obtenga un mayor control de inventarios, y así

Pueda identificar qué cantidad de producto tiene en bodega y evaluar su política de

Inventarios.

 Se espera que estos datos se mantengan actualizados de tal manera que permita
saber qué cantidad real se necesita (si se necesita) para cumplir con los pedidos
de los clientes.
Ámbito del sistema de información.

El software a diseñar tiene, como objetivo principal, apoyar en la gestión de la

Zapatería BLACK MOUTAIN SAS. Dicho almacén está ubicado en los outlets de
las Américas en la ciudad de Bogotá. Se desea automatizar, fundamentalmente, la
gestión de inventarios del almacén entre empleados y propietarios. En cuanto al
stock, debe facilitarse su gestión integral, desde el momento en que un empleado
ofrece un producto, pasando por la venta, y también el ingreso de productos al
almacén. Se desea implantar un software en el que se pueda consultar
información sobre el stock disponible, de forma que se facilite la venta a los
clientes. Los datos deberán estar actualizados permanentemente, siendo
necesario que se sincronicen diariamente con las bases de datos internas.

Visión general del documento.

En este documento consta de tres secciones. La sección 1 muestra la introducción

y proporciona una visión general acerca de la especificación de requerimientos. En
la sección 2 se proporciona una descripción general del sistema, con el fin de
conocer las principales funciones que debe efectuar, los datos asociados y los que
influyen en el desarrollo, sin entrar en excesivos detalles. En la sección 3 se define
detalladamente los requisitos y los diagramas que debe tener el sistema al
momento del desarrollo y la implementación.
Perspectivas del producto

Se proyecta implementar un software que permita controlar los productos del stock tanto
de entrada como de salida, además permitirá registrar todos los movimientos realizados
con los productos del almacén, El sistema de información a implementarse es un software
independiente, ya que no tendrá relación con otros sistemas.

Diseño de software y hardware

Funciones del producto.

Los procesos o funciones que conforman el software son los siguientes:

EMPRESA BLACKMOUNTAIN
ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE

1. Analizar el documento de requerimientos

1. Inicio de sesión
El sistema permitirá al actor el Ingreso al sistema para que los usuarios puedan
interactuar con él con base en sus perfiles de trabajo.
2. Crear usuarios
El sistema permitirá al administrador crear un nuevo usuario dentro del dominio del
sistema; el sistema tendrá un formulario de creación de usuario, y permitirá modificar los
campos de nombre, celular, rol y dirección.
3. Filtrar usuarios

El sistema permitirá al administrador filtrar a un usuario con base a sus perfiles de

trabajo según criterio de búsqueda (código o nombre).

4. Editar usuarios

El sistema permitirá al administrador editar los datos de los usuarios del sistema,
permitirá editar, correo, teléfono, dirección, perfil de usuario.

5. Consultar usuarios
El sistema permitirá al administrador consultar a un usuario con base a sus perfiles de
trabajo y podrá verificar todos los datos registrados.

6. Crear proveedores

El sistema permitirá crear un nuevo proveedor dentro del sistema, en el cual se registrará
tipo de documento, numero de documento, nombres, celular, dirección sucursal. Además
de esto deberá registrar los datos del producto, en donde ingresa el nombre del producto,
la descripción y el costo del proveedor.

7. Filtrar proveedores

El sistema permitirá al usuario filtrar los proveedores según criterio de búsqueda (código
o por nombre o NIT.)

8. Editar proveedor

El sistema permitirá al usuario editar a los datos de un proveedor como tipo de

documento, numero de documento, nombres, celular, dirección sucursal.

9. Consultar proveedor
El sistema permitirá al usuario consultar a un proveedor y verificar todos los datos
registrados según criterio de búsqueda.
10. Filtrar productos
El sistema permitirá al usuario filtrar los productos según criterio de búsqueda. (Código,
producto, categoría).
11. Administrar productos

El sistema permitirá al usuario visualizar las existencias de productos por bodegas y sus
cantidades.

12. Administrar productos – movimientos

El sistema permitirá al usuario visualizar las existencias de productos por bodegas, sus
cantidades, sus movimientos y en cual área están almacenados.
13. Administrar factura – filtrar

El sistema permitirá al usuario filtrar las facturas según criterio de búsqueda. (Código,
producto, categoría).

14. Administrar factura - consultar detalle

El sistema permite al usuario elegir la factura de la cual desea ver el detalle la cual
permite la Visualización de talle de datos de la factura.

15. Crear factura - cliente

El sistema permitirá al usuario validar la existencia del Cliente y crea el cliente anexando
datos como tipo de documento, numero de documento, nombres, celular, dirección.

16. Crear factura – productos

El sistema permitirá al usuario crear la factura de los productos anexando según criterio
(código, producto, categoría)

17. Generar factura

El sistema permitirá al usuario registrar el cliente, los productos y la forma de pago para la
generación de la factura.

18. Unidades devueltas

El sistema permitirá registrar las devoluciones e incluir nuevamente la mercancía al

inventario

19. salir del sistema

El sistema permitirá al usuario salir de la aplicación.

 Iniciar sesión

 Crear usuario
 Administrador de usuarios

 Filtrar usuario
 Crear usuario
 Editar usuario

 Filtrar usuario
 Resultado del filtro de usuario

 Consultar usuario
 Resultado de consulta

 Crear proveedor
 Filtrar proveedor
 Resultado de filtro de proveedor

 Editar proveedor

 Consultar proveedor
 Resultado de consultar proveedor
 Filtrar factura

 Detalle de factura
 Crear factura cliente

 Facturas productos
 Filtrar productos

 Administrar productos

 Devoluciones
 Salir del sistema
Características del usuario

Se ha identificado los siguientes procesos que realiza el usuario en la empresa BLACK

MOUNTAIN GROUP SAS procediendo a realizar la matriz de funciones que realiza cada
personal:

Restricciones.

El sistema de información de BLACK MOUTAIN GROUP SAS dependerá del recurso

humano ya que será alimentado de información por parte del personal, y puede darse e
caso de que la empresa invierta en tecnología y el sistema de información tenga que
adaptarse a esos cambios para su normal funcionamiento.
El sistema de información “SIGERMUL” dependerá del recurso humano ya que será
alimentado de información por parte del personal, y puede darse el caso de que la
empresa invierta en tecnología y el sistema de información tenga que adaptarse a esos
cambios para su normal funcionamiento, lo que provoca que tenemos que dejar la
posibilidad del que sistema tenga que adaptarse a posibles cambios en un futuro.
Suposiciones y dependencias

Los requisitos descritos en este documento pueden cambiar, pues los procesos son
dinámicos y por lo tanto cambia los requisitos del software, para lo cual es necesario que
las fases de análisis y diseño estén bien documentados y además definir una fase y
metodología de mantenimiento del sistema.

Arquitectura de software.
DIAGRAMA CASO DE USO
DIAGRAMA DE SECUENCIAS
DIAGRAMA DE CLASES
Modelo de actividades
 DIAGRAMA DE PAQUETES

ARQUITECTURA DE HADWARE

DIAGRAMA DE COMPONENTES
DIAGRAMA DE DESPLIEGUE

DIAGRAMA DE NODOS
 Definiciones y acrónimos

 GUI : Es la abreviatura de Graphic User Interface o interfaz gráfica de usuario.

Es cualquier artefacto gráfico que permite a los usuarios interaccionar con una
aplicación usando iconos, botones, indicadores visuales, etc... en contraste con las
interfaces más tradicionales basadas en texto, o las más avanzadas actualmente basadas
en la voz o en la interacción mediante movimientos.
Por cierto, se pronuncia "güi", (como en "pingüino", es decir, la "u" no es muda, como en
español).
API : Se refiere a las interfaces de programación de aplicaciones o Application
Programming Interfaces. Es cualquier conjunto de funciones y métodos que se
exponen por parte de un programador para que lo utilicen otros programadores,
bien referenciando directamente una biblioteca o bien exponiéndolo a través de algún
protocolo (por ejemplo HTTP para acceder a través de internet), etc...

Una característica importante de una API es que es independiente de la implementación

que haya debajo. Es decir, una API es como una caja negra para el programador que la
usa, de modo que mientras no cambie la parte expuesta, lo que se haga por debajo y
cómo se haga es indiferente.

De este modo, si creamos una API en un lenguaje (por ejemplo Java) y la exponemos a
través de HTTP como API REST (otro bonito acrónimo algo más avanzado, que
significa Representational State Transfer, no lo veremos hoy), si más adelante cambiamos
el modo en que funciona o incluso la escribimos de nuevo desde cero con otro lenguaje
de programación diferente, mientras no cambiemos la parte expuesta (o sea, las
funciones y sus parámetros y el modo de acceder a éstas), a todos los efectos sigue
siendo la misma API para los programadores que la utilicen.

IDE: Un Entorno Integrado de Desarrollo o IDE (del inglés Integrated Development

Environment) es una aplicación para desarrollar aplicaciones y que va mucho más allá de
lo que ofrece un simple editor. Ofrece muchas herramientas avanzadas para ayudarnos
en nuestro trabajo, tales como depuradores, diseño visual, análisis de rendimiento, testeo
de aplicaciones, herramientas de colaboración, inspectores de objetos y de clases,
integración con otras herramientas...

Algunos IDE valen para trabajar en varios lenguajes y otros están enfocados a una
plataforma concreta (como Java).

 SDK : Un SDK es un Kit de Desarrollo de Software (Software Development Kit).

Se trata de un conjunto de APIs (ver antes), ejemplos de código y documentación
que los fabricantes de software entregan a otros programadores para que puedan
desarrollar para alguna plataforma.
Por regla general los SDKs se lanzan para un sistema operativo (Windows, iOS,
Android...), una plataforma de desarrollo (como .NET, Java) o una consola de juegos
(XBox), por poner ejemplos comunes.

Podríamos pensar en un SDK como el intermediario que pone un fabricante entre sus
sistemas y las aplicaciones que crean terceros programadores. Si programas
profesionalmente, tarde o temprano te tocará pelearte con alguno.

SCM o VCS : Ningún programador que se precie debería trabajar sin usar un sistema de
control de código fuente o Source Control Management, también conocido por Version
Control System (sistema de control de versiones). Verás por ahí que se utilizan
indistintamente los dos términos, pero en ambos casos se refieren a lo mismo.

Se trata de un sistema que permite almacenar el código fuente de los programas así
como cualquier otro archivo relacionado que utilicemos, y monitoriza y guarda todos los
cambios y versiones diferentes de cada archivo que se hayan guardado explícitamente.

Se trata de una herramienta muy potente que es indispensable a la hora de colaborar

con otros programadores en un mismo proyecto, pero que es también casi obligatoria
aunque trabajemos solos. Gracias a su uso podemos volver a cualquier punto del
pasado en nuestras aplicaciones, trazar los cambios hasta dar con aquel que ha hecho
que algo falle, trabajar de manera separada en nuevas características sin que influyan en
el producto principal hasta que estén terminadas, etc..
TDD: Este término se refiere al desarrollo guiado por pruebas o Test Driven
Development.

Un desarrollo guiado por pruebas implica testear/probar todo el código que escribes para
asegurar que funciona, que cubre todos los casos y que no interfiere con otras partes de
la aplicación que en principio puede que no hubieras tenido en cuenta.

Pero TDD va más allá de eso, ya que es una filosofía que implica que los desarrollos
comienzan realmente con las pruebas. Es decir, un desarrollo TDD implicaría seguir, más
o menos, estos pasos:

1. Pensar en la funcionalidad que necesitamos para una función o una clase

2. Crear el test que servirá para validar que está haciendo su trabajo, y que
contemple todas las casuísticas. ¡Antes de escribir el código!
3. Implementar la función o la clase.
4. Pasar las pruebas. No damos el desarrollo por terminado hasta que las pase.

Aunque pueda parecer contraproducente seguir este proceso, hay muchos estudios que
demuestran que a la larga es más eficiente que el método tradicional, ya que ayuda a
diseñar mejor el código, tener en cuenta mejor todos los casos, y tener menos errores.
Esto hace que el código sea más robusto y más fácil de mantener, y se ahorra tiempo
porque hay menos errores que corregir, aumentando la calidad.
 Anexos

La guía sencilla para la diagramación de UML y el modelado de la base de datos

Ventajas

 Simplifica las complejidades 

 Mantiene abiertas las líneas de comunicación 
 Automatiza la producción de software y los procesos  
  Ayuda a resolver los problemas arquitectónicos constantes 
 Aumenta la calidad del trabajo 
 Reduce los costos y el tiempo de comercialización 

Tipos de diagramas UML  

Diagramas estructurales

Los diagramas estructurales representan la estructura estática de un software o sistema, y

también muestran diferentes niveles de abstracción e implementación. Estos se usan para
ayudarlo a visualizar las diversas estructuras que componen un sistema, como una base
de datos o aplicación. Muestran la jerarquía de componentes o módulos y cómo se
conectan e interactúan entre sí. Estas herramientas ofrecen orientación y garantizan que
todas las partes de un sistema funcionen según lo previsto en relación con todas las
demás partes. 

 Diagrama de clases. Este diagrama, el más común en el desarrollo de software,

se usa para representar el diseño lógico y físico de un sistema, y muestra sus
clases. Tiene un aspecto similar al del diagrama de flujo porque las clases se
representan con cuadros. Este diagrama ofrece una imagen de las diferentes
clases y la forma en la que se interrelacionan, y cada clase posee tres
compartimientos: 
 Sección superior: nombre de clase 
 Sección central: atributos de clase 
 Sección inferior: métodos u operaciones de clase

 Diagrama de objetos. A menudo, este diagrama se usa como una forma de

comprobar la revisión de un diagrama de clases para fines de precisión. En otras
palabras, ¿funcionará en la práctica? Muestra los objetos de un sistema y sus
relaciones, y ofrece una mejor visión de los potenciales defectos de diseño que
necesitan reparación. 

 Diagrama de componentes. También conocido como diagrama de flujo de

componentes, muestra agrupaciones lógicas de elementos y sus relaciones. En
otras palabras, ofrece una vista más simplificada de un sistema complejo al
desglosarlo en componentes más pequeños. Cada una de las piezas se muestra
con una caja rectangular, que tiene su nombre escrito dentro. Los conectores
definen la relación/las dependencias entre los diferentes componentes. 
  Diagrama de estructura compuesta. Este lo utilizan rara vez las personas
externas al campo de desarrollo de software. ¿Por qué? Aunque es similar a un
diagrama de clases, adopta un enfoque más profundo, que describe la estructura
interna de múltiples clases y muestra las interacciones entre ellas. Salvo que usted
sea desarrollador, la vista de nivel superior probablemente le entregará
información suficiente. 
 Diagrama de despliegue. Este diagrama muestra los componentes de hardware
(nodos) y software (artefactos) y sus relaciones. Ofrece una representación visual
exacta del lugar donde se implementa cada componente de software. 
 Diagrama de paquetes. Este se utiliza para representar las dependencias entre
los paquetes que componen un modelo. Su objetivo principal es mostrar la relación
entre los diversos componentes grandes que forman un sistema complejo. 

Diagrama de perfiles. Este es más similar a un lenguaje que a un diagrama. Un

diagrama de perfil ayuda a crear nuevas propiedades y semántica para los diagramas
UML al definir estereotipos personalizados, valores marcados y restricciones. Estos
perfiles le permiten personalizar un metamodelo de UML para diferentes plataformas (por
ejemplo, Java Platform, Enterprise Edition (Java EE) o Microsoft .NET Framework) y
dominios (por ejemplo modelado de proceso empresarial, arquitectura orientada a
servicios, aplicaciones médicas y más).

2. Diagramas UML de comportamiento: 

 Diagrama de actividades. Este representa un proceso paso a paso con un inicio

y final claros. Es un conjunto de actividades que deben realizarse para lograr un
objetivo. Muestra cómo cada actividad conduce a la siguiente y cómo todas estas
se conectan. Además del desarrollo de software, estas se pueden utilizar en casi
cualquier entorno empresarial. También se denominan asignación o modelado de
proceso empresarial. 
 Diagrama de casos de uso. Este describe lo que un sistema hace las cosas, pero
no la forma en que las hace. Un caso de uso es un conjunto de eventos que
ocurren cuando un “actor” usa un sistema para completar un proceso. Un actor se
define como cualquier persona o cualquier cosa que interactúa con el sistema
(persona, organización o aplicación) desde fuera del sistema. Por lo tanto, un
diagrama de casos de uso describe visualmente ese conjunto de secuencias y
representa los requisitos funcionales del sistema. 

Diagrama de descripción general de interacción. Este diagrama, a menudo complejo,

es similar al diagrama de actividad, ya que ambos muestran una secuencia paso a paso
de las actividades. Sin embargo, un diagrama de descripción general de interacción es un
diagrama de actividad que se compone de diferentes diagramas de interacción. Usan la
misma composición que un diagrama de actividad (nodos inicial, final, decisión, unión, fork
y join) e incorpora elementos como la interacción, el uso de la interacción, restricción de
tiempo y restricción de la duración.
Diagrama de tiempos. Cuando el tiempo ocupa un lugar central, se usa este diagrama
de UML. También conocido como un diagrama de secuencia o eventos, no muestra la
forma en que los objetos interactúan o cambian entre sí. Funcionalmente, muestra cómo
los objetos y actores se desempeñan en una línea de tiempo. El enfoque aquí está en la
duración de los eventos y los cambios que se producen en función de las restricciones de
duración. Las principales partes de un diagrama de plazos incluye: 

 Línea de vida: participante individual 

 Línea de tiempo de estado: estados diferentes por los que pasa la línea de vida
dentro de una canalización 
 Restricción de duración: tiempo necesario para que se cumpla una restricción 
 Restricción de tiempo: un periodo en el que el participante debe completar una
acción 
 Destrucción: cuando finaliza la línea de vida de un objeto. Después de que se
realiza la destrucción en una línea de tiempo, no se produce otra ocurrencia. 
 Diagrama de máquina de estados. También denominado gráfico de estados,
este diagrama se aplica cuando el comportamiento de un objeto es complejo y el
detalle es esencial. Ayuda a describir el comportamiento de un objeto (o a veces
de un operador) y la forma en que cambia según los eventos internos y externos. 
 Diagrama de secuencia. Popular más allá de la comunidad de diseño, este
diagrama visualmente atractivo es bueno para mostrar todo tipo de procesos
empresariales. Simplemente revela la estructura de un sistema, mostrando la
secuencia de mensajes e interacciones entre actores y objetos cronológicamente.
Los diagramas de secuencia muestran iteraciones y ramificaciones simples. Es
favorable al realizar múltiples tareas. 
 Diagrama de comunicación. Un diagrama de comunicación o colaboración es
similar a un diagrama de secuencia. Sin embargo, enfatiza la comunicación entre
objetos. Muestra la organización de los objetos que participan en una interacción y
presenta iteraciones y ramificaciones más complejas. 

Modelos de base de datos 

Echemos un vistazo a los diferentes tipos de modelos de bases de datos que puede
crear: 

 Modelo de base de datos jerárquico. Un modelo antiguo, pero bueno. Los datos
de este modelo están organizados en una estructura de árbol. El árbol está
compuesto por varios grupos llamados segmentos. Utiliza una relación de uno a
muchos. El acceso a los datos también es predecible. 

 Modelo de red. Este modelo adopta la forma de un gráfico, donde los tipos de
relación son arcos y los tipos de objeto son nodos. A diferencia de otros modelos
de bases de datos, el esquema del modelo de red no se limita a una red o
jerarquía. 
 Modelo de base de datos orientado a objetos. Este modelo utiliza una colección
de objetos, o elementos de software reutilizables, con características y métodos
asociados. Por ejemplo, una base de datos multimedia podría tener imágenes que
no se pueden almacenar en una base de datos relacional. O una base de datos de
hipertexto permite establecer vínculos con otros objetos. 

 Modelo relacional. Aquí, los datos se estructuran utilizando relaciones o

estructuras matemáticas similares a una cuadrícula que tienen columnas y filas.
Básicamente, es una tabla. 

 El modelo objeto-relacional. Como su nombre lo indica, este modelo es una

combinación de los dos mencionados anteriormente. Admite objetos, clases,
herencia y otros elementos orientados a objetos, pero también admite tipos de
datos, estructuras tabulares y más, como en un modelo de datos relacionales. 

 Modelo entidad-relación. Este se compone de tipos de entidad (personas,

lugares o cosas). Muestra las relaciones que pueden existir entre ellos. Al definir
las entidades, sus atributos y mostrar las relaciones entre ellas, un diagrama ER
ilustra la estructura lógica de las bases de datos. 

 Modelo de documento. Está diseñado para almacenar y administrar documentos

o datos semiestructurados, en lugar de datos atómicos. Tiene una estructura de
árbol en la que cada nodo es un objeto que representa una parte del documento. 

 Modelo de entidad-atributo-valor. En el EAV o los modelos de esquema abierto,

los datos se registran en tres columnas:  

1. La entidad (lo que se describe)  

2. El atributo o parámetro (por ejemplo, nombre, descripción, tipo de datos) 
3. El valor del atributo. 

Esquema de estrella. Esta es la versión más simple de un modelo dimensional,

en el que los datos se organizan en dimensiones y hechos. Se utiliza en
inteligencia empresarial y almacenamiento de datos, ya que es adecuado para
consultar conjuntos de macrodatos. 
 Bibliografía

https://www.microsoft.com/es-co/microsoft-365/business-insights-ideas/resources/guide-
to-uml-diagramming-and-database-modeling

https://sites.google.com/

https://sena.territorio.la/

https://www.monografias. com/
https://www.youtube.com/
nelsonjas --- Diagrama de paquetes UML

https://www.youtube.com/watch?v=NSB0ATJUavA --- Diagrama despliegue

https://www.google.com/

https://www.campusmvp.es/recursos/post/Los-8-acronimos-mas-importantes-que-todo-
programador-debe-conocer.aspx