Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Diseño e implementación
Temas
 Diseño orientado a objetos utilizando el UML
 Patrones de diseño
 Problemas de implementación
 Desarrollo de có...
Diseño e implementación
 El diseño e implementación de software es la etapa en el proceso de
ingeniería de software en el...
Construir o comprar
 En una amplia gama de dominios, ahora es posible comprar sistemas
disponibles en el mercado (COTS) q...
Un proceso de diseño orientado a objetos
 Los procesos estructurados de diseño orientados a objetos implican el
desarroll...
Etapas del proceso
 Hay una variedad de diferentes procesos de diseño orientados a objetos que
dependen de la organizació...
Contexto del sistema e interacciones
 Comprender las relaciones entre el software que se está diseñando y su
entorno exte...
Modelos de contexto y de interacción
 Un modelo de contexto del sistema es un modelo estructural que demuestra
los otros ...
Contexto del sistema para la estación meteorológica
Casos de uso de estación meteorológica
Descripción del caso de uso
Sistema Estación meteorológica
Caso de uso Informar el tiempo
Actores Sistema de información m...
Diseño arquitectonico
 Una vez comprendidas las interacciones entre el sistema y su
entorno, se utiliza esta información ...
Arquitectura de alto nivel de la estación
meteorológica
Arquitectura del sistema de recopilación
de datos
Identificación de clase de objeto
 La identificación de clases de objetos es a menudo una parte difícil del diseño
orient...
Enfoques de identificación
 Utilice un enfoque gramatical basado en una descripción
