Arquitectura integra 2

GABY SPA & SALÓN
Sistema de Nóminas
Arquitectura Integra
Versión 0.9

SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
Historial de Revisiones
Fecha Versión Descripción Autor
04/05/2013 1.0 Versión preliminar como propuesta de
desarrollo.
Carlos Rosado, Jordin
Ocaña Mendez Lopez, Eder
Perez Napancca, Karla
Ramirez Carranza, Alvaro
Sanchez Villegas, Carolina
Torres Gonzales, Jose
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 2

Fecha: 10/05/2013
DOCUMENTO ARQUITECTURA INTEGRA
1. Introducción
En el siguiente documento veremos la arquitectura Integra del sistema.
1.1. Propósito
El objetivo del documento es dar una visión al cliente de la arquitectura integra
del sistema.
1.2. Vista General
En este documento contiene los diferentes componentes de la arquitectura
integra del sistema como los modelos tanto estáticos y dinámicos del sistema,
además de la definición de términos y abreviaturas usadas durante el
desarrollo de este documento.
1.3. Definición de Términos, Abreviaturas y Siglas
1.3.1. Diagrama de Clases
MVC (Modelo Vista Controlador): Es un patrón de software, nos permite
desarrollar aplicaciones independizando su funcionalidad. Se basa en las
ideas de reutilización de código y la separación de conceptos, características
que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior
mantenimiento
SGDB: Sistema gestor de base de datos. Son programas que permiten el
almacenamiento, modificación y extracción de la información en una base de
datos, además de proporcionar herramientas para añadir, borrar modificar y
analizar los datos.
Uso de Patrón MVC: El patron de arquitectura de software va a separar los
datos y la logica de negocio de una aplicación de interfaz de usuario. Para

Fecha: 10/05/2013
ello propone la separacion de tres componentes distintos: modelo, vista y
controlador.
Se diseño con este patron para reducir el esfuerzo de programar. Además
porque permite una clara separación entre los componentes de un
programa; lo cual nos permite implementarlos por separado.
VISTA: Es la respuesta de cada controlador y lo que se le presenta al usuario
final, usualmente un elemento de interfaz de usuario en un formato adecuado
para interactuar.
Organización de la Vista
Como ya se mencionó anteriormente la capa de vista de acuerdo al patrón
MVC tendra los formularios que podrá visualizar los diferentes tipos de
usuario en el Sistema de Nóminas.

Fecha: 10/05/2013
Controlador: En esta capa se crea el controlador que es el encargado de
recoger la interacción del usuario con el sistema y llamar a la capa de modelo
para realizar la operación deseada. Una vez la capa de modelo devuelve el
control al controlador, este redirecciona la petición a otra página que
visualizará el usuario.
Modelo: Es la capa encargada de encapsular toda la lógica de negocio de
nuestra aplicación. Se encarga de atender a las peticiones de los
controladores y así dar una respuesta acorde con lo recibido y tambien de
gestionar toda la interconexión con el SGBD.
1.3.2. Diagrama de Colaboración
Representación gráfica de las clases y de las instancias
Con cada tipo de elemento del UML (clase, actor), una instancia utiliza el
mismo símbolo gráfico usado para representar el tipo, pero se subraya el
texto.
Por tanto, para incluir la instancia de una clase en un diagrama de
interacción, se recurre al símbolo gráfico usual de la casilla de la clase, solo
el nombre se subraya.
Venta :Venta s1: Venta
clase instancia instancia
con nombre

