Autor: juliocesar20200413 Página 105 de 141

Desarrollador web apasionado y gusto por la buena musica

¿QUE ES UN RIESGO PARA UN PROYECTO DE SOFTWARE?

Un riesgo es aquel factor que influye negativamente en el éxito del proyecto. El riesgo en un proyecto de desarrollo de software incluye componentes técnicos y de conocimiento del mismo. Los temas de naturaleza organizacional constituyen los factores dominantes de los riesgos del proyecto, a la vez que son los que se tratan satisfactoriamente en menos de la tercera parte de los proyectos de desarrollo, entre ellos los conflictos entre departamentos, entre usuarios, el cambio del responsable ejecutivo del proyecto, volatilidad del personal, número de unidades de la organización implicadas y proyectos que involucran a múltiples proveedores.

¿CUAL ES LA IMPORTANCIA DE LA GESTION DE RIESGOS?

Para lograr producir aquello que el cliente requiere, en el plazo solicitado y ajustados al presupuesto asignado, se necesita desarrollar un proceso que incluya desde la etapa más temprana la gestión de los riesgos asociados a los requisitos, de forma que se contribuya al mejoramiento gradual del proceso de desarrollo y la gestión de un proyecto de software que logre la satisfacción del cliente.

La identificación y gestión de los riesgos asociados a los requisitos del software, individuales y a grupos de ellos, desde la fase de ingeniería de requisitos puede permitir minimizarlos, evadirlos y controlarlos. El enfrentamiento proactivo de los riesgos que pueden afectar al desarrollo o a la calidad de los requisitos y las acciones para evitarlos, permitirían minimizar problemas que persisten en el desarrollo de software. Son de mayor importancia los riesgos asociados a las principales características de calidad de los requisitos.

¿DEFINE LAS ETAPAS DEL MODELO DE GESTION DE RIESGOS?

· IDENTIFICACION DE RIESGOS

El Tratar de identificar riesgos es un criterio proactivo que busca identificar posibles factores de riesgo y tomar medidas de factores de riesgos y tomar medidas de aseguramiento o planes de contingencia para contrarrestarlos a ellos y a sus efectos.

Al realizar esta identificación podría hablarse de riesgos genéricos y riesgos específicos del producto.

LISTADO DE RIESGOS POTENCIALES

TIPO DE RIESGO	INDICADORES POTENCIALES
Tecnológico	Entrega retrasada del hardware o de la ayuda al software, muchos problemas tecnológicos reportados.
Personal	Baja moral del personal, malas relaciones entre los miembros del equipo, disponibilidad de empleo.
Organizacional	Chismorreo organizacional, falta de acciones por el administrador principal.
Herramientas	Rechazo de los miembros del equipo para utilizar herramientas, quejas acerca de las herramientas CASE, peticiones de estaciones de trabajo mas potentes.
Requerimientos	Peticiones de muchos cambios en los requerimientos, quejas del cliente.
Estimación	Fracaso en el cumplimiento de los tiempos acordados, y en la eliminación de defectos reportados.

ANALISIS DE RIEGOS

Durante este proceso, se considera por separado cada riesgo identificado y se decide acerca de la probabilidad y la seriedad del mismo.

No existe una forma fácil de hacer esto, Recae en la opinión del administrador del proyecto. No se hace una valoración con números precisos sino en intervalos.

RIESGO	PROBABILIDAD	EFECTOS
Los problemas financieros de la organización fuerzan a reducir el presupuesto del proyecto.	Baja	Catastrófico
Es imposible reclutar personal con las habilidades requeridas para el proyecto.	Alta	Catastrófico
El personal clave esta enfermo y no disponible en momentos críticos.	Moderada	Serio
Los componentes de software a reutilizarse contienen defectos que limitan su funcionalidad.	Moderada	Serio
Se proponen cambios en los requerimientos que requieren rehacer el diseño.	Moderada	Serio
La organización se reestructura de tal forma que una administración diferente se responsabiliza del proyecto.	Alta	Serio
La BD que se utiliza en el sistema no puede procesar muchas transacciones por segundo como se esperaba.	Moderada	Serio
El tiempo requerido para desarrollar el software esta subestimado.	Alta	Serio
Las herramientas CASE no se pueden integrar.	Alta	Tolerable
Los clientes no comprenden el impacto de los cambios en los requerimientos.	Moderada	Tolerable
La capacitación solicitada para el personal no esta disponible.	Moderada	Tolerable
La tasa de reparación de defectos esta subestimada.	Moderada	Tolerable
El tamaño del software esta subestimado.	Alta	Tolerable

