Ingenieria de 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,
Capas Ingeniería De Software
La ingeniería de software es una tecnología multicapa, cualquier enfoque de ingeniería debe apoyarse sobre un compromiso de organización de calidad.
El fundamento de la ingeniería de software es la capa del proceso. El proceso de la ingeniería de software es la unión que mantiene juntas las capas de tecnología y que permiten un desarrollo racional y oportuno de la ingeniería de software.
El proceso define un marco de trabajo para un conjunto de áreas clave de proceso que se deben establecer para la entrega de la tecnología de la ingeniería de software.
Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento.
Las herramientas de la ingeniería de software proporcionan un enfoque automático o semiautomático para el proceso y para los métodos.
Enfoque en capas
- Herramientas.- proporcionan un soporte automático o semi automático a los procesos y a los métodos.
- Métodos.- indican cómo construir técnicamente el software
- Procesos.-son el fundamento de la ingeniería de software.
- Un enfoque de Calidad.- son la base o cimientos de la ingeniería de software.
Coordinador de Investigación: ING. JOSE ANTONIO FLORES LARA
Tecnologico ITSZO 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.
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.
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).
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.
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.
BIBIBLIOGRAFIA:
| [Booch 1998] | Booch G. 1998. Software Architecture and the UML. Presentación disponible en: http://www.rational.com/uml como arch.zip. |
| Booch, G. 1988. Object Oriented Development. Trans. of Soft. Eng. Vol. SE-12. Num. 2. Feb. 1986. pp. 211-221. | |
| Conallen, J. "Modeling Web Applications with UML" Conallen, Inc. 9-Mar-1999 Disponible en: http://www.conallen.com/whitepapers/webapps/ModelingWebApplications.htm | |
| 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 A. 1994 "Ingeniería de Software". Soluciones Avanzadas. Julio de 1994. pp. 5-13. | |
| Greiff W. R. Paradigma vs Metodología; El Caso de | |
| 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, 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 G. 1994. "What is Software Engineering?" DataPro (4015). Feb 1994. pp. 1-10. | |
| Microsoft 1997. Microsoft Solutions Framework 1.0. Microsoft Corporation. USA. | |
| Microsoft y Rational | |
| 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 R. 2000. Diseño de un Sistema de Información Geográfica sobre internet. Tesis de Maestría en Ciencias de |
Links:
http://www.mitecnologico.com/Main/CapasIngenieriaDeSoftware
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#fig2
