Está en la página 1de 8

INGENIERIA DE SOFTWARE

Modelos especializados de proceso


MODELO BASADO EN COMPONENTES Un componente es una pieza de cdigo preelaborado que encapsula alguna funcionalidad expuesta a travs de interfaces estndar. Es algo muy similar a lo que podemos observar en el equipo de msica que tenemos en nuestra sala. Cada componente de aquel aparato ha sido diseado para acoplarse perfectamente con sus pares, las conexiones son estndar y el protocolo de comunicacin est ya preestablecido. Al unirse las partes, obtenemos msica para nuestros odos. El paradigma de ensamblar componentes y escribir cdigo para hacer que estos componentes funcionen se conoce como Desarrollo de Software Basado en Componentes.

Desarrollo basado en componentes El modelo de desarrollo basado en componentes incorpora muchas de las caractersticas del modelo espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creacin del software. Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software (clases). El modelo de desarrollo basado en componentes conduce a la reutilizacin del software, y la reutilizacin proporciona beneficios a los ingenieros de software. Segn estudios de reutilizacin, QSM Associates, Inc. Informa que el ensamblaje de componentes lleva a una reduccin del 70 % del ciclo de desarrollo un 84% del coste del proyecto y un ndice de productividad del 26.2. No hay duda que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros del software. El proceso unificado de desarrollo de software representa un nmero de modelos de desarrollo basado en componentes que han sido propuestos en la industria. El lenguaje de modelado unificado define los componentes. Utilizando una combinacin del desarrollo incremental e interactivo, el proceso unificado define la funcin del sistema aplicando un enfoque basado en escenarios. El desarrollo de software basado en componentes se ha convertido actualmente en uno de los mecanismos ms efectivos para la construccin de grandes sistemas y aplicaciones de software. Una vez que la mayor parte de los aspectos funcionales de esta disciplina comienzan a estar bien definidos, la atencin de la comunidad cientfica comienza a centrarse en los aspectos extrafuncionales y de calidad, como un paso hacia una

Pgina 1

INGENIERIA DE SOFTWARE

verdadera ingeniera. En este artculo se discuten precisamente los aspectos de calidad relativos a los componentes software y a las aplicaciones que con ellos se construyen, con especial nfasis en los estndares internacionales que los definen y regulan, y en los problemas que se plantean en este tipo de entornos.

Beneficios del Desarrollo de Software Basado en Componentes El uso de este paradigma posee algunas ventajas: 1. Reutilizacin del software. Nos lleva a alcanzar un mayor nivel de reutilizacin de software. 2. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados. 3. Simplifica el mantenimiento del sistema. Cuando existe un dbil acoplamiento entre componentes, el desabollador es libre de actualizar y/o agregar componentes segn sea necesario, sin afectar otras partes del sistema. 4. Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organizacin, la calidad de una aplicacin basada en componentes mejorar con el paso del tiempo

La Notacin de Componentes Un componente puede ser algo como un control Actives; tanto un componente de la Interfaz de usuario como un servidor de reglas de negocio.

El Diagrama de Componentes El diagrama de componentes muestra la relacin entre componentes de software, sus dependencias, su comunicacin su ubicacin y otras condiciones.

Interfaces Los componentes tambin pueden exponer las interfaces. Estas son los puntos visibles de entrada o los servicios que un componente est ofreciendo y dejando disponibles a otros componentes de software y clases. Tpicamente, un componente
Pgina 2

INGENIERIA DE SOFTWARE

est compuesto por numerosas clases y paquetes de clases internos. Tambin se puede crear a partir de una coleccin de componentes ms pequeos.

Los componentes y los Nodos Un diagrama de despliegue muestra el despliegue fsico del sistema en un ambiente de produccin (o de prueba). Muestra dnde se ubican los componentes, en qu servidores, mquinas o hardware. Puede representar los enlaces de redes.

Restricciones Los componentes pueden restricciones asignadas que indican el entorno en el que operan. Las pre-condiciones especifican lo que debe ser verdadero antes de que un componente pueda realizar alguna funcin; las post-condiciones indican lo que debe ser verdadero despus de que un componente haya realizado algn trabajo y los invariantes especifican lo que debe permanecer verdadero durante la vida del componente.

Modelo de mtodos formales