PLANEACION DE RIESGOS

Se establece un plan de gestión del riesgo para cada uno de los riesgos clave identificados.

Depende del conocimiento y la experiencia del gestor del proyecto.

Estrategias de anulación o prevención.
Estrategias de disminución o minimización
Planes de contingencia.

RIESGO	ESTRATEGIA
Problemas financieros de la organización	Preparar un documento breve para el administrador principal que muestre que el proyecto hace contribuciones muy importantes a las metas del negocio.
Problemas de reclutamiento	Alertar al cliente de las dificultades potenciales y las posibilidades de retraso, investigar los componentes comprados.
Enfermedad del personal	Reorganizar el equipo de tal forma que haya traslape en el trabajo y las personas comprendan en de los demás.
Componentes defectuosos	Reemplazar los componentes defectuosos con los comprados de fiabilidad conocida.
Cambios en los requerimientos	Rastrear la información para valorar el impacto de los requerimientos, maximizar la información oculta en ellos.
Restructuración organizacional	Preparar un documento breve para el administrador principal que muestre que el proyecto hace contribuciones muy importantes a las metas del negocio.
Desempeño de la base de datos	Investigar la posibilidad de comprar una BD con alto desempeño
Tiempo de desarrollo subestimado	Investigar los componentes comprados y la utilización de una generador de programas.

SUPERVICION DEL RIESGO

Valora cada uno de los riesgos identificados para decidir si este es más o menos probable y cuando los efectos del mismo han cambiado.

Se hace una valoración después de alcanzar cada hito principal.
Encargado de riesgos:
Alertar sobre los riesgos del proyecto y evitar que los administradores y desarrolladores los ignoren en la planificación.
Buscar todas las razones por las cuales el proyecto puede fallar.
Supervisar la efectividad de los planes de reducción de riesgos.

Realizar el clásico análisis costo-beneficio para la prevención o el plan de contingencia del riesgo.

La supervisión del riesgo debe ser un proceso continuo y en cada revisión del progreso de la administración cada uno de los riesgos clave debe ser considerado por separado y discutido.

Modelado de implementación

por juliocesar20200413

en septiembre 29, 2012

en Sin categoría

Para que se usa un diagrama de despliegue

Se utiliza para modelar el hardware utilizado en las implementaciones del sistema y las relaciones entre sus componentes los elementos usados en este tipo de diagramas son:

Sistema empotrado
Sistema cliente-servidor
Sistema completamente distribuido

Que es un nodo

Es un punto de una onda estacionaria cuya amplitud es 0 un punto de interacción o unión de varios elementos que confluyen en el mismo lugar.

Representación de un nodo

Ejemplo de un diagrama de despliegue

Diagrama de despliegue

Es un diagrama tipo de lenguaje unificado de modelador, representa como un sistema de software es dividido en componente y muestra las desventajas entre estos campos puede ser usado para modelar cualquier arquitectura de sistemas.

Que es un componente

Componentes, acerca de las características de software, la elaboración de un definición única la utilización de una específica depende del contexto en donde se esté empleando el comportamiento de los acuerdos que se hagan dentro del marco de trabajo.

Representación de un componente

Ejemplo de diagrama de componentes

Modelo de arquitectura de interacción

Diagrama secuencial

Diagrama de despliegue

Especificación de requerimientos de software

por juliocesar20200413

en septiembre 29, 2012

en Sin categoría

