D. Parnas: Designing Software for Ease of Extension and Contraction
Anuncio
Paper
Designing Software for Ease of Extension and Contraction,
presentado en el Third International Conference on Software
Engineering, Atlanta, GA, USA, en Mayo del 78.
Por David L. Parnas:
I
Doctor en ingenierı́a eléctrica en la universidad Carnegie
Mellon.
I
Principal impulsor de la modularización en el desarrollo de
software.
I
Introdujo el concepto de Information Hidding en la
programación.
Grupo 4 (Por orden alfabético)
I
Román Gorojovsky
I
Luis Mastrángelo
I
Eduardo Perez Leale
I
Luis Ziliani
Introducción
I
Contexto: Corre 1978, no existen procesos definidos para la
construcción de software.
I
I
Concepción monolı́tica: un problema = una solución/programa.
No se diseña anticipando cambios.
Introducción
I
Contexto: Corre 1978, no existen procesos definidos para la
construcción de software.
I
I
I
Concepción monolı́tica: un problema = una solución/programa.
No se diseña anticipando cambios.
Parnas estudia los problemas surgidos al intentar extender o
contraer un software, y propone soluciones a dichos problemas.
Introducción
I
Contexto: Corre 1978, no existen procesos definidos para la
construcción de software.
I
I
I
I
Concepción monolı́tica: un problema = una solución/programa.
No se diseña anticipando cambios.
Parnas estudia los problemas surgidos al intentar extender o
contraer un software, y propone soluciones a dichos problemas.
Es un paso en el esfuerzo de llevar la construcción de software
al nivel de ingenierı́a.
Introducción
I
Contexto: Corre 1978, no existen procesos definidos para la
construcción de software.
I
I
I
I
I
Concepción monolı́tica: un problema = una solución/programa.
No se diseña anticipando cambios.
Parnas estudia los problemas surgidos al intentar extender o
contraer un software, y propone soluciones a dichos problemas.
Es un paso en el esfuerzo de llevar la construcción de software
al nivel de ingenierı́a.
Diferencias entre la Ingenierı́a de Software con otras
disciplinas.
(∀n, m ∈ ℵ)n + m ∈ ℵ
(∀n, m ∈ <)n + m ∈ <
|
{z
}
Abstracción
⇓
(∀a, b ∈ Grupo)n ◦ m ∈ Grupo
Ingeniero Electrónico
Matemático
Ingeniero en Sistemas
Familia de Programas
I
Parnas introduce el concepto de familias de programas y dá la
siguiente taxonomı́a:
I
Se ejecutan en distinto hardware. Ejemplo actual: Juegos para
PC y consolas o Gmail para PC y celular.
Familia de Programas
I
Parnas introduce el concepto de familias de programas y dá la
siguiente taxonomı́a:
I
I
Se ejecutan en distinto hardware. Ejemplo actual: Juegos para
PC y consolas o Gmail para PC y celular.
Ejecutan las mismas operaciones pero difieren en el formato de
entrada y/o salida de los datos.
Familia de Programas
I
Parnas introduce el concepto de familias de programas y dá la
siguiente taxonomı́a:
I
I
I
Se ejecutan en distinto hardware. Ejemplo actual: Juegos para
PC y consolas o Gmail para PC y celular.
Ejecutan las mismas operaciones pero difieren en el formato de
entrada y/o salida de los datos.
Difieren en las estructuras de datos o algoritmos debido a
recursos disponibles.
Familia de Programas
I
Parnas introduce el concepto de familias de programas y dá la
siguiente taxonomı́a:
I
I
I
I
Se ejecutan en distinto hardware. Ejemplo actual: Juegos para
PC y consolas o Gmail para PC y celular.
Ejecutan las mismas operaciones pero difieren en el formato de
entrada y/o salida de los datos.
Difieren en las estructuras de datos o algoritmos debido a
recursos disponibles.
Difieren en las estructuras de datos o algoritmos debido a las
diferencias en el tamaño de la entrada.
Familia de Programas
I
Parnas introduce el concepto de familias de programas y dá la
siguiente taxonomı́a:
I
I
I
I
I
Se ejecutan en distinto hardware. Ejemplo actual: Juegos para
PC y consolas o Gmail para PC y celular.
Ejecutan las mismas operaciones pero difieren en el formato de
entrada y/o salida de los datos.
Difieren en las estructuras de datos o algoritmos debido a
recursos disponibles.
Difieren en las estructuras de datos o algoritmos debido a las
diferencias en el tamaño de la entrada.
Algunos usuarios tal vez requieren menos funcionalidades que
otros. Estos usuarios menos demandantes tal vez no quieren
estar obligados a pagar por los recursos consumidos por las
funcionalidades que no utilizan.
Como se manifiesta la falta de extenciones y
contracciones
I
Distribución excesiva de la información: Dificultad en
expandir o contraer un programa asumiendo que una
caracterı́stica dada está presente o no.
Como se manifiesta la falta de extenciones y
contracciones
I
Distribución excesiva de la información: Dificultad en
expandir o contraer un programa asumiendo que una
caracterı́stica dada está presente o no.
I
Una cadena de componentes que transforman datos: Si
se puede prescindir de un componente en la cadena, en
general es dı́ficil de removerlo debido a la incompatibilidad de
los datos de entrada y salida.
Como se manifiesta la falta de extenciones y
contracciones
I
Distribución excesiva de la información: Dificultad en
expandir o contraer un programa asumiendo que una
caracterı́stica dada está presente o no.
I
Una cadena de componentes que transforman datos: Si
se puede prescindir de un componente en la cadena, en
general es dı́ficil de removerlo debido a la incompatibilidad de
los datos de entrada y salida.
I
Componentes que realizan más de una función: Se suele
incluir en un mismo componente más de una funcionalidad
debido a que las funciones parecen demasiado simples para
separarlas.
Como se manifiesta la falta de extenciones y
contracciones
I
Distribución excesiva de la información: Dificultad en
expandir o contraer un programa asumiendo que una
caracterı́stica dada está presente o no.
I
Una cadena de componentes que transforman datos: Si
se puede prescindir de un componente en la cadena, en
general es dı́ficil de removerlo debido a la incompatibilidad de
los datos de entrada y salida.
I
Componentes que realizan más de una función: Se suele
incluir en un mismo componente más de una funcionalidad
debido a que las funciones parecen demasiado simples para
separarlas.
I
Ciclos en la relacion “usa”: Nada funciona hasta que todo
funciona. Diseño horizontal (vs. diseño vertical).
Pasos hacia una mejor solución
I
Definición de los requerimientos: identificando primero los
subconjuntos de funcionalidad. De átomos a moléculas.
Pasos hacia una mejor solución
I
Definición de los requerimientos: identificando primero los
subconjuntos de funcionalidad. De átomos a moléculas.
I
Ocultamiento de la información: interfaces y definición de
módulos. Exponer la semántica de la funcionalidad. Qué hace?
vs. Cómo lo hace?.
Pasos hacia una mejor solución
I
Definición de los requerimientos: identificando primero los
subconjuntos de funcionalidad. De átomos a moléculas.
I
Ocultamiento de la información: interfaces y definición de
módulos. Exponer la semántica de la funcionalidad. Qué hace?
vs. Cómo lo hace?.
I
El concepto de máquina virtual: Definición de núcleo,
diseño en capas.
Pasos hacia una mejor solución
I
Definición de los requerimientos: identificando primero los
subconjuntos de funcionalidad. De átomos a moléculas.
I
Ocultamiento de la información: interfaces y definición de
módulos. Exponer la semántica de la funcionalidad. Qué hace?
vs. Cómo lo hace?.
I
El concepto de máquina virtual: Definición de núcleo,
diseño en capas.
I
Diseñar la estructura de “usos”: Por ejemplo, diagrama de
packages con esta relación.
Monolı́tica vs. Incremental
Conclusiones
I
En el desarrollo de software no existen soluciones canónicas.
Parnas, sin embargo, propuso hace 30 años una forma de
construir software que aún sigue vigente, mediante la
modularización de componentes.
Conclusiones
I
En el desarrollo de software no existen soluciones canónicas.
Parnas, sin embargo, propuso hace 30 años una forma de
construir software que aún sigue vigente, mediante la
modularización de componentes.
I
Aún ası́, algunos de estos problemas siguen vigentes. Ejemplo,
mostrar un sistema andando antes de tiempo.
Conclusiones
I
En el desarrollo de software no existen soluciones canónicas.
Parnas, sin embargo, propuso hace 30 años una forma de
construir software que aún sigue vigente, mediante la
modularización de componentes.
I
Aún ası́, algunos de estos problemas siguen vigentes. Ejemplo,
mostrar un sistema andando antes de tiempo.
I
La relación de “usa” y de “subset mı́nimo” como base para el
desarrollo incremental.
Conclusiones
I
En el desarrollo de software no existen soluciones canónicas.
Parnas, sin embargo, propuso hace 30 años una forma de
construir software que aún sigue vigente, mediante la
modularización de componentes.
I
Aún ası́, algunos de estos problemas siguen vigentes. Ejemplo,
mostrar un sistema andando antes de tiempo.
I
La relación de “usa” y de “subset mı́nimo” como base para el
desarrollo incremental.
I
Concepto de “Virtual Machine”.
