En la primera parte se aborda la concepción técnica o tradicional de lo que se le atribuye a la definición de ingeniería de software. Información complementaria pueden obtenerla en Wikipedia y en la Guide to Software Engineering Body of Knowledge (SWEBoK).
En la segunda parte se remite al lector a un ensayo que se publicó en el libro de H. Oktaba y M. Piattini (Eds.) Software Process Improvement for Small and Medium Enterprises: Techniques and Case Studies, en 2008.
En la tercera parte se expone brevemente una concepción ecléctica de lo que es la ingeniería de software a partir de mis últimas investigaciones, condensadas en la tesis de maestría con la cual obtuve el grado en 2011. En este ensayo se desnudan los mitos que se han generado en torno a la ingeniería de software a partir de investigar sus fundamentos. La tesis estará en línea próximamente en la biblioteca de la Universidad Autónoma Metropolitana - Unidad Azcapotzalco.
Parte 1: ¿Qué es la Ingeniería de Software?: La visión tradicional
Contenido
La Ingeniería de Software
El Paradigma de lo Orientado a Objetos
La Programación Orientada a Objetos
Fundamentos de lo Orientado a Objetos
El Proceso Unificado
Proceso
Unificado y MSF; complementos tecnológicos
El
ciclo de vida del software en el Proceso Unificado
Figura 1.
Estructura del Proceso Unificado
Figura 2.
Arquitectura lógica de tres capas de una aplicación
cliente/servidor
Diseño
Conceptual
Diseño
Lógico
Diseño
físico
Figura 3.
Arquitectura física de tres capas de la aplicación
cliente/servidor
Comentario Final... para
reflexionar
Literatura
citada
Ultima publicación
La
Ingeniería de Software
Según la definición del IEEE, citada por
[Lewis 1994] "software es la suma total de los
programas de computadora, procedimientos, reglas, la
documentación asociada y los datos que pertenecen a un sistema
de cómputo". Según el mismo autor, "un producto de
software es un producto diseñado para un usuario". En este
contexto, la Ingeniería de Software (SE del inglés Software
Engineering) es un enfoque sistemático del desarrollo,
operación, mantenimiento y retiro del software", que en
palabras más llanas, se considera que "la Ingeniería de
Software es la rama de la ingeniería que aplica los
principios de la ciencia de la computación y las matemáticas
para lograr soluciones costo-efectivas (eficaces en costo o
económicas) a los problemas de desarrollo de software", es
decir, "permite elaborar consistentemente productos
correctos, utilizables y costo-efectivos" [Cota 1994].
El proceso de ingeniería de software
se define como "un conjunto de etapas parcialmente ordenadas
con la intención de logra un objetivo, en este caso, la
obtención de un producto de software de calidad" [Jacobson 1998].El proceso de desarrollo de software
"es aquel en que las necesidades del usuario son traducidas
en requerimientos de software, estos requerimientos transformados
en diseño y el diseño implementado en código, el código es
probado, documentado y certificado para su uso operativo".
Concretamente "define quién está haciendo qué, cuándo
hacerlo y cómo alcanzar un cierto objetivo" [Jacobson 1998].
El proceso de desarrollo de software
requiere por un lado un conjunto de conceptos, una metodología y
un lenguaje propio. A este proceso también se le llama el ciclo
de vida del software que comprende cuatro grandes fases:
concepción, elaboración, construcción y transición. La
concepción define le alcance del proyecto y desarrolla un caso
de negocio. La elaboración define un plan del proyecto,
especifica las características y fundamenta la arquitectura. La
construcción crea el producto y la transición transfiere el
producto a los usuarios.
Actualmente se encuentra en una etapa de
madurez el enfoque Orientado a Objetos (OO) como paradigma del
desarrollo de sistemas de información. El Object Management
Group (OMG) es un consorcio a nivel internacional que integra
a los principales representantes de la industria de la
tecnología de información OO. El OMG tiene como objetivo
central la promoción, fortalecimiento e impulso de la industria
OO. El OMG propone y adopta por consenso especificaciones
entorno a la tecnología OO. Una de las especificaciones más
importantes es la adopción en 1998 del Lenguaje de Modelado
Unificado o UML (del inglés Unified Modeling Language) como
un estándar, que junto con el Proceso Unificado están
consolidando la tecnología OO.
Para mayor información consulta las siguientes
direcciones electrónicas:
- Carnegie Mellon's
Software Engineering Institute (SEI) donde encontrarás información y
documentos relacionados con la Ingeniería de Software, análisis y diseño,
metodologías, métricas, certificación, calidad (CMM), seguridad (CERT),
etc.
- The
Rational Edge e-Magazine Es una revista electrónica donde mensualmente
se publican artículos sobre la importancia de la ingeniería en el
software, con experiencias de la industria
- Herramientas de
Ingeniería de Software Aquí encontrarás información sobre las
herramientas líderes que implementan la ingeniería de software, desde el
modelado de sistemas con UML hasta el proceso unificado que tiene que ver
con la administración de proyectos.
El
Paradigma de lo Orientado a Objetos
Antes de analizar los pasos del proceso de
desarrollo de software se expondrán los conceptos fundamentales
del paradigma que guía la tecnología OO.
Existen conceptos ligados en torno a la
tecnología orientada a objetos: el paradigma, los principios, el
análisis y el diseño, mismos que a continuación se comentan.
La
Programación Orientada a Objetos
La Programación Orientada a Objetos
(OOP por sus siglas en inglés de Object Oriented Programming)
como paradigma, "es una forma de pensar, una filosofía, de
la cual surge una cultura nueva que incorpora técnicas y
metodologías diferentes. Pero estas técnicas y metodologías, y
la cultura misma, provienen del paradigma, no lo hacen. La OOP
como paradigma es una postura ontológica: el universo
computacional está poblado por objetos, cada uno
responsabilizándose por sí mismo, y comunicándose con los
demás por medio de mensajes" [Greiff 1994].
Se debe distinguir que la OOP como
paradigma (enfoque o manera de visualizar la realidad) y como
metodología (colección de características para la ingeniería
de software) no son la misma cosa. Sin embargo, la publicidad nos
confunde asociando la OOP más a una metodología, que al
paradigma. De aquí que "el interés en la OOP radica más
en los mecanismos que aporta para la construcción de programas
que en aprovechar un esquema alterno para el modelado de procesos
computacionales" [Greiff 1994].
La Programación Orientada a Objetos desde
el punto de vista computacional "es un método de
implementación en el cuál los programas son organizados como
grupos cooperativos de objetos, cada uno de los cuales representa
una instancia de alguna clase, y estas clases, todas son miembros
de una jerarquía de clases unidas vía relaciones de
herencia" [Greiff
1994].
Fundamentos
de lo Orientado a Objetos
El paradigma OO se basa en el concepto de
objeto. Un objeto es aquello que tiene estado (propiedades
más valores), comportamiento (acciones y reacciones a mensajes)
e identidad (propiedad que lo distingue de los demás objetos).
La estructura y comportamiento de objetos similares están
definidos en su clase común; los términos instancia y objeto
son intercambiables. Una clase es un conjunto de objetos
que comparten una estructura y comportamiento común.
La diferencia entre un objeto y una clase
es que un objeto es una entidad concreta que existe en tiempo y
espacio, mientras que una clase representa una abstracción, la
"esencia" de un objeto, tal como son. De aquí que un
objeto no es una clase, sin embargo, una clase puede ser un
objeto.
En el enfoque OO las propiedades del objeto
son claves. Los principios del modelo OO son:
abstracción, encapsulación, modularidad y jerarquía,
fundamentalmente, y en menor grado tipificación (typing),
concurrencia, persistencia. [Booch 1986] dice que si un
modelo que se dice OO no contiene alguno de los primeros cuatro
elementos, entonces no es OO.
- Abstracción. Es una
descripción simplificada o especificación de un sistema
que enfatiza algunos de los detalles o propiedades del
sistema, mientras suprime otros.
- Encapsulación. En el proceso
de ocultar todos los detalles de un objetoque no
contribuyen a sus características esenciales.
- Modularidad. Es la propiedad de
un sistema que ha sido descompuesto en un conjunto de
módulos coherentes e independientes.
- Jerarquía o herencia. Es el
orden de las abstracciones organizado por niveles.
- Tipificación. Es la
definición precisa de un objeto de tal forma que objetos
de diferentes tipos no puedan ser intercambiados o,
cuando mucho, puedan intercambiarse de manera muy
restringida.
- Concurrencia . Es la propiedad
que distingue un objeto que está activo de uno que no lo
está.
- Persistencia. Es la propiedad
de un objeto a través de la cual su existencia
trasciende el tiempo (es decir, el objeto continua
existiendo después de que su creador ha dejado de
existir) y/o el espacio (es decir, la localización del
objeto se mueve del espacio de dirección en que fue
creado).
Según [Booch 1986], los beneficios
del enfoque OO son:
- Primero, el uso del modelo OO
nos ayuda a explotar el poder expresivo de todos los
lenguajes de programación basados en objetos y los
orientados a objetos, como Smalltalk, Object Pascal, C++,
CLOS, Ada, [ y recientemente Java] .
- Segundo, el uso del modelo OO
alienta el reuso no solo del software, sino de diseños
completos.
- Tercero, produce sistemas que
están construidos en formas intermedias estables y por
ello son más resistentes al cambio en especificaciones y
tecnología.
El mismo autor considera que el principal
beneficio del OOD es que da un mecanismo para formalizar el
modelo de la realidad.
Las relaciones entre objetos definen el
comportamiento del sistema. Se dice que un objeto es un actor,
si su única función es operar sobre otros objetos. El objeto es
un servidor si solo es manejado por otros objetos y es un agente
si tiene ambas propiedades. Se dice que los objetos actúan entre
sí mediante mensajes, es decir, acciones que pide el
objeto transmisor que ejecute el objeto receptor. Dependiendo del
comportamiento definido para un objeto, éste tomará las
acciones para ejecutar o no el mensaje, de manera apropiada.
[Greiff 1994] comenta que
el Análisis Orientado a Objetos (OOA por sus siglas en
inglés de Object Oriented Analysis) "es un método de
análisis que examina los requerimientos desde la perspectiva
de las clases y objetos encontrados en el vocabulario de del
dominio del problema". Según [Booch 1986], el Diseño
Orientado a Objetos "es un método de diseño abarcando
el proceso de descomposición orientado a objetos y una
notación para representar ambos modelos lógico y físico
tal como los modelos estáticos y dinámicos del sistema bajo
diseño".
En cuanto a las metodologías OO, diremos
que hay un gran número de métodos orientado a objetos
actualmente. Muchos de los métodos pueden ser clasificados como
orientados a objetos porque soportan de manera central los
conceptos de la orientación a objetos. Algunos de las
metodología más conocidas y estudiadas hasta antes del UML
según [Jacobson
1992] son:
- Object-Oriented Design (OOD), Booch.
- Object Modeling Technique (OMT),
Rumbaugh.
- Object Oriented Analysis (OOA),
Coad/Yourdon.
- Hierarchical Object Oriented Design
(HOOD), ESA.
- Object Oriented Structured Design
(OOSD), Wasserman.
- Object Oriented Systems Analysis
(OOSA), Shaler y Mellor.
- Responsibility Driven Design (RDD),
Wirfs-Brock, entre otros.
Actualmente las metodologías más
importantes de análisis y diseño de sistemas han confluido en
lo que se es el UML, bajo el respaldo del Object Management Group.
El
Proceso Unificado
El Proceso Unificado "es un
proceso de desarrollo de software configurable que se adapta a
través de los proyectos variados en tamaños y complejidad. Se
basa en muchos años de experiencia en el uso de la tecnología
orientada a objetos en el desarrollo de software de misión
crítica en una variedad de industrias por la compañía
Rational", donde confluyen 'los tres amigos' como se llaman
a sí mismos o los tres grandes OO: Grady Booch, James Rumbaugh e
Ivar Jacobson [M&R
1998].
El Proceso Unificado guía a los equipos de
proyecto en cómo administrar el desarrollo iterativo de un modo
controlado mientras se balancean los requerimientos del negocio,
el tiempo al mercado y los riesgos del proyecto. El proceso
describe los diversos pasos involucrados en la captura de los
requerimientos y en el establecimiento de una guía
arquitectónica lo más pronto, para diseñar y probar el sistema
hecho de acuerdo a los requerimientos y a la arquitectura. El
proceso describe qué entregables producir, cómo desarrollarlos
y también provee patrones. El proceso unificado es soportado por
herramientas que automatizan entre otras cosas, el modelado
visual, la administración de cambios y las pruebas.
Proceso
Unificado y MSF; complementos tecnológicos
Según [M&R 1998], "más
que una metodología, Microsoft Solutions Framework (MSF) es una serie de modelos flexibles
interrelacionados que guían a una organización sobre como
ensamblar los recursos, el personal y las técnicas necesaria
para asegurar que su infraestructura tecnológica y sus
soluciones cumplan los objetivos de negocio. MSF mantiene una
relación clara entre los objetivos de negocio y las
implementaciones tecnológicas".
"MSF se puede utilizar por sí mismo o
con otras herramientas y técnicas como el Proceso Rational
[Proceso Unificado] para planear, construir y administrar el
desarrollo de soluciones de negocio a la medida" [M&R 1998].
"El proceso Unificado es un proceso de
desarrollo de software configurable que se adapta a proyectos que
varían en tamaño y complejidad. Se basa en muchos años de
experiencia en el uso de la tecnología de objetos en el
desarrollo de software de misión crítica en una variedad de
industrias. Uno de los componentes clave es el UML"
[M&R 1998].
MSF proporciona las técnicas ligadas a la
tecnología y el Proceso Unificado la guía detallada para el
desarrollo de software minimizando los riesgos.
El Proceso Unificado ha adoptado un enfoque
que se caracteriza por:
- Interacción con el usuario continua
desde un inicio
- Mitigación de riesgos antes de que
ocurran
- Liberaciones frecuentes
- Aseguramiento de la calidad
- Involucramiento del equipo en todas
las decisiones del proyecto
- Anticiparse al cambio de
requerimientos
El Proceso Unificado y MSF se enfocan en la
arquitectura como el centro del desarrollo para asegurar que el
desarrollo basado en componentes sea clave para un alto nivel de
reuso. MSF considera que hay cuatro perspectivas de
arquitectura que cumplen los requerimientos de una empresa [M&R 1998]:
- Arquitectura de Negocios
- Describe como opera un negocio. Desarrolla una imagen
clara de los procesos de flujo de trabajo de la
organización y de cómo son apoyados por una
infraestructura tecnológica basada en servicios.
- Arquitectura de Aplicación
– Adopta un modelo de aplicación de toda la empresa
para diseñar y desarrollar sistemas de negocios que
puedan compartir un conjunto de componentes back-end de
alto valor.
- Arquitectura de Información
– Define qué información es necesaria para apoyar
el proceso de negocios y como poner esa información
eficientemente en manos de quienes que la necesitan sin
crear islas de datos inaccesibles ni sistemas
redundantes.
- Arquitectura Tecnológica
– Define los estándares y guías para la
adquisición y despliegue de herramientas, bloques de
construcción de aplicaciones, servicios de
infraestructura, componentes de conectividad de red y
plataformas cliente servidor.
El Modelo de Equipo de MSF muestra como
estructurar equipos de alto desempeño para crear soluciones más
rápido, mejor y más baratas. El Modelo de Equipo de MSF se basa
en las formas de organizar equipos para crear los propios
productos de Microsoft. Hace énfasis en las comunicaciones
claras y en un equipo de iguales con papeles y responsabilidades
claras en todo el proyecto. La calidad del producto se asegura
por cada miembro del equipo. El Proceso Unificado proporciona
más detalle y guía para algunos de los roles en el proyecto.
Una vista arquitectónica es
"una descripción simplificada (una abstracción) de un
sistema desde una perspectiva particular o punto de vista, que
cubre particularidades y omite entidades que no son relevantes a
esta perspectiva" [Booch 1998].
Según el mismo autor, las características
primordiales del Proceso Unificado son:
- Iterativo e incremental
- Centrado en la arquitectura
- Guiado por casos de uso
- Confrontación de riesgos
El Proceso Unificado es un proceso porque
"define quién está haciendo qué, cuándo lo hacer y cómo
alcanzar cierto objetivo, en este caso el desarrollo de
software" [Jacobson
1998]. Según [Booch 1998], los conceptos clave del Proceso Unificado
son:
| Fase e
iteraciones |
¿Cuándo
se hace? |
| Flujos de
trabajo de procesos (actividades y pasos) |
¿Qué se
está haciendo? |
| Artefactos
(modelos, reportes, documentos) |
¿Qué se
produjo? |
| Trabajador:
un arquitecto |
¿Quién
lo hace?) |
El ciclo de
vida del software en el Proceso Unificado
Las fases del ciclo de vida del software
son: concepción, elaboración, construcción y transición. La
concepción es definir el alcance del proyecto y definir el caso
de uso. La elaboración es proyectar un plan, definir las
características y cimentar la arquitectura. La construcción es
crear el producto y la transición es transferir el producto a
sus usuarios [Booch
1998].
Figura 1. Estructura del
Proceso Unificado
Según [Microsoft 1997], el
diseño de software se realiza a tres niveles: conceptual,
lógico y físico.
Figura 2. Arquitectura
lógica de tres capas de una aplicación cliente/servidor
Para mayor información consulta las siguiente dirección
electrónica:
- Herramientas de
Ingeniería de Software Aquí encontrarás información sobre las
herramientas líderes que implementan la ingeniería de software, desde el
modelado de sistemas con UML hasta el proceso unificado que tiene que ver
con la administración de proyectos.
- SourceForge.net
Es una base de datos de proyectos de software de código abierto u open
source software.
Un ingeniero de software necesita de herramientas, entre
ellas las herramientas de Rational son las más avanzadas, pero son muy
costosas. También puede utilizar las herramientas de oficina como un editor de
textos, un modelador de datos, etc., muchas de ellas son de código abierto y
aún están de desarrollo. Utiliza las que más te sean de utilidad.
Diseño
Conceptual
El diseño conceptual se considera
como un análisis de actividades y consiste en la solución de
negocios para el usuario y se expresa con los casos de uso. El
diseño lógico es la solución del equipo de proyecto del
negocio y consiste de las siguientes tareas:
- Identificar los usuarios y sus roles
- Obtener datos de los usuarios
- Evaluar la información
- Documentar los escenarios de uso
- Validar con los usuarios
- Validar contra la arquitectura de la
empresa
Una forma de obtener estos requerimientos
es construir una matriz usuarios-actividades de negocios,
realizar entrevistas, encuestas y/o visitas a los usuarios, de
tal manera que se obtenga quién, qué, cuándo, dónde y por
qué de la solución.
Diseño Lógico
El diseño lógico traduce los
escenarios de uso creados en el diseño conceptual en un conjunto
de objetos de negocio y sus servicios. El diseño lógico se
convierte en parte en la especificación funcional que se usa en
el diseño físico. El diseño lógico es independiente de la
tecnología. El diseño lógico refina, organiza y detalla la
solución de negocios y define formalmente las reglas y
políticas específicas de negocios.
Un objeto de negocios es la
encapsulación de un servicio que abstrae las cualidades
esenciales de algo de interés.
Un servicio es una unidad con
capacidad de cómputo. Un servicio debe satisfacer lo siguiente:
- Ser seguro, lo que equivale a un uso
correcto y con autorización
- Ser válido, qué tareas o reglas se
pueden aplicar
- Manejar excepciones, informando al
cliente
- Contar con un catálogo de servicios
que constituye un repositorio de servicios.
Los objetos de negocio deben verificarse y
probarse de tal manera que asegure que los módulos operen como
unidades completas de trabajo. Las tareas de verificación
incluyen:
- Una verificación independiente:
- Pre y post condiciones
- Lógica y funcionalidad
individual
- Una verificación dependiente:
- Verificación de dependencias
- Que operan como una unidad
específica de trabajo
El diseño lógico comprende las siguientes
tareas:
- Identificar y definir los objetos de
negocio y sus servicios
- Definir las interfases
- Identificar las dependencias entre
objetos
- Validar contra los escenarios de uso
- Comparar con la arquitectura de la
empresa
- Revisar y refinar tanto como sea
necesario
Para definir los objetos de negocios y sus
servicios se puede usar la técnica de análisis nombre-verbo de
los escenarios de uso. También se puede emplear la técnica
sujeto-verbo-objeto directo. En estas técnicas los sujetos y el
objeto directo son los candidatos a objetos de negocio y los
verbos activos son los candidatos a servicios.
Una interfase tiene las siguientes
partes:
- Nombre
- Precondiciones, lo que debe estar
presente antes de ejecutarse
- Postcondiciones, estado final
- Capacidad o funcionalidad (SQL,
pseudocódigo, función matemática)
- Dependencias
La tarea de identificar las dependencias
entre objetos permite identificar eventos, sucesos o
condiciones que permitan la realización de tareas de negocios
coordinadamente o transaccionalmente. Para ello se debe
considerar lo siguiente:
- Identificar los eventos disparadores
(triggers)
- Determinar cualquier dependencia
(existencial o funcional)
- Determinar cualquier problema de
consistencia o secuencia
- Identificar cualquier regulación de
tiempo crítica
- Considerar algún problema
organizacional (transacciones)
- Identificar y auditar los
requerimientos de control
- Determinar lugares y dependencias a
través de la ubicación
- Determinar cuando el servicio que
controla la transacción es dependiente de los servicios
contenidos en otros objetos de negocio
La validación del modelo lógico debe
ser tal que éste sea:
- Completo – debe representar todos
los escenarios de uso,
- Correcto – el comportamiento
lógico debe corresponder con el comportamiento
conceptual, y
- Claro – los objetos de negocio y
servicios no deben ser ambiguos
En el diseño lógico conceptualmente se
divide en tres niveles de servicios con el fin de que la
aplicación resulte flexible ante los cambios de requerimientos
y/o de tecnología cambiando únicamente la capa o capas
necesarias. Los tres niveles son: servicios de usuario, servicios
de negocio y servicios de datos.
Los servicios de usuario (user
services) controlan la interacción. Un servicio de usuario
son personas, aplicaciones, otros servicios o la combinación de
éstos. Generalmente involucra una interfase gráfica de usuario
(GUI) o pude ser no visual (mensajes o funciones), maneja todos
los aspectos de la interacción con la aplicación. El objetivo
central es minimizar el esfuerzo de conocimiento requerido para
interpretar la información. Un servicio de usuario incluye un
contenido (qué se necesita comunicar al usuario) y una forma
(cómo se comunica el contenido) cuando es necesaria la
comunicación.
Los servicios de negocio (bussines
services) convierten datos recibidos de los servicios de
datos y de usuario en información (datos + regla de negocio) y
pueden usar otros servicios de negocio para completar su tarea.
Las tareas de los servicios de negocio son:
- Dar formato a los datos
- Obtener y mover datos desde y hasta
los servicios de datos
- Transformar los datos en información
- Validar los datos inmediatamente en el
contexto o en forma diferida una vez terminada la
transacción.
Los servicios de datos (data
services) son los servicios de bajo nivel que apoyan los
servicios de negocio y son de una amplia gama de categorías como
las siguientes:
- Declaración del esquema y su
evolución (estructuras de datos, tipos, acceso indexado,
SQL, APIs)
- Respaldo y recuperación
(recuperación de datos si un evento falla)
- Búsqueda y Lectura (búsquedas,
compilación, optimización y ejecución de solicitudes,
formación de un conjunto de resultados)
- Inserción, actualización y borrado
(procesar modificaciones consistentemente transaccional).
Una transacción es atómica (ocurre o no),
consistente (preserva integridad), aislada (otras
transacciones ocurren antes o después) y durable (una
vez completada, ésta sobrevive).
- Bloqueo (permite al acceso concurrente
a los datos)
- Validación de datos (verifica la
integridad del dominio, triggers y gateways para
verificar el estado de los datos antes de aceptarlos,
manejo de errores)
- Seguridad (acceso seguro a los
objetos, operaciones, permisos a usuario y grupos y
servicios)
- Administración de la conexión
(mecanismos básicos para establecer una sesión de los
servicios de datos). Establecer una conexión involucra:
una identificación, la colocación y provisión de
datos, tiempo de sesión, el tipo de interacción
(conversacional, transaccional, multiusuario,
monousuario).
- Distribución de datos (Distribuye
información, a múltiples unidades de recuperación,
bases de datos heterogéneas, según la topologías de la
red).
Diseño físico
El diseño físico traduce el
diseño lógico en una solución implementable y costo-efectiva o
económica.
El componente es la unidad de construcción
elemental del diseño físico. Las características de un
componente son:
- Se define según cómo interactúa con
otros
- Encapsula sus funciones y sus datos
- Es reusable a través de las
aplicaciones
- Puede verse como una caja negra
- Puede contener otros componentes
En el diseño físico se debe cuidar el
nivel de granularidad (un componente puede ser tan grande o tan
pequeño según su funcionalidad, es decir, del tamaño tal que
pueda proveer de una funcionalidad compleja pero de control
genérico) y la agregación y contención (un componente puede
reusar utilizando técnicas de agregación y contención, sin
duplicar código).
El diseño físico debe involucrar:
- El diseño para distribución –
debe minimizarse la cantidad de datos que pasan como
parámetros entre los componentes y éstos deben enviarse
de manera segura por la red.
- El diseño para multitarea – debe
diseñarse en términos de la administración concurrente
de dos o más tareas distintas por una computadora y el multithreading
o múltiples hilos de un mismo proceso)
- El diseño para uso concurrente –
el desempeño de un componente remoto depende de si está
corriendo mientras recibe una solicitud.
- El diseño con el manejo de errores y
prueba de eventos:
- Validando los parámetros- a
la entrada antes de continuar con cualquier
proceso.
- Protegiendo recursos críticos
–manejar excepciones para evitar la falla o
terminación sin cerrar archivos, liberar objetos
sincronizados o memoria.
- Protegiendo datos importantes
– contar con una excepción a la mitad de la
actuación en las bases de datos.
- Debugging – crear una
versión para limpiar errores.
- Protección integral de
transacciones de negocios – los errores
deben regresarse al componente que llama.
Figura 3. Arquitectura
física de tres capas de la aplicación cliente/servidor
El diseño físico comprende las siguientes
tareas:
- Definir los componentes
- Refinar el empaquetamiento y
distribución de componentes
- Especificar las interfases de los
componentes
- Distribuir los componentes en la red
- Distribuir los repositorios físicos
de datos
- Examinar la tolerancia a fallas y la
recuperación de errores
- Validar el diseño físico
De las tareas anteriores la más importante
es la distribución de los datos que pueden ser centralizados,
una partición, un extracto o una réplica.
Los datos centralizados equivalen a
una base de datos maestra ubicada en un lugar central. No hay
copias de los datos.
Una partición de datos es una
segmentación de la base de datos maestra. Es útil cuando los
datos se pueden fragmentar fácilmente y actualizarse en un sitio
local con cambios frecuentes. No hay sobreposición entre
particiones. En una partición horizontal cada hilera existe en
una sola base de datos. En una partición vertical cada columna
es contenida en una y solo una base de datos.
Un extracto de datos es una copia de
toda o una porción de la base de datos maestra. No se permite la
actualización. Se usa un timestamp o etiqueta de tiempo
para indicar qué tan viejos son los datos.
Una réplica de datos es un
fragmento de la bases de datos maestra que se puede actualizar.
Una réplica de datos es cuando el sitio de actualización cambia
a un sitio local. No se permiten actualizaciones en la base de
datos réplica y en la base de datos maestra a la vez, por lo que
debe de haber sincronización entre ambas.
El diseño físico está íntimamente
ligado a una alternativa tecnológica. Ante la acelerada
evolución tecnológica es importante considerar los estándares
del momento y las tendencias ya que una mala decisión implicará
un costo enorme (en dinero y en tiempo) al actualizarse a otra
plataforma distinta.
La tendencia actual en la arquitectura
cliente/servidor es crear el back-end como un servidor robusto
multitareas y multithreading y el front-end como un
cliente muy delgado que no acapare al servidor comunicándose
entre sí en una plataforma internet con protocolos estándar en
redes heterogéneas.
Comentario final ... para reflexionar
Todo lo que se expresó en este artículo, muestra tal
como la teoría aconseja que se deben hacer las cosas. En la práctica, en la
ingeniería de software comúnmente se menosprecia el valor de una metodología
para crear el software. Esto, a mi juicio, está demeritando la incipiente
profesión de Ingeniero de Software en particular, la del especialista en
Tecnología de Información, en general y a las empresas de consultoría en
software, ya que generalmente se cede al "chantaje" profesional del
jefe o del cliente quien ordena la construcción del software, con argumentos
como "no hay tiempo para eso, pónte a programar".
Para reflexionar, pregunto, lo siguiente:
¿Qué pasaría, si el ingeniero
civil o el arquitecto construye una casa o un edificio sin hacer sus planos,
proyectos o maquetas? ¿Crees que la obra pueda concluirse
cubriendo las necesidades, con la calidad necesaria y a tiempo? Simplemente observa la calidad de
las viviendas "en obra negra perpetua" en la mayoría de las calles de México.
Y todavía más
allá, ¿Permitirías que tu propio cirujano te interviniera sin hacer los
estudios respectivos para obtener las evidencias del problema de salud que te
aqueja? O ¿permitirías a tu abogado que te defendiera sin conocer las pruebas y sin un
plan para tu defensa? Entonces, ¿por qué los ingenieros en software a veces
cedemos al "chantaje de la falta de tiempo" y construimos software sin el
análisis y diseño expresado en un proyecto, más allá de las ideas existentes
"en nuestra cabeza"? ¿Por qué lo intentamos hacer sobre la marcha,
pero nunca lo concluimos pues ya no hay tiempo? ¿Dónde quedó la ética
profesional?...
Sugiero que consultes, como referencia, el Código de Etica del
Ingeniero en Software y de la Práctica Profesional en el site de la Association for
Computing Machinery aquí: http://www.acm.org/serving/ethics.html.
Literatura
citada
| [Booch 1998] |
Booch G.
1998. Software Architecture and the UML. Presentación
disponible en: http://www.rational.com/uml como arch.zip. |
| [Booch 1986] |
Booch, G. 1988. Object Oriented
Development. Trans. of Soft. Eng. Vol. SE-12. Num. 2.
Feb. 1986. pp. 211-221. |
| [Conallen 1999A] |
Conallen,
J. "Modeling Web Applications with UML"
Conallen, Inc. 9-Mar-1999 Disponible en: http://www.conallen.com/whitepapers/webapps/ModelingWebApplications.htm |
| [Conallen 1999B] |
Conallen,
J. "UML Extension for Web Applications 0.91"
Drafted Conallen, Inc. 22-Mar-1999 Disponible en: http://www.conallen.com/technologyCorner/webextension/WebExtension091.htm |
| [Cota 1994] |
Cota A. 1994 "Ingeniería
de Software". Soluciones Avanzadas. Julio de 1994.
pp. 5-13. |
| [Greiff 1994] |
Greiff W. R. Paradigma vs
Metodología; El Caso de la POO (Parte II). Soluciones
Avanzadas. Ene-Feb 1994. pp. 31-39. |
| [Jacobson 1998] |
Jacobson,
I. 1998. "Applying UML in The Unified Process"
Presentación. Rational Software. Presentación
disponible en http://www.rational.com/uml como UMLconf.zip |
| [Jacobson 1992] |
Jacobson,
I. et. al. 1992. Object-Oriented Software
Engineering; A Use Case Driven Aproach. ACM Press.
Adison-Wesley Publishing. Co. U.S.A. 524 p. Ilus. pp.
465-493. |
| [Lewis 1994] |
Lewis G. 1994. "What is
Software Engineering?" DataPro (4015). Feb 1994. pp.
1-10. |
| [Microsoft 1997] |
Microsoft
1997. Microsoft Solutions Framework 1.0. Microsoft
Corporation. USA. |
| [M&R 1998] |
Microsoft
y Rational 1998. A White Paper on the Benefits of
Integrating Microsoft Solutions Framework and The
Rational Process. Rational Software Corporation y Microsoft Corporation.
Documento msfratprocs.doc Disponible en
http://www.rational.com/uml/papers. |
| [OMG 1999] |
Object
Management Group. 1999. OMG Unified Modeling Language
Specification (Draft). Versión 1.3. alfa R5, marzo de
1999. Disponible en: http://www.rational.com/uml |
| [Zavala 2000] |
Zavala R.
2000. Diseño de un Sistema de Información
Geográfica sobre internet. Tesis de Maestría en
Ciencias de la Computación. Universidad Autónoma
Metropolitana-Azcapotzalco. México, D.F. En prensa. |
Parte 2: Análisis organizacional de empresas de software. Una primera aproximación a una visión alterna de la Ingeniería de Software
Zavala-Ruiz, J. (2008) "Organizational Analysis of Small Software Organizations: Framework and Case Study" en H. Oktaba y M. Piattini (Eds.)
Software Process Improvement for Small and Medium Enterprises: Techniques and Case Studies
.
Abstract
The intention of this chapter is twofold. On the one hand, I illustrate the complexity of the small software
organization, because it is not a reduced version of a large company. Rather, it has very important advantages
and challenges. Then, I use organization studies as a multi-disciplinary and multi-paradigmatic link between disciplines, able to reconcile those distinct visions. On the other hand, I open the discussion on the state of crisis affecting software engineering as a discipline. For that, I try to sensitize the reader to the facts surrounding this crisis, but also to the most promising alternative, which is the redefinition of
software engineering as a discipline. One of the possible options for that paradigmatic shift requires
a multi-disciplinary orientation because their positivist roots and the adoption of a constructivist ontology and epistemology facilitating the inclusion of visions non-qualified for a systematic, disciplined
and quantitative approach. My position is that only by opening up this discussion is it possible to begin
transforming and consolidating software engineering as a strengthened and more terrain-attached discipline because of its powerful theoretical and practical explanatory capacity.
Disponible como "Free Sample Chapter" en
la Editorial IGI-Global
o aquí
Parte 3. ¿Qué es la ingeniería de software?: Una visión alterna
La Ingeniería de Software: Su filosofía y su desafío
En mis investigaciones, de campo y bibliográficas, llevadas a cabo desde 2005 a la fecha, me han llevado a concluir que la Ingeniería de Software no es lo que uno supone que es, o en otras palabras, no es lo que institucionalmente se nos ha hecho creer. A pesar del nombre de ingeniería, ésta dista mucho de ser tal.
La ingeniería de software, no es una disciplina de ingeniería sino más bien una disciplina técnica y de administración (o management) impulsada desde sus orígenes por el Departamento de Defensa de los Estados Unidos (DoD), como lo demuestra la investigación histórica.
La esencia del objeto de estudio de la Ingeniería de Software como disciplina teórico-práctica, es decir, su ontología es de naturaleza más organizacional que ingenieril, aunque tiene un componente tecnológico muy importante.
Descarga la presentación de la ponencia "La Ingeniería de Software: Su filosofía y su desafío" presentada por mí y por la M.C.C. Rafaela Blanca Silva López de la Universidad Autónoma Metropolitana - Unidad Azcapotzalco, en el XXIV Congreso de la ANIEI en Colima, Colima, México, el 26 de octubre de 2011.
La Ingeniería de Software: Una Discusión Epistemológica
Tesis de maestría en ciencias de la computación, Universidad Autónoma Metropolitana, Unidad Azcapotzalco, México. 2011.
Descarga las primeras páginas aquí:aquí
Resumen
La Ingeniería de Software se encuentra en una crisis disciplinaria por la
falta de fundamentos bien establecidos. El impulso de la iniciativa Software
Engineering Method And Theory (SEMAT) ignorando la Guide to Software
Engineering Body of Knowledge (SWEBoK) confirma esa situación que se
prolonga ya por más de 40 años. Partiendo de una propuesta epistemológica
interdisciplinaria, esta investigación propuso la creación de la Ciencia del
Software.
Despues de una profunda revisón histórica y del contexto, se propuso
un marco conceptual de cuatro niveles ontológicos complementarios. El primer
nivel aborda el “software” como lenguaje de programación, algoritmo, cálculo y
como sistema de software acotado por el hardware; es la dimesión técnica. El
segundo nivel ontológico abordó el “proceso de producción” o “desarrollo de
software” como un proceso de organización del trabajo, un tema central en la
teoría de la organización. El tercer nivel se centró en el “proyecto de software”
como proceso social y organización temporal, dominio de la teoría de la
administración de proyectos. Y el cuarto nivel abordó la “fábrica de software”
como una empresa de naturaleza organizacionl y empresarial.
Se propusieron dos modelos en complemento, el primero originado en la psicología social para
delinear una estrategia de cambio paradigmático y el segundo, un modelo
filosófico originado en la administración, para integrar todos los elementos en
una propuesta integral. Así, las “mejores prácticas” estarán basadas en
fundamentos ontológicos y epistemológicos sólidos y en un comportamiento
ético, que lleve al establecimeinto de la filosofía de la ciencia del software.
Palabras clave: ciencias de la computación, ingeniería de software,
ciencia del software, filosofía de la ciencia, crisis desciplinaria, filosofía del
software, cambio paradigmático.
Descarga las primeras páginas del capítulo 3 aquí.
Software Engineering: An Interdisciplinary Epistemological Discussion
