SlideShare una empresa de Scribd logo
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
SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
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
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 3
SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
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.
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 4
SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
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.
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 5
Venta :Venta s1: Venta
clase instancia instancia
con nombre
SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
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.
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 6
SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
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
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 7
SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
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.
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 8
SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
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
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 9
SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
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.
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 10
SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
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.
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 11
SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
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
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 12
SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
3. MODELO DINÁMICO DEL SISTEMA
3.1. Diagrama de Colaboración
3.1.1. Administrador General
3.1.1.1. Login
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 13
SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
3.1.1.2. Gestionar Usuarios
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 14
SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
3.1.2. Administrador Sucursal
3.1.2.1. Gestionar Empleado
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 15
SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
3.1.2.2. Registrar Ingreso
3.1.2.3. Registrar Egreso
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 16
SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
3.2. Diagrama de Secuencia
3.2.1. Administrador General
3.2.1.1. Login
3.2.1.2. Gestionar Usuarios
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 17
SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
3.2.2. Administrador Sucursal
3.2.2.1. Gestionar Empleado
3.2.2.2. Registrar Ingreso
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 18
SISTEMA DE NÓMINAS Versión: 0.9
Fecha: 10/05/2013
Documento Arquitectura Integra
3.2.3. Registrar Egreso
SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 19

Más contenido relacionado

La actualidad más candente

Caso de Uso
Caso de UsoCaso de Uso
Caso de Uso
utrilla
 
Mcvs mn-01 casos de uso de negocio
Mcvs mn-01 casos de uso de negocioMcvs mn-01 casos de uso de negocio
Mcvs mn-01 casos de uso de negocio
giancarlo Aguirre Campos
 
Implementacion de control de pago de agua
Implementacion de control de pago de aguaImplementacion de control de pago de agua
Implementacion de control de pago de agua
Jean Carlos
 
Documento vision
Documento visionDocumento vision
Documento vision
Jose Torres Gonzales
 
Tm03 modelo de casos de uso
Tm03 modelo de casos de usoTm03 modelo de casos de uso
Tm03 modelo de casos de uso
Julio Pari
 
Plan de desarrollo software
Plan de desarrollo softwarePlan de desarrollo software
Plan de desarrollo software
Jose Torres Gonzales
 
IEEE 1471-2000: Documento de arquitectura de software
IEEE 1471-2000: Documento de arquitectura de softwareIEEE 1471-2000: Documento de arquitectura de software
IEEE 1471-2000: Documento de arquitectura de software
Jesús Navarro
 
Plan desarrollo software
Plan desarrollo softwarePlan desarrollo software
Plan desarrollo software
Michael Daniel Murillo
 
Plan de Desarrollo de Software - Sistema Gestor de Oferta y Adjudicación de P...
Plan de Desarrollo de Software - Sistema Gestor de Oferta y Adjudicación de P...Plan de Desarrollo de Software - Sistema Gestor de Oferta y Adjudicación de P...
Plan de Desarrollo de Software - Sistema Gestor de Oferta y Adjudicación de P...
Yessenia I. Martínez M.
 
Modelo de casos de uso 2ª versión(2)
Modelo de casos de uso 2ª versión(2)Modelo de casos de uso 2ª versión(2)
Modelo de casos de uso 2ª versión(2)
Jose Torres Gonzales
 
Casos de uso de negocios y sistemas
Casos de uso de negocios y sistemasCasos de uso de negocios y sistemas
Casos de uso de negocios y sistemas
servicio medicina aeronautica
 
Documento arquitectura de software
Documento arquitectura de softwareDocumento arquitectura de software
Documento arquitectura de software
AURA SYSTEMS S.A.C
 
Equipo#2 wiki2-caso de uso- diagrama de caso de uso- uml
Equipo#2 wiki2-caso de uso- diagrama de caso de uso- umlEquipo#2 wiki2-caso de uso- diagrama de caso de uso- uml
Equipo#2 wiki2-caso de uso- diagrama de caso de uso- uml
marimallol
 