Qu es un Mtodo Formal? Definicin: "Mtodo formal es cualquier tcnica que trate la construccin y/o el anlisis de modelos matemticos que contribuyen a la automatizacin del desarrollo de sistemas informticos" El papel de los mtodos formales en la Ingeniera del Software Los mtodos formales se basan en el empleo de tcnicas, lenguajes y herramientas definidos matemticamente para cumplir objetivos tales como facilitar el anlisis y construccin de sistemas confiables independientemente de su complejidad, delatando posibles inconsistencias o ambigedades que de otra forma podran pasar inadvertidas.
Pgina 3

INGENIERIA DE SOFTWARE

En los ltimos aos, la idea de que la formalizacin matemtica del SW es el enfoque ms apropiado para conseguir mejorar su calidad va adquiriendo cada vez ms fuerza. Los partidarios de los mtodos formales defienden que su empleo, a lo largo de todo el ciclo de vida, facilita el desarrollo de especificaciones claras, concisas y no ambiguas, permite el anlisis funcional de la especificacin y posibilita el desarrollo de implementaciones correctas respecto a su especificacin. Sin embargo los detractores aseguran que el empleo de mtodos formales supone un volumen de trabajo considerable, aumento en los costes y tiempo de desarrollo y que debe quedar supeditado a herramientas que lo automaticen. Ventajas de los mtodos formales

Se comprende mejor el sistema. La comunicacin con el cliente mejora ya que se dispone de una descripcin clara y no ambigua de los requisitos del usuario. El sistema se describe de manera ms precisa. El sistema se asegura matemticamente que es correcto segn las especificaciones. Mayor calidad software respecto al cumplimiento de las especificaciones. Mayor productividad

Problemtica actual de los mtodos formales La falta de madurez en la prctica de los mtodos formales es la causa de la imposibilidad de utilizarlos a nivel industrial tal y como se utilizan otros mtodos de la Ingeniera del Software. Algunas de estas causas son las siguientes: El desarrollo de herramientas que apoyen la aplicacin de mtodos formales es complicado y los programas resultantes son incmodos para los usuarios. Los investigadores por lo general no conocen la realidad industrial. Es escasa la colaboracin entre la industria y el mundo acadmico, que en ocasiones se muestra demasiado dogmtico. Se considera que la aplicacin de mtodos formales encarece los productos y ralentiza su desarrollo.

Conclusin: Los mtodos formales se implantarn en la industria probablemente a travs de nuevos profesionales con conocimientos slidos de las tcnicas matemticas. Aun as, como ya veremos ms adelante, los mtodos formales estn presentes en bastantes campos y no solo los referidos a la ingeniera y la ciencia informtica. Clasificacin de los mtodos formales Se pueden encontrar multitud de mtodos y tcnicas formales con lo que los criterios de clasificacin son bastante variados. La clasificacin ms comn se realiza en base al modelo matemtico subyacente en cada mtodo, de esta manera podran clasificarse en:

Especificaciones basadas en lgica de primer orden y teora de conjuntos: permiten especificar el sistema mediante un concepto formal de estados y operaciones sobre estados. Los datos y relaciones/funciones se describen en detalle y sus propiedades se
Pgina 4

INGENIERIA DE SOFTWARE

expresan en lgica de primer orden. La semntica de los lenguajes est basada en la teora de conjuntos. Los mtodos de este tipo ms conocidos son: Z, VDM y B. Especificaciones algebraicas: proponen una descripcin de estructuras de datos estableciendo tipos y operaciones sobre esos tipos. Para cada tipo se define un conjunto de valores y operaciones sobre dichos valores. Las operaciones de un tipo se definen a travs de un conjunto de axiomas o ecuaciones que especifican las restricciones que deben satisfacer las operaciones. Mtodos ms conocidos: Larch, OBJ, TADs. Especificacin de comportamiento: Mtodos basados en lgebra de procesos: modelan la interaccin entre procesos concurrentes. Esto ha potenciado su difusin en la especificacin de sistemas de comunicacin (protocolos y servicios de telecomunicaciones) y de sistemas distribuidos y concurrentes. Los ms conocidos son: CCS,CSP y LOTOS. Mtodos basados en Redes de Petri: una red de petri es un formalismo basado en autmatas, es decir, un modelo formal basado en flujos de informacin. Permiten expresar eventos concurrentes. Los formalismos basados en redes de petri establecen la nocin de estado de un sistema mediante lugares que pueden contener marcas. Un conjunto de transiciones (con pre y post condiciones) describe la evolucin del sistema entendida como la produccin y consumo de marcas en varios puntos de la red. Mtodos basados en lgica temporal: se usan para especificar sistemas concurrentes y reactivos. Los sistemas reactivos son aquellos que mantienen una continua interaccin con su entorno respondiendo a los estmulos externos y produciendo salidas en respuestas a los mismos, por lo tanto el orden de los eventos en el sistema no es predecible y su ejecucin no tiene por qu terminar.

