You are on page 1of 10

Un enfoque estructurado y orientado a

objetos

Paradigmas
de la
ingeniera de
Software
Fundamentos de ingeniera de
software

Erik Ivan Mancilla Romero


Introduccin
La Ingeniera de Software est compuesta por una serie de pasos que abarcan los
mtodos, herramientas y procedimientos mencionados, a los que se denominan
Paradigmas de la Ingeniera de Software.

Paradigma de la ingeniera de software


La ingeniera de software surge de la ingeniera de sistemas y de hardware. Abarca
un conjunto de tres elementos que facilitan el control sobre el proceso de desarrollo
de software y suministran las bases para construir software de calidad de una forma
productiva:
Mtodos
Herramientas
Procedimientos
Mtodos que indican cmo construir el software tcnicamente e incluyen un amplio
espectro de mtodos para la planificacin, la estimacin, el anlisis, el diseo,
codificacin, prueba y mantenimiento.

Herramientas automticas y semiautomticas que apoyan a la aplicacin de los


mtodos. Cuando se integran las herramientas de forma que la informacin creada
por una herramienta puede ser usada por otra, se establece un sistema para el
soporte del desarrollo de software, llamado Ingeniera de Software Asistida por
Computadora (CASE).

Procedimientos que definen la secuencia en la que se aplican los mtodos, las


entregas, los controles de calidad y guas para evaluacin del progreso.

Enfoque estructurado

En el Enfoque Estructurado se usan los DFD (Diagramas de Flujos de Datos) como


principal herramienta para entender al sistema antes de plasmarlo a cdigo fuente.
DFD es un diagrama en el que participan procesos (mtodos), flujo de datos
(argumentos) y archivos (base de datos). Hay de diferentes niveles dependiendo la
complejidad del sistema que analiza.
Muestran en forma visual slo el flujo de datos entre los distintos procesos,
entidades externas y almacenes que conforman un sistema.
Cuando los analistas de sistemas indagan sobre los requerimientos de informacin
de los usuarios, deben ser capaces de concebir la manera en que los datos fluyen
a travs del sistema u organizacin, los procesos que sufren estos datos y sus tipos
de salida.
Diagrama de flujo

Un diagrama de flujo de datos (DFD por sus siglas en


Espaol e ingls) es una descripcin grafica de un procedimiento para la resolucin
de un problema. Son frecuentemente usados para descubrir algoritmos y programas
de computador.
Los diagramas de flujos estn compuestos por figuras conectadas con flechas. Para
ejecutar un proceso comienza por el Inicio y se siguen las acciones indicadas por
cada figura: El tipo de figura indica el tipo de paso que representa el Software.

DFD es un software diseado para contribuir y analizar algoritmos se puede crear


diagramas de flujos de datos para la representacin de algoritmos de programacin
estructurada a partir de las herramientas de edicin que para este propsito
suministra el programa. La interfaz grfica de DFD facilita en gran medida el trabajo
con diagramas ya que simula la representacin estndar de diagramas de flujo en
hojas de papel.

Los componentes de un Diagrama de Flujo son:

Flujo de datos

Un flujo se representa grficamente por medio de una flecha que entra y sale de
proceso; el flujo se usa para describir el movimiento, de bloques o paquetes de
informacin de una parte del sistema a otra.

Almacn de Datos

Se utiliza para modelar una coleccin de paquetes de datos en reposo. Se denota


por dos lneas paralelas, de modo caracterstico el nombre que se utiliza para
identificar los paquetes que entran y salen del almacn por medios de flujo.

Proceso

El primer componente de diagrama de flujo de datos se conoce como Proceso.


Cuando un flujo de datos entra en un proceso sufre una transformacin, y muestra
una parte del sistema que transforman en Entradas y Salidas.
Entidad externa
Representa personas, organizaciones, o sistemas que no pertenecen al sistema. En
el caso de que las entidades externas se comunicasen entre s, esto no se
contemplara en el diagrama, por estar fuera del mbito de nuestro sistema.

Ejemplo general:
Diccionario de datos
Un diccionario de datos: es un conjunto de metadatos (en general, un grupo de
metadatos se refiere a un grupo de datos).Que contiene las caractersticas lgicas
y puntuales de los datos que se van a utilizar en el sistema que se programa,
incluyendo nombre, descripcin, alias, contenido y organizacin.
Identifica los procesos donde se emplean los datos y los sitios donde se necesita el
acceso inmediato a la informacin, se desarrolla durante el anlisis de flujo de datos
y auxilia a los analistas que participan en la determinacin de los requerimientos del
sistema, su contenido tambin se emplea durante el diseo.

Los diccionarios de datos son buenos complementos a los diagramas de flujo de


datos, los diagramas de entidad-relacin, etc.
Existen muchos esquemas de anotacin usados por los analistas de sistemas el
que sigue es uno de los ms usados