Diagrama de actividades inscripcion, evaluacion, Asistencia
Diagrama de actividades inscripcion, evaluacion, AsistenciaDiagrama de actividades inscripcion, evaluacion, Asistencia
Diagrama de actividades inscripcion, evaluacion, Asistencia
Robert Rodriguez
 
Gestión del riesgo de software
Gestión del riesgo de software Gestión del riesgo de software
Gestión del riesgo de software
jose_macias
 
Perfiles UML
Perfiles UMLPerfiles UML
Perfiles UML
Jose R. Hilera
 
Diagramas de colaboracion
Diagramas de colaboracionDiagramas de colaboracion
Diagramas de colaboracion
d-draem
 
Requerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicaciónRequerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicación
Yare LoZada
 
Metodología RUP
Metodología RUPMetodología RUP
Metodología RUP
Jorge Cortés Alvarez
 
Rational rose
Rational roseRational rose
Rational rose
Israel Chava Gonzales
 

La actualidad más candente (20)

Caso de Uso
Caso de UsoCaso de Uso
Caso de Uso
 
Mcvs mn-01 casos de uso de negocio
Mcvs mn-01 casos de uso de negocioMcvs mn-01 casos de uso de negocio
Mcvs mn-01 casos de uso de negocio
 
Implementacion de control de pago de agua
Implementacion de control de pago de aguaImplementacion de control de pago de agua
Implementacion de control de pago de agua
 
Documento vision
Documento visionDocumento vision
Documento vision
 
Tm03 modelo de casos de uso
Tm03 modelo de casos de usoTm03 modelo de casos de uso
Tm03 modelo de casos de uso
 
Plan de desarrollo software
Plan de desarrollo softwarePlan de desarrollo software
Plan de desarrollo software
 
IEEE 1471-2000: Documento de arquitectura de software
IEEE 1471-2000: Documento de arquitectura de softwareIEEE 1471-2000: Documento de arquitectura de software
IEEE 1471-2000: Documento de arquitectura de software
 
Plan desarrollo software
Plan desarrollo softwarePlan desarrollo software
Plan desarrollo software
 
Plan de Desarrollo de Software - Sistema Gestor de Oferta y Adjudicación de P...
Plan de Desarrollo de Software - Sistema Gestor de Oferta y Adjudicación de P...Plan de Desarrollo de Software - Sistema Gestor de Oferta y Adjudicación de P...
Plan de Desarrollo de Software - Sistema Gestor de Oferta y Adjudicación de P...
 
Modelo de casos de uso 2ª versión(2)
Modelo de casos de uso 2ª versión(2)Modelo de casos de uso 2ª versión(2)
Modelo de casos de uso 2ª versión(2)
 
Casos de uso de negocios y sistemas
Casos de uso de negocios y sistemasCasos de uso de negocios y sistemas
Casos de uso de negocios y sistemas
 
Documento arquitectura de software
Documento arquitectura de softwareDocumento arquitectura de software
Documento arquitectura de software
 
Equipo#2 wiki2-caso de uso- diagrama de caso de uso- uml
Equipo#2 wiki2-caso de uso- diagrama de caso de uso- umlEquipo#2 wiki2-caso de uso- diagrama de caso de uso- uml
Equipo#2 wiki2-caso de uso- diagrama de caso de uso- uml
 
Diagrama de actividades inscripcion, evaluacion, Asistencia
Diagrama de actividades inscripcion, evaluacion, AsistenciaDiagrama de actividades inscripcion, evaluacion, Asistencia
Diagrama de actividades inscripcion, evaluacion, Asistencia
 
Gestión del riesgo de software
Gestión del riesgo de software Gestión del riesgo de software
Gestión del riesgo de software
 
Perfiles UML
Perfiles UMLPerfiles UML
Perfiles UML
 
Diagramas de colaboracion
Diagramas de colaboracionDiagramas de colaboracion
Diagramas de colaboracion
 
Requerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicaciónRequerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicación
 
Metodología RUP
Metodología RUPMetodología RUP
Metodología RUP
 
Rational rose
Rational roseRational rose
Rational rose
 

Similar a Arquitectura integra 2

