RESUMEN

RICARDO TOVAR TISCAREO

INGENIERA EN TECNOLOGAS DE LA INFORMACIN Y COMUNICACIONES
INSTITUTO TECNOLGICO DE AGUASCALIENTES

INGENIERA DE SOFTWARE

MODELOS DEL SISTEMA

Los requerimientos del usuario deberan redactarse en lenguaje natural debido a que
tienen que ser comprendidos por personas que no son tcnicos expertos. Sin embargo,
pueden expresarse requerimientos del sistema ms detallados de forma ms tcnica.
Pueden usarse modelos en el proceso de anlisis para comprender el sistema existente
que debe ser reemplazado o mejorado, o para especificar el nuevo sistema que sea
requerido. Pueden desarrollarse diferentes modelos para representar el sistema desde
diferentes perspectivas.
Por ejemplo:
1. Una perspectiva externa, en la que se modela el contexto o entorno del sistema.
2. Una perspectiva de comportamiento, en la que se modela el comportamiento del
sistema.
3. Una perspectiva estructural, en la que se modela la arquitectura del sistema o la
estructura de los datos procesados por el sistema.
Un modelo del sistema es una abstraccin del sistema que se est estudiando en lugar de
una representacin alternativa de ese sistema. Idealmente, una representacin de un
sistema debera mantener toda la informacin sobre la entidad que se est
representando. Una abstraccin simplifica y resalta de forma deliberada las caractersticas
ms relevantes.
Un modelo de flujo de datos (por ejemplo) se centra en el flujo de datos y las
transformaciones funcionales sobre esos datos. Se omiten los detalles de las estructuras
de datos. Por el contrario, un modelo de entidades de datos y sus relaciones documentan
las estructuras de datos del sistema en lugar de su funcionalidad.
Ejemplos de tipos de modelos del sistema que podran crearse durante el proceso de
anlisis son:
1. Un modelo de flujo de datos. Los modelos de flujo de datos muestran cmo se
procesan los datos en el sistema en diferentes etapas.
2. Un modelo de composicin. Un modelo de composicin o agregacin muestra
cmo las entidades del sistema estn compuestas por otras entidades.
3. Un modelo arquitectnico. Los modelos arquitectnicos muestran los principales
subsistemas que componen un sistema.
4. Un modelo de clasificacin. Los diagramas de clases/herencia de objetos
muestran cmo las entidades tienen caractersticas comunes.
5. Un modelo de estmulo-respuesta. Un modelo de estmulo respuesta o diagrama
de transicin de estados muestra cmo reacciona el sistema a eventos internos y
externos.
Los modelos arquitectnicos de alto nivel se expresan normalmente como sencillos
diagramas de bloques en donde cada subsistema se representa por un rectngulo con
nombre, y las lneas indican asociaciones entre los subsistemas.
Los modelos de flujo de datos son una forma intuitiva de mostrar cmo los datos son
procesados por un sistema. A nivel de anlisis, deberan usarse para modelar la forma en
la que los datos son procesados en el sistema existente.

Un modelo de mquina de estados describe cmo responde un sistema a eventos

internos o externos. El modelo de mquina de estados muestra los estados del sistema y
los eventos que provocan las transiciones de un estado a otro. No muestra el flujo de
datos dentro del sistema.
La notacin UML indica la actividad que tiene lugar en un estado. En una especificacin
detallada del sistema, usted tiene que proporcionar ms detalle sobre el estmulo y los
estados del sistema. Esta informacin puede mantenerse en un diccionario de datos o
enciclopedia y que es mantenida por las herramientas CASE utilizadas para crear el
modelo del sistema.
Al igual que todos los modelos grficos, a los modelos de datos les faltan detalles, y usted
debera mantener descripciones ms detalladas de las entidades, relaciones y atributos
incluidas en el modelo. Usted puede reunir estas descripciones ms detalladas en un
repositorio o diccionario de datos.
Un diccionario de datos es, de forma simple, una lista de nombres ordenada
alfabticamente incluida en los modelos del sistema.
Las ventajas de usar un diccionario de datos son las siguientes:
1. Es un mecanismo para la gestin de nombres.
2. Sirve como un almacn de informacin de la organizacin.
Los modelos de objetos que usted desarrolla durante el anlisis de requerimientos pueden
utilizarse para representar tanto los datos del sistema como su procesamiento. A este
respecto, dichos modelos combinan algunos de los usos de los modelos de flujo de datos
y los modelos semnticos de datos.
Una clase de objetos es una abstraccin sobre un conjunto de objetos que identifica
atributos comunes (como en un modelo semntico de datos) y los servicios u operaciones
que son proporcionados por cada objeto. Los objetos son entidades ejecutables que
tienen atributos y servicios de la clase de objetos. Los objetos son instanciaciones de la
clase de objetos, y pueden crearse muchos objetos a partir de una clase.
Una taxonoma es un esquema de clasificacin que muestra cmo una clase de objetos
est relacionada con otras clases a travs de atributos y servicios comunes.
Para mostrar esta taxonoma, las clases se organizan en una jerarqua de herencia con
las clases de objetos ms generales al principio de la jerarqua.
Un mtodo estructurado es una forma sistemtica de elaborar modelos de un sistema
existente o de un sistema que tiene que ser construido.
Sin embargo, los mtodos estructurados tienen una serie de inconvenientes:
1. No proporcionan un soporte efectivo para la comprensin o el modelado de
requerimientos del sistema no funcionales.
2. No discriminan en tanto que normalmente no incluyen guas que ayuden a los
usuarios a decidir si un mtodo es adecuado para un problema concreto.
3. A menudo generan demasiada documentacin.
4. Los modelos producidos son muy detallados, y los usuarios a menudo los
encuentran difciles de entender.
Las herramientas que soportan mtodos completos normalmente incluyen:
1. Editores de diagramas
2. Herramientas de anlisis y comprobacin de diseos

