MODELO/DISEÑO ESTRUCTURADO

"Diseño estructurado es el proceso de decidir que componentes, y la interconexión

entre los mismos, para solucionar un problema bien especificado".

Una vez que se han establecido los requisitos del software (en el análisis), el
diseño del software es la primera de tres actividades técnicas: diseño, codificación,
y prueba. Cada actividad transforma la información de forma que finalmente se
obtiene un software para computadora válido.

"El diseño estructurado, tiende a transformar el desarrollo de software de una

práctica artesanal a una disciplina de ingeniería".

 Eficiencia
 Mantenibilidad
 Modificabilidad
 Flexibilidad
 Generalidad
 Utilidad

PRINCIPIOS UTILIZADOS POR EL DISEÑO ESTRUCTURADO

Abstracción:
La noción psicológica de abstracción permite concentrarse en un problema al
mismo nivel de generalización, independientemente de los detalles irrelevantes de
bajo nivel. El uso de la abstracción también permite trabajar con conceptos y
términos que son familiares al entorno del problema, sin tener que transformarlos
a una estructura no familiar.

Refinamiento sucesivo:
La arquitectura de un programa se desarrolla en niveles sucesivos de refinamiento
de los detalles procedimentales. Se desarrolla una jerarquía descomponiendo una
declaración macroscópica de una función de una forma sucesiva, hasta que se
llega a las sentencias del lenguaje de programación.

Modularidad:
La arquitectura implica modularidad, el software se divide en componentes con
nombres y ubicaciones determinados, que se denominan módulos, y que se
integran para satisfacer los requisitos del problema.
Arquitectura del software:
La arquitectura del software se refiere a dos características importantes del
software de computadoras:
 1.la estructura jerárquica de los componentes procedimentales (módulos)
 2.la estructura de datos

Jerarquía de control:
La jerarquía de control, también denominada estructura de programa, representa
la organización
(Frecuentemente jerárquica) de los componentes del programa (módulos) e
implica una jerarquía de control. No representa aspectos procedimentales del
software, tales como secuencias de procesos, o la repetición de operaciones.

Estructura de datos:
La estructura de datos es una representación de la relación lógica existente entre
los elementos individuales de datos. Debido a que la estructura de la información
afectará invariablemente al diseño procedimental final, la estructura de datos es
tan importante como la estructura del programa en la representación de la
arquitectura del software.

COMPONENTES
Símbolos gráficos; iconos y convenciones para identificar y describir los
componentes de un sistema junto con las relaciones entre estos componentes.

• Diccionario de datos; descripciones de todos los datos utilizados en el sistema.

• Descripciones de procesos y procedimientos; declaraciones formales que

emplean técnicas y lenguajes que permiten a los analistas describir actividades
importantes que forman parte del sistema.

• Reglas; estándares para describir y documentar el sistema en forma correcta y

completa.

HERRAMIENTAS
Diagrama de Flujo de Datos: Es la base para otros componentes y
describe como navegan los datos entre procesos y elementos relacionados.

Diccionario de Datos: Contiene las características de los campos y/o

descripción detallada de los diferentes objetos que componen el sistema

Diagrama de Estructuras de Datos: describe la relación entre las

entidades y los objetos (conjunta de información que contienen las
entidades).
 TIPOS DE DISEÑOS
• 1. Diseño de datos.
Transforma el modelo de dominio de la información creado estructuras de datos
para implementar el software.

• 2. Diseño de la Interfaz.
se comunica el software consigo mismo, con los sistemas que operan con él y con
los operadores que los emplean.

• 3. Diseño Procedimental.
Transforma elementos estructurales del programa en una descripción
procedimientos del software.

• 4. Diseño Arquitectónico.
importancia del diseño del software reside en la calidad. es la única manera de
traducir los requisitos del cliente un sistema o producto de software.

CARACTERÍSTICAS
El diseño debe implementar todos los requisitos contenidos en el modelo de
análisis y debe acomodar todos los requerimientos implícitos que desea el
cliente
El diseño debe ser una guía que puedan leer y entender los que
construyan el código y los que prueban y mantienen el software.
El diseño debería proporcionar una completa idea de lo que es el software,
enfocando los dominios de datos, funcional y de comportamiento desde la
perspectiva de la implementación.
 Es el proceso de decidir que componentes, y
la interconexión entre los mismos, para
solucionar un problema bien especificado.

