CURSO DE “SEMINARIO II”

S O F T W A R E

INTRODUCCIÓN
 AGENDA:

1. CICLO GENÉRICO DE CONSTRUCCIÓN DE SOFTWARE

2. COMPLEJIDAD

3. MODELOS
1
CICLO GENÉRICO EN LA CONSTRUCCIÓN DE SOFTWARE
Comunicación
CONCEPTO
NECESIDADES
S
Y
TEORIAS
DEMANDAS
TECNICAS

REALIDAD MODELO
CONCEPTUAL

MODELO
FUNCIONAL
 2
COMPLEJIDAD
 Complejidad y Construcción de Software

2. COMPLEJO: ¿ Es lo complicado, embrollado, enmarañado y por tanto idescrictible

por el astronómico número de mediciones, operaciones, computaciones...?

“ La complejidad es insimplificable ”, ateniéndose al paradigma-sistema

[Morin Ciencia con conciencia pag.212] . Es complejo por que nos obliga a unir nociones
que se excluyen en el marco del principio de simplificación/reducción:

UNO MÚLTIPLE TODO PARTE

Orden/organización Desorden

Sujeto Objeto
(Observador) (Sistema Observado)
 Complejidad y Construcción de Software

2. COMPLEJIDAD

La complejidad en los sistemas discretos,

frecuentemente están expuestos a alteraciones
del medio y su impacto, en la transición de
un estado a otro, es enorme e impredesible,
pues no existe el dominio matemático pleno y
tampoco existen las herramientas y reta la
capacidad intelectual del hombre.
 Complejidad y Construcción de Software

CARACTERISTICA DE LA COMPELJIDAD DE SOFTWARE

[Booch, ADOO 1.997]

“La
1. elección de los componentes dependen del observador
2. “Frecuentemente toma forma de Jerarquías”
(susbsistemas)
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
 2. Complejidad y Construcción de Software

ALGORITMICA
TENDENCIAS METODOLOGICAS
DE DESARROLLO DE SOFTWARE Hace énfasis en los procesos
o las funciones del sistema

ORIENTACION A OBJETOS

Hace énfasis en las cosas (objetos)

que se destacan del sistema
2. Complejidad y Construcción de Software

ARQUITECTURA DE CAPAS O NIVELES

One tier

Capa Presentación

Capa Reglas del

? Negocio

Capa de Datos
 2. Complejidad y Construcción de Software

ARQUITECTURA DE CAPAS O NIVELES

Two tier

Cliente inteligente
CAPA PRESENTACIÓN

CAPA DE REGLAS
DEL NEGOCIO

CAPA DE
BASE DE
DATOS
Servidor inteligente
2. Complejidad y Construcción de Software

ARQUITECTURA DE CAPAS O NIVELES

Three tier

Capa de Presentación

CAPA DE REGLAS
DEL NEGOCIO

CAPA DE
BASE DE
DATOS
2. Complejidad y Construcción de Software

ARQUITECTURA DE CAPAS O NIVELES

N- tier

Capa de Presentación

CAPA DE REGLAS
DEL NEGOCIO

CAPA DE
BASE DE DATOS
3
 3. MODELOS

PRINCIPIOS DEL 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
 3. MODELOS

MODELO: Es una
representación de las
caracterísitcas principales de
un sistema.

: ¿ POR QUE SE MODELA?

Para dominar la
complejidad del sistema

REALIDAD MODELO
 3. MODELOS

JETIVOS DE LOS MODELOS (EN SOFTWARE):

1. Visualizan la idea del sistema que se quiere con

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 REVISAR EN ESTA MATERIA
POR SU UTILIDAD CONCEPTUAL

• COMPLEJIDAD  NOCIONES DE CAOS

 NOCIONES DE INCERTIDUMBRE
• COMPLEJIDAD DE SOFTWARE
 MÁQUINAS DE ESTADO FINITO

• INCERTIDUMBRE

• MODULARIDAD • PROPIEDADES DE CONJUNTOS

• GENERALIDAD - GENERACIDAD
• MODELOS DE ANÁLISIS DE
SISTEMAS MAS UTILIZADOS
• INTERFAZ
 I S
Á LIS
N
A
D E O S
Í AS ET
G B J
L O O
D O OR
T O S P
ME D A
T A
I EN
OR
 METODOLOGÍAS DE ANÁLISIS
ORIENTADAS POR OBJETOS

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