3.
4.
5.
6.
7.
8.

Lenguajes de consulta del repositorio

Un diccionario de datos
Herramientas de generacin y definicin de informes
Herramientas de definicin de formularios
Facilidades para importar/exportar
Generadores de cdigo

ESPECIFICACIN FORMAL
La denominacin mtodos formales se usa para referirse a cualquier actividad
relacionada con representaciones matemticas del software, incluyendo la especificacin
formal de sistemas, anlisis y demostracin de la especificacin, el desarrollo
transformacional y la verificacin de programas.
Se han utilizado dos aproximaciones fundamentales para redactar especificaciones
detalladas para sistemas de software industriales. Estas son:
1. Una aproximacin algebraica
2. Una aproximacin basada en modelos
El cuerpo de la especificacin tiene cuatro componentes:
1. Una introduccin
2. Una parte de descripcin
3. La parte de signatura
4. La parte de axiomas
El proceso del desarrollo de una especificacin formal de la interfaz de un subsistema
comprende las siguientes actividades:
1. Estructura de la especificacin. Se organiza la especificacin informal de la
interfaz en un conjunto de tipos abstractos de datos o clases de objetos. Se
deberan definir informalmente las operaciones asociadas con cada clase.
2. Nombrado de la especificacin. Se establece un nombre para la especificacin
de cada tipo abstracto de datos, decide si stos requieren parmetros y determina
los nombres para las clases identificadas.
3. Seleccin de las operaciones. Se elige un conjunto de operaciones para cada
especificacin basada en la funcionalidad identificada de la interfaz. Deberan
incluirse operaciones para crear instancias de la clase, para modificar el valor de
las instancias y para inspeccionar los valores de las instancias. Deben aadirse
funciones a las inicialmente identificadas en la definicin informal de la interfaz.
4. Especificacin informal de las operaciones. Se redacta una especificacin
informal de cada operacin. Debera describirse cmo las operaciones afectan a la
clase definida.
5. Definicin de la sintaxis. Se define la sintaxis de las operaciones y sus
parmetros sta es la parte de la signatura de la especificacin formal. Si fuera
necesario, debera actualizarse la especificacin informal en esta etapa.
6. Definicin de axiomas. Se define la semntica de las operaciones describiendo
qu condiciones son siempre verdaderas para diferentes combinaciones de
operaciones.

DISEO ARQUITECTNICO
El estilo y estructura particulares elegidos para una aplicacin puede, por lo tanto,
depender de los requerimientos no funcionales del sistema:
1. Rendimiento.
2. Proteccin.
3. Seguridad.
4. Disponibilidad.
5. Mantenibilidad.
El diseo arquitectnico es un proceso creativo en el que se intenta establecer una
organizacin del sistema que satisfaga los requerimientos funcionales y no funcionales del
propio sistema. Debido a que es un proceso creativo, las actividades dentro del proceso
difieren radicalmente dependiendo del tipo de sistema a desarrollar, el conocimiento y la
experiencia del arquitecto del sistema, y los requerimientos especficos del mismo.
La arquitectura de un sistema software puede basarse en un modelo o estilo
arquitectnico particular. Un estilo arquitectnico es un patrn de organizacin de un
sistema tal como una organizacin cliente-servidor o una arquitectura por capas. Es
importante un conocimiento de estos estilos, sus aplicaciones, y sus ventajas e
inconvenientes.
Los modelos arquitectnicos que pueden desarrollarse pueden incluir:
1. Un modelo estructural esttico que muestre los subsistemas o componentes
que han sido desarrollados como unidades separadas.
2. Un modelo de proceso dinmico que muestre cmo se organiza el sistema en
procesos en tiempo de ejecucin. Este modelo puede ser diferente del modelo
esttico.
3. Un modelo de interfaz que defina los servicios ofrecidos por cada subsistema a
travs de su interfaz pblica.
4. Modelos de relaciones que muestren las relaciones, tales como el flujo de datos,
entre los subsistemas.
5. Un modelo de distribucin, que muestre cmo se distribuyen los subsistemas
entre las computadoras.
En una descomposicin orientada a flujos de funciones o modelo de flujo de datos, las
transformaciones funcionales procesan sus entradas y producen salidas. Los datos fluyen
de una funcin a otra y se transforman a medida que se mueven a travs de la secuencia
de funciones.
Cada paso de procesamiento se implementa como una transformacin. Los datos de
entrada fluyen a travs de estas transformaciones hasta que se convierten en datos de
salida. Las transformaciones se pueden ejecutar secuencialmente o en paralelo.
Los modelos de control a nivel arquitectnico estn relacionados con el flujo de control
entre subsistemas.
Hay dos estilos de control genricos que se usan en sistemas software:

1. Control centralizado. Un subsistema tiene toda la responsabilidad para controlar

e iniciar y detener a otros subsistemas. Tambin puede devolver el control a otro
subsistema, pero esperar que le sea devuelta la responsabilidad del control.
2. Control basado en eventos. En lugar de que la informacin de control est
embebida en un subsistema, cada subsistema puede responder a eventos
generados externamente.

INGENIERA DE SOFTWARE BASADA EN COMPONENTES

La ingeniera del software basada en componentes (CBSE) surgi a finales de los 90 con
una aproximacin basada en reutilizacin al desarrollo de sistemas software. Su creacin
fue motivada por la frustracin de los diseadores de que el desarrollo orientado a objetos
no conducido a una reutilizacin extensiva, tal y como se sugiri originalmente. Las clases
de objetos simples eran demasiado detalladas y especficas, y a menudo tenan que ser
enlazada con aplicaciones en tiempo de compilacin.
CBSE es el proceso de definir, implementar e integrar o componer en sistemas
componentes independientes dbilmente acoplados. Se ha convertido en una importante
aproximacin de desarrollo del software debido a que los sistemas software son cada vez
ms grande y ms complejos y los clientes demandan software ms confiable que sea
desarrollado rpidamente.
Los fundamentos de la ingeniera del software basada en componentes son:
1. Componentes independientes
2. Estndares de componentes
3. El middleware
4. Un proceso de desarrollo
Un componente software es una unidad de composicin con interfaces especificadas
contractualmente y dependencias de contexto explcitas nicamente. Un componente
software puede ser desplegado de forma independiente y est sujeto a la composicin por
terceras partes.
Un modelo de componentes es una definicin de los estndares para la definicin de
componentes, documentacin y despliegue.
La composicin de componentes es el proceso de ensamblar componentes para crear un
sistema. Si nosotros asumimos una situacin en la que los componentes reutilizables
estn disponibles, entonces la mayora de los sistemas se construirn componiendo estos
componentes reutilizables unos con otros, con componentes escritos de forma especial y
con la infraestructura de soporte de los componentes proporcionada por el marco de
trabajo del modelo.

NOTACIONES
UML
Lenguaje Unificado de Modelado (LUM o UML) es el lenguaje de modelado de sistemas
de software ms reconocido y usado en la actualidad; est respaldado por el OMG
(Object Management Group). Es un lenguaje grfico para especificar, visualizar, construir
y documentar un sistema. UML ofrece un estndar para describir un "plano" del sistema,
incluyendo aspectos conceptuales tales como procesos de negocio y funciones del
sistema, y aspectos concretos como expresiones de lenguajes de programacin,
esquemas de bases de datos y componentes reutilizables.

BPMN
El Business Modeling Notation o BPMN (Notacin para el Modelado de Procesos de
Negocios) es un mtodo de negocios que ilustra los procesos en forma similar a un
diagrama de flujo. El BPMN fue desarrollado en un principio por el Business Process
Management Initiative (BPMNI). Actualmente es sostenido por el Grupo de Gestin de
Objetos (OMG).

DFD
Un diagrama de flujo de datos (DFD por sus siglas en espaol e ingls ) es una
representacin grfica del "flujo" de datos a travs de un sistema de informacin . Un
diagrama de flujo de datos tambin se puede utilizar para la visualizacin de
procesamiento de datos (diseo estructurado ). Es una prctica comn para
un diseador dibujar un contexto a nivel de DFD que primero muestra la interaccin entre
el sistema y las entidades externas. Este contexto a nivel de DFD se "explot" para
mostrar ms detalles del sistema que se est modelando.