*Abstracción
PRINCIPIOS *Refinamiento sucesivo
UTILIZADOS POR *Modularidad
EL DISEÑO *Jerarquía de control
ESTRUCTURADO * Estructura de datos

*Símbolos gráficos

*Diccionario de datos
COMPONENTES *Descripciones de procesos y
procedimientos

*Reglas

MODELO/DISEÑO *Diagrama de Estructuras de

ESTRUCTURADO Datos
HERRAMIENTAS *Diccionario de Datos

*Diagrama de Flujo de Datos:

1. Diseño de datos.

TIPOS DE DISEÑOS 2. Diseño de la Interfaz.

3. Diseño Procedimental.
4. Diseño Arquitectónico.

CARACTERISTICAS:
Debe implementar todos los requisitos
contenidos en el modelo de análisis y debe
acomodar todos los requerimientos implícitos
que desea el cliente
Debe ser una guía que puedan leer y entender
los que construyan el código y los que prueban y
mantienen el software.
UNIVERSIDAD MEXIQUENSE DEL BICENTENARIO.
UNIDAD DE ESTUDIOS SUPERIORES TULTEPEC.
LIC. INFORMÁTICA ADMINISTRATIVA Y FINANCIERA.

MATERIA: SISTEMAS DE INFORMACIÓN II

PROFESOR: REYES SANCHEZ DULCE MARIA.

INTEGRANTES:

ARELLANO OLMEDO JOSE ELEUTERIO

FLORES RODRIGUEZ NANCY

GALLEGOS HERNANDEZ JANETH GUADALUPE

GONZALEZ MARTINEZ DIEGO ESTEBAN

MEJIA GARCIA ITZEL GABRIELA

SANCHEZ HERNANDEZ GLORIA DEL CARMEN

VAZQUEZ GALOMO GERMAN

VAZQUEZ ORTEGA ADRIAN

TEMA: MODELO DE ORIENTADO A OBJETOS (OO)

FECHA:8/MAYO/2016
 MODELO DE ORIENTADO A OBJETOS (OO)
Conceptos y propósito del modelo de estructura de objetos

El OSM es el modelo fundamental que provee un medio uniforme para modelar el

sistema desde la captura de requerimientos en la etapa inicial del análisis hasta la
implementación, atravesando todo el ciclo de desarrollo del sistema.

El modelo orientado a objetos utiliza el paradigma de la orientación a objetos para

el desarrollo de software. Este enfoque realiza la construcción de modelos de un
sistema por medio de la identificación y la especificación de un conjunto de objetos
relacionados, que colaboran entre sí de acuerdo a los requerimientos establecidos
para el sistema de objetos.

La definición del modelado orientado a objetos puede claramente dividir el enfoque

en tres dimensiones:

• La dimensión estructural.
• La dimensión dinámica.
• La dimisión funcional.

Este tipo de modelado implica la realización de las siguientes actividades:

1. Identificar las clases, modelos y objetos. (objetos y atributos).

2. Asociar estáticamente los objetos. (relaciones dependientes del dominio del
problema).
3. Especificación del comportamiento de los objetos. (Definir como se
comportaran los objetos).
4. Definir la jerarquía de herencia de las clases. (Definir la jerarquía de clases,
para que el sistema quede lo más abstracto posible).

Complementos:

5. Las clases de objetos en la aplicación

6. Como las clases de objetos se asocian unas con otras
7. Como se comunican los objetos.
8. Los detalles de cada clase de objetos, incluyendo atributos y operaciones.

Durante el proceso de análisis y diseño, el OSM es definido en sucesivos niveles

incrementales de detalle, hasta que el nivel necesario para la implementación es
alcanzado.
Todos los demás modelos capturan detalles que alimentan es modelo.

El desarrollo de OSM es un proceso aditivo, diferenciándose esto del enfoque

transformacional característico de otros métodos como el estructurado, donde los
DFD del análisis son transformados en diagramas de estructura durante el diseño,
con los consiguientes problemas que esto acarrea.

Durante el ciclo de desarrollo se aportan los siguientes elementos al modelo:

Análisis del Negocio: se reconocen objetos claves del negocio y generan las
abstracciones en las clases apropiadas (objetos entidad).

Análisis de Requerimientos: se identifican asociaciones estructurales entre

objetos y nuevas clases (entidad).

Diseño lógico: Se incorporan todas las clases necesarias para la aplicación