Presentacion uml dian1_2003
Presentacion uml dian1_2003Presentacion uml dian1_2003
Presentacion uml dian1_2003
Diana Vásquez
 
Introducción a UML
Introducción a UMLIntroducción a UML
Introducción a UML
Hermes Romero
 
Tecno
TecnoTecno
Estructuras basicas
Estructuras basicasEstructuras basicas
Estructuras basicas
AlejandroLozada20
 
Tecnologia
TecnologiaTecnologia
Estructuras básicas
Estructuras básicas Estructuras básicas
Estructuras básicas
alancardona3
 
ESTRUCTURAS BÁSICAS
ESTRUCTURAS BÁSICASESTRUCTURAS BÁSICAS
ESTRUCTURAS BÁSICAS
Sara Sofía Imbachí Nieto
 
Estructuras básicas
Estructuras básicas Estructuras básicas
Estructuras básicas
alancardona3
 
13 Clase Flujo De Analisis
13 Clase Flujo De Analisis13 Clase Flujo De Analisis
13 Clase Flujo De Analisis
Julio Pari
 
Trabajo final fredy
Trabajo final fredyTrabajo final fredy
Trabajo final fredy
fredyverg
 
UML - Diagramas de Actividades, componentes y clases
UML - Diagramas de Actividades, componentes y clasesUML - Diagramas de Actividades, componentes y clases
UML - Diagramas de Actividades, componentes y clases
ErickMontesdeoca5
 
Diagramas deactividad
Diagramas deactividadDiagramas deactividad
Diagramas deactividad
Antonio Mora
 
Uml
UmlUml
Tutorial-StarUML.pdf
Tutorial-StarUML.pdfTutorial-StarUML.pdf
Tutorial-StarUML.pdf
None
 
ADS - Sesion2
ADS - Sesion2ADS - Sesion2
ADS - Sesion2
willy0303
 
Modelamiento visual-y-uml346
Modelamiento visual-y-uml346Modelamiento visual-y-uml346
Modelamiento visual-y-uml346
Mguel
 
MODELAMIENTO VISUAL Y UML
MODELAMIENTO VISUAL Y UMLMODELAMIENTO VISUAL Y UML
MODELAMIENTO VISUAL Y UML
Kudos S.A.S
 
Mis diapositivas uml
Mis diapositivas umlMis diapositivas uml
Mis diapositivas uml
Beatriz Moreyra
 
Diagramas de flujo
Diagramas de flujoDiagramas de flujo
Diagramas de flujo
lordXDie
 
Modelamiento uml
Modelamiento umlModelamiento uml
Modelamiento uml
alejo_13
 

Similar a Arquitectura integra 2 (20)

Presentacion uml dian1_2003
Presentacion uml dian1_2003Presentacion uml dian1_2003
Presentacion uml dian1_2003
 
Introducción a UML
Introducción a UMLIntroducción a UML
Introducción a UML
 
Tecno
TecnoTecno
Tecno
 
Estructuras basicas
Estructuras basicasEstructuras basicas
Estructuras basicas
 
Tecnologia
TecnologiaTecnologia
Tecnologia
 
Estructuras básicas
Estructuras básicas Estructuras básicas
Estructuras básicas
 
ESTRUCTURAS BÁSICAS
ESTRUCTURAS BÁSICASESTRUCTURAS BÁSICAS
ESTRUCTURAS BÁSICAS
 
Estructuras básicas
Estructuras básicas Estructuras básicas
Estructuras básicas
 
13 Clase Flujo De Analisis
13 Clase Flujo De Analisis13 Clase Flujo De Analisis
13 Clase Flujo De Analisis
 
Trabajo final fredy
Trabajo final fredyTrabajo final fredy
Trabajo final fredy
 
UML - Diagramas de Actividades, componentes y clases
UML - Diagramas de Actividades, componentes y clasesUML - Diagramas de Actividades, componentes y clases
UML - Diagramas de Actividades, componentes y clases
 
Diagramas deactividad
Diagramas deactividadDiagramas deactividad
Diagramas deactividad
 