Desarrollo de software orientado a aspectos


Introduccin Son muchos los intereses que un equipo de desarrollo de software debe fijar su atencin: entender el problema, entender su entorno, gestin del proyecto, equipo de desarrollo, aspectos tcnicos, entre otros. Los intereses referidos a aspectos tcnicos como seguridad, persistencia, presentacin, manejo de errores, etc. Han dado origen al paradigma orientado a aspectos. El enfoque orientado a aspectos define un mecanismo que ayuda a resolver problemas de codificacin en los requisitos, los cuales son un cdigo disperso (scattered) y diseminado (tangled), que no se resuelven fcilmente usando el enfoque orientado a objetos. Este mecanismo se enfoca principalmente en la separacin de intereses (separation of concerns) de un sistema para obtener una mejor modularizacin.

El proceso unificado

Pgina 5

INGENIERIA DE SOFTWARE

Introduccin El Proceso Unificado es un proceso de desarrollo de software configurable que se adapta a travs de los proyectos variados en tamaos y complejidad. Se basa en muchos aos de experiencia en el uso de la tecnologa orientada a objetos en el desarrollo de software de misin crtica en una variedad de industrias por la compaa 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 gua a los equipos de proyecto en cmo 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 gua arquitectnica lo ms pronto, para disear y probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura. El proceso describe qu entregables producir, cmo desarrollarlos y tambin provee patrones. El proceso unificado es soportado por herramientas que automatizan entre otras cosas, el modelado visual, la administracin de cambios y las pruebas. Proceso Unificado y MSF; complementos tecnolgicos Segn [M&R 1998], ms que una metodologa, Microsoft Solutions Framework (MSF) es una serie de modelos flexibles interrelacionados que guan a una organizacin sobre como ensamblar los recursos, el personal y las tcnicas necesaria para asegurar que su infraestructura tecnolgica y sus soluciones cumplan los objetivos de negocio. MSF mantiene una relacin clara entre los objetivos de negocio y las implementaciones tecnolgicas. MSF se puede utilizar por s mismo o con otras herramientas y tcnicas 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 varan en tamao y complejidad. Se basa en muchos aos de experiencia en el uso de la tecnologa de objetos en el desarrollo de software de misin crtica en una variedad de industrias. Uno de los componentes clave es elUML [M&R 1998]. MSF proporciona las tcnicas ligadas a la tecnologa y el Proceso Unificado la gua detallada para el desarrollo de software minimizando los riesgos. El Proceso Unificado ha adoptado un enfoque que se caracteriza por:
Interaccin con el usuario contina desde un inicio

Mitigacin 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

Pgina 6

INGENIERIA DE SOFTWARE

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]:

Las fases del proceso unificado


Establece oportunidad y alcance Identifica las entidades externas o actores con las que se trata Identifica los casos de uso

RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas: 'Proceso': Las etapas de esta seccin son: (Revise nuevamente la grfica)

Modelado de negocio Requisitos Anlisis y Diseo Implementacin Pruebas Despliegue

Soporte: En esta parte nos encontramos con las siguientes etapas:


Gestin del cambio y configuraciones Gestin del proyecto Entorno

La estructura dinmica de RUP es la que permite que ste sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente:

Inicio(Tambin llamado Incepcin o Concepcin) Elaboracin Desarrollo(Tambin llamado Implementacin, Construccin) Cierre (Tambin llamado Transicin)

Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores. Fase de elaboracin: En la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar.

Pgina 7

INGENIERIA DE SOFTWARE

Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. Fase de Cierre: El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.

Productos de trabajo del proceso unificado


El producto de su trabajo (Artefactos) en esquemas o diagramas estandarizados.

Pgina 8