incluyendo los objetos de interfaz y de control.

Diseño Físico: se incorporan todos los detalles remanentes para la

implementación física de cada clase de objetos.

Características de los modelos Orientados a Objetos.

• EL modelado Orientado a Objetos está basado en el paradigma orientado a
objetos.
• Trata el almacenamiento de objetos (persistencia de los objetos).
• Define un lenguaje para le definición y manipulación de objetos.
• Incluye mecanismos para optimizar el acceso (Indexación y Clustering), el
control de la concurrencia, seguridad y gestión de usuarios, facilidad de
consulta y recuperación ante fallos.
• Debido a que es un esquema orientado a objetos incluye: Encapsulamiento,
herencia, polimorfismo, etc.
Componentes del modelo de estructura de objetos.

El componente básico del OSM es la clase de objetos.

Se distinguen tres tipos de clases:

· Objetos Entidad
· Objetos de Interfaz
· Objetos de Control.

Para cada clase identificada se describen:

· Operaciones
· Atributos
· Restricciones

Adicionalmente el OSM describe las asociaciones entre objetos o clases de

objetos. Se distinguen los siguientes tipos de asociaciones:
· Relaciones Estáticas
· Herencia
· Agregación
· Comunicación por mensajes

Objetos entidad

Representan algo real o abstracto sobre el cual el sistema necesita almacenar

datos. Representan la memoria esencial del negocio. Los objetos del negocio
(business objects) son normalmente objetos entidad. Ejemplos de objetos entidad
pueden ser empleado, alumno, etc.
:

Objetos Interface

Representan los objetos técnicos requeridos para vincular la aplicación con el

entorno. Representan el vínculo a través del cual el sistema recibe o suministra
datos e información al entorno. Típicamente incluyen interfaces con el usuario.

Objetos de control

Contienen comportamiento que no pertenece naturalmente ni a objetos entidad ni

de interfaz. Son normalmente objetos transitorios, como ser un controlador de
reportes.
Clases abstractas y concretas

Una clase de la cual pueden generarse instancias particulares (objetos), se

denomina clase concreta.

Una clase abstracta es aquella que no instancias (objetos) propias. Las clases
abstractas son un poderoso mecanismo conceptual para definir estructuras
comunes de atributos, operaciones, y restricciones, reutilizadas a través de la
herencia por múltiples clases concretas.

En el diagrama de estructura de objetos una clase abstracta se representa con un

rectángulo punteado.

Modelo Dinámico.
El modelo dinámico está basado y constituido en aquellos aspectos de un sistema
relacionados con el tiempo (objetos y cambio de los mismos) a lo largo del tiempo.
El modelo dinámico describe el control del sistema, esto quiere decir, las
secuencias que ocurren como consecuencia del uso de los usuarios finales, sin
tener en cuenta lo que hacen las operaciones sobre que operan y como se
implementan. Como ocurre en el modelo orientado a objetos los objetos se
comunican entre sí a través del paso de mensajes (parámetros), a esta acción el
modelo dinámico se denomina interacción entre objetos.

Los desgramas de estado, interacción (secuencia, comunicación, tempo y visión

de conjunto) son utilizados para describir como los objetos interactúan
dinámicamente. El modelo dinámico está constituido principalmente por los
diagramas de estado y de actividad, a continuación se presentan las principales
características de casa uno de ellos:

• Diagrama de Estado: Este tipo de diagrama indica de qué manera se

comportan los objetos durante su ciclo de vida, define el comportamiento
del sistema completo.

Características de los diagramas de estado:

o Los principales conceptos de un diagrama de estado son: los

eventos los estados. Un estado es un valor de los atributos de los
objetos.
o El modelo dinámico consiste en múltiples diagramas de estado y
muestra el patrón de actividad para el sistema completo.
 o Éste tipo de diagramas contienen transiciones que son las relaciones
entre los objetos y los eventos que ocurren entra ellos.
• Diagramas de actividad: Son utilizados para especificar el flujo de trabajo
dentro del sistema, a diferencia del diagrama de secuencia el diagrama de
actividad no modela el comportamiento de un sistema de software si no los
procesos y los flujos de un muy alto nivel. El diagrama de actividad define
las siguientes características:
o Proceso de negocio: Utilizado para definir como los objetos cambian
para definir una vista de alto nivel.
o Cartas de estados: Capturan los cambios del sistema a lo largo del
tiempo.