del lenguaje natural del sistema (uti...
Descripción de la estación
meteorológica
Una estación meteorológica es un paquete de instrumentos
controlados por software...
Clases de objetos de estaciones
meteorológicas
 La identificación de la clase de objeto en el sistema de estación
meteoro...
Clases de objetos de estaciones
meteorológicas
Modelos de diseño
 Los modelos de diseño muestran los objetos y clases de objetos y las
relaciones entre estas entidades....
Ejemplos de modelos de diseño
 Modelos de subsistemas que muestran agrupaciones
lógicas de objetos en subsistemas coheren...
Modelos del subsistema
 Muestra cómo el diseño se organiza en grupos de objetos relacionados
lógicamente.
 En el UML, es...
Modelos de secuencias
 Los modelos de secuencia muestran la secuencia de interacciones de objetos
que tienen lugar
 Los ...
Diagrama de secuencia que describe la
recopilación de datos
Diagramas de estado
 Los diagramas de estado se utilizan para mostrar cómo los
objetos responden a diferentes solicitudes...
Diagrama del estado de la estación
meteorológica
Especificación de interfaz
 Las interfaces de objetos deben especificarse para que los
objetos y otros componentes se pue...
Interfaces estación meteorológica
Puntos clave
 El diseño e implementación de software son actividades entrelazadas. El
nivel de detalle en el diseño depen...
Patrones de diseño
 Un patrón de diseño es una forma de reutilizar el conocimiento abstracto
sobre un problema y su soluc...
Elementos de diseño
 Nombre
 Un identificador de patrón significativo.
 Descripción del problema.
 Descripción de la s...
El patrón Observador
 Nombre
 Observador.
 Descripción
 Separa la visualización del estado del objeto del objeto mismo...
El patrón Observador (1)
Nombre del
patrón
Observador
Descripción Separa la visualización del estado de un objeto del obje...
El patrón Observador (2)
Nombre del
patrón
Observador
Descripción de la
solución
Esto implica dos objetos abstractos, Subj...
Múltiples pantallas utilizando el patrón
de Observador
Un modelo UML del patrón Observer
Problemas de diseño
 Para utilizar patrones en su diseño, debe reconocer que cualquier problema
de diseño que esté enfren...
Problemas de implementación
 El foco aquí no es en la programación, aunque esto es obviamente
importante, pero en otras e...
Reutilizar
 Desde la década de 1960 hasta la década de 1990, la mayoría del nuevo
software se desarrolló desde cero, escr...
Niveles de reutilización
 El nivel de abstracción
 En este nivel, no reutiliza el software directamente, sino que utiliz...
Costes de reutilización
 Los costos del tiempo dedicado a buscar software para reutilizar y evaluar si
responde o no a su...
Gestión de la configuración
 Gestión de la configuración es el nombre dado al proceso general de gestión
de un sistema de...
Actividades de gestión de la
configuración
 Gestión de versiones, donde se proporciona soporte para realizar un
seguimien...
Desarrollo del host-destino
 La mayoría del software se desarrolla en una computadora (el anfitrión), pero
funciona en un...
Herramientas de la plataforma de
desarrollo
 Un compilador integrado y un sistema de edición dirigido por sintaxis que le...
Entornos de desarrollo integrado (IDE)
 Las herramientas de desarrollo de software a menudo se agrupan para crear
un ento...
Factores de implementación de
componentes / sistemas
 Si un componente está diseñado para una arquitectura de
hardware es...
Desarrollo de código abierto
 El desarrollo de código abierto es un enfoque de desarrollo de software en el
que se public...
Sistemas de código abierto
 El producto de código abierto más conocido es, por supuesto, el sistema
operativo Linux que e...
Problemas de código abierto
 ¿Debe el producto que se está desarrollando hacer uso de componentes de
código abierto?
 ¿D...
Negocio de código abierto
 Cada vez más empresas de productos están utilizando un enfoque de código
abierto para el desar...
Licencias de código abierto
 Un principio fundamental del desarrollo de código abierto es que el código
fuente debe estar...
Modelos de licencia
 La Licencia Pública General GNU (GPL). Esta es una licencia llamada
"recíproca" que significa que si...
Gestión de licencias
 Establecer un sistema para mantener información sobre los componentes de
código abierto que se desc...
Resumen
 Al desarrollar software, siempre debe considerar la posibilidad de
reutilizar el software existente, ya sea como...
Upcoming SlideShare
Loading in …5
×

Ingenieria de Software: Diseño e implementación

645 views

Published on

Dejo con ustedes la septima parte de una serie de tutoriales enfocado en la ingenieria de software

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Ingenieria de Software: Diseño e implementación

  1. 1. Diseño e implementación
  2. 2. Temas  Diseño orientado a objetos utilizando el UML  Patrones de diseño  Problemas de implementación  Desarrollo de código abierto
  3. 3. Diseño e implementación  El diseño e implementación de software es la etapa en el proceso de ingeniería de software en el que se desarrolla un sistema de software ejecutable.  Las actividades de diseño e implementación de software son invariablemente entretejidas.  El diseño de software es una actividad creativa en la que identifica los componentes de software y sus relaciones, basándose en los requisitos de un cliente.  La implementación es el proceso de realizar el diseño como un programa.
  4. 4. Construir o comprar  En una amplia gama de dominios, ahora es posible comprar sistemas disponibles en el mercado (COTS) que pueden ser adaptados y adaptados a las necesidades de los usuarios.  Por ejemplo, si desea implementar un sistema de registros médicos, puede comprar un paquete que ya se utiliza en los hospitales. Puede ser más barato y más rápido usar este enfoque en lugar de desarrollar un sistema en un lenguaje de programación convencional.  Cuando desarrolla una aplicación de esta manera, el proceso de diseño se preocupa de cómo utilizar las características de configuración de ese sistema para entregar los requisitos del sistema.
  5. 5. Un proceso de diseño orientado a objetos  Los procesos estructurados de diseño orientados a objetos implican el desarrollo de una serie de modelos de sistemas diferentes.  Requieren mucho esfuerzo para el desarrollo y mantenimiento de estos modelos y, para sistemas pequeños, esto puede no ser rentable.  Sin embargo, para grandes sistemas desarrollados por diferentes grupos, los modelos de diseño son un importante mecanismo de comunicación.
  6. 6. Etapas del proceso  Hay una variedad de diferentes procesos de diseño orientados a objetos que dependen de la organización que utiliza el proceso.  Las actividades comunes en estos procesos incluyen:  Definir el contexto y los modos de uso del sistema;  Diseñar la arquitectura del sistema;  Identificar los principales objetos del sistema;  Desarrollar modelos de diseño;  Especificar interfaces de objetos.  Proceso ilustrado aquí usando un diseño para una estación de tiempo salvaje.
  7. 7. Contexto del sistema e interacciones  Comprender las relaciones entre el software que se está diseñando y su entorno externo es esencial para decidir cómo proporcionar la funcionalidad requerida del sistema y cómo estructurar el sistema para comunicarse con su entorno.  La comprensión del contexto también le permite establecer los límites del sistema. Establecer los límites del sistema le ayuda a decidir qué características se implementan en el sistema que se está diseñando y qué características se encuentran en otros sistemas asociados.
  8. 8. Modelos de contexto y de interacción  Un modelo de contexto del sistema es un modelo estructural que demuestra los otros sistemas en el entorno del sistema que se está desarrollando.  Un modelo de interacción es un modelo dinámico que muestra cómo el sistema interactúa con su entorno tal como se utiliza.
  9. 9. Contexto del sistema para la estación meteorológica
  10. 10. Casos de uso de estación meteorológica
  11. 11. Descripción del caso de uso Sistema Estación meteorológica Caso de uso Informar el tiempo Actores Sistema de información meteorológica, Estación meteorológica Descripción La estación meteorológica envía un resumen de los datos meteorológicos que se han recogido de los instrumentos en el período de recogida al sistema de información meteorológica. Los datos enviados son las temperaturas máxima, mínima y media de la tierra y del aire; Las presiones de aire máximas, mínimas y promedio; Las velocidades máxima, mínima y media del viento; La precipitación total; Y la dirección del viento como muestra a intervalos de cinco minutos. Estímulo El sistema de información meteorológica establece un enlace de comunicación satelital con la estación meteorológica y solicita la transmisión de los datos Respuesta Los datos resumidos se envían al sistema de información meteorológica. Comentarios Se suele pedir a las estaciones meteorológicas que informen una vez por hora, pero esta frecuencia puede diferir de una estación a otra y puede ser modificada en el futuro.
  12. 12. Diseño arquitectonico  Una vez comprendidas las interacciones entre el sistema y su entorno, se utiliza esta información para diseñar la arquitectura del sistema.  Identifica los componentes principales que componen el sistema y sus interacciones y, a continuación, puede organizar los componentes utilizando un patrón arquitectónico, como un modelo de capas o cliente-servidor.  La estación meteorológica está compuesta por subsistemas independientes que se comunican mediante la difusión de mensajes en una infraestructura común.
  13. 13. Arquitectura de alto nivel de la estación meteorológica
  14. 14. Arquitectura del sistema de recopilación de datos
  15. 15. Identificación de clase de objeto  La identificación de clases de objetos es a menudo una parte difícil del diseño orientado a objetos.  No hay una "fórmula mágica" para la identificación de objetos. Se basa en la habilidad, experiencia y conocimiento de dominio de los diseñadores de sistemas.  La identificación de objetos es un proceso iterativo. Es poco probable que lo haga bien la primera vez.
  16. 16. Enfoques de identificación  Utilice un enfoque gramatical basado en una descripción del lenguaje natural del sistema (utilizada en el método Hood OOD).  Basar la identificación en cosas tangibles en el dominio de la aplicación.  Utilice un enfoque conductual e identifique objetos basados en lo que participa en qué comportamiento.  Utilice un análisis basado en escenarios. Se identifican los objetos, atributos y métodos en cada escenario.
  17. 17. Descripción de la estación meteorológica Una estación meteorológica es un paquete de instrumentos controlados por software que recopila datos, realiza algún procesamiento de datos y transmite estos datos para su posterior procesamiento. Los instrumentos incluyen termómetros de aire y tierra, un anemómetro, una paleta de viento, un barómetro y un pluviómetro. Los datos se recogen periódicamente. Cuando se emite un comando para transmitir los datos meteorológicos, la estación meteorológica procesa y resume los datos recopilados. Los datos resumidos se transmiten al ordenador de mapeo cuando se recibe una solicitud.
  18. 18. Clases de objetos de estaciones meteorológicas  La identificación de la clase de objeto en el sistema de estación meteorológica puede basarse en el hardware tangible y los datos en el sistema:  Termómetro de tierra, Anemómetro, Barómetro  Objetos de dominio de aplicación que son objetos de 'hardware' relacionados con los instrumentos del sistema.  Estación meteorológica  La interfaz básica de la estación meteorológica a su entorno. Por lo tanto, refleja las interacciones identificadas en el modelo de casos de uso.  Datos del tiempo  Encapsula los datos resumidos de los instrumentos.
  19. 19. Clases de objetos de estaciones meteorológicas
  20. 20. Modelos de diseño  Los modelos de diseño muestran los objetos y clases de objetos y las relaciones entre estas entidades.  Los modelos estáticos describen la estructura estática del sistema en términos de clases de objetos y relaciones.  Los modelos dinámicos describen las interacciones dinámicas entre los objetos.
  21. 21. Ejemplos de modelos de diseño  Modelos de subsistemas que muestran agrupaciones lógicas de objetos en subsistemas coherentes.  Modelos de secuencias que muestran la secuencia de interacciones de objetos.  Modelos de máquinas de estado que muestran cómo los objetos individuales cambian su estado en respuesta a los eventos.  Otros modelos incluyen modelos de casos de uso, modelos de agregación, modelos de generalización, etc.
  22. 22. Modelos del subsistema  Muestra cómo el diseño se organiza en grupos de objetos relacionados lógicamente.  En el UML, estos se muestran usando paquetes - una construcción de encapsulación. Este es un modelo lógico. La organización real de objetos en el sistema puede ser diferente.
  23. 23. Modelos de secuencias  Los modelos de secuencia muestran la secuencia de interacciones de objetos que tienen lugar  Los objetos están dispuestos horizontalmente en la parte superior;  El tiempo se representa verticalmente para que los modelos se lean de arriba a abajo;  Las interacciones están representadas por flechas marcadas, diferentes estilos de flecha representan diferentes tipos de interacción;  Un rectángulo delgado en una línea de vida de objeto representa el momento en que el objeto es el objeto de control en el sistema.
  24. 24. Diagrama de secuencia que describe la recopilación de datos
  25. 25. Diagramas de estado  Los diagramas de estado se utilizan para mostrar cómo los objetos responden a diferentes solicitudes de servicio y las transiciones de estado activadas por estas solicitudes.  Los diagramas de estado son modelos útiles de alto nivel de un sistema o el comportamiento de un objeto en tiempo de ejecución.  Por lo general, no necesita un diagrama de estado para todos los objetos del sistema. Muchos de los objetos en un sistema son relativamente simples y un modelo de estado agrega detalles innecesarios al diseño.
  26. 26. Diagrama del estado de la estación meteorológica
  27. 27. Especificación de interfaz  Las interfaces de objetos deben especificarse para que los objetos y otros componentes se puedan diseñar en paralelo.  Los diseñadores deben evitar diseñar la representación de la interfaz, pero deben ocultar esto en el propio objeto.  Los objetos pueden tener varias interfaces que son puntos de vista en los métodos proporcionados.  El UML utiliza diagramas de clases para la especificación de la interfaz, pero también se puede usar Java.
  28. 28. Interfaces estación meteorológica
  29. 29. Puntos clave  El diseño e implementación de software son actividades entrelazadas. El nivel de detalle en el diseño depende del tipo de sistema y de si está utilizando un enfoque orientado a planes o ágil.  El proceso de diseño orientado a objetos incluye actividades para diseñar la arquitectura del sistema, identificar objetos en el sistema, describir el diseño utilizando diferentes modelos de objetos y documentar las interfaces de componentes.  Se puede producir una gama de diferentes modelos durante un proceso de diseño orientado a objetos. Estos incluyen modelos estáticos (modelos de clase, modelos de generalización, modelos de asociación) y modelos dinámicos (modelos de secuencia, modelos de máquina de estado).  Las interfaces de componentes deben definirse con precisión para que otros objetos puedan utilizarlas. Se puede usar un estereotipo de interfaz UML para definir interfaces.
  30. 30. Patrones de diseño  Un patrón de diseño es una forma de reutilizar el conocimiento abstracto sobre un problema y su solución.  Un patrón es una descripción del problema y la esencia de su solución.  Debe ser suficientemente abstracto para ser reutilizado en diferentes entornos.  Las descripciones de patrones usualmente usan características orientadas a objetos tales como herencia y polimorfismo.
  31. 31. Elementos de diseño  Nombre  Un identificador de patrón significativo.  Descripción del problema.  Descripción de la solución.  No es un diseño concreto, sino una plantilla para una solución de diseño que se puede instanciar de diferentes maneras.  Consecuencias  Los resultados y los trade-offs de aplicar el patrón.
  32. 32. El patrón Observador  Nombre  Observador.  Descripción  Separa la visualización del estado del objeto del objeto mismo.  Descripción del problema  Se utiliza cuando se necesitan varias pantallas de estado.  Descripción de la solución  Vea la diapositiva con la descripción de UML.  Consecuencias  Las optimizaciones para mejorar el rendimiento de la pantalla no son prácticas.
  33. 33. El patrón Observador (1) Nombre del patrón Observador Descripción Separa la visualización del estado de un objeto del objeto en sí y permite mostrar alternativas. Cuando el estado del objeto cambia, todas las pantallas se notifican y actualizan automáticamente para reflejar el cambio. Descripción del problema En muchas situaciones, tiene que proporcionar múltiples visualizaciones de información de estado, como una presentación gráfica y una presentación tabular. No todos estos pueden ser conocidos cuando se especifica la información. Todas las presentaciones alternativas deben apoyar la interacción y, cuando se cambia el estado, todas las pantallas deben ser actualizadas. Este patrón se puede utilizar en todas las situaciones en las que se requiere más de un formato de presentación para la información de estado y donde no es necesario que el objeto que mantiene la información de estado conozca los formatos de presentación específicos utilizados.
  34. 34. El patrón Observador (2) Nombre del patrón Observador Descripción de la solución Esto implica dos objetos abstractos, Subject y Observer, y dos objetos concretos, ConcreteSubject y ConcreteObject, que heredan los atributos de los objetos abstractos relacionados. Los objetos abstractos incluyen operaciones generales que son aplicables en todas las situaciones. El estado que se va a mostrar se mantiene en ConcreteSubject, que hereda operaciones de Subject permitiendo agregar y quitar observadores (cada observador corresponde a una pantalla) y emitir una notificación cuando el estado ha cambiado. El ConcreteObserver mantiene una copia del estado de ConcreteSubject e implementa la interfaz Update () de Observer que permite que estas copias se mantengan en el paso. El ConcreteObserver muestra automáticamente el estado y refleja los cambios siempre que se actualice el estado. Consecuencias El sujeto solo conoce al Observador abstracto y no conoce detalles de la clase concreta. Por lo tanto, existe un acoplamiento mínimo entre estos objetos. Debido a esta falta de conocimiento, las optimizaciones que mejoran el rendimiento de la pantalla son poco prácticas. Los cambios en el tema pueden provocar que se genere un conjunto de actualizaciones vinculadas a los observadores, algunas de las cuales pueden no ser necesarias.
  35. 35. Múltiples pantallas utilizando el patrón de Observador
  36. 36. Un modelo UML del patrón Observer
  37. 37. Problemas de diseño  Para utilizar patrones en su diseño, debe reconocer que cualquier problema de diseño que esté enfrentando puede tener un patrón asociado que pueda aplicarse.  Dígale a varios objetos que el estado de algún otro objeto ha cambiado (patrón Observador).  Arreglar las interfaces a una serie de objetos relacionados que a menudo se han desarrollado de forma incremental (patrón de fachada).  Proporcionar una forma estándar de acceso a los elementos de una colección, independientemente de cómo se implementa esa colección (patrón Iterator).  Permitir la posibilidad de ampliar la funcionalidad de una clase existente en tiempo de ejecución (Patrón Decorador).
  38. 38. Problemas de implementación  El foco aquí no es en la programación, aunque esto es obviamente importante, pero en otras ediciones de la ejecución que no se cubren a menudo en textos de programación:  Reutilización La mayoría del software moderno se construye mediante la reutilización de componentes o sistemas existentes. Cuando usted está desarrollando software, debe hacer tanto uso como sea posible del código existente.  Gestión de la configuración Durante el proceso de desarrollo, debe realizar un seguimiento de las diferentes versiones de cada componente de software en un sistema de gestión de la configuración.  Desarrollo de destino de host El software de producción no suele ejecutarse en el mismo equipo que el entorno de desarrollo de software. Más bien, se desarrolla en una computadora (el sistema host) y se ejecuta en una computadora separada (el sistema de destino).
  39. 39. Reutilizar  Desde la década de 1960 hasta la década de 1990, la mayoría del nuevo software se desarrolló desde cero, escribiendo todo el código en un lenguaje de programación de alto nivel.  La única reutilización significativa o software fue la reutilización de funciones y objetos en bibliotecas de lenguaje de programación.  Los costos y la presión de programación hacen que este enfoque sea cada vez más inviable, especialmente para sistemas comerciales y basados en Internet.  Un enfoque para el desarrollo basado en la reutilización de software existente surgió y ahora se utiliza generalmente para negocios y software científico.
  40. 40. Niveles de reutilización  El nivel de abstracción  En este nivel, no reutiliza el software directamente, sino que utiliza el conocimiento de las abstracciones exitosas en el diseño de su software.  El nivel del objeto  En este nivel, reutiliza directamente objetos de una biblioteca en lugar de escribir el código tú mismo.  El nivel de componentes  Los componentes son colecciones de objetos y clases de objetos que se reutilizan en sistemas de aplicaciones.  El nivel del sistema  En este nivel, reutiliza sistemas de aplicación completos.
  41. 41. Costes de reutilización  Los costos del tiempo dedicado a buscar software para reutilizar y evaluar si responde o no a sus necesidades.  En su caso, los costes de compra del software reutilizable. Para los grandes sistemas disponibles en el mercado, estos costos pueden ser muy altos.  Los costes de adaptación y configuración de los componentes o sistemas de software reutilizables para reflejar los requisitos del sistema que está desarrollando.  Los costos de integrar elementos de software reutilizables entre sí (si está utilizando software de diferentes fuentes) y con el nuevo código que ha desarrollado.
  42. 42. Gestión de la configuración  Gestión de la configuración es el nombre dado al proceso general de gestión de un sistema de software cambiante.  El objetivo de la administración de la configuración es apoyar el proceso de integración del sistema para que todos los desarrolladores puedan acceder al código del proyecto y los documentos de forma controlada, averiguar qué cambios se han hecho y compilar y vincular componentes para crear un sistema.
  43. 43. Actividades de gestión de la configuración  Gestión de versiones, donde se proporciona soporte para realizar un seguimiento de las diferentes versiones de componentes de software. Los sistemas de gestión de versiones incluyen instalaciones para coordinar el desarrollo de varios programadores.  Integración de sistemas, donde se proporciona asistencia para ayudar a los desarrolladores a definir qué versiones de componentes se utilizan para crear cada versión de un sistema. Esta descripción se utiliza entonces para construir un sistema automáticamente compilando y enlazando los componentes requeridos.  Seguimiento de problemas, donde se proporciona soporte para permitir a los usuarios reportar errores y otros problemas y permitir que todos los desarrolladores vean quién está trabajando en estos problemas y cuándo están solucionados.
  44. 44. Desarrollo del host-destino  La mayoría del software se desarrolla en una computadora (el anfitrión), pero funciona en una máquina separada (la blanco).  En términos más generales, podemos hablar de una plataforma de desarrollo y una plataforma de ejecución.  Una plataforma es algo más que hardware.  Incluye el sistema operativo instalado y otro software de soporte, como un sistema de gestión de bases de datos o, para las plataformas de desarrollo, un entorno de desarrollo interactivo.  La plataforma de desarrollo por lo general tiene software instalado diferente de la plataforma de ejecución; Estas plataformas pueden tener diferentes arquitecturas.
  45. 45. Herramientas de la plataforma de desarrollo  Un compilador integrado y un sistema de edición dirigido por sintaxis que le permite crear, editar y compilar código.  Un sistema de depuración de lenguaje.  Herramientas de edición gráfica, como herramientas para editar modelos UML.  Herramientas de prueba, como Junit que puede ejecutar automáticamente un conjunto de pruebas en una nueva versión de un programa.  Herramientas de soporte de proyectos que le ayudan a organizar el código para diferentes proyectos de desarrollo.
  46. 46. Entornos de desarrollo integrado (IDE)  Las herramientas de desarrollo de software a menudo se agrupan para crear un entorno de desarrollo integrado (IDE).  Un IDE es un conjunto de herramientas de software que soporta diferentes aspectos del desarrollo de software, dentro de un marco común y una interfaz de usuario.  Los IDE se crean para admitir el desarrollo en un lenguaje de programación específico como Java. El lenguaje IDE puede desarrollarse especialmente, o puede ser una instancia de un IDE de uso general, con herramientas específicas de soporte de idioma.
  47. 47. Factores de implementación de componentes / sistemas  Si un componente está diseñado para una arquitectura de hardware específica, o se basa en algún otro sistema de software, obviamente debe ser desplegado en una plataforma que proporciona el soporte necesario de hardware y software.  Los sistemas de alta disponibilidad pueden requerir que los componentes se desplieguen en más de una plataforma. Esto significa que, en caso de fallo de la plataforma, está disponible una implementación alternativa del componente.  Si hay un alto nivel de tráfico de comunicaciones entre componentes, generalmente tiene sentido desplegarlos en la misma plataforma o en plataformas físicamente cercanas entre sí. Esto reduce el retardo entre el momento en que un mensaje es enviado por un componente y recibido por otro.
  48. 48. Desarrollo de código abierto  El desarrollo de código abierto es un enfoque de desarrollo de software en el que se publica el código fuente de un sistema de software y se invita a los voluntarios a participar en el proceso de desarrollo  Sus raíces están en la Free Software Foundation (www.fsf.org), que defiende que el código fuente no debe ser propietario, sino que debe estar siempre disponible para que los usuarios puedan examinar y modificar como lo desean.  El software de código abierto extendió esta idea utilizando Internet para reclutar a una población mucho mayor de desarrolladores voluntarios. Muchos de ellos también son usuarios del código.
  49. 49. Sistemas de código abierto  El producto de código abierto más conocido es, por supuesto, el sistema operativo Linux que es ampliamente utilizado como un sistema de servidor y, cada vez más, como un entorno de escritorio.  Otros productos de código abierto importantes son Java, el servidor web Apache y el sistema de gestión de bases de datos mySQL.
  50. 50. Problemas de código abierto  ¿Debe el producto que se está desarrollando hacer uso de componentes de código abierto?  ¿Debería utilizarse un enfoque de código abierto para el desarrollo del software?
  51. 51. Negocio de código abierto  Cada vez más empresas de productos están utilizando un enfoque de código abierto para el desarrollo.  Su modelo de negocio no depende de la venta de un producto de software, sino de la venta de soporte para ese producto.  Ellos creen que la participación de la comunidad de código abierto permitirá que el software se desarrolle más barato, más rápidamente y creará una comunidad de usuarios para el software.
  52. 52. Licencias de código abierto  Un principio fundamental del desarrollo de código abierto es que el código fuente debe estar libremente disponible, esto no significa que cualquiera pueda hacer lo que quiera con ese código.  Legalmente, el desarrollador del código (ya sea una empresa o un individuo) sigue siendo el propietario del código. Pueden imponer restricciones sobre cómo se utiliza al incluir condiciones legalmente vinculantes en una licencia de software de código abierto.  Algunos desarrolladores de código abierto creen que si un componente de código abierto se utiliza para desarrollar un nuevo sistema, entonces ese sistema también debe ser de código abierto.  Otros están dispuestos a permitir que su código se use sin esta restricción. Los sistemas desarrollados pueden ser propietarios y vendidos como sistemas de código cerrado.
  53. 53. Modelos de licencia  La Licencia Pública General GNU (GPL). Esta es una licencia llamada "recíproca" que significa que si utiliza software de código abierto que está bajo la licencia GPL, entonces debe hacer que el software de código abierto.  La Licencia Pública General Menor de GNU (LGPL) es una variante de la licencia GPL donde se pueden escribir componentes que enlazan al código fuente abierto sin tener que publicar el origen de estos componentes.  La licencia de distribución estándar (BSD) de Berkley. Esta es una licencia no recíproca, lo que significa que no está obligado a volver a publicar los cambios o modificaciones realizados en el código fuente abierto. Puede incluir el código en sistemas propietarios que se venden.
  54. 54. Gestión de licencias  Establecer un sistema para mantener información sobre los componentes de código abierto que se descargan y utilizan.  Tenga en cuenta los diferentes tipos de licencias y comprenda cómo se licencia un componente antes de utilizarlo.  Sea consciente de las vías de evolución de los componentes.  Educar a la gente sobre código abierto.  Disponer de sistemas de auditoría.  Participa en la comunidad de código abierto.
  55. 55. Resumen  Al desarrollar software, siempre debe considerar la posibilidad de reutilizar el software existente, ya sea como componentes, servicios o sistemas completos.  La gestión de la configuración es el proceso de gestión de cambios en un sistema de software en evolución. Es esencial cuando un equipo de personas están cooperando para desarrollar software.  La mayoría del desarrollo de software es el desarrollo de destino de host. Utiliza un IDE en una máquina host para desarrollar el software, que se transfiere a una máquina de destino para su ejecución.  El desarrollo de código abierto implica que el código fuente de un sistema esté disponible públicamente. Esto significa que muchas personas pueden proponer cambios y mejoras al software.

×