Contenido de diccionario de datos


El Diccionario de datos debe contener la siguiente informacin:
Nombre: el nombre principal del elemento; del flujo de datos, del repositorio de datos
o de una entidad externa.

Alias: otros nombres usados para la entrada, dado que un mismo elemento
puede ser conocido por diferentes nombres.

Definicin: Exposicin clara y precisa de las caractersticas genricas y


diferenciales del objeto.

Descripcin: Explicar las diversas partes o circunstancias, que componen


la definicin, de los objetos. Dnde se usa/cmo se usa: Un listado de los
procesos que usan un elemento de datos, o del control de cmo lo usan.

Descripcin del contenido: El contenido es representado mediante una


anotacin que se describe en la siguiente tabla.
Diseos de datos
La definicin de Mdulo es una dimensin que convencionalmente se toma como
unidad de medida, Unidad de diseo que presenta una divisin de Software clara y
manejable con sus interfaces definidas, Puede representar un programa,
subprograma o rutina.
En programacin, un mdulo es un software que agrupa un conjunto de
subprogramas y estructuras de datos. Los mdulos son unidades que pueden ser
compiladas por separado y los hace reusables y permite que mltiples
programadores trabajen en diferentes mdulos en forma simultnea, produciendo
Ahorro en los tiempos de desarrollo.

Criterios de diseo modular


El objetivo principal del diseo estructurado es desarrollar una estructura de
programa en la que queden bien definidas las divisiones entre elementos
homogneos y la comunicacin entre ellos.
Dichos elementos son llamados mdulos y su identificacin har mucho ms
sencillo un Software, as como su control y mantenimiento.

Conceptos de divisin
La subdivisin de un sistema en subsistemas y de stos en mdulos se hace de
acuerdo a una serie de conceptos que se anuncian a continuacin

Abstraccin: El nivel de abstraccin disminuye a medida nos adentramos en


terrenos ms tcnicos. Encontramos tres tipos de abstracciones:

1. De procesos
2. De datos
3. De control.

Refinamiento:
Mientras la abstraccin nos permite conceptualizar con independencia los
detalles de bajo nivel, el refinamiento nos permite avanzar hacia estos.

Modularidad:
Divisin del Software en elementos con funcin propia distinguibles de
otros que se comunican e intercambian informacin.

Diseo estructurado: Nos da una gua para modelar un problema. Definir


los mdulos del sistema de informacin, y la manera en que van a
interactuar unos con otros, intentando que cada mdulo trate total o
parcialmente un proceso especfico y tenga una interfaz sencilla.
Jerarqua de DFD's

En un DFD completo cada proceso tiene un nmero nico que lo identifica


en funcin de su situacin en la jerarqua.

Cada DFD tiene tambin un nmero nico que coincide con el proceso que
describe.

Las hojas o nodos terminales corresponden a procesos primitivos no


descomponibles.

Para cada proceso primitivo existir una mini especificacin. Un modelo de datos
es un lenguaje orientado a describir una Base de Datos.
Tpicamente un Modelo de Datos permite describir:

Las estructuras de datos de la base: El tipo de los datos que hay en la base
y la forma en que se relacionan.

Las restricciones de integridad: Un conjunto de condiciones que deben


cumplir los datos para reflejar correctamente la realidad deseada.

Operaciones de manipulacin de los datos: tpicamente, operaciones de


agregado, borrado, modificacin y recuperacin de los datos de la base.

Descomposicin en procesos

En cualquier momento nos puede aparecer un proceso que no necesite


descomposicin y es lo que denominaremos Proceso Primitivo (PP). En ellos, se
detallar la entrada y salida que tenga, adems de la descripcin asociada que
explique lo que realiza.

DFD: Construccin.

Representar el diagrama de contexto.

Representar el DFD de primer nivel, indicando los distintos subsistemas


funcionales en que se descompone nuestro sistema.
Descomponer cada uno de los procesos que aparecen en el DFD de primer
nivel, hasta llegar a un nivel suficiente de detalle.

Se recomienda el utilizar cuatro niveles de descomposicin de diagramas.

Nivel 0: Diagrama de contexto

Nivel 1: Subsistemas
Nivel 2: Funciones de cada subsistema

Nivel 3: Subfunciones asociadas

Nivel 4: Procesos necesarios para el tratamiento de cada subfuncin.

Descomposicin funcional
Cada proceso se puede explotar, refinar o descomponer en un DFD ms
detallado.

El DFD de unsistema es realmente un conjunto de DFDs dispuestos


jerrquicamente.

Los niveles de la jerarqua estn determinados por la descomposicin


funcional de los procesos.

La raz de la jerarqua es el diagrama de contexto, que es el ms general


de todos.

Enfoque orientados a objetos

