GUIAAPRENDIZAJE2

SERVICIO NACIONAL DE APRENDIZAJE, SENA
TÉCNICO EN PROGRAMACIÓN DE SOFTWARE
INTRODUCCION AL SOFTWARE
CICLO GENÉRICO DE LA INTRODUCCIÓN AL SOFTWARE
COMPLEJIDAD DE LA CONSTRUCCIÓN DE UN SOFTWARE
¿Que significa complejo?
Es lo complicado, embrollado, enmarañado y por tanto indescriptible por el astronómico número

de mediciones, operaciones, computaciones.
¿Porque la complejidad es insimplificable?
Por que nos obliga a unir nociones que se excluyen en el marco del principio de
simplificación/reducción.
¿Características de la complejidad del software?
1. La elección de los componentes dependen del observador

2. Frecuentemente toma forma de Jerarquías” (subsistemas)
3. Los enlaces internos de los componentes son mas fuertes que los externos
4. Usualmente se componen de unas pocas clases
5. Evolucionan de sistemas mas simples
Tendencias de metodologías de desarrollo de software
Capas o niveles
MODELOS
¿Que es un modelo en software?
Es una representación de las características principales de un sistema.
¿Para que se modela en un software?
Para dominar la complejidad del sistema
Principios de modelado en software
P1. Elegir bien el modelo. La elección del modelo influye contundentemente sobre como se
acomete el problema y como se acomete la solución
P2. Todo modelo puede tener varios niveles de precisión
P3. Los mejores modelos están ligados con la realidad
P4. Un solo modelo no es suficiente para explicar el sistema
Como se representa un modelo

Objetivos de los modelos en software
1. Visualizan la idea del sistema que se quiere construir.
2. Especifican la estructura y el comportamiento.
3. Proporcionan plantillas que guían la construcción del software.
4. Permiten documentar nuestras decisiones.
TEMAS SUGERIDOS PARA SU UTILIDAD CONCEPTUAL
 COMPLEJIDAD
 COMPLEJIDAD DE SOFTWARE
 INCERTIDUMBRE
 MODULARIDAD
 GENERALIDAD - GENERACIDAD
 INTERFAZ
 NOCIONES DE CAOS
 NOCIONES DE INCERTIDUMBRE
 MÁQUINAS DE ESTADO FINITO
METODOLOGÍAS DE ANÁLISIS ORIENTADO A OBJETOS
• OMT: (Técnicas de Modelado de Objetos).

• Shaller-Mellor: Orientación a Objetos
• OOIE: (Ingeniería de Información Orientada Por Objetos)
• Booch: (Análisis y diseño OO)
• OOSE: (Ingeniería de Software Orientados por Objetos)
• OSA: (Análisis de Sistemas Orientado por Objetos)
• MOSES (modelos Orientados a objetos)
• SOMA: (Enfoque de Modelado de Objetos Semánticos)
• UML: Unify Modeling Language.
Como se expresa análisis y síntesis
Por que se dice análisis de sistemas
PORQUE SE DEBE ESTUDIAR una realidad en plenitud de su complejidad, lo que implica:
• Un trabajo multidisciplinario entre personas de la empresa, técnicos en informática

(ingenieros) y especialistas en ciertas materias.
• Es un estudio disciplinado con rigor ingenieril y de resultados explícitos.
• Es la base de cualquier construcción importante que puede evolucionar a través del

tiempo, del desarrollo organizacional y del progreso de la propia tecnología.
• Es un trabajo PROFESIONAL de amplio valor agregado, con un fuerte impacto en las

organizaciones modernas y de carácter crítico.
• Combina conocimiento, tecnología, organización y un amplio espectro de los objetivos de

la organización.
INGENIERÍA DE REQUERIMIENTOS
CONSTRUCCIÓN DE SOFTWARE ORIENTADO A OBJETOS

CALIDAD DEL SOFTWARE
Que es una corrección
Es la capacidad de los productos de software para realizar Con exactitud sus tareas tal y como la
definen las especificaciones. Son tantas las situaciones complejas que una estrategia multinivel
en la que cada nivel confía en la corrección de los niveles inferiores.
Hardware
Robustez
Es la capacidad del sistema de software de reaccionar apropiadamente ante condiciones