Fecha: 10/05/2013
En un diagrama de colaboración, al nombre de la clase siempre se le
antepone dos puntos.
Finalmente, un nombre de distancia sirve para identificarla de modo
inequívoco.
Representación gráfica de los vínculos
El vínculo es una trayectoria de conexión entre dos instancias; indica alguna
forma de navegación y visibilidad que es posible entre las instancias. En un
lenguaje más formal, el vínculo es una instancia de una asociación. Si
vemos dos instancias en una relación de cliente/servidor, una trayectoria de
navegación del cliente al servidor significa que los mensajes pueden
enviarse del primero al segundo. Así, existe un vínculo entre TPDV y una
Ventana, a lo largo del cual pueden fluir los mensajes.
Representación gráfica de los mensajes
Los mensajes entre objetos pueden representarse por medio de una flecha
con un nombre y situada sobre una línea del vínculo. A través de éste puede
fluir un número indefinido de mensajes. Se agrega un número de secuencia
que indique el orden consecutivo de los mensajes en la serie de control.

Fecha: 10/05/2013
Representación gráfica de los parámetros
Los parámetros de un mensaje pueden anotarse dentro de paréntesis del
nombre del mensaje. Es opcional incluir o no el tipo de parámetro en
cuestión.
Representación gráfica del mensaje de devolver valor
Pueden incluir un valor de retorno anteponiéndole al mensaje un nombre de
variable de esa instrucción y un operador de asignación. Es opciones
mostrar el tipo de valor retorno.
Sintaxis de los mensajes
El lenguaje UML cuenta con una sintaxis estándar para los mensajes:
retorno: mensaje(parámetro : tipoParámetro ) : tipoRetorno
Es legal servirse de otra sintaxis como la de Java o la de Smalltalk.
Recomendamos emplear la sintaxis estándar de UML a fin de que los
diagramas de colaboración sigan siendo un lenguaje relativamente

Fecha: 10/05/2013
independiente.
Representación gráfica de los mensajes al “emisor” o a “esto”
Puede enviarse un mensaje de un objeto a sí mismo.
Esto lo muestra gráficamente un vínculo consigo mismo, donde el mensaje
fluye a lo largo del vínculo.
Representación gráfica de la iteración
La iteración se indica posponiendo un asterisco (*) al número de secuencia.
Ese símbolo significa que, dentro de un ciclo, el mensaje va a ser enviado
repetidamente al receptor.

Fecha: 10/05/2013
1.3.3. Diagrama de Actividades
Diagrama de Actividad
Semántica
Estos diagramas muestran básicamente actividades, representando la
realización de operaciones y las transiciones son disparadas por la
finalización de estas operaciones.
Notación
Un diagrama de actividad es un caso especial de un diagrama de estados en
donde todos o al menos la mayoría de los estados son estados de acciones
y en donde todas o al menos la mayoría de las transiciones son disparadas
por la finalización de las acciones que las alimentan. Un diagrama de
actividad está asociado a la implementación de un caso de uso.
Acción
Semántica
Un estado de acción, o acción simplemente es una representación de un
estado con una acción interna y al menos una transición saliente que es el
evento implícito de finalización de la acción interna. Las acciones no deben
tener transiciones internas o transiciones salientes basadas en eventos
explícitos: se deben usar otras acciones para esta situación. El uso normal
de una acción es modelar un paso o un conjunto de pasos en la ejecución
de un algoritmo (un procedimiento).
Notación

Fecha: 10/05/2013
Una acción es mostrada como una figura con la parte superior e inferior
recta y con arcos convexos en los dos lados. La expresión de acción se
ubica dentro del símbolo. La expresión de acción no es necesariamente
única dentro del diagrama, y debe comenzar con un verbo en infinitivo.
Las transiciones salientes de las acciones no deben incluir un nombre de
evento; ya que estas transiciones son disparadas implícitamente por la
finalización de la acción. Las transiciones pueden incluir condiciones y
acciones.
Opciones de Presentación
La acción puede ser descrita mediante lenguaje natural o pseudocódigo.
Decisiones
Semántica
Un diagrama de actividad expresa una decisión cuando una condición es
usada para indicar diferentes transiciones posibles que dependen de un
valor booleano.
Notación
Una decisión puede ser mostrada etiquetando varias transiciones salientes
de una acción con diferentes condiciones.
El icono provisto para una decisión es la tradicional figura con forma de
diamante, con una o más flechas entrantes y con dos o más flechas
salientes, cada una etiquetada por una condición diferente y sin evento que
la dispare. Todos los posibles valores para la condición deben aparecer en
las transiciones salientes.