La especificación de software es la descripción completa del comportamiento del sistema que se va a desarrollar

Diagramas UML usados en la ERS

Los diagramas utilizados en la ERS son:

Casos de usos
Diagramas de flujo
Interfaces graficas de usuario

Riesgos de un mal ERS

Los riesgos mas comunes al hacer una mala especificación de requerimientos de software es en primer lugar la perdida de tiempo del cliente como de nuestros empleado, a esto le sigue la perdida de dinero junto con un cliente irritado que hará ver a los demás la mala calidad del desarrollo.

Clasificación de los requerimientos

De usuario: Deben describir los requerimientos funcionales o no funcionales que sean comprensible para los usuarios.

De sistema: Son versiones extendidas de los requerimientos de usuario y suelen ser utilizadas por los ingenieros de software. Describe a detalle y explica como el sistema debe proporcionar los requerimientos del usuario. Debe ser una especificación técnica y consistente de un sistema.

Requerimientos funcionales y no funcionales

FUNCIONALES: Son aquellos procesos que están dentro del software que se esta desarrollando.

NO FUNCIONALES: Son aquellos requerimientos externos al software, como puede ser:

Sistema operativo en el que se instalara
Seguridad firewall que se recomienda para su funcionamiento

Diagramas de interacción

Modela el comportamiento dinámico del sistema el flujo de control en una operación. Describe la interacción entre objetos, los objetos interactúan atreves de mensajes para cumplir ciertas tareas. Las interacciones provén un “comportamiento” que se implementa en un caso de uso. Existen dos casos de imitación

Diagrama de colaboración

Enfatizan la organización industrial y recibe mensajes. Gráficamente es una selección, colección de vértices y aros.

Diagramas de secuencia

Ordena tiempo los mensajes. Este diagrama es una tabla que muestra objetos ordenados junto al y de las x y los mensajes, son ordenados en incremento del tiempo junto al eje de las y.

Simbología

Ejemplo de diagrama de colaboración

TABLA COMPARATIVA DE LA ARQUITECTURA MULTI-TIER “MULTI NIVEL”

por juliocesar20200413

en septiembre 16, 2012

en Sin categoría

	1 NIVEL	2 NIVELES	3 NIVELES
BENEFICIOS	· COSTO MININO · TIEMPO DE EJECUCIÓN RAPIDO	· VARIOS USUARIOS PODRAN REALIZAR CONSULTAS DESDE OTRO EQUIPO AL SERVIDOR · MAS SEGURIDAD, POR QUE SOLO EL ADMINISTRADOR DEL SERVIDOR PODRA TENER ACCESO TOTAL A LA BASE DE DATOS	· TIEMPO DE EJECUCIÓN RAPIDO YA QUE LA CARGA DE PROCESOS SE DIVIDEN EN VARIOS EQUIPOS · SEGURIDAD MAS ELEVADA, AL TENER TODO SEPARADO
PROBLEMAS	· TODOS LOS QUE TENGAN ACCESO AL EQUIPO PODRAN TENER ACCESO A LOS DATOS · SOLO UN USUARIO A LA VEZ PODRA REALIZAR CONSULTAS	· EJECUCION LENTA · TODO EL PROCESO SE GENERA EN EL SERVIDOR · ENTRE MAS CLIENTES ESTEN CONECTADOS AL SERVIDOR MAS LENTA SERA LA EJECUCIÓN	· COSTO MAS ELEVADOS AL UTILIZAR MAS EQUIPOS. · COSTOS DE MANTENIMIENTO
USUARIOS SIMULTANEOS	· 1	· MAS DE DOS	· MAS DE DOS

MEMORIA DE SERVICIO DEL INSTITUTO TECNOLÓGICO DE LOS MOCHIS

por juliocesar20200413

en septiembre 16, 2012

en Sin categoría

INSTITUTO TECNOLOGICO

DE LOS MOCHIS

PRESTANTE DEL SERVICIO:

Leyva Rodríguez Julio Cesar

08440863

CARRERA:

Lic. Informática

“MEMORIA DEL SERVICIO SOCIAL”

DEPENDENCIA:
Instituto Tecnológico de Los Mochis

FECHA: 31-08-12

ÍNDICE

Página

Introducción ————————————————————————- 3

Objetivos —————————————————————————– 4

Desarrollo de Actividades ———————————————————-5

Resultados y conclusiones ——————————————————– 6

Recomendaciones —————————————————————— 7

INTRODUCCION

En el presente documento se describirán las actividades y experiencias realizadas durante el desarrollo del servicio social en las instalaciones del Instituto Tecnológico de Los Mochis, En el departamento del centro de cómputo, dando mantenimiento preventivo y correctivo al equipo de cómputo de la institución, así como las conclusiones que obtuvimos al finalizar el periodo de realización del servicio social.

Así como brindar al personal del Instituto Tecnológico de Los Mochis soporte técnico a la problemáticas que surgían durante el periodo que se realizo el servicio.

OBJETIVOS

Dar mantenimiento preventivo y correctivo al equipo de computo de los siguientes departamentos
- Centro de información
- Departamento económico administrativo
- Departamento de centro de cómputo
- Departamento de arquitectura
- Departamento de vinculación
- Departamento de servicios escolares
- Departamento de ciencias básicas
- Departamento de química, bioquímica y biología
- Departamento de electrónica
- Departamento de extraescolares
- Taller de mantenimiento
- Departamento de desarrollo académico
Registrar a los alumnos del Instituto Tecnológico de Los Mochis para que tengan acceso a internet de la institución
Brindar soporte al personal del departamento del centro de computo

DESARROLLO DE ACTIVIDADES

Programar horario para iniciar el mantenimiento, es necesario, por que se suspenderán labores durante el día en que se realice el mantenimiento en dicho departamento
1. Iniciar mantenimiento en el centro de computo
2. Iniciar mantenimiento en el departamento de centro de información
3. Iniciar mantenimiento en el departamento de química, bioquímica y biología
4. Iniciar mantenimiento al departamento de servicios escolares
5. Iniciar mantenimiento al departamento de extraescolares
6. Iniciar mantenimiento al taller de mantenimiento
7. Iniciar mantenimiento al departamento de arquitectura
8. Iniciar mantenimiento al departamento de ciencias básicas
9. Iniciar mantenimiento al departamento de desarrollo económico
10. Iniciar mantenimiento al departamento de electrónica
Dar contraseñas a los alumnos de del Instituto Tecnológicos de Los Mochis para que tengan acceso a internet de la institución, esto se hará cuando al finalizar el mantenimiento preventivo correctivo en los departamentos mencionados.
Dar soporte al personal del centro de computo y demás departamentos, resolviendo problemáticas desde problemas con el sistema operativos hasta programación y desarrollo.
Dar soporte a la página del prenacional deportivo de los Institutos tecnológicos.

RESULTADOS Y CONCLUSIONES

Durante el tiempo que preste mi servicio social en el Instituto Tecnológico de Los Mochis llegue a la conclusión que es de vital importancia el trabajo armónico en equipo, ya que al trabajar en alguna institución o empresa siempre vamos a necesitar de la ayuda de los demás.

Las cosas que aprendí en mi estancia fueron entre otras: diseño web y programación PHP.

RECOMENDACIONES

Mantener los equipos de cómputo en un área limpia.
Evitar sobre cargar el sistema con servicios y aplicaciones de otro tipo
Realizar este mantenimiento cada año
Evitar ingerir alimento en el área de trabajo
Mantener el equipo de cómputo en un área despejada, con buena ventilación y libre de polvo.

DESCARGAR ARCHIVO EN WORD

CREAR UN ARCHIVO PDF DESDE PHP

por juliocesar20200413

en septiembre 7, 2012

en DISEÑO DE PAGINAS WEB, MySQL, MYSQL;CONECTAR PHP MYSQL, php, PHP CURSOS, PHP CURSOS GRATUITOS, PHP MYSQL

