Este es un artículo-ensayo que tuvimos que escribir con respecto al Guitar Hero.. y de cómo sería si crearamos un Acordeón hero ;)
Para descargar, click aquí
jueves, 4 de febrero de 2010
domingo, 27 de septiembre de 2009
Libros de sistemas distruidos y operativos
Hola!! Bueno, a mi me parece importante compartir la información y los documentos que no se encuentran facilmente, entonces aquí está un link donde encontraran libros de:
- Stallings, William - Sistemas Operativos.2da Edición (1997)
- Tanenbaum, Andrew - Sistemas Operativos.3ra Edición (1997)
- Tanenbaum, Andrew - Sistemas Operativos. Diseno e Implementacion.2da Edición (1997)
- Tanenbaum, Andrew - Sistemas Operativos Distribuidos.1era Edición (1996)
Click Aquí para descargar libros en .RAR
Espero les sirva tanto como me sirvio a mi.
- Stallings, William - Sistemas Operativos.2da Edición (1997)
- Tanenbaum, Andrew - Sistemas Operativos.3ra Edición (1997)
- Tanenbaum, Andrew - Sistemas Operativos. Diseno e Implementacion.2da Edición (1997)
- Tanenbaum, Andrew - Sistemas Operativos Distribuidos.1era Edición (1996)
Click Aquí para descargar libros en .RAR
Espero les sirva tanto como me sirvio a mi.
domingo, 6 de septiembre de 2009
Marco Jurídico y Controles en la Música
Hola!!!!
Este es un artículo sobre los controles de la música que se tienen en Colombia, opiniones, estadísticas y posibles soluciones.
Click aquí para ver PDF
Este es un artículo sobre los controles de la música que se tienen en Colombia, opiniones, estadísticas y posibles soluciones.
Click aquí para ver PDF
Teoría del Error
Hola! Este es un trabajo que hice con una compañera de Teoria del Error, para Análisis Numérico. Espero les sirva... con ejemplos y todo!
https://docs.google.com/fileview?id=0B5QDKrR0I-caOWQ2NDA4MTgtYzRmYS00YWI3LTk2MjMtNjY4ZDZmZGNiODBl&hl=en
https://docs.google.com/fileview?id=0B5QDKrR0I-caOWQ2NDA4MTgtYzRmYS00YWI3LTk2MjMtNjY4ZDZmZGNiODBl&hl=en
Rational Unified Process (R. U. P.)
Rational Unified Process (R. U. P.)
Se han desarrollado muchos métodos para hacer modelos de sistemas de información. Sin embargo, los métodos Orientados a Objeto llegan a ser patrones definidos.
El RUP o Rational Unified Process es un proceso de desarrollo de software, del cual se le pueden denotar tres características esenciales: está dirigido por los Casos de Uso, está centrado en la arquitectura, y es iterativo e incremental. Además, cuenta con ciertos elementos que lo definen como tal y cuenta con 6 best practices con las que define una forma efectiva de trabajar para y con los equipos de desarrollo de software.
En primero lugar, una de las principales características es el uso de Casos De Uso. Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Estos representan los requisitos funcionales del sistema, ya que “son una técnica de búsqueda de requisitos que fuerza a pensar en términos de importancia para el usuario y no sólo en términos de funciones que seria bueno contemplar” . Los casos de uso también guían el diseño del sistema, lo implementan, lo prueban. Además, entre cada uno de estos pasos, estos tienden a establecer una conexión o trazabilidad entre los artefactos que muestran cómo se generan unos a partir de otros.
En segundo lugar, la arquitectura de un sistema “es la organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo” . En otras palabras, es el acuerdo al que se llega entre el usuario y el desarrollador al momento de decidir la estructura en la que se va a basar el proyecto en un futuro. Este proceso se basa en diseñar anticipadamente una arquitectura base ejecutable, donde los casos de uso se ven involucrados para guiar el proceso para que en algún momento el proyecto no se “caiga” gracias a un fuerte cambio en la construcción o en el mantenimiento. Los Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos, para así llevar a cabo ambas cosas al tiempo en el proceso.
Para esto, la única manera de lograr este equilibrio entre los Casos de Uso y la arquitectura se consigue con un proceso iterativo e incremental en donde el trabajo se divida en partes más pequeñas o mini proyectos, permitiendo que el equilibrio se vaya logrando durante cada uno de estos, y así hasta acabar el proceso de desarrollo.
Este proceso consta de una secuencia de iteraciones que pueden ser Inicio, Elaboración, Construcción y Transición.
Cada una de estas fases se encargan, entre muchas otras cosas, de poner mayor énfasis en actividades modelado del negocio y de requisitos, de orientar al desarrollo de la arquitectura, de llevar a cabo la construcción del producto por medio de una serie de iteraciones y de garantizar que se tenga un producto preparado para su entrega a los usuarios respectivamente; en cada fase participan todas las disciplinas, pero que dependiendo de la fase se puede poner más énfasis a una que a otra.
Por otro lado, RUP, cuenta con los siguientes procedimientos, que a mi parecer, son los que definen quién hace qué, cuándo, y cómo: Flujos de trabajo por medio de disciplinas, Roles, Actividades y Artefactos, que responden a cada una de estas preguntas.
Por último, es necesario nombrar las best practices que se utilizan en este proceso de desarrollo, para hacer más eficiente y eficaz la práctica misma.
Estas son: Gestión de Requisitos, que “brinda una guía para encontrar, organizar, documentar, y seguir los cambios de los requisitos funcionales y restricciones”;Desarrollo De Software Iterativo, que “es el desarrollo del producto mediante iteraciones con hitos bien definidos, en las cuales se repiten las actividades pero con distinto énfasis, según la fase del proyecto”; Desarrollo Basado En Componentes que se refiere a una característica que permite que el sistema se vaya creando a medida que se desarrollan cada uno de sus componentes; Modelado Visual (Usando UML), que facilita la forma de visualizar, especificar, construir y documentar los artefactos en un proyecto; Verificación Continua de la Calidad, que como su nombre lo dice, las pruebas durante todo el desarrollo son fundamentales y se realizan a todo lo largo del proceso; Gestión De Los Cambios, es la encargada de ocuparse de los cambios que se puedan realizar durante el proceso.
Con esto, se puede concluir que RUP es una forma disciplinada de asignar tareas y responsabilidades en el desarrollo de un proyecto (quién hace qué, cuándo y cómo), que tiene como objetivo asegurar la realización del software de calidad dentro de los plazos y presupuestos que se hayan dicho con anterioridad. También cabe denotar que es un proceso que se caracteriza por ser dirigido por casos de uso, por el manejo especial de su arquitectura, ser iterativo (mini-proyectos) e incremental. Además, es “actualizado constantemente para tener en cuenta las mejores prácticas de acuerdo con la experiencia” .
BIBLIOGRAFÍA
• UML y Patrones, caps. 1 y 2. , Análisis y diseño orientado a objetos, Desarrollo iterativo y proceso unificado.
• Rational Unified Process. Universidad De Valencia. https://pid.dsic.upv.es/C1/Material/Documentos%20Disponibles/Introducci%C3%B3n%20a%20RUP.doc
• ¿Qué es RUP?. Universidad De Chile. www.dcc.uchile.cl/~luguerre/cc61j/recursos/clase2.ppt
• Soluciones tecnológicas y servicios. Soltec Perú. www.solutecperu.com/blog/2005/10/qu-es-uml-y-qu-es-rup.html
Se han desarrollado muchos métodos para hacer modelos de sistemas de información. Sin embargo, los métodos Orientados a Objeto llegan a ser patrones definidos.
El RUP o Rational Unified Process es un proceso de desarrollo de software, del cual se le pueden denotar tres características esenciales: está dirigido por los Casos de Uso, está centrado en la arquitectura, y es iterativo e incremental. Además, cuenta con ciertos elementos que lo definen como tal y cuenta con 6 best practices con las que define una forma efectiva de trabajar para y con los equipos de desarrollo de software.
En primero lugar, una de las principales características es el uso de Casos De Uso. Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Estos representan los requisitos funcionales del sistema, ya que “son una técnica de búsqueda de requisitos que fuerza a pensar en términos de importancia para el usuario y no sólo en términos de funciones que seria bueno contemplar” . Los casos de uso también guían el diseño del sistema, lo implementan, lo prueban. Además, entre cada uno de estos pasos, estos tienden a establecer una conexión o trazabilidad entre los artefactos que muestran cómo se generan unos a partir de otros.
En segundo lugar, la arquitectura de un sistema “es la organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo” . En otras palabras, es el acuerdo al que se llega entre el usuario y el desarrollador al momento de decidir la estructura en la que se va a basar el proyecto en un futuro. Este proceso se basa en diseñar anticipadamente una arquitectura base ejecutable, donde los casos de uso se ven involucrados para guiar el proceso para que en algún momento el proyecto no se “caiga” gracias a un fuerte cambio en la construcción o en el mantenimiento. Los Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos, para así llevar a cabo ambas cosas al tiempo en el proceso.
Para esto, la única manera de lograr este equilibrio entre los Casos de Uso y la arquitectura se consigue con un proceso iterativo e incremental en donde el trabajo se divida en partes más pequeñas o mini proyectos, permitiendo que el equilibrio se vaya logrando durante cada uno de estos, y así hasta acabar el proceso de desarrollo.
Este proceso consta de una secuencia de iteraciones que pueden ser Inicio, Elaboración, Construcción y Transición.
Cada una de estas fases se encargan, entre muchas otras cosas, de poner mayor énfasis en actividades modelado del negocio y de requisitos, de orientar al desarrollo de la arquitectura, de llevar a cabo la construcción del producto por medio de una serie de iteraciones y de garantizar que se tenga un producto preparado para su entrega a los usuarios respectivamente; en cada fase participan todas las disciplinas, pero que dependiendo de la fase se puede poner más énfasis a una que a otra.
Por otro lado, RUP, cuenta con los siguientes procedimientos, que a mi parecer, son los que definen quién hace qué, cuándo, y cómo: Flujos de trabajo por medio de disciplinas, Roles, Actividades y Artefactos, que responden a cada una de estas preguntas.
Por último, es necesario nombrar las best practices que se utilizan en este proceso de desarrollo, para hacer más eficiente y eficaz la práctica misma.
Estas son: Gestión de Requisitos, que “brinda una guía para encontrar, organizar, documentar, y seguir los cambios de los requisitos funcionales y restricciones”;Desarrollo De Software Iterativo, que “es el desarrollo del producto mediante iteraciones con hitos bien definidos, en las cuales se repiten las actividades pero con distinto énfasis, según la fase del proyecto”; Desarrollo Basado En Componentes que se refiere a una característica que permite que el sistema se vaya creando a medida que se desarrollan cada uno de sus componentes; Modelado Visual (Usando UML), que facilita la forma de visualizar, especificar, construir y documentar los artefactos en un proyecto; Verificación Continua de la Calidad, que como su nombre lo dice, las pruebas durante todo el desarrollo son fundamentales y se realizan a todo lo largo del proceso; Gestión De Los Cambios, es la encargada de ocuparse de los cambios que se puedan realizar durante el proceso.
Con esto, se puede concluir que RUP es una forma disciplinada de asignar tareas y responsabilidades en el desarrollo de un proyecto (quién hace qué, cuándo y cómo), que tiene como objetivo asegurar la realización del software de calidad dentro de los plazos y presupuestos que se hayan dicho con anterioridad. También cabe denotar que es un proceso que se caracteriza por ser dirigido por casos de uso, por el manejo especial de su arquitectura, ser iterativo (mini-proyectos) e incremental. Además, es “actualizado constantemente para tener en cuenta las mejores prácticas de acuerdo con la experiencia” .
BIBLIOGRAFÍA
• UML y Patrones, caps. 1 y 2. , Análisis y diseño orientado a objetos, Desarrollo iterativo y proceso unificado.
• Rational Unified Process. Universidad De Valencia. https://pid.dsic.upv.es/C1/Material/Documentos%20Disponibles/Introducci%C3%B3n%20a%20RUP.doc
• ¿Qué es RUP?. Universidad De Chile. www.dcc.uchile.cl/~luguerre/cc61j/recursos/clase2.ppt
• Soluciones tecnológicas y servicios. Soltec Perú. www.solutecperu.com/blog/2005/10/qu-es-uml-y-qu-es-rup.html
Lenguaje UML
Ana María González U.
Ingeniería de Sistemas
Análisis y Diseño Orientado a Objetos
Pontificia Universidad Javeriana
Lenguaje UML
UML (Unified Modeling Language) o Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos y describe la semántica esencial de estos diagramas y los símbolos en ellos utilizados[1]. En otras palabras, es un lenguaje creado para describir un proceso de desarrollo o modelado de sistemas de software (diseño orientado a objetos), que puede ser entendido por cualquier persona que quisiera saber de qué se trata este mismo en cualquier parte del mundo, ya que como se ha dicho anteriormente, es un lenguaje estandarizado. Este sirve para escribir los planos del software, puede utilizarse para visualizar, especificar, construir y documentar todos los artefactos que componen un sistema con gran cantidad de software. UML puede usarse para modelar desde sistemas de información hasta aplicaciones distribuidas basadas en Web, pasando por sistemas empotrados de tiempo real.
El desarrollo de este sistema de modelado comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus métodos. A finales de 1995, Ivar Jacobson y su compañía Objectory se incorporaron a Rational en su unificación, aportando el método OOSE.
De las tres metodologías de partida, las de Booch y Rumbaugh pueden ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que componen el sistema, su relación y colaboración. Por otro lado, la metodología de Jacobson es más centrada a usuario, ya que todo en su método se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estándar desde el OMG que es también el origen de CORBA, el estándar líder en la industria para la programación de objetos distribuidos. En 1997 UML 1.1 fue aprobada por
Debido a su estandarización y su definición completa, y aunque no sea un lenguaje de programación, UML se puede conectar de manera directa a lenguajes de programación como Java, C++ o Visual Basic; esta correspondencia permite lo que se conoce como ingeniería directa, que es obtener el código fuente partiendo de los modelos, pero además es posible reconstruir un modelo en UML partiendo de la implementación, o sea, la ingeniería inversa.[3]
Por otro lado, UML tiene su propia arquitectura, la cual tiene el objetivo de cumplir con la especificación Meta Object Facility del OMG:
- Meta-metamodelo: define el lenguaje para especificar metamodelos.
- Metamodelo: define el lenguaje para especificar modelos.
- Modelo: define el lenguaje para describir un dominio de información.
- Objetos de usuario: define un dominio de información específico.[4]
Como conclusión, se puede decir entonces que este es un lenguaje que nos ayuda a interpretar grandes sistemas mediante gráficos o mediante texto obteniendo modelos explícitos que ayudan a la comunicación durante el desarrollo ya que al ser estándar, los modelos podrán ser interpretados por personas que no participaron en su diseño (e incluso por herramientas) sin ninguna ambigüedad. Además, UML es un lenguaje porque proporciona un vocabulario y las reglas para utilizarlo, asimismo es un lenguaje de modelado lo que significa que el vocabulario y las reglas se utilizan para la representación conceptual y física del sistema.
BIBLIOGRAFÍA
· Historia del UML, http://www-gris.det.uvigo.es/~avilas/UML/node7.html
· Monografías.com, Diseño y Modelación de un Proyecto De Software Utilizando el Lenguaje UML. Qué es UML?, http://www.monografias.com/trabajos28/proyecto-uml/proyecto-uml.shtml
· El “Unified Modelling Languaje” (UML), http://www.geocities.com/txmetsb/UML-Use-cases.htm
· UML Resource Center. Rational Software. http://www.rational.com/uml
[1]Lenguaje UML http://www.hipertexto.info/documentos/uml.htm..
[2] Diseño y Modelación de un Proyecto De Software Utilizando el Lenguaje UML. Historia. http://www.monografias.com/trabajos28/proyecto-uml/proyecto-uml.shtml#histor
[3] Diseño y Modelación de un Proyecto De Software Utilizando el Lenguaje UML. Qué es UML? http://www.monografias.com/trabajos28/proyecto-uml/proyecto-uml.shtml#quees.
[4] Consultoría en seguridad. UML. http://www.creangel.com/uml/intro.php
jueves, 3 de septiembre de 2009
Saludos!
Holaa! Este es el primer bloc que creo en mi corta vida y espero sea de beneficio para todos. La idea es exponer mis trabajos académicos, dando la oportunidad al que le interese de leer y comentar. Vamos a ver cómo nos va!! :)
Suscribirse a:
Entradas (Atom)