excepcionales.
Esta complementa la corrección que cubre lo previsto y aquí cubre lo imprevisto. Tendrá que ver
con el estudio de excepciones.
Extensibilidad
Es la facilidad de adaptar los productos de software a los cambios de especificación
Hay dos principios básicos para mejorar la extensibilidad:
1. Simplicidad de diseño: Una arquitectura simple siempre será más fácil de adaptar a los
Cambios que una arquitectura compleja.
2. Descentralización: Cuanto más autónomos sean los módulos, más alta es la probabilidad
De que un cambio simple solo afecte a un módulo o un número reducido de ellos.
Reutilización
Es la capacidad de los elementos de software de servir para la construcción de muchas

aplicaciones diferentes.
Hay situaciones en las que sistemas de software siguen ciertos patrones similares de modo que se
puede explotar esta similitud. Capturando este patrón un elemento reutilizable de software se
podrá aplicar en muchos desarrollos diferentes.
Compatibilidad
Es la facilidad de combinar unos elementos de software con otros. La clave recae en la

homogeneidad del diseño y en acordar convenciones estándares para comunicación entre
programas.
• Formatos de archivos estándar
• Estructuras de datos estándar
 Interfaces de usuario estándar.
Eficiencia
Es la capacidad de un sistema de software para exigir la menor cantidad posible de recursos de

hardware (Tiempo de procesador, espacio de memoria interna o externa, ancho de banda.)
Portabilidad
Es la facilidad de transferir los productos software a diferentes entornos de hardware y software.

Se acostumbra a utilizar el término <<plataforma>> para denotar el Hardware-Software que
empleará un determinado sistema
Facilidad de uso
Es la facilidad con la cual las personas de diferentes niveles y oficios pueden aprender a usar los
productos software y aplicarlos a la solución de problemas. Facilidad de instalación, operación y
supervisión. “un buen diseñador debe hacer un esfuerzo para comprender a la comunidad de
usuarios a la que se destina el sistema”.
Funcionalidad
Es el conjunto de posibilidades que proporciona un sistema. Problema difícil: ¿Cuánta

funcionalidad es suficiente? Sin debilitar el sistema pero también haciéndolo completo.
Otras cualidades
Son otras que afectan al usuario.
Verificabilidad: Es la facilidad para preparar procedimientos de aceptación
Integridad: Es la capacidad de los sistemas de software para proteger sus diversos Componentes
(programas, datos...).
Separabilidad: Es la facilidad para reparar (corregir) los defectos
Economía: Es la capacidad que un sistema tiene de completarse con el presupuesto asignado o

aun mejor, por debajo del presupuesto.
BENEFICIOS
Los beneficios de una verdadera EXTENSIBILIDAD Y REUTILIZACIÓN tienen como resultante

módulos que sean auto contenidos y organizados en arquitecturas estables.
La idea es disponer de elementos autónomos interconectados mediante una estructura simple y

coherente, que permitan a los diseñadores construir (producir) sistemas de software.
5 CRITERIOR PARA MADULAR
1. Descomposición modular:
Es problema se puede descomponer en un pequeño número de subproblemas menos complejos,

interconectados mediante una estructura sencilla y satisfactoriamente dependientes, para
permitir que el trabajo futuro pueda proseguir por separado en cada uno de ellos.
División de tareas – Mínima dependencias – No ignorar las dependencias
2. Composición modular:
“Un método la satisface si satisface la producción de elementos de software que se puedan

combinar libremente unos con otros para producir nuevos sistemas, posiblemente en un entorno
bastante diferente de aquel en que fueron desarrollados inicialmente”.
La composición es independiente de la descomposición.
3. Compr
ensibilidad modular:
Un método favorece la compresibilidad modular si ayuda a producir software en el cual un lector

humano puede entender cada módulo sin tener que conocer los otros, o, en el peor caso,
teniendo que examinar unos pocos de los restantes módulos.
4. Continuidad modular:
Un método satisface la continuidad modular si en la arquitectura software que producen, un

pequeño cambio en la especificación de un problema provoca solo cambios en un solo módulo ó
un pequeño número de módulos”.
5. Protección modular:
Un método satisface la protección modular si produce arquitecturas en las cuales el efecto de una
situación anormal que se produzca dentro de un módulo durante la ejecución, queda confinado a
dicho módulo , ó, en el peor de los casos, solo a unos pocos módulos vecinos.
Errores en ejecución – Entradas erróneas – Agotamiento de memoria – Violaciones de espacio –