Uml
UmlUml
Uml
 
Tutorial-StarUML.pdf
Tutorial-StarUML.pdfTutorial-StarUML.pdf
Tutorial-StarUML.pdf
 
ADS - Sesion2
ADS - Sesion2ADS - Sesion2
ADS - Sesion2
 
Modelamiento visual-y-uml346
Modelamiento visual-y-uml346Modelamiento visual-y-uml346
Modelamiento visual-y-uml346
 
MODELAMIENTO VISUAL Y UML
MODELAMIENTO VISUAL Y UMLMODELAMIENTO VISUAL Y UML
MODELAMIENTO VISUAL Y UML
 
Mis diapositivas uml
Mis diapositivas umlMis diapositivas uml
Mis diapositivas uml
 
Diagramas de flujo
Diagramas de flujoDiagramas de flujo
Diagramas de flujo
 
Modelamiento uml
Modelamiento umlModelamiento uml
Modelamiento uml
 

Más de Jose Torres Gonzales

Modelo de implementación
Modelo de implementaciónModelo de implementación
Modelo de implementación
Jose Torres Gonzales
 
Prototipos2
Prototipos2Prototipos2
Modelo implementacion
Modelo implementacionModelo implementacion
Modelo implementacion
Jose Torres Gonzales
 
Modelo de diseño vladimir
Modelo de diseño  vladimirModelo de diseño  vladimir
Modelo de diseño vladimir
Jose Torres Gonzales
 
Modelo de despliegue
Modelo de despliegueModelo de despliegue
Modelo de despliegue
Jose Torres Gonzales
 
Modelo de datos2 2
Modelo de datos2 2Modelo de datos2 2
Modelo de datos2 2
Jose Torres Gonzales
 
Arquitectura de referencia
Arquitectura de referenciaArquitectura de referencia
Arquitectura de referencia
Jose Torres Gonzales
 
Modelo de analisis2
Modelo de analisis2Modelo de analisis2
Modelo de analisis2
Jose Torres Gonzales
 
Especificacion de requerimientos
Especificacion de requerimientosEspecificacion de requerimientos
Especificacion de requerimientos
Jose Torres Gonzales
 
Arquitectura del software
Arquitectura del softwareArquitectura del software
Arquitectura del software
Jose Torres Gonzales
 
Glosario
GlosarioGlosario
Cusistema
CusistemaCusistema
Vision del negocio 1
Vision del negocio 1Vision del negocio 1
Vision del negocio 1
Jose Torres Gonzales
 
Modelo del negocio
Modelo del negocioModelo del negocio
Modelo del negocio
Jose Torres Gonzales
 
Documento glosario
Documento glosarioDocumento glosario
Documento glosario
Jose Torres Gonzales
 
INTRODUCCION
INTRODUCCIONINTRODUCCION
INTRODUCCION
Jose Torres Gonzales
 

Más de Jose Torres Gonzales (17)

Modelo de implementación
Modelo de implementaciónModelo de implementación
Modelo de implementación
 
Prototipos2
Prototipos2Prototipos2
Prototipos2
 
Modelo implementacion
Modelo implementacionModelo implementacion
Modelo implementacion
 
Modelo de diseño vladimir
Modelo de diseño  vladimirModelo de diseño  vladimir
Modelo de diseño vladimir
 
Modelo de despliegue
Modelo de despliegueModelo de despliegue
Modelo de despliegue
 
Modelo de datos2 2
Modelo de datos2 2Modelo de datos2 2
Modelo de datos2 2
 
Arquitectura de referencia
Arquitectura de referenciaArquitectura de referencia
Arquitectura de referencia
 
Modelo de analisis2
Modelo de analisis2Modelo de analisis2
Modelo de analisis2
 
Especificacion de requerimientos
Especificacion de requerimientosEspecificacion de requerimientos
Especificacion de requerimientos
 
Arquitectura del software
Arquitectura del softwareArquitectura del software
Arquitectura del software
 
Glosario
GlosarioGlosario
Glosario
 
Cusistema
CusistemaCusistema
Cusistema
 