En resumen el UML contiene las herramientas necesarias para la definición del

modelo dinámico de los sistemas de software mediante diversas herramientas que
ayudan a definir el comportamiento del sistema durante lo largo del tiempo. Cada
tipo de diagrama ayuda a capturar la información de los sistemas como un todo
con todos los detalles del mismo a través de diagramas que definen el
comportamiento.

Modelo Funcional.
El modelo funcional representa todos los factores esenciales del desarrollo de
software ignorando aquellos que forman parte de los detalles más específicos de
sistema. Este modelo parte de un propósito general bien especificado y de la
manera más simplificada posible.

Desde una perspectiva más general el modelo funcional se relaciona con el

modelo orientado a objetos, este modelo se relaciona con una entidad existente.
Éste modelo tiene tres principios fundamentales:

• Particionamiento
• Abstracción
• Proyección

Este modelo está basado en conceptos de funciones o procesos, de modo que

estos se conviertan en el elemento más importante de este enfoque. Este modelo
describe los cálculos dentro del sistema, es decir lo que sucede. Comprende los
siguientes tipos de funciones:

• Función asíncrona: Una función asincrónica puede ser activado por otro
objeto o función para realizar alguna acción.
• Función asíncrona dependiente de un estado: Un asíncrono dependiente
del estado es generalmente una función "one-shot" de acción, que se
 ejecuta durante una transición de un estado a otro estado. Esta función se
activa mediante una transformación de control
• Función periódica: Una función periódica se activa a intervalos regulares
para realizar alguna acción. La frecuencia con la que se activa una función
específica depende de la aplicación
• Función periódica dependiente de un estado: Una función periódica se
activa a intervalos regulares para realizar alguna acción. La frecuencia con
la que se activa una función específica depende de la aplicación. Esta
función se activa mediante una transformación de control

Un ejemplo de programas que utilizan este tipo de modelado pueden ser

compiladores, ya que por lo general este tipo de programas realizan cálculos de
las operaciones que tiene que realizar un sistema. Por otra parte, las bases de
datos a menudo tienen un modelo funcional trivial, ya que su finalidad es
almacenar y organizar datos, no transformarla.

Metodología OOHDM
Es una metodología orientada a objetos la cual comprende 5 fases:

1. Obtención de requerimientos.
2. Modelo conceptual.
3. Diseño navegacional.
4. Diseño de la interfaz abstracta.
5. Implementación.

Fase 1 (obtención de requerimientos): La herramienta en la cual se fundamenta

esta fase son los diagramas de casos de usos, los cuales son diseñados por
escenarios con la finalidad de obtener de manera clara los requerimientos y
acciones del sistema.

Fase 2 (Modelo conceptual): Se construye un modelo orientado a objetos que

represente el dominio de la aplicación usando las técnicas propias de la
orientación a objetos.

Fase 3 (Diseño navegacional): La estructura de navegación de una aplicación

hipermedia está definida por un esquema de clases de navegación específica, que
refleja una posible vista elegida.

Fase 4 (diseño de la interfaz abstracta): En esta fase se definen qué objetos de

interfaz va a percibir el usuario, el camino en el cuál aparecerán los diferentes
objetos de navegación, qué objeto de interfaz actuarán en la navegación, la forma
de sincronización de los objetos multimedia y el interfaz de transformaciones.
Fase 5 (Implementación): Una vez cumplidas las 4 fases anteriores solo queda
llevar los objetos a un lenguaje concreto de programación.

SOHDM

Propone un proceso para el modelo conceptual del sistema, que es representado

mediante un diagrama de clases. El proceso de SOHDM continúa reagrupando
estas clases para conseguir un modelo de clases navegacionales del sistema.
Consiste en seis fases: análisis del dominio, modelado del objeto, diseño de la
visión, diseño de la navegación, diseño de la puesta en práctica y construcción.
Esta metodología tiene semejanzas con, OOHDM y EORM donde se diferencian
en el uso de panoramas, que describen las actividades en los acontecimientos y
primitivas de flujos de actividades. Los panoramas se definen en la fase de
análisis y se utilizan para modelar los objetos

RUP

El Proceso Unificado Racional, consiste en un proceso de desarrollo de software y

junto con el Lenguaje Unificado de Modelado (UML), este proceso constituye la
metodología estándar más utilizada para el análisis, implementación y
documentación de sistemas orientados a objetos. Este modelo tiene 4 fases
principales:

Inicio: Se hace un plan de fases, donde se identifican los principales casos de uso
y se identifican los riesgos. Se concreta la idea, la visión del producto, como se
enmarca en el sistema, el alcance del proyecto. Elaboración: Se realiza el plan
que seguirá el proyecto de software, donde se contemplan todos los casos de uso
del sistema. Construcción: Se realiza un producto totalmente operativo y se
elabora el manual de usuario, es en esta fase donde se define la arquitectura del
proyecto. Transición: Se implementa el proyecto, en esta fase se entrena a los
usuarios como deben utilizar el producto, en esta fase se el proyecto pasa del
desarrollador el usuario (transición).

UML

El lenguaje de modelado unificado es una especificación de notación orientada a

objetos, el cual se compone de diferentes diagramas, los cuales representan las
diferentes etapas del desarrollo del proyecto. UML no preescribe un proceso o
método estándar para desarrollar un sistema, es decir no especifica una sola
forma de realizar una operación, si no que brinda las herramientas necearías para
definir, crear y modelar las diferentes etapas de un proyecto mediante una serie de
diagramas. Hay varias metodologías existentes; entre las más populares se
incluyen las siguientes:
Catalysis: Un método orientado a objetos que fusiona mucho del trabajo reciente
en métodos orientados a objetos, y además ofrece técnicas específicas para
modelar componentes distribuidos.

Objetory: Un método de Caso de Uso guiado para el desarrollo, creado por Ivar
Jacobson.

Shlaer/Mellor: El método para diseñar sistemas de tiempo real.

Fusion: Desarrollado en Hewlett Packard a mediados de los noventa como primer

intento de un método de diseño orientado a objetos estándar.
OMT: La Técnica de Modelado de Objetos fue desarrollada por James Rumbaugh
y otros, y publicada en el libro de gran influencia. Un método que propone análisis
y diseño ‘iterative’, más centrado en el lado del análisis.

Modelado de casos de uso

Un caso de uso se modela para todos los procesos que el sistema debe llevar a
cabo. Los procesos se describen dentro del caso de uso por una descripción
textual o una secuencia de pasos ejecutados. Una vez que el comportamiento del
sistema está captado de esta manera, los casos de uso se examinan y amplían
para mostrar qué objetos se interrelacionan para que ocurra este comportamiento.
Los casos de uso son la forma más efectiva y fácil de modelar los requisitos de un
usuario desde el punto de vista de este. Los casos de uso son la herramienta que
describen como debe funcionar un sistema o como se desearía que funcione. No
es realmente una aproximación a la orientación a objetos; es realmente una forma
de modelar procesos. Los casos de uso son generalmente el punto de partida del
análisis orientado a objetos con UML.

Booch: Parecido al OMT con características adicionales.

 MODELADO ORIENTADO A OBJETOS

MODELO DEFINICIÓN CARACTERÍSTICAS

Orientado a Objetos Este enfoque realiza la Utiliza clases, asocia

construcción de modelos objetos, define una
de un sistema por medio jerarquía de cases.
de la identificación y la Utiliza el paradigma OO:
especificación de un clases, objetos, herencia,
conjunto de objetos polimorfismo,
relacionados, que encapsulamiento, etc.
colaboran entre si de
acuerdo a los
requerimientos
establecidos para el
sistema de objetos.
Modelo Dinámico. El modelo dinámico está Diagrama de estado:
basado y constituido en define la manera en cómo
aquellos aspectos de un se comportan los objetos.
sistema relacionados con Diagramas de actividad:
el tiempo (objetos y Especifican el flujo de
cambio de los mismos) a trabajo dentro del
lo largo del tiempo. sistema.
Modelo Funcional El modelo funcional Se basa en tres
representa todos los principios:
factores esenciales del particionamiento,
desarrollo de software abstracción, proyección.
ignorando aquellos que Está basado en
forman parte de los conceptos de funciones o
detalles más específicos procesos (siendo estos el
de sistema. Este modelo elemento más importante
parte de un propósito del enfoque)
general bien especificado
y de la manera más
simplificada posible
El método de Booch considera que las etapas del proceso en un desarrollo
orientado a objetos son:

Identificar las claves y objetos en un nivel dado de abstracción

Identificar la semántica de estas clases y objetos
Identificar las relaciones entre clases y objetos
Especificar la interfaz y la implementación de estas clases y objetos