A CONTINUACIÓN LES DEJO UN ARHIVO PARA PODER GENERAR UN ARCHIVO PDF CON PHP.

PARA ELLO UTILIZAREMOS LA LIBRERIA DE EZPDF

ABAJO EL CODIGO FUENTE

   1: <?php

2:

   3: //DomPDF

4:

5:

   6: require_once('class.ezpdf.php'); //IMPORTAMOS LA LIBRERIA DE EZPDF

   7: include ('conexionmysql.php');   //IMPORTAMOS LA LIBRERIA PARA REALIZAR LA CONEXIÓN CON MYSQL

8:

   9: $pdf =& new Cezpdf('LETTER');                //SELECCIONAMOS EL EL TAMAÑO DE HOJA DEL ARCHIVO PDF, EN ESTE CASO SERA TAMAÑO CARTA

  10: $pdf->selectFont('../fonts/courier.afm');    //SELECCIONAMOS EL TIPO DE LETRA

  11: $pdf->ezSetCmMargins(1,1,1.5,1.5);           //AQUI VA LOS MARGENES DE LAHOJA

12:

13:

  14:     //GUARDAREMOS EN UNA VARIABLE LOS DATOS PARA LA CONEXIÓN AL GESTOR DE BASE DE DATOS

  15:     $direccion1="localhost";

  16:     $usuario1="root";

  17:     $password1="";

  18:     $basededatos1="bd_itlm";

19:

20:

  21:     //NOS CONECTAMOS A LA BASE DE DATOS LLAMANDO LA FUNCIÓN cononectar_mysql() UTILIZANDO LAS VARIABLES DE ARRIBA

  22:     conectar_mysql("$direccion1","$usuario1","$password1","$basededatos1");

23:

24:

  25: //GUARDAMOS LA CADENA PARA REALIZAR LA CONSULTA

  26: $Presta = "SELECT * FROM usuarios ORDER BY id ASC";

27:

  28: //EJECUTAMOS LA CONSULTA Y GUARDAMOS EL RESULTADO EN UNA VARIABLE

  29: $resPres = mysql_query($Presta);

30:

  31: //GUARDAMOS EL NUEMRO DE FILAS EN OTRA VARIABLE

  32: $total_presta = mysql_num_rows($resPres);

33:

34:

  35: $ixx = 0;

  36: while($datatmp = mysql_fetch_assoc($resPres)){

  37:     $ixx = $ixx+1;

  38:     $data[] = array_merge($datatmp, array('num'=>$ixx));

  39: }

  40: $titles = array(

  41:                 'id'=>'id',

  42:                 'usuario'=>'solicitante',

  43:                 'clave'=>'clave',

  44:             );

  45: $options = array(

  46:                 'shadeCol'=>array(0.9,0.9,0.9),

  47:                 'xOrientation'=>'center',

  48:                 'width'=>500

  49:             );

  50: $txttit = "Instituto Tecnológico de Los Mochisn";

  51: $txttit.= "Reporte general de prestamos de edificiosn";

52:

  53: $pdf->ezimage("escudo.jpg",0,150,'none','center');

  54: $pdf->ezText($txttit, 12);

  55: $pdf->ezTable($data, $titles, '', $options);

  56: $pdf->ezText("nnn", 10);

  57: $pdf->ezText("Fecha: ".date("d/m/Y"), 10);

  58: $pdf->ezText("Hora: ".date("H:i:s")."nn", 10);

  59: ob_end_clean();

  60: $pdf->ezStream();

  61: ?>

LES DEJO LAS LIBRERIAS Y CODIGOS FUENTE PARA QUE LO PUEDAN DESCARGAR, EN ESTE ENLACE ESTA TODO JUNTO CON EL EJEMPLO

DESCARGAR

EN ESTE ENLACE ESTA NOMAS LA LIBRERIA ORIGINAL PARA GENERAR EL PDF

DESCARGAR EZPDF

DEFINICIÓN ARQUITECTURA MULTINIVEL

por juliocesar20200413