Vision del negocio 1
Vision del negocio 1Vision del negocio 1
Vision del negocio 1
 
Modelo del negocio
Modelo del negocioModelo del negocio
Modelo del negocio
 
Documento glosario
Documento glosarioDocumento glosario
Documento glosario
 
INTRODUCCION
INTRODUCCIONINTRODUCCION
INTRODUCCION
 
PROTOTIPOS
PROTOTIPOSPROTOTIPOS
PROTOTIPOS
 

Arquitectura integra 2

  • 1. GABY SPA & SALÓN Sistema de Nóminas Arquitectura Integra Versión 0.9
  • 2. 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
  • 3. SISTEMA DE NÓMINAS Versión: 0.9 Fecha: 10/05/2013 Documento Arquitectura Integra 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 SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 3
  • 4. SISTEMA DE NÓMINAS Versión: 0.9 Fecha: 10/05/2013 Documento Arquitectura Integra 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. SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 4
  • 5. SISTEMA DE NÓMINAS Versión: 0.9 Fecha: 10/05/2013 Documento Arquitectura Integra 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. SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 5 Venta :Venta s1: Venta clase instancia instancia con nombre
  • 6. SISTEMA DE NÓMINAS Versión: 0.9 Fecha: 10/05/2013 Documento Arquitectura Integra 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. SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 6
  • 7. SISTEMA DE NÓMINAS Versión: 0.9 Fecha: 10/05/2013 Documento Arquitectura Integra 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 SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 7
  • 8. SISTEMA DE NÓMINAS Versión: 0.9 Fecha: 10/05/2013 Documento Arquitectura Integra 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. SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 8
  • 9. SISTEMA DE NÓMINAS Versión: 0.9 Fecha: 10/05/2013 Documento Arquitectura Integra 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 SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 9
  • 10. SISTEMA DE NÓMINAS Versión: 0.9 Fecha: 10/05/2013 Documento Arquitectura Integra 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. SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 10
  • 11. SISTEMA DE NÓMINAS Versión: 0.9 Fecha: 10/05/2013 Documento Arquitectura Integra 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. SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 11
  • 12. SISTEMA DE NÓMINAS Versión: 0.9 Fecha: 10/05/2013 Documento Arquitectura Integra 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 SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 12
  • 13. SISTEMA DE NÓMINAS Versión: 0.9 Fecha: 10/05/2013 Documento Arquitectura Integra 3. MODELO DINÁMICO DEL SISTEMA 3.1. Diagrama de Colaboración 3.1.1. Administrador General 3.1.1.1. Login SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 13
  • 14. SISTEMA DE NÓMINAS Versión: 0.9 Fecha: 10/05/2013 Documento Arquitectura Integra 3.1.1.2. Gestionar Usuarios SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 14
  • 15. SISTEMA DE NÓMINAS Versión: 0.9 Fecha: 10/05/2013 Documento Arquitectura Integra 3.1.2. Administrador Sucursal 3.1.2.1. Gestionar Empleado SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 15
  • 16. SISTEMA DE NÓMINAS Versión: 0.9 Fecha: 10/05/2013 Documento Arquitectura Integra 3.1.2.2. Registrar Ingreso 3.1.2.3. Registrar Egreso SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 16
  • 17. SISTEMA DE NÓMINAS Versión: 0.9 Fecha: 10/05/2013 Documento Arquitectura Integra 3.2. Diagrama de Secuencia 3.2.1. Administrador General 3.2.1.1. Login 3.2.1.2. Gestionar Usuarios SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 17
  • 18. SISTEMA DE NÓMINAS Versión: 0.9 Fecha: 10/05/2013 Documento Arquitectura Integra 3.2.2. Administrador Sucursal 3.2.2.1. Gestionar Empleado 3.2.2.2. Registrar Ingreso SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 18
  • 19. SISTEMA DE NÓMINAS Versión: 0.9 Fecha: 10/05/2013 Documento Arquitectura Integra 3.2.3. Registrar Egreso SISTEMA DE NÓMINAS – GABY SPA & SALON Pág. 19