La orientacin a objetos puede describirse como el conjunto de disciplinas que


desarrollan y modernizan software que facilitan la construccin de sistemas
complejos a partir de componentes.
El atractivo intuitivo de la orientacin a objetos es que proporciona conceptos y
herramientas con las cuales se modela y representa el mundo real tan fielmente
como sea posible. Estos conceptos y herramientas orientados a objetos son
tecnologas que permiten que los problemas del mundo real sean expresados de
modo fcil y natural.
Las tcnicas orientadas a objetos proporcionan mejoras y metodologas para
construir sistemas de software complejos a partir de unidades de software modula
rizado y reutilizable. Se necesita un nuevo enfoque para construir software en la
actualidad.
Este nuevo enfoque debe ser capaz de manipular tanto sistemas grandes como
pequeos y debe crear sistemas fiables que sean flexibles, sustentable y capaces
de evolucionar para cumplir las necesidades del cambio.
La orientacin a objetos trata de cubrir las necesidades de los usuarios finales, as
como las propias de los desarrolladores de productos software.

Estas tareas se realizan mediante la modelizacin del mundo real. El soporte


fundamental es el modelo objeto.
Un objeto es la instancia de una clase. Una clase es la representacin abstracta
de un concepto en el mundo real, y proporciona la base a partir de la cual creamos
instancias de objetos especficos. Como ejemplo, puede crear una clase que
defina a un cliente. Despus puede crear una nueva instancia de la clase cliente
para tener un objeto utilizable de Cliente. Para poder crear un objeto de la clase
cliente, debe crear una nueva instancia basada en esa clase.
Todos los objetos estn compuestos de tres cosas:

Interfaz: La Interfaz es el conjunto de mtodos, propiedades, eventos y atributos


que se declaran como pblicos en su alcance y que pueden invocar los programas
escritos para usar nuestro objeto.

Implementacin: Al cdigo dentro de los mtodos se le llaman Implementacin.


Algunas veces tambin se le llama comportamiento, ya que este cdigo es el que
efectivamente logra que el objeto haga un trabajo til. Es importante entender que
las aplicaciones del cliente pueden utilizar nuestro objeto aunque cambiemos la
implementacin, siempre que no cambiemos la interfaz. Siempre que se
mantengan sin cambio nuestro nombre de mtodo, su lista de parmetro y el tipo
de datos de devolucin, podremos cambiar la implementacin totalmente.

Estado: El estado o los datos de un objeto es lo que lo hace diferente de otros


objetos de la misma clase. El estado se describe a travs de las variables del
Miembro o de la Instancia. Las variables del miembro son aquellas declaradas, de
tal manera que estn disponibles para todo el cdigo dentro de la clase. Por lo
general, las variables del miembro son Privadas en su alcance. Algunas veces, se
les conoce como variables de la instancia o como atributos. Observe que las
propiedades no son variables del Miembro, ya que son un tipo de mtodo que
funciona para recuperar y establecer valores.
Anlisis

El modelo de anlisis se extiende luego para describir la manera en que


interactan los actores y el sistema para manipular el modelo del dominio de
aplicacin. Los desarrolladores usan el modelo de anlisis, junto con los
requerimientos no funcionales, para preparar la arquitectura del sistema que se
desarrolla durante el diseo de alto nivel.
Las actividades del anlisis: la identificacin de objetos, su comportamiento, sus
relaciones, su clasificacin y su organizacin.
El modelo de anlisis est compuesto por tres modelos individuales: el modelo
funcional, representado por casos de uso y escenarios, el modelo de objetos de
anlisis, representado por diagramas de clase y objeto, y el modelo dinmico,
representado por grficas de estado y diagramas de secuencia.

Conceptos de anlisis

En lugar de considerar el software desde una perspectiva bsica de entrada-


proceso-salida como los mtodos estructurados se basan en modelar el sistema
mediante los objetos que forman parte del y las relacin estticas (herencia y
composicin) o dinmicas (uso entre otros objetos).
Conclusin

Como toda actividad ya sea humana, qumica, fsica tiene un orden para
llevarse a cabo y mucho ms en un proyecto en donde se maneja una
creacin para el beneficio de la sociedad. Ya sea Estructurado que es
donde se hace uso de los DDF y el Orientado a Objetos es el uso de
una portabilidad ms eficiente, un escalamiento y alteracin muy fcil.

Bibliografa
Itlalaguna. (4 de Octubre de 2014). Ingenieria de Software. Obtenido de
http://www.itlalaguna.edu.mx/Academico/Carreras/sistemas/ingsofware1/Unidad1.pdf

Tesoem. (4 de Octubre de 2014). Tesoem. Obtenido de Cuadernillos:


http://www.tesoem.edu.mx/alumnos/cuadernillos/2011.017.pdf

You might also like