Estas etapas suelen seguirse por la mayoría de los métodos de diseño OO

existentes. De hecho, para los sistemas orientados a objetos se define el siguiente
diseño en pirámide que contempla el método de Booch.

La capa del subsistema.- Contiene una representación de cada uno de los

subsistemas que le permiten al software conseguir los requisitos definidos por el
cliente e implementar la infraestructura técnica que los soporta.
La capa de clases y Objetos.- Contiene las jerarquías de clase que permiten
crear el sistema usando generalizaciones y especializaciones mejor definidas.
Esta capa también contiene representaciones de diseño para cada objeto.

La capa de mensajes.- Contiene los detalles que le permiten a cada objeto

comunicarse con sus colaboradores. Esta capa establece las interfaces externas e
internas para el sistema.

La capa de responsabilidades.- Contiene las estructuras de datos y el diseño

algorítmico para todo los atributos y operaciones de cada objeto.
Esta pirámide de diseño se centra entonces en el diseño de un producto o sistema
específico.

El enfoque convencional y el enfoque OO

Los enfoques convencionales para el diseño del software aplican notaciones y
heurísticas diferentes para establecer correspondencias entre el modelo de
análisis y el diseño. Si recordamos la ingeniería de software clásica (imperativa),
veremos que cada elemento del modelo de análisis convencional tiene
correspondencia con una o más capas del modelo de diseño tal como lo ilustra la
siguiente figura:

El modelo de Análisis El modelo de Diseño

La arquitectura de diseño OO se centra más en las colaboraciones entre los
objetos que con el flujo de control de datos. De esta manera las capas de la
pirámide se renombran para reflejar de forma más exacta la naturaleza del DOO.
La siguiente figura muestra ahora la correspondencia entre el AOO con las
correspondientes capas de la pirámide de diseño OO.
 UES TULTEPEC

PROFESORA: DULCE MARIA REYES

DESARROLLO DE SOFTWARE BASADO EN

COMPONENTES

SISTEMAS DE INFORMACION
INTEGRANTES:
*GARCIA LONGINOS JESSICA ELENA
*LINARES ROMERO EMILIA DEL ROSARIO
*MENDOZA RODRIGUEZ ADRIAN
* OCHOA DAGDUG JAQUELINE
*MOLINA RUIZ CAROLINA
*VARGAZ HERNANDEZ LEONARDO
*SERRATO AGUILAR VIRIDIANA
*VENTURA RODRIGUEZ CARLOS EDUARDO

GRUPO: 28LF261

DESARROLLO DE SOFTWARE BASADO EN COMPONENTES

 DESARROLLO DE SOFTWARE BASADO EN COMPONENTES

Objetivos

El desarrollo basado en componentes es una aplicación de la técnica de; divide y conquer, para
manejar la complejidad. La diferencia principal con los métodos estructurados principalmente
que el análisis y diseño es realizado dentro del mismo paradigma que la implementación. Esta
implementación queda relegada a un segundo plano, siendo importante dar una solución lógica al
problema, previo a su codificación. Este principio fue utilizado en el paradigma de orientación a
objetos, el hecho de combinar operaciones e información en una misma unidad, y de contar con
técnicas de modelado dentro del mismo paradigma, hizo que la orientación a objetos tuviera un
éxito importante.

PRINCIPALES OBJETIVOS

1. Lograr el reúso (tal hecho es admirable pero no es fácil de obtener).

2. Buscar el fácil reemplazo. (Esto implica una nueva implementación del componente para
que pueda ser utilizada en lugar de la implementación anterior sin afectar el funcionamiento
del resto de los componentes.)

COMPONENTE

“Un componente es una unidad de composición de aplicaciones software, que posee un conjunto
de
interfaces y un conjunto de requisitos, y que ha de poder ser desarrollado, adquirido, incorporado
al sistema y compuesto con otros componentes de forma independiente, en tiempo y espacio”

DESARROLLO DE SOFTWARE BASADO EN COMPONENTES

Características de un Componente