en septiembre 6, 2012

en Sin categoría

ARQUITECTURA DE APLICACIONES EMPRESARIALES

ACTIVIDAD 1.2 .1 DEFINICIÓN ARQUITECTURA MULTINIVEL

1.2.2 COMPARACIÓN CON LA ARQUITECTURA MULTICAPA

1.2.3 ¿SE PUEDE FUSIONAR LA ARQUITECTURA MULTINIVEL Y LA

LA ARQUITECTURA MULTICAPA?

1.2.4 ESQUEMA

1.2.5 EJEMPLO DE ARQUITECTURA MULTINIVEL

1.2.1 DEFINICIÓN

Referido como (arquitectura n-tier), es una arquitectura cliente-servidor en la presentación, el procesamiento la solicitud de los datos y la gestión de los datos son físicamente procesos separados.

1.2.2 COMPARACIÓN CON LA ARQUITECTURA MULTICAPA

La diferencia es que la arquitectura multicapa, los procesos están separados en un mismo equipo en cambio en la arquitectura se refiere a separar físicamente los procesos en aplicaciones independientes que trabajan en conjunto.

1.2.3 ¿Se puede fusionar la arquitectura multinivel con la arquitectura multicapa?

Si se puede ya que en una está separada lógicamente y en otra físicamente.

1.2.4 ESQUEMA

1.1.5 EJEMPLO DE FUNCIONAMIENTO

Por ejemplo una aplicación utiliza middleware a solicitudes de datos de servicio entre un usuario y una base de datos, emplean múltiples niveles de arquitectura. El uso más extendido de la arquitectura multi-tier es la arquitectura de tres niveles.

Por ser tan pobre

por juliocesar20200413

en septiembre 6, 2012

en Sin categoría

Me voy para nunca regresar
al fin y al cabo tu ya me pagaste mal
y si algún día te traiciona algún querer
pues ya ni modo yo no te volveré a ver.

Tu bien lo sabes que te quise de verdad
y no lo niego si hasta me hiciste llorar
cuando decías que me ibas a abandonar
por ser tan pobre era todo y nada más

Que seas feliz es lo que yo te deseo
que seas rodeada de pura felicidad
que te amen mucho y te sepan comprender
que seas dichosa ya que yo no pude ser.

<img src="http://lh6.ggpht.com/-H9_vn0a2Sfo/UEkkFh2urRI/AAAAAAAACQk/b4cRFGICoPI/video9541cfe5eef0%25255B3%25255D.jpg?imgmax=800" style="border-style: none" galleryimg="no" onload="var downlevelDiv = document.getElementById('a8a03633-d550-4130-a596-052227927b71'); downlevelDiv.innerHTML = "

http://www.youtube.com/v/YsccBvD5e5A&hl=en“;” alt=””>

1.2.1 DEFINICIÓN ARQUITECTURA MULTICAPAS

por juliocesar20200413

en agosto 31, 2012

en ARQUITECTURA DE APLICACIONES EMPRESARIALES

ARQUITECTURA DE APLICACIONES EMPRESARIALES

ACTIVIDAD 1.2 .1 DEFINICIÓN ARQUITECTURA MULTICAPAS

1.2.2 VENTAJAS Y DESVENTAJAS

1.2.3 MODELO DE 3 CAPAS

1.2.4 ESQUEMA

1.2.5 EJEMPLO DE FUNCIONAMIENTO

1.1.1 DEFINICIÓN

Lo que se conoce como arquitectura en capas es en realidad un estilo de programación donde el objetivo principal es separar los diferentes aspectos del desarrollo, tales como las cuestiones de presentación, lógica de negocio, mecanismos de almacenamiento, etc.

1.1.2 VENTAJAS Y DESVENTAJAS DE LA ARQUITECTURA MULTICAPAS

Ventajas

La ventaja fundamental de la arquitectura n-capas con una arquitectura de dos niveles (o una de de 3 capas con una de 2 niveles) es que separa hacia afuera el proceso, eso ocurre para mejorar el balance de la carga en los diversos servidores; es más escalable.