otros.
DE LOS 5 CRITERIOS ANTERIORES SE DERIVAN CINCO REGLAS QUE SE DEBEN SEGUIR PARA
GARANTIZAR LA MODULARIDAD.
5 REGLAS PARA CONTINUIDAD Y DESCOMPOSICIÓN.
1. Correspondencia directa.
La estructura modular obtenida en el proceso de construcción de un sistema software debe seguir

siendo compatible con cualquier otra estructura modular obtenida en el proceso de modelado del
dominio del problema.
2. Pocas interfaces
Cada módulo debe comunicarse con el menor número de módulos posible“.

3. Pequeñas interfaces
Si dos módulos se comunican deben intercambiar la menor información posible“.
4. Interfaces explícitas.
Siempre que dos módulos A y B se comuniquen esto debe ser obvio a partir del texto de A
y B o de ambos.
5. OCULTACIÓN DE INFORMACIÓN (Encapsulamiento)

El diseñador de cada módulo debe seleccionar un subconjunto de propiedades del
Módulo como información oficial sobre el módulo para ponerla a disposición de los
autores de los módulos clientes.
CRITERIOS PARA LA CREACIÓN DEL SOFTWARE
1. Principio unidades modulares lingüísticas.

Los módulos deben corresponderse con las unidades sintácticas en el lenguaje utilizado
En resumen, esta regla se refiere a que el lenguaje a cualquier nivel (Análisis – diseño-
implementación) los módulos puedan compilarse por separado.
Excluye combinar métodos que permiten modularidad y otros no. Ejemplo, intentar
Implementar, lo que esta OO en un lenguaje que no permite objetos (pascal o C).
2. Principio auto-documentación.
El diseñador de un módulo deberá esforzarse por lograr que toda la información relativa
al módulo forme parte del propio módulo.
3. Principio acceso uniforme

Todos los servicios ofrecidos por un módulo deben estar disponibles a través de una
notación uniforme sin importar si están implementados a través de almacenamientos
Ó de un cálculo.
4. Principio abierto-cerrado.
Los módulos deben ser a la vez abiertos y cerrados.
Abierto: El módulo debe poderse extender. Ejemplo: Debería ser posible expandir su
conjunto de operaciones o añadir datos a sus estructuras de datos.
CERRADO: El módulo está disponible para ser usado por otros módulos. Entonces se
supone que el módulo tiene una descripción (interfaz en el sentido de ocultación de
información) estable y bien definida.
Cerrar un módulo en especificación o diseño: Que haya sido aprobado por la dirección
del proyecto.
Cerrar un módulo en nivel implementación: Implica que se pueda compilar, tal vez,
almacenar en una biblioteca y ponerlo a disposición de otros (clientes) para su uso.
5. Principio elección única.

Siempre que un sistema de software deba admitir un conjunto de alternativas, habrá un
módulo del sistema (y solo uno) que conozca su lista completa.
Es consecuencia de la regla cerrada y ocultación de información
Cada módulo deberá conocer estrictamente lo necesario para su funcionamiento y un

módulo, al menos uno dentro de la familia de módulos y no más que uno, deberá conocer
la lista completa de todos los módulos.
CONCEPTOS PARA RECORDAR
1. Una ESTRUCTURA adecuada es CLAVE para lograr la reutilización y extensibilidad.

2. Descomposición (visión descendente) , Composición(visión ascendente)
3. Modularidad aplica a: (Especificaciones – Diseño – implementación)
4. El control del volumen y la comunicación entre módulos es clave para una Buena
arquitectura modular.
5. La ocultación de información implica separar claramente

6. Módulo Abierto: Aún está sometido a extensiones.
7. Módulo Cerrado: Puede ser usado a través de interfaces por su módulos clientes.
¿Que es generosidad?
La generosidad es una facilidad para autores de módulos proveedores. Hace posible escribir el
mismo texto del proveedor cuando se utiliza la misma implementación de un cierto concepto,
aplicada a diferentes clases de objetos.
¿Qué es un paquete?
Son unidades de descomposición del software con las siguientes propiedades:
P1.Es una estructura del lenguaje, de modo que todo paquete tiene un nombre y un ámbito
sintáctico claro.
P2.La definición de cada paquete contiene un cierto número de declaraciones de los elementos
relacionados, tales como rutinas y variables, que en lo sucesivos se denominan características del
paquete.
P3.Cada paquete puede especificar unos derechos de acceso precisos que gobiernan la utilización
de sus características por parte de otros paquetes. Es decir, permite la ocultación de información.
P4.En un lenguaje de compilar (que pueda usarse para implementación y no solo para
especificación y diseño) es posible compilar paquetes por separado.
Ingredientes de la computación
• Los procesadores: son los dispositivos de computo físicos o virtuales.
• Las acciones. son operaciones de que consta la computación.
• Los objetos: son las estructuras de datos sobre los que se aplican las acciones
TECNOLOGIA DE OBJETOS
Que es una clase
Es un tipo abstracto de dato equipado de una implementación posiblemente parcial. Una clase es
un modelo y un objeto es una instancia de ese modelo
CLASE EFECTIVA:
Es una clase que está completamente implementada. Tiene 3 elementos:
• La especificación de un TAD (conjunto de funciones con sus axiomas y precondiciones que

describen las propiedades de las funciones).
• La selección de una representación.
• La correspondencia de las funciones (E1) con la representación (E2) en la forma de

mecanismo o características cada una de las cuales implementa una de las funciones en
términos de representación, de modo que se satisfagan los axiomas y las precondiciones.
Clase diferida:
Es una clase parcialmente implementada.
PRINCIPIOS METODOLOGICOS
De las bases teóricas:
Las reglas de metodologías de software deben basarse en una teoría sobre el tema adyacente.
De las bases prácticas:
Las reglas de metodologías de software deben estar respaldadas por una amplia experiencia
práctica”.
De la experiencia en reutilización:
Para poder asegurar que se es un experto en el campo de la orientación a objetos Se debe haber
desempeñado un papel clave en el desarrollo de alguna biblioteca. De clases que haya sido
utilizada con éxito en un grupo amplio de proyectos Diferentes y en diferentes contextos.
De los positivos absolutos:
Al elaborar las reglas metodológicas se deben favorecer los positivos absolutos para cada una de
estas reglas hay que examinar si es posible o no imponerla automáticamente a través de
herramientas o estructuras del lenguaje.
De los negativos absolutos.
Todo negativo absoluto debe estar respaldado por una explicación precisa de por que el autor
considera que el mecanismo rechazado es malo en la práctica y ddebe estar acompañado por una
descripción precisa de la forma de sustituir este Mecanismo por otros.
De las recomendaciones:
Al elaborar recomendaciones (positivas o negativas) use principio, no perogrulladas. Para

ayudarse a sí mismo a hacer la distinción, examine la negación de la regla.
EXCEPCIONES
De inclusión de excepciones:
Si una regla metodológica presenta una guía que es aplicable en general, pero que tiene
excepciones, las excepciones deben anunciarse como parte de la regla.
De arreglar lo que no funciona.
Si se encuentra la necesidad de muchas recomendaciones negativas.
• Examine la herramienta o lenguaje usados como base para determinar si esta refleja
deficiencia en el diseño su adyacente.
• De ser así, considere la posibilidad de invertir parte del esfuerzo, en documentarlo, en

corregir su diseño.
• Considere también la posibilidad de eliminar por completo el problema pasando a una

herramienta mejor.
IMPORTANCIA DE SER HUMILDE:
• Por grande que se sea, no hay que sobrestimar el valor de su experiencia.
• Demasiada confianza puede hacer daño.
• El diseño de un gran proyecto de software es una aventura intelectual.
• Todo proyecto ambicioso de software es un nuevo reto, no hay recetas seguras.
• Las experiencias no hacen infalible al desarrollador. Se es mejor cuanta mayor

experiencia positiva se tenga, peor no se es infalible.
TALLER
1. Con tus palabras define que es complejidad del software

2. Según tu que es un modelado en software
3. Que es un modelo estático
4. Que es un modelo dinámico
5. Cual es la diferencia entre análisis y síntesis

6. Cuales son los factores externos de la calidad del software
7. Explica cada uno de los 5 criterios de modularidad
8. Que es un paquete y sus partes
9. Explica cada uno de los ingredientes de la programación
10. Explica el objetivo del análisis orientado a objetos
11. Que es una clase
12. Explica cada uno de los de los principios metodológicos

GUIAAPRENDIZAJE2

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

GUIAAPRENDIZAJE2

Cargado por

Copyright:

Formatos disponibles

SERVICIO NACIONAL DE APRENDIZAJE, SENA

TÉCNICO EN PROGRAMACIÓN DE SOFTWARE

CICLO GENÉRICO DE LA INTRODUCCIÓN AL SOFTWARE

COMPLEJIDAD DE LA CONSTRUCCIÓN DE UN SOFTWARE

¿Que significa complejo?

Es lo complicado, embrollado, enmarañado y por tanto indescriptible por el astronómico número

¿Porque la complejidad es insimplificable?

¿Características de la complejidad del software?

1. La elección de los componentes dependen del observador

Tendencias de metodologías de desarrollo de software

¿Que es un modelo en software?

Es una representación de las características principales de un sistema.

¿Para que se modela en un software?

Para dominar la complejidad del sistema

Principios de modelado en software

P2. Todo modelo puede tener varios niveles de precisión

P3. Los mejores modelos están ligados con la realidad

P4. Un solo modelo no es suficiente para explicar el sistema

Como se representa un modelo

Objetivos de los modelos en software

1. Visualizan la idea del sistema que se quiere construir.

2. Especifican la estructura y el comportamiento.

3. Proporcionan plantillas que guían la construcción del software.

4. Permiten documentar nuestras decisiones.

TEMAS SUGERIDOS PARA SU UTILIDAD CONCEPTUAL

METODOLOGÍAS DE ANÁLISIS ORIENTADO A OBJETOS

• OMT: (Técnicas de Modelado de Objetos).

• UML: Unify Modeling Language.

Como se expresa análisis y síntesis

Por que se dice análisis de sistemas

PORQUE SE DEBE ESTUDIAR una realidad en plenitud de su complejidad, lo que implica:

• Un trabajo multidisciplinario entre personas de la empresa, técnicos en informática

• Es un estudio disciplinado con rigor ingenieril y de resultados explícitos.

• Es la base de cualquier construcción importante que puede evolucionar a través del

• Es un trabajo PROFESIONAL de amplio valor agregado, con un fuerte impacto en las

• Combina conocimiento, tecnología, organización y un amplio espectro de los objetivos de

CONSTRUCCIÓN DE SOFTWARE ORIENTADO A OBJETOS

CALIDAD DEL SOFTWARE

Que es una corrección

Es la capacidad del sistema de software de reaccionar apropiadamente ante condiciones

Es la facilidad de adaptar los productos de software a los cambios de especificación

Hay dos principios básicos para mejorar la extensibilidad:

Cambios que una arquitectura compleja.

De que un cambio simple solo afecte a un módulo o un número reducido de ellos.

Es la capacidad de los elementos de software de servir para la construcción de muchas

Es la facilidad de combinar unos elementos de software con otros. La clave recae en la

• Formatos de archivos estándar

• Estructuras de datos estándar

 Interfaces de usuario estándar.

Es la capacidad de un sistema de software para exigir la menor cantidad posible de recursos de

Es la facilidad de transferir los productos software a diferentes entornos de hardware y software.

Es el conjunto de posibilidades que proporciona un sistema. Problema difícil: ¿Cuánta

Son otras que afectan al usuario.

Verificabilidad: Es la facilidad para preparar procedimientos de aceptación

Separabilidad: Es la facilidad para reparar (corregir) los defectos

Economía: Es la capacidad que un sistema tiene de completarse con el presupuesto asignado o

Los beneficios de una verdadera EXTENSIBILIDAD Y REUTILIZACIÓN tienen como resultante

La idea es disponer de elementos autónomos interconectados mediante una estructura simple y

5 CRITERIOR PARA MADULAR

Es problema se puede descomponer en un pequeño número de subproblemas menos complejos,

División de tareas – Mínima dependencias – No ignorar las dependencias

“Un método la satisface si satisface la producción de elementos de software que se puedan

La composición es independiente de la descomposición.

Un método favorece la compresibilidad modular si ayuda a producir software en el cual un lector