Identificable: Debe tener una identificación que permita acceder fácilmente a sus servicios que
permita su clasificación.
Auto contenido: Un componente no debe requerir de la utilización de otros para finiquitar la
función para la cual fue diseñado.
Puede ser remplazado por otro componente: Se puede remplazar por nuevas versiones u otro
componente que lo remplace y mejore.
Con acceso solamente a través de su interfaz: Debe asegurar que estas no cambiaran a lo largo
de su implementación.
Sus servicios no varían: Las funcionalidades ofrecidas en su interfaz no deben variar, pero su
implementación sí.
Bien Documentado: Un componente debe estar correctamente documentado para facilitar su
búsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc.
Es genérico: Sus servicios deben servir para varias aplicaciones.
Reutilizado dinámicamente: Puede ser cargado en tiempo de ejecución en una aplicación.
Independiente de la plataforma: Hardware, Software, S.O.[9]

LA INTERFAZ DE UN COMPONENTE

Una interfaz define el conjunto de operaciones que un componente puede realizar; estas
operaciones son llamadas también servicios o responsabilidades. Las interfaces proveen un
mecanismo para interconectar componentes y controlar las dependencias entre ellos.
La naturaleza de la interfaz varía dependiendo del lenguaje programación empleado para
implementar el componente.
En general, una interfaz de programación de aplicaciones (API, Application Programming
Interface) es una especificación, en un lenguaje de programación, de las propiedades de un
módulo de software. Los clientes del módulo sólo deben depender exclusivamente de las
propiedades definidas por el API de forma explícita.

Existen dos tipos de interfaces:

1. interfaz de negocio: que refleja el rol del componente en el sistema.

DESARROLLO DE SOFTWARE BASADO EN COMPONENTES

2. interfaz de infraestructura: es impuesta por el modelo de componentes con el fin de permitirle
al framework interactuar con el componente.
Por otra parte, nótese que las interfaces convencionales definen la firma de las operaciones
(nombre de la operación, tipo y orden de los argumentos, y la manera como se devuelven los
resultados) que provee un componente. Las operaciones también se conocen como Propiedades
Funcionales. Sin embargo, estas interfaces no expresan adecuadamente propiedades del
componente relativas a, por ejemplo, su desempeño, precisión, disponibilidad, latencia,
seguridad, entre otras. Dichas propiedades se conocen como Propiedades Extrafuncionales

Es útil diferenciar los tipos de propiedades de los componentes. Por ejemplo, Beugnard et al.
[25] define cuatro tipos de propiedades relacionadas con:
1. Sintaxis: corresponden a las propiedades funcionales expresadas explícitamente a través de la
interfaz del componente.
2. Comportamiento: definen las condiciones que deben cumplir los valores de entrada
(precondiciones) y salida (postcondiciones) de las operaciones.
3. Sincronización: expresan aspectos de concurrencia.
4. Calidad de Servicio: contempla atributos tales como tiempo de respuesta, uso de memoria,
precisión, confiabilidad, facilidad de mantenimiento y reutilización, entre otros.

DESARROLLO DE SOFTWARE BASADO EN COMPONENTES

El paradigma de ensamblar componentes y escribir código para hacer que estos componentes
funcionen se conoce como Desarrollo de Software Basado en Componentes.

El desarrollo de software basado en componentes permite reutilizar piezas de código pre

elaborado que permiten realizar diversas tareas, conllevando a diversos beneficios como las
mejoras a la calidad, la reducción del ciclo de desarrollo y el mayor retorno sobre la inversión.

Un componente de software puede ser visto desde dos perspectivas distintas, como:

1. implementación: los componentes se pueden ensamblar y desplegar para crear sistemas y

aplicaciones que se ejecutan en un computador.

DESARROLLO DE SOFTWARE BASADO EN COMPONENTES

2. abstracción de arquitectura: los componentes expresan las reglas de diseño que impone el

modelo de componentes.

CARACTERISTICAS DEL DESARROLLO BASADO EN COMPONENTES

El modelo de desarrollo basado en componentes incorpora muchas de las características del

modelo en espiral.

Para esto debemos recordar que un modelo en espiral se desarrolla en una serie de versiones
incrementales. Se divide en un número de actividades de marco de trabajo también llamadas
regiones de tareas las cuales son:

1_. Comunicación con el cliente

2_. Planificación

3_. Análisis de riesgo

4_. Ingeniería

5_. Evaluación del cliente

6_. Construcción y entrega

Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde

componentes preparados de software (llamados «clases»).

La actividad de la ingeniería comienza con la identificación de clases candidatas. Esto se lleva ac