Desventajas

· Pone más carga a la red, debido al tráfico que genera en la red

· Es mucho más difícil programar y probar el software que en la arquitectura de dos niveles por que tienen que comunicarse con más dispositivos para terminar la transacción del usuario.

1.1.3 MODELO DE 3 CAPAS

1. Capa de presentación: es la que ve el usuario (también se la denomina “capa de usuario”), presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). También es conocida como interfaz gráfica y debe tener la característica de ser “amigable” (entendible y fácil de usar) para el usuario. Esta capa se comunica únicamente con la capa de negocio.

2. Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él. También se consideran aquí los programas de aplicación.

3. Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.

1.1.4 ESQUEMA

1.1.4 EJEMPLO DE FUNCIONAMIENTO

Un ejemplo simple es la transacción del cajero de un banco

1. Al cliente se le muestra la información y la interfaz grafica para hacer operaciones.

2. Una vez enviada la información al servidor la capa de negocios hace las operaciones necesarias, como transformar claves y hacer llamadas a la capa de datos (Esta es la lógica de negocios).

3. Luego se hace una llamada a la función del gestor de base de datos para devolver un valor a la capa de negocios y este procesara la información para mostrarla en la interfaz grafica.

ARQUITECTURA MODELO-VISTA-CONTROLADOR

por juliocesar20200413

en agosto 31, 2012

en ARQUITECTURA DE APLICACIONES EMPRESARIALES, ARQUITECTURA MODELO-VISTA-CONTROLADOR, DEFINICIO, DEFINICION, DESCRPCION DEL PATRON, EJEMPLO DE FUNCIONAMIENTO, ESQUEMA

ARQUITECTURA DE APLICACIONES EMPRESARIALES

ACTIVIDAD 1.1 .1 ARQUITECTURA MODELO-VISTA-CONTROLADOR

1.1.2 DEFINICIÓN

1.1.3 ESQUEMA

1.1.4 DESCRIPCION DEL PATRÓN

1.1.5 EJEMPLO DE FUNCIONAMIENTO

1.1.1 DEFINICIÓN

Es un patrón o modelo de abstracción de desarrollo de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de negocio en tres componentes distintos.

Como ejemplo:

Sería un sistema Web, el código HTML muestra la interfaz de usuario, el código PHP obtiene los datos que el usuario ingreso y los procesa, esto sería la lógica de negocios, luego se hacen consultas o modificaciones a los datos almacenados en el gestor de base de datos ej. MySQL que seria los datos de aplicación.

1.1.2 FUNCIONAMIENTO

1. El usuario interactúa con la interfaz de usuario de al recibir la acción notificada por el usuario mismo.

2. El controlador recibe por parte de la interfaz de usuario la notificación de la acción solicitada por el usuario.

3. El controlador accede al modelo actualizándolo, posiblemente modificándolo en forma adecuada a la acción solicitada por el usuario

4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario, luego da la orden de actualización.

5. La interfaz de usuario espera de nuevo interacciones del usuario, comenzando el ciclo nuevamente.

1.1.3 ESQUEMA

1.1.4 DESCRIPCIÓN DEL PATRÓN

Modelo: Esta es la representación específica de la información con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema también puede operar con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos afines con el sistema modelado.
Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario.
Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista.

1.1.5 EJEMPLO DE FUNCIONAMIENTO

Un ejemplo simple es el proceso de acceso a FACEBOOK

1. Se muestra la pantalla de acceso, el usuario ingresa el nombre, la contraseña y da clic en envía (Esta es la interfaz de usuario).

2. Los datos se procesan en un archivo PHP que se encuentra en el servidor, encriptando la contraseña (Esta es la lógica de negocios).

3. Ya la contraseña esta encriptada, ahora se busca en la base de datos para saber si existe y coincide el usuario y contraseña (Datos de aplicación).

4. Se procesa los datos en el modelo y luego devuelve un resultado en la interfaz de usuario.