arquitectura integra 2

GABY SPA & SALÓN

Sistema de NóminasArquitectura 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 Autor04/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

Documents