abo examinando los datos que se van a manejar por parte de la aplicación y el algoritmo que se
va a aplicar para conseguir el tratamiento. Los datos y los algoritmos correspondientes se
empaquetan en una clase.
Las clases creadas en los proyectos de ingeniería del software anteriores, se almacenan en una
biblioteca de clases o diccionario de datos.
Una vez identificadas las clases candidatas, la biblioteca de clases se examina para determinar si
estas clases ya existen. En caso de que así fuera, se extraen de la biblioteca y se vuelven a utilizar
. Si una clase candidata no reside en la biblioteca, se aplican los métodos orientados a objetos.

DESARROLLO DE SOFTWARE BASADO EN COMPONENTES

Se compone así la primera iteración de la aplicación a construirse, mediante las clases extraídas d
e
la biblioteca y las clases nuevas construidas para cumplir las necesidades Únicas de la aplicación
.
El flujo del proceso vuelve a la espiral y volverá a introducir por último la iteración ensamblador
a de componentes a través de la actividad de ingeniería

ARQUITECTURA

El término ‘arquitectura’ es heredado de otras disciplinas de la ciencia. Se entiende por

arquitectura a un conjunto de piezas de distintos tipos, que encajan entre sí y cumplen una
función determinada. La arquitectura presenta además el impacto del cambio de una de las
piezas. Dentro del paradigma de componentes, las piezas (o building blocks) son los
componentes. La arquitectura de componentes dirá con qué tipos de componentes y en qué
relación de dependencia se encuentran. Como fue mencionado antes, la metodología aquí
propuesta busca utilizar el paradigma de componentes a sistemas empresariales de gran porte.
Para ello consideramos arquitecturas distribuidas, en múltiples capas, que incorporan fuentes de
datos heterogéneas, sistemas legados y paquetes off-the-shelf. El estilo de arquitectura en capas
es aplicable a este tipo de sistemas. Cada capa sugiere un tipo diferente de componentes, e indica
el rol que juegan los componentes que residan en ella

El enfoque metodológico se centra en aquellas capas que representan las funcionalidades del
sistema, a saber, la capa de Servicios del Sistema y la capa de Servicios del Negocio. La
definición de la arquitectura de componentes cubre aspectos únicamente lógicos y es totalmente
independiente de la tecnología con la cual se implementarán los componentes y sobre la cual se
hará el deploy del sistema. Esta vista lógica nos permite medir el nivel de acoplamiento del
sistema y razonar sobre los efectos de modificar o reemplazar un componente. La independencia
de la tecnología nos permite abstraernos de los tecnicismos de éstas así como elegir la más apta

DESARROLLO DE SOFTWARE BASADO EN COMPONENTES

dependiendo del sistema que se esté desarrollando

BENEFICIOS.

1. Reutilización del software. Nos lleva a alcanzar un mayor nivel de reutilización de softwa
re.
2. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de l
os componentes antes de probar el conjunto completo de componentes ensamblados.
3. Simplifica el mantenimiento del sistema. Cuando existe un débil acoplamiento entre
componentes, el desarrollador es libre de actualizar y/o agregar componentes según 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 organización, la calidad de una aplicación basada en
componentes mejorará con el paso del tiempo.

DESARROLLO DE SOFTWARE BASADO EN COMPONENTES

 ETAPAS DEL MODELO BASADO EN COMPONENTES

Se realiza el estudio de procesos de

desarrollo basado en componentes, en
1.- Análisis y comparación de Procesos especial de los que utilizan técnicas de
De Desarrollo de Software Basado en Componentes. modelado. Con extensiones específicas
para componentes, a los fines de definir
adaptaciones y/o extensiones
apropiadas de los mismos

Durante esta etapa se realiza el estudio y comparación de diferentes

estilos y patrones arquitecturales, analizando ventajas y desventajas
de su utilización para el desarrollo de este tipo de sistemas, así como
2.- Análisis arquitectural de arquitecturas existentes y estándares más utilizados en la
actualidad.

Esta etapa comprende la identificación de interfaces del

sistema, de interfaces del Negocio, la identificación de
componentes y la descripción inicial de las
3.- Identificación de componentes
especificaciones de componentes, así como la
especificación de la arquitectura inicial de componentes.

Se trabajará en la especificación de
interfaces y de componentes, definiendo
4.- Especificación de los principales componentes Contratos de uso y Contratos de
realización. Se realizan en esta etapa, los
Modelos de Información de Interfaces.

DESARROLLO DE SOFTWARE BASADO EN COMPONENTES