Fecha: 10/05/2013
Actividades
Semántica
Las acciones pueden ser organizadas en andariveles. Los andariveles se
usan para organizar las responsabilidades de las actividades. Usualmente
corresponden a unidades organizacionales dentro de un modelo de negocio
(por ejemplo áreas de una empresa).
No debemos olvidar que cuando estamos modelando los casos de uso, las
actividades que realiza el sistema que estamos empezando a idear pueden
ser llevadas a cabo tanto por máquinas como por personas que pertenezcan
a distintas áreas de la organización. La utilidad de los andariveles aparece
en estos casos, cuando quiero mostrar que la secuencia de pasos que el
usuario está expresando como parte del procesamiento del sistema es
realizada por personas de distintas áreas o distintos tipos de máquinas.
Notación
Un diagrama de actividad puede ser dividido visualmente en andariveles
separados de sus andariveles vecinos por líneas sólidas verticales a ambos
lados. Cada andarivel representa la responsabilidad para una parte del
conjunto de actividades. El ordenamiento relativo de los andariveles no tiene
importancia semántica pero puede llegar a indicar alguna afinidad. Cada
acción es asignada a un único andarivel.
1.3.4. Diagrama de Secuencias
En un diagrama de secuencia se indicarán los módulos o clases que forman
parte del programa y las llamadas que se hacen en cada uno de ellos para
realizar una tarea determinada.

Fecha: 10/05/2013
Se realizan diagramas de secuencia para definir acciones que se pueden
realizar en la aplicación en cuestión. Así, en el caso de una aplicación para
jugar al ajedrez, se podrían realizar diagramas de secuencia para “jugar una
partida” o bien para acciones más específicas como “mover pieza”.
El detalle que se muestre en el diagrama de secuencia debe estar en
consonancia con lo que se intenta mostrar o bien con la fase de desarrollo
en la que esté el proyecto, no es lo mismo un diagrama de secuencia que
muestre la acción de “mover pieza” a otro que sea “mover caballo”, o bien no
es lo mismo un diagrama de secuencia “mover pieza” que verifique ciertos
parámetros antes de mover como la viabilidad del movimiento con respecto
a una estrategia marcada a una diagrama que no muestre este nivel de
detalle por estar en una fase inicial de diseño del sistema.
El detalle del diagrama depende de la fase en la que estemos, lo que
pretendamos contar con el diagrama y a quién. En una primera fase de
diseño podemos poner clases grandes y ficticias, que representen un
paquete/librería o, si nuestro programa está compuesto por varios
ejecutables corriendo a la vez, incluso clases que representen un ejecutable.
2. MODELO ESTÁTICO DEL SISTEMA
2.1. Diagrame de Clases

Fecha: 10/05/2013
3. MODELO DINÁMICO DEL SISTEMA
3.1. Diagrama de Colaboración
3.1.1. Administrador General
3.1.1.1. Login

Fecha: 10/05/2013
3.1.1.2. Gestionar Usuarios

Fecha: 10/05/2013
3.1.2. Administrador Sucursal
3.1.2.1. Gestionar Empleado

Fecha: 10/05/2013
3.1.2.2. Registrar Ingreso
3.1.2.3. Registrar Egreso

Fecha: 10/05/2013
3.2. Diagrama de Secuencia
3.2.1. Administrador General
3.2.1.1. Login
3.2.1.2. Gestionar Usuarios

Fecha: 10/05/2013
3.2.2. Administrador Sucursal
3.2.2.1. Gestionar Empleado
3.2.2.2. Registrar Ingreso

Fecha: 10/05/2013
3.2.3. Registrar Egreso

Arquitectura integra 2

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Arquitectura integra 2

Similar a Arquitectura integra 2 (20)

Más de Jose Torres Gonzales

Más de Jose Torres Gonzales (15)

Arquitectura integra 2