• Shaller-Mellor: Orientación a Objetos
• OOIE: : (Ingeniería de Información Orientada Por Objetos)
• Booch: (Analisis y diesño O O)
• 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.
 METODOLOGÍAS DE ANÁLISIS
ORIENTADAS POR OBJETOS

MT: (Técnicas de Modelado de Objetos).

ombina conceptos de objetos con otros de modelo
tidad-relación.

cluye:
Un modelo estático
(basado en clase, atributo, operación, relación y agregaci

Un modelo dinámico (Basado en diagramas

•eventos-estados que describe de forma abstracta
•el comportamiento que se pretenda que tenga el sistema).
 METODOLOGÍAS DE ANÁLISIS
ORIENTADAS POR OBJETOS

Shaller-Mellor:

• Produce modelos que se prestan a la simulación y a la ejecución,

permitiendo validar el comportamiento del sistema independiente
de todo diseño y de toda implementación.

• Divide el problema en cierto número de dominios:

• Dominio de la aplicación.
• Dominio del servicio (ej: Dominio de interfaz de usuario)
• Domino de la arquitectura de software.
• Dominio de Implementación,
(tales como el sistema operativo o el lenguaje).
 METODOLOGÍAS DE ANÁLISIS
ORIENTADAS POR OBJETOS

OOIE :(Ingeniería de Información Orientada Por Objetos) –

(Martín-Odell)

Booch:

OOSE: (Ingeniería de Software Orientados por Objetos)

OSA: (Análisis de Sistemas Orientado por Objetos)

FUSIÓN: Combina lo mejor de los anteriores.
 METODOLOGÍAS DE ANÁLISIS
ORIENTADAS POR OBJETOS

MOSES:
•Modelo Objetos y Clases.
•Modelo Eventos.
•Modelo Diagramas de Objetos.
•Notación de Objetos de Negocios.
•Modelo de Proceso.
 LISTA DE METODOLOGÍAS DE ANÁLISIS
ORIENTADAS POR OBJETOS

SOMA: (Enfoque de Modelado de Objetos Semánticos)

UML: Unify Modeling Language.
 METODOLOGÍAS DE ANÁLISIS
ORIENTADAS POR OBJETOS

Sybtropy:
•Modelo esencial.
•Modelo de especificación
•Modelo de implementación
MOSES:
•Modelo Objetos y Clases.
•Modelo Eventos.
•Modelo Diagramas de Objetos.
•Notación de Objetos de Negocios.
•Modelo de Proceso.
 METODOLOGÍAS DE ANÁLISIS
ORIENTADAS POR OBJETOS

n orden aproximado de aparición.

oad-Yourdon: Las ideas de Análisis estructurado se intentan
sladar a la orientación por objetos.
ontiene cinco fases:
Fase-I: Búsqueda de clases y objetos, partiendo del
dominio de la aplicación.
Fase-2: Identificación de la estructura, buscando relacione
de generalización y especialización y de todo-parte
Fase-3: Búsqueda de "sujetos" (grupos de clases objetos)
Fase-4: Identificación de atributos.
Fase-5: Definición de servicios.
 4. “ANÁLISIS” y “SÍNTESIS”

• ANALISIS: Descomponer

SINTESIS: Unir o agrupar

 4. ¿POR QUÉ “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.

HAY UNA FUERTE CRISIS EN LOS PROYECTOS DE SOFTWARE

31% se cancela antes de

terminar el proyecto.

16% terminan
dentro del CAUSAS: Se estima que:
tiempo 53%
y costo. sobrepasa •16% por no involucrar al usuario
tiempo y costo.
• 14% por falta de ayuda a
los directivos.

•12% por falta de declaración

clara de los requerimientos.

En las estadisticas del standish Group (www.standishgroup.com)

 “ANÁLISIS” DE SISTEMAS

METODOLOGIA DE ESTUDIO DE SISTEMAS

CONTIENE DOS ASPECTOS

TIPOS Y/O ESTRATEGIAS
Del proceso :
1. El lenguaje de modelamiento:
• LIBRE
(SIMBOLOS – REGLAS – • CASCADA
SEMANTICA,...) • PROTOTIPOS
• ESPIRAL
• EVOLUTIVOS
• ITERATIVOS INCREMENTALES, .......
2. El proceso de
modelamiento Modelos :

(ACTIVIDADES Y • ANÁLISIS ESTRUCTURADO

ORDEN DE LAS • ENTIDAD – RELACIÓN
MISMAS EN EL • ORIENTACIÓN A OBJETOS
TIEMPO)
 Construcción de Software OO
[Meyer- - Cap.27
- 1.998]

A1.Comprender
Objetivo A7
. Proporcionar una
base para el desarrollo
el problema del del sistema
análisis:
A2.Suscitar cuestiones
relevantes del problema A6.
Asegurar satisfaga las
y del sistema necesidades de sus usuarios
y definir los criterios de aceptación

A3.Proporcionar una base para A5.

responder preguntas acerca de Decidir lo que no
tiene que hacer el
las propiedades específicas sistema.
del problema y del sistema

A4.Decidir lo que SI tiene

que hacer el sistema.
 ANALISIS ESTRUCTURADO

ENTIDAD Fluj
o Dato
Entidad o s
Flujo de Datos Agente Externo
Flujo de Datos
Flujo de Datos
PROCESO Proceso
Entidad o O
Agente Externo Sistema Entidad o
ALMACENAMIENTO Flujo de Datos Agente Externo
Flujo de Datos

ENTIDAD RELACION CARDINALIDAD

entidad 1 a 1

Nombre Entidad
Nombre Entidad
ENTIDAD • Atributos 1 a muchos
• atributos
0
relación
1 Muchos a 1
ASOCIACION
Estudiante Profesor
• Atributos
• Atributos
Muchos a Muchos
Cardinalidad
CONSTRUCCIÓN DE SOFTWARE.

CONSTRUCCIÓN DE SOFTWARE

ORIENTADO A OBJETOS

Bertrand Meyer
Pretince Hall
Segunda edición 1.999
 CALIDAD DE SOFTWARE.

“LA INGENIERÍA DE SOFTWARE ES LA PRODUCCIÓN DE SOFTWARE DE CALIDAD

La calidad de software es la combinación de varios factores tales como:

Modularidad Velocidad

INTERNOS FACTORES DE EXTERNOS

(Detectables por CALIDAD DE (Detectables por
los desarrolladores) SOFTWARE los usuarios)

Legibilidad Facilidad
de uso
CALIDAD DE SOFTWARE. – Factores Externos -

PORTABILIDAD
CORRECCIÓN
FACILIDAD DE USO FIABILIDAD
ROBUSTEZ
FACTORES
FUNCIONALIDAD EXTERNOS
DE EXTENSIBILIDAD
CALIDAD MODULARIDAD
OPORTUNIDAD REUTILIZACIÓN
DE
SOFTWARE
OTRAS CUALIDADES COMPATIBILIDAD

INTEGRIDAD EFICIENCIA
VERIFICABILIDAD

REPARABILIDAD

ECONOMIA

DOCUMENTACIÓN
 CALIDAD DE SOFTWARE– Factores Externos-.

CORRECCIÓNEs 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.

Sistema de aplicación

Biblioteca de aplicación
...Mas Biblioteca...

Biblioteca Básica

Biblioteca Núcleo
Compilador

Sistema operativo

Hardware Niveles en un proceso de

desarrollo que incluye
reutilización.
 CALIDAD DE SOFTWARE–Factores Externos-.

ROBUSTEZ

Es la capacidad del sistema de software de reaccionar

apropiadamenteante condiciones excepcionales.

Esta complementa la corrección que cubre lo previsto

y aquí cubre lo imprevisto. Tendrá que ver

con el estudio de excepciones.

 CALIDAD DE SOFTWARE–Factores Externos-.

EXTENSIBILIDAD“Es la facilidad de adaptar los productos de software a los cambios

de especificación”

La extensibilidad es un problema de escala.

Hay dos principios básicos para mejorar la extensibilidad:

. Simplicidad de diseño: Una arquitectura simple siempre será más fácil de adaptar a
cambios que una arquitectura compleja.

. Descentralización: Cuanto más autónomos sean los módulos, más alta es la probabil
de que un cambio simple solo afecte a un módulo o un número reducido de ellos.
 CALIDAD DE SOFTWARE-Factores
Externos-.
Es la capacidad de los elementos de software de servir para la construcción
REUTILIZACIÓ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.

Es la facilidad de combinar unos elementos de software con

COMPATIBILIDAD
otros.

La clave recae en la homogenmeidad del diseño y en acordar convenciones estandares para

comunicación entre programas.

• Formatos de archivos estándar

• Estructuras de datos estándar

• Interfaces de usuario estándar.

 CALIDAD DE SOFTWARE-Factores Externos-

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

EFICIENCIA
de recursos de hardware (Tiempo de procesador, espacio de memoria interna o
(Rendimiento)
externa, ancho de banda..)

“No importa que tan rápido es hasta que no esté correcto”.

PORTABILIDAD Es la facilidad de transferir los productos software a diferentes

entornos de hardware y software.
(Transportabilidad)
Se acostumbra a utilizar el término <<plaraforma>> para
denotar el
Hardware-Software que empleará un determinado sistema.
 CALIDAD DE SOFTWARE – Factores Externos - .

FACILIDADEs la facilidad con la cual las personas de diferentes niveles y oficios puede
DE USO aprender a usar los productos software y aplicarlos a la solución de problem
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”.

Es el conjunto de posibilidades que proporciona un sistema.

FUNCIONALIDAD Problema difícil: ¿Cuánta funcionalidad es suficiente?
sin debilitar el sistema pero también haciéndolo completo.

Otras Cualidades.

Deseable

Común Depuración
Previsión de los
primeros laza –
mientos.
Funcionalidad
 CALIDAD DE SOFTWARE – Factores Externos - .

Es la capacidad de un sistema de software de ser lanzado cuando los usuarios

OPORTUNIDAD
lo desean, o antes.

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,adatos...).

Reparabilidad:Es la facilidad para reprarar (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.
 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.

Los beneficios de una verdadera EXTENSIBILIDAD y

REUTILIZACIÓN
tienen como resultante módulos que sean autocontenidos 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.
 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.
ADEMAS DE LA EXTENSIBILIDAD Y LA REUTILIZACIÓN, HAY
UN CONJUNTO DE PROPIEDADES DE LA MODULARIDAD

DESCOMPOSICIÓN

EXTENSIBILIDAD COMPOSICIÓN
CORRESPONDENCIA
DIRECTA
5 CRITERIOS COMPRENSIBILIDAD

POCAS INTERFACES CONTINUIDAD

PROTECCIÓN
INTERFACES PEQUEÑAS
(Acoplamiento débil) 5 REGLAS
UNIDADES MODULARES
INTERFACES LINGÜÍSTICA
EXPLÍCITAS
AUTODOCUMENTACIÓN
OCULTACIÓN DE
INFORMACIÓN 5 PRINCIPIOS ACCESO UNIFORME

REUTILIZACIÓN ABIERTO-CERRADO

ELECCIÓN ÚNICA
CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.

1. DESCOMPOSICIÓN MODULAR

2. COMPOSICIÓN MODULAR

5 CRITERIOS 3. COMPRENSIBILIDAD MODULAR

4. CONTINUIDAD MODULAR

5. PROTECCIÓN MODULAR
 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.

1. DESCOMPOSICIÓN MODULAR:

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

complejos, interconectados mediante una estrucutra sencilla y satisfactoriamente
dependientes, para permitir que el trabajo futuro pueda proseguir porseparado en cada
uno de ellos”.

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

Abstracción funcional de más alto nivel
Una jerarquía A
descendente
Secuencia

B C
D

Condicional
Bucle

C1 I II C2 I1
 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.

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.

 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.

3. COMPRENSIBILIDAD MODULAR:

“Un método favorece la compresebilidad 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”.
 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.

PROTECCIÓN MODULAR:

n método satisface la protección modular si produce arqueitecturas en las cuale

efecto de una situación anormal que se produzca dentro de un módulo durante

ecución, queda confinado a dicho módulo , ó, en el peor de los casos, solo a unos

cos módulos vecinos”.

rores en ejecución – Entradas erroneas – Agotamiento de memoria –

olaciones de espacio – otros.

 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.

DE LOS 5 CRITERIOS ANTERIORES SE DERIVAN CINCO REGLAS QUE SE DEBEN

SEGUIR PARA GARANTIZAR LA MODULARIDAD.

CORRESPONDENCIA
DIRECTA

POCAS INTERFACES

5 REGLAS INTERFACES PEQUEÑAS

(Acoplamiento débil)

INTERFACES
EXPLÍCITAS

OCULTACIÓN DE
INFORMACIÓN
 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.

vado principalmnete de los criterios de modularidad: Continuidad y Descomposición.

– Regla - CORRESPONDENCIA DIRECTA.

estructura modular obtenida en el proceso de construcción de un sistema software
be seguir siendo compatible con cualquier otra estructura modular obtenida en el
ceso de modelado del dominio del problema“.
 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.

Esta regla se deriva principalmente de los criterios de: Continuidad y Protección

2. - Regla - POCAS INTERFACES

“Cada módulo debe comunicarse con el menor número de módulos posible“.

Restringe el número total de canales de comunicación entre módulos en una arquitectura

de software.
 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.

erivado principalmnete de los criterios de modularidad: Continuidad y Protección.

3. - Regla -PEQUEÑAS INTEFACES

(Acoplamiento débil).

“ Si dos módulos se comunican deben intercambiar

la menor información posible“.

Se refiere mas al tamaño de las

conexiones que al número de estas.
 CALIDAD DE SOFTWARE – Factores Internos –

MODULARIDAD.
Esta regla se deriva principalmente de los criterios de: Descomposición y composició

4. - Regla - 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“.

“Totalitarismo de la sociedad de módulos”

No solo exige que toda conversación este limitada
a unos pocos participantes y que conste de pocas
palabras, sino que también requiere que tales
conversaciones deban ser en público y en voz alta.
 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.
ivado principalmnete de los criterios de modularidad:
to con la CONTINUIDAD se ref. Descomposición, Composición, Comprensibilidad

. 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
e los módulos clientes.“.

Descripción pública debería incluir algunas

de las propiedades del módulo (Exportadas), las
Parte Pública demás debverían ser secretas (o privadas).

Parte Secreta Supone que todo módulo es conocido por el resto

del mundo( por el resto de diseñadores de los
otros módulos) a través de alguna disposición
oficial o de propiedades públicas.

La ocultación de información hace énfasis

En separar la funcionalidad de la implementación.
 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.
¿Qué propiedades deben ser públicas y cuáles secretas?
COMO REGLA GENERAL:

La descripción de la funcionalidad del módulo.

Parte Pública
Los módulos clientes, deberían basarse solo
en las propiedades públicas de los proveedores.

Parte Secreta

Todo lo que tenga que ver con la implementación

de la funcionalidad del módulo debe ser secreto,
para preservar los otros módulos contra futuros
cambios

un enfoque totalmente formal... Esta propiedad – ocultación de información- se enunciaría

ara probar la corrección de un modulo se necesita sumir algunas propiedades relativas a lo
oveedores. La ocultación de información significa que tales pruebas solo se pueden basar
s preopiedades públicas de los proveedores, nunca en las propiedades secretas”.
 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.

DE LAS CINCO REGLAS E INDIRECTAMENTE DE LOS CINCO CRITERIOS SE DERIBAN

LOS CINCO PRINCIPIOS RELATIVOS A LA CONSTRUCCIÓN DE SOFTWARE.

1. UNIDADES MODULARES ES LINGÜÍSTICA

2. AUTODOCUMENTACIÓN

5 PRINCIPIOS 3. ACCESO UNIFORME

4. ABIERTO-CERRADO

5. ELECCIÓN ÚNICA
 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.

. 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 leneguaje 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).
 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.

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“.

Busca Garantizar que el módulo (software) y su documentación esten sincronizadas.

Será muy difícil manejarlas por separado cuando vengan los cambios.
 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.

PRINCIPIO ACCESO UNIFORME

Todos los servicios ofrecidos por un módulo deben deben estar disponibles a través
una notación uniforme sin importar si están implementados a través de almacenamientos
de un cálculo“.
e deriva del criterio de Continuidad y es un caso especial de ocultación de información.

CASO-1
x.f
Nombre de una característica aplicable a x

Nombre utilizado para acceder a cierto objeto

Al invocar el objeto sucede que:

El CASO-1 SI afecta el saldo de una cuenta.

CASO-1

El CASO-2 NO afecta el saldo de una cuenta.

Pocos lenguajes satisfacen este principio. (Algol W)

f(x)
 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.

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 definidad.

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.
 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.

. 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 concecuencia de las reglas abierto-cerrado y ocultación de información

ada módulo deberá conocer estrictamente lo necesario para su funcionamiento y un módu

menos uno dentro de la familia de módulos y no más que uno, deberá conocer la lista
ompleta de todos los módulos.
 CALIDAD DE SOFTWARE – Factores Internos –
MODULARIDAD.
Una
1. ESTRUCTURA adecuada es CLAVE para lograr la reutilización y extensebilidad.

2. Descomposición Composición
(visión descendente) (visión ascendente)

3. Modularidad aplica a: (Especificaciones – Diseño – implementación)

El control del volumen y la comunicación entre módulos es clave para una

4.
Buena arquitectura modular.

5. La ocultación de información implica

separar claramente Implementación
La interfaz
6. Módulo Abierto: Módulo Cerrado:
Aún está sometido Puede ser usuado a través de
a extensiones. interfaces por su módulos clientes.

7. Otros más
 GENERACIDAD [Meyer-Construcción de Software OO- Cap.10- 1.998]

La GENERACIDAD es un mecanismo para definir patrones parametrizados de módulos,

cuyos parámetros representan tipos.
MANEJADOR_DE_TABLA_DE_ENTEROS
MANEJADOR_DE_TABLA_DE_ELECTRONES Generalización

MANEJADOR_DE_TABLA_DE_CUENTA
S
Generacidad
Para escribir un único patrón de módulo de la forma:

MANEJADOR_DE_TABLA [G] Especialización

[G] representa un tipo arbitrario y se conoce con el nombre de

Este módulo se conoceparámetro genérico formal.
módulo genérico- no es
módulo sino proyecto de Para obtener un módulo real hay que proporcionar un tipo,
muchos módulos. Conocido con el nombre de parámetro genérico actaul.

MANEJADOR_DE_TABLA [INTEGER]
MANEJADOR_DE_TABLA [ELECTRON]
MANEJADOR_DE_TABLA [CUENTA]
 GENERACIDAD [Meyer-Construcción de Software OO- Cap.10- 1.998]
Abstracción

CONJUNTO
_DE_LIBROS

Parametrización de tipos Parametrización de tipo

LISTA_DE_ LISTA_DE_ LISTA_DE_

LISTA_DE_
PERSONAS LOBROS LOBROS
REVISTAS

Generalización

LISTA_ENLAZADA
Generacidad DE_LIBROS

Especialización
La generacidad es una facilidad para autores de módulos proveedores.
Especialización
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.
 PAQUETES [Meyer-Construcción de Software OO- Cap.4.7- 1.998]

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 caraterísticas del paquete.

P3. Cada paquete puede especificar unos derechos de acceso precisos que gobierna
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 compilable (que pueda usarse para implementación y no solo

para especificación y diseño) es posible compilar paquetes por separado.
 HACIA UNA TENOLOGIA DE OBJETOS
[Meyer-Construcción de Software OO- Cap.5- 1.998]

5.1. LOS INGREDIENTES DE LA COMPUTACIÓN (Triangulo básico)

La arquitectura de un sistema
se obtiene de objeto o de
Acción (datos u)
funciones.
(funciones) Objeto

Procesadores
(o hilos de control)
• 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

cuál es el criterio apropiado para encontrar los módulos del sistema?

i los módulos se construyen:
. como unidades de descomposición funcional. Otros métodos
. Basándose en los principales tipos de objetos. OO.
 HACIA UNA TENOLOGIA DE OBJETOS
[Meyer-Construcción de Software OO- Cap.5- 1.998]

• Ordenación y desarrollo OO
5.2. Descomposición funcional:
• Continuidad • Reutilización.
• Desarrollo descendente • Producción y descripción
• No solo una función • valoración del diseño
• Encontrar la cima • Descendente
• Funciones y evolución
• Interfaz y diseño de software
• Ordenación prematura
 HACIA UNA TENOLOGIA DE OBJETOS
[Meyer-Construcción de Software OO- Cap.5- 1.998]

5.3. Descomposición basada en objetos:

• Compatibilidad. • Reutilización.

• Extensibilidad.
 Análisis orientado a objetos
[Meyer-Construcción de Software OO- Cap.27- 1.998]

Objetivo del análisis:

A1. Comprender el problema que deberá resolver el software si llegare a existir.

A2. Sussitar cuestiones relevantes respecto del problema y del sistema.

A3. Proporcionar una base para responder para responder preguntas acerca de las
propiedades específicas del problema y del sistema.

A4. Decidir lo que tiene que hacer el sistema.

A5. Decidir lo que no tiene que hacer el sistema.

A6. Asegurar que el sistema satisfaga las necesidades de sus usuarios y definir los
criterios de aceptación (especialmente cuando el sistema se desarrolla para
clientes externos con una relación contractual).

A7. Proporcionar una base para el desarrollo del sistema.

 Análisis orientado por objetos
[Meyer-Construcción de Software OO- Cap.27- 1.998]

A1. Comprender
Objetivo A7. Proporcionar una
base para el desarrollo
el problema
del del sistema
análisis:
A2. Suscitar cuestiones
relevantes del problema A6. Asegurar satisfaga las
y del sistema necesidades de sus usuarios
y definir los criterios de aceptación

A3. Proporcionar una base

para
A5. Decidir lo que no
responder preguntas acerca
tiene que hacer el
de las propiedades
sistema.
específicas
del problema y del sistemaA4. Decidir lo que tiene
que hacer el sistema.
CLASE: Es un tipo abstracto de dato equipado de una implementación posiblemente parcia

“Una clase es un modelo y un objeto es una instancia de ese modelo” [Meyer pag.158]

CLASE EFECTIVA: Es una clase que está completamente implementada.

Tiene 3 elementos:

•(E1) La especificación de un TAD (conjunto de funciones con sus axiomas y

precondiciones que describen las propiedades de las funciones).
• (E2) La selección de una representación.
• (E3) 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.

 BERTHRAN MEYER - SOBRE LA METODOLOGIA

No hay reglas infalibles, por el contrario, puede ser muy dañinas. Si se puede
tener una serie de reflexiones que pueden ayudar a evitar problemas.

PRONCIPIOS METODOLOGICOS (P.M.)

P.M. DE LAS BASES TEORICAS: Las reglas de metodologías de software

eben basarse en una teroría sobre el tema adyacente”.

“P.M. DE LAS BASES PRÁCTICAS: Las reglas de metodologías de software

deben estar respaldadas por una amplia experiencia práctica”.
 BERTHRAN MEYER - SOBRE LA METODOLOGIA

“P.M. DE LA EXPERIENCIA EN REUTILIZACIÓN:

Para poder asegurar que se es un e´perto en el campo de la orientación a objeto
Se debe haber desempeñado un papel clave en el desarrollo de alguna bibliotec
De clases que haya sido utilizada con éxito en un grupo amplio de proyectos
Diferentes y en diferentes contextos.

Una tipologia de reglas: Reglas de recomendación o absolutas.

“CLASIFICACIÓN DE LAS REGLA METODOLÓGICAS:

• Positiva absoluta: “Hacer siempre a” .
• Negativa absoluta: “No utilizar nunca b” .
• Recomendación positiva: “Utilizar c siempre que sea posible”.
• Recomendación negativa “Evitar d siempre que sea posible”.
 BERTHRAN MEYER - SOBRE LA METODOLOGIA

P.M. 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 estrucuturas del lenguaje.

NEGATICOS ABSOLUTOS:

“P.M. 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
Debe estar acompañado por una descripción precisa de la forma de sustituir este
Mecanismo por otros.
 BERTHRAN MEYER - SOBRE LA METODOLOGIA

“P.M. DE LAS RECOMENDACIONES:

Al elbaorar recomendaciones (positivas o negativas) use principio,

no peregulladas. Para ayudarse a sí mismo a hacer la distinción,
examine la negación de la regla.

EXCEPCIONES:

P.M. DE INCLUSION DE EXCEPCIONES:

i una regla metodológica presenta una guía que es aplicable en

eneral, pero que tiene excepciones, las excepciones deben anunciarse
omo partede la regla.
 BERTHRAN MEYER - SOBRE LA METODOLOGIA

P.M. 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 subadyacente.

• 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 pasand

a una herramienta mejor”.
 BERTHRAN MEYER - SOBRE LA METÁFORAS

odo el mundo utiliza metáforas -analogías- para enseñar temas técnicos.

na metáfora se define tanto por lo que difiere como lo que tiene en com

A se parece a B
B tiene la propiedad P
_____________________________
Conclusión: A tiene la propiedad P.
 BERTHRAN MEYER - SOBRE LA METÁFORAS

PORTANCIA DE SER HUMILDE:

or grande que se sea, no hay que sobrestimar el valor de su experienci

Demasiada confianza puede hacer daño.
l diseño de un gran proyecto de software es una aventura intelectual.

odo proyecto ambicioso de software es un nuevo reto,

o hay recetas seguras.

as experiencias no hacen infalible al desarrollador. Se es mejor cuanta

ayor experiencia positiva se tenga, peor no se es infalible.