Sei sulla pagina 1di 22

REPUBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA EDUCACIN SUPERIOR


I.U.P. "SANTIAGO MARIO"
ESPECIALIDAD: ING. SISTEMAS
SECCIN: SV7

PROFESORA: BACHILLERES:

Roxana Rodrguez Masters Raquel CI: 24.892.876

Belmonte Mara C.I: 26.706.963

Campos Oriana C.I: 26.346.267

Gonzlez Jos C.I: 25.722.315

Mndez Glorinelly C.I: 25.257.267

Barcelona, Octubre de 2017


INDICE
INTRODUCCION ........................................................................................................................................ 3
ENFOQUE ESTRUCTURADO ............................................................................................................... 4
ENFOQUE ORIENTADO A OBJETOS .................................................................................................. 5
ENFOQUE DE APLICACIONES WEB Y UML .................................................................................... 8
DIFERENCIAS ENTRE LOS DISTINTOS ENFOQUES ..................................................................... 10
TIPOS DE MODELOS ........................................................................................................................... 10
Modelo Espiral: ................................................................................................................................ 10
Modelo Cascada: .............................................................................................................................. 12
Cascada con Prototipo...................................................................................................................... 13
Por Incremento ................................................................................................................................. 14
Desarrollo de Software Unificado (USDP): ..................................................................................... 15
Modelo Cluster: ................................................................................................................................ 16
Modelo Grady Booch:...................................................................................................................... 17
BENEFICIOS DE MODELO ................................................................................................................. 18
MAPAS MENTALES ............................................................................................................................ 19
CONCLUSIN ........................................................................................................................................... 21
BIBLIOGRAFIA ........................................................................................................................................ 22
INTRODUCCION
El Enfoque Estructurado se podr denominar como la forma particular de pensar el
software en trminos de funciones de transformacin de datos. El Anlisis Estructurado consiste
en interpretar el concepto del sistema (o situaciones del mundo real) en datos y controlar la
terminologa representada por el DFD (Diagrama de Flujo de Datos), cuyas herramientas
principales ayudan a la comprensin del sistema antes de plasmarlo a cdigo fuente; sin embargo
el enfoque Orientado a Objeto puede ser descrito como el Modelo de Software y desarrollo de
disciplinas que hacen fcil la construccin de sistemas complejos para competencias
individuales.

Las aplicaciones web a aquellas herramientas que los usuarios pueden utilizar accediendo
a un servidor web a travs de Internet o de una intranet mediante un navegador. el Lenguaje
unificado de modelado de sistemas de software ms conocido y utilizado en la actualidad; est
respaldado por el OMG (Object Management Group). Es un lenguaje grfico para visualizar,
especificar, construir y documentar un sistema.
ENFOQUE ESTRUCTURADO
El Enfoque Estructurado se podr denominar como la forma particular de pensar el
software en trminos de funciones de transformacin de datos. El universo de discurso se disocia
en funciones y datos, y cualquier tarea se interpreta como una transformacin de datos. Por
ejemplo al dibujar un circulo en pantalla por medio de las coordenadas, en cual la resolucin de
ello implementa mtodos de software donde se transforma y procesa los datos de entrada para
tener un producto final deseado, es decir hay que tomar en cuenta que la particularidad del
enfoque estructurado consiste en pensar la solucin como una funcin que transforma datos.

El Anlisis Estructurado se hizo popular en la dcada de 1980, representan una


coleccin de tcnicas de anlisis, diseo y programacin que se desarrollaron en respuesta a los
problemas que enfrenta el mundo del software desde 1960. El anlisis consiste en interpretar el
concepto del sistema (o situaciones del mundo real) en datos y controlar la terminologa
representada por el DFD (Diagrama de Flujo de Datos), cuyas herramientas principales ayudan a
la comprensin del sistema antes de plasmarlo a cdigo fuente.

Entonces que es un DFD? se dice que es un diagrama en el que participan procesos


(mtodos), flujo de datos (argumentos) y archivos (base de datos). Pero existen diferentes niveles
dependiendo la complejidad del sistema que se analiza. Bien en cuanto a las desventajas una de
ellas es que una porcin de cdigo en lenguaje estructurado es difcil que pueda servir en otros
proyectos.

Desde finales de la dcada de 1960 varios Mtodos Estructurados surgieron:

La programacin estructurada en alrededor de 1967 con Edsger Dijkstra Ir a la


Declaracin Considerada nociva.

Niklaus Wirth Diseo paso a paso en 1971.

Diagrama Nassi-Shneiderman en 1972

Diagrama Warnier/Orr en 1974 La construccin lgica de los programas.

Anlisis Estructurado y Tcnicas de Diseo (AETD) presentado por primera vez en


1983 desarrollado por la Office of Government Commerce del Reino Unido.
Ingeniera de la Informacin en alrededor de 1990 con Finkelstein y popularizada por
James Martin.

Segn Hay (1999) ingeniera de la informacin era una extensin lgica de las tcnicas
estructuradas que se desarrollaron durante la dcada de 1970. La programacin estructurada
condujo al diseo estructurado, que a su vez condujo a sistemas de anlisis estructurado. Estas
tcnicas se caracterizan por su uso de diagramas: diagramas de estructura para el diseo
estructurado y diagramas de flujo de datos para el anlisis estructurado, tanto para ayudar en la
comunicacin entre usuarios y desarrolladores, y para mejorar el anlisis de la disciplina y del
diseador. Durante la dcada de 1980, comenzaron a aparecer herramientas para el dibujo de los
diagramas automatizados, y llevaron un registro de las cosas dibujadas en un diccionario de
datos. Despus del ejemplo de diseo asistido por computadora y la fabricacin asistida por
computadora (CAD / CAM), el uso de estas herramientas fue nombrada la Herramienta CASE.

ENFOQUE ORIENTADO A OBJETOS


El enfoque Orientado a Objeto puede ser descrito como el Modelo de Software y
desarrollo (Ingeniera) de disciplinas que hacen fcil la construccin de sistemas complejos para
competencias individuales [Khosafian 95].

La propuesta de Orientado a Objeto es que provee mejores conceptos y herramientas con


el cual modela y representa el mundo real tan cercano como le sea posible. Las ventajas en
programacin y modelado de datos son muchas.

La Figura 3.1 ilustra lo anteriormente descrito. Usando tcnicas convencionales, el


cdigo generado para un problema consiste en que primero codifica el problema y luego se
transforma en trminos de un lenguaje computacional Von Neumann. La disciplina Orientada a
Objeto y sus tcnicas manejan la transformacin automticamente, as el volumen del cdigo
codifica el problema y la transformacin es minimizada.

Por lo tanto los conceptos y herramientas Orientadas a Objeto son posibles tecnologas
que permiten a problemas del mundo real ser expresadas ms claramente. Las tecnologas
Orientadas a Objeto proveen mejor metodologa al construir sistemas de software complejos
fuera de mdulos en unidades de software reusable. Con ello se quiere decir que el cdigo o
clases generadas pueden ser utilizados en cualquier otro momento evitndonos as problemas en
la realizacin de sistemas en forma futura.

Existe cierto desacuerdo acerca de las caractersticas precisas que requieren un enfoque
Orientado a Objeto aunque suelen incluirse cuatro aspectos: Identidad, clasificacin,
polimorfismo y herencia [Rumbaugh 96 et. al].

Fundamentos:

Abstraccin: Es el principio de ignorar aquellos aspectos de un fenmeno observado


que no son relevantes, con el objetivo de concentrarse en aquellos que s lo son. Una abstraccin
denota las caractersticas esenciales de un objeto (datos y operaciones), que lo distingue de otras
clases de objetos. Decidir el conjunto correcto de abstracciones de un determinado dominio, es el
problema central del diseo orientado a objetos.

Encapsulamiento: Permite ocultar al mundo exterior la representacin interna del


objeto. Esto quiere decir que el objeto puede ser utilizado, pero los datos esenciales del mismo
no son conocidos fuera de l. La idea central del encapsulamiento es esconder los detalles y
mostrar lo relevante. Permite el ocultamiento de la informacin separando el aspecto
correspondiente a la especificacin de la implementacin; de esta forma, distingue el qu hacer
del cmo hacer. La especificacin es visible al usuario, mientras que la implementacin se le
oculta.

El encapsulamiento en un sistema orientado a objeto se representa en cada clase u objeto,


definiendo sus atributos y mtodos con los siguientes modos de acceso:

Pblico (+): Atributos o Mtodos que son accesibles fuera de la clase. Pueden ser
llamados por cualquier clase, aun si no est relacionada con ella.

Privado (-): Atributos o Mtodos que solo son accesibles dentro de la implementacin
de la clase. Protegido (#): Atributos o Mtodos que son accesibles para la propia clase y sus
clases hijas (subclases).

Modularidad: Es la propiedad que permite tener independencia entre las diferentes


partes de un sistema. Consiste en dividir un programa en mdulos o partes, que pueden ser
compilados separadamente, pero que tienen conexiones con otros mdulos. En un mismo mdulo
se suele colocar clases y objetos que guarden una estrecha relacin. El sentido de modularidad
est muy relacionado con el ocultamiento de informacin

Polimorfismo: Comportamientos diferentes, asociados a objetos distintos, pueden


compartir el mismo nombre, al llamarlos por ese nombre se utilizar el comportamiento
correspondiente al objeto que se est usando.

Herencia: Es el proceso mediante el cual un objeto de una clase adquiere propiedades


definidas en otra clase que lo preceda en una jerarqua de clasificaciones. Permite la definicin
de un nuevo objeto a partir de otros, agregando las diferencias entre ellos (Programacin
Diferencial), evitando repeticin de cdigo y permitiendo la reusabilidad. Las clases heredan los
datos y mtodos de la superclase. Un mtodo heredado puede ser sustituido por uno propio si
ambos tienen el mismo nombre. La herencia puede ser simple (cada clase tiene slo una
superclase) o mltiple (cada clase puede tener asociada varias superclases). La clase Docente y la
clase Estudiante heredan las propiedades de la clase Persona (superclase, herencia simple). La
clase Preparador (subclase) hereda propiedades de la clase Docente y de la clase Estudiante
(herencia mltiple).
Recoleccin de basura: o (garbage collector) es la tcnica por la cual el entorno de
objetos se encarga de destruir automticamente, y por tanto desvincular la memoria asociada, los
objetos que hayan quedado sin ninguna referencia a ellos.

ENFOQUE DE APLICACIONES WEB Y UML


En la ingeniera de software se denomina aplicacin web a aquellas herramientas que los
usuarios pueden utilizar accediendo a un servidor web a travs de Internet o de una intranet
mediante un navegador. En otras palabras, es una aplicacin software que se codifica en un
lenguaje soportado por los navegadores web en la que se confa la ejecucin al navegador.

Las aplicaciones web son populares debido a lo prctico del navegador web como cliente
ligero, a la independencia del sistema operativo, as como a la facilidad para actualizar y
mantener aplicaciones web sin distribuir e instalar software a miles de usuarios potenciales.
Existen aplicaciones como los webmails, wikis, weblogs, tiendas en lnea y la propia Wikipedia
que son ejemplos bastante conocidos de aplicaciones web.

Es importante mencionar que una pgina Web puede contener elementos que permiten una
comunicacin activa entre el usuario y la informacin. Esto permite que el usuario acceda a los
datos de modo interactivo, gracias a que la pgina responder a cada una de sus acciones, como
por ejemplo rellenar y enviar formularios, participar en juegos diversos y acceder a gestores de
base de datos de todo tipo.

UML

Es el Lenguaje unificado de modelado de sistemas de software ms conocido y utilizado en la


actualidad; est respaldado por el OMG (Object Management Group). Es un lenguaje grfico
para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar para
describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos
de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de
programacin, esquemas de bases de datos y compuestos reciclados.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para


describir mtodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el
sistema y para documentar y construir. En otras palabras, es el lenguaje en el que est descrito el
modelo. Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a
una metodologa de desarrollo de software (tal como el Proceso Unificado Racional o RUP),
pero no especifica en s mismo qu metodologa o proceso usar.

UML no puede compararse con la programacin estructurada, pues UML significa


Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad de una
utilizacin en un requerimiento. Mientras que, programacin estructurada, es una forma de
programar como lo es la orientacin a objetos, la programacin orientada a objetos viene siendo
un complemento perfecto de UML, pero no por eso se toma UML slo para lenguajes orientados
a objetos.

UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las
entidades representadas.
DIFERENCIAS ENTRE LOS DISTINTOS ENFOQUES
Estructurado Orientado a Objeto Aplicaciones Web
y UML
Se consideran los elementos o Se consideran los conceptos bsicos como el
perspectivas bsicas del anlisis Objeto y el Atributo, el todo y sus partes
(Entrada-Proceso-Salida), en (software), clases y miembros. Modela los
funcin del Software. objetos que son parte de l.
Une a los usuarios y a los diseadores. Permite
No enfoca apropiadamente el proporcionar una descripcin completa del
diseo de familias de programas. problema, legible y revisable por las partes
Asume una progresin relativa interesadas y verificables contra la realidad.
uniforme de pasos de
elaboracin.
El Diseo inicia an antes de concluir con la
etapa de anlisis. Se recomienda analizar un
poco y disear. Esta etapa debe concluir una
El Diseo inicia una vez que ha vez que se establecieron claves y mecanismos
culminado la fase de anlisis de importantes.
sistema.
Requiere traducir el dominio del
problema en una serie de
funciones y subfunciones. El
analista debe comprender Es una forma de pensar acerca de un problema
primero el dominio del problema en trminos del mundo real en vez de en
y a continuacin documentar las trminos de un ordenador.
funciones y subfunciones que
debe proporcionar el sistema.
Si estn correctamente definidas las jerarquas
de clase, hacer modificaciones no es tan
No acomoda el tipo de desarrollo costoso como en el caso de programacin
evolutivo. No enfoca los posibles tradicional. Slo hay que entrar en la parte de
modos futuros de desarrollo de Evolucin para hacer modificaciones.
software.

TIPOS DE MODELOS
Modelo Espiral: Es un modelo meta del ciclo de vida del software donde el esfuerzo del
desarrollo es iterativo, tan pronto culmina un esfuerzo del desarrollo por ah mismo comienza
otro; adems en cada ejecucin del desarrollo se sigue cuatro pasos principales:

Determinar o fijar los objetivos. En este paso se definen los objetivos especficos para
posteriormente identifica las limitaciones del proceso y del sistema de software, adems se
disea una planificacin detallada de gestin y se identifican los riesgos.
Anlisis del riesgo. En este paso se efecta un anlisis detallado para cada uno de los
riesgos identificados del proyecto, se definen los pasos a seguir para reducir los riesgos y luego
del anlisis de estos riesgos se planean estrategias alternativas.

Desarrollar, verificar y validar. En este tercer paso, despus del anlisis de riesgo, se
eligen un paradigma para el desarrollo del sistema de software y se lo desarrolla.

Planificar. En este ltimo paso es donde el proyecto se revisa y se toma la decisin si se


debe continuar con un ciclo posterior al de la espiral. Si se decide continuar, se desarrollan los
planes para la siguiente fase del proyecto.

Un modelo espiral comienza con la determinacin de los objetivos tanto funcionales


como de rendimiento. Despus se enumeran algunas formas posibles de alcanzar estos objetivos
identificando las fuentes de riesgos posibles. Luego continuamos con el siguiente paso que es
resolver estos riesgos y llevar a cabo las actividades de desarrollo, para finalizar con la
planificacin del siguiente ciclo de la espiral.

Caractersticas:

Es considerado como un modelo evolutivo ya que combina el modelo clsico con el diseo de
prototipos.

Contiene una nueva etapa que es el anlisis de riesgos, no incluida anteriormente.

Este modelo es el indicado para desarrollar software con diferentes versiones actualizadas
como se hace con los programas modernos de PCs.

La ingeniera puede desarrollarse a travs del ciclo de vida clsico o el de construccin de


prototipos.

Este es el enfoque ms realista actualmente.


Modelo Cascada: Es el enfoque metodolgico que ordena rigurosamente las etapas del ciclo
de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalizacin de la
inmediatamente anterior.

De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce


necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costos
del desarrollo.

Fases

Fase de ingeniera y anlisis del sistema. Debido a que el software es siempre parte de
un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del
sistema y luego asignando algn subconjunto de estos requisitos al software.

Fase de anlisis de los requisitos. Se analizan las necesidades de los usuarios finales del
software a desarrollar para determinar qu objetivos debe cubrir. De esta fase surge una memoria
llamada SRD (Documento de Especificacin de Requisitos), que contiene la especificacin
completa de lo que debe hacer el sistema sin entrar en detalles internos. Es importante sealar
que en esta etapa se deben verificar todo lo que se requiere en el sistema y ser aquello lo que
seguir en las siguientes etapas, ya que no se pueden solicitar nuevos requisitos a mitad del
proceso de elaboracin del software.

Fase de diseo. Se descompone y organiza el sistema en elementos que puedan


elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado
surge el SDD (Documento de Diseo del Software), que contiene la descripcin de la estructura
global del sistema y la especificacin de lo que debe hacer cada una de sus partes, as como la
manera en que se combinan unas con otras. Se realizan los algoritmos necesarios para el
cumplimiento de los requerimientos del usuario as como tambin los anlisis necesarios para
saber que herramientas usar en la etapa de Codificacin.
Fase de codificacin. Es la fase de programacin propiamente dicha. Aqu se desarrolla
el cdigo fuente, haciendo uso de prototipos as como pruebas y ensayos para corregir errores.
Dependiendo del lenguaje de programacin y su versin, se crean las libreras y componentes
reutilizables dentro del mismo proyecto para hacer que la programacin sea un proceso mucho
ms rpido.

Fase de pruebas. Los elementos, ya programados, se ensamblan para componer el


sistema y se comprueba que funciona correctamente antes de ser puesto en explotacin. Una vez
que se ha generado el cdigo comienza la prueba del programa. La prueba se centra en la lgica
interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada
definida produce los resultados que realmente se requieren.

Fase de mantenimiento. El software obtenido se pone en produccin. Es una de las fases


finales del proyecto. En el desarrollo surgen cambios, para corregir errores o bien para introducir
mejoras. El software sufre cambios despus de que se entrega al cliente. Los cambios ocurrirn
debidos a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno
externo (sistema operativo o dispositivos perifricos), o debido a que el cliente requiera
ampliaciones funcionales o del rendimiento.

Cascada con Prototipo: permite que todo el sistema, o algunos de sus partes, se
construyan rpidamente para comprender con facilidad y aclarar ciertos aspectos en los que se
aseguren que el desarrollador, el usuario, el cliente estn de acuerdo en lo que se necesita as
como tambin la solucin que se propone para dicha necesidad y de esta forma minimizar el
riesgo y la incertidumbre en el desarrollo, este modelo se encarga del desarrollo de diseos para
que estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones,
es ideal para medir el alcance del producto, pero no se asegura su uso real.

Este modelo principalmente se lo aplica cuando un cliente define un conjunto de


objetivos generales para el software a desarrollarse sin delimitar detalladamente los requisitos de
entrada procesamiento y salida, es decir cuando el responsable no est seguro de la eficacia de un
algoritmo, de la adaptabilidad del sistema o de la forma en que interacta el hombre y la
mquina. Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a
entender de mejor manera cul ser el resultado de la construccin cuando los requisitos estn
satisfechos.

El paradigma de construccin de prototipos tiene tres pasos:

Escuchar al cliente. Recoleccin de requisitos. Se encuentran y definen los objetivos


globales, se identifican los requisitos conocidos y las reas donde es obligatorio ms definicin.

Construir y revisar la maqueta (prototipo).

El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del
software.

Por Incremento: En esta modelo el desarrollo y entrega del sistema se divide en


incrementos, con cada incremento se entrega parte de la funcionalidad requerida en el sistema.
Los Requerimientos de usuarios son priorizados y la prioridad ms alta es incluida en los
primeros incrementos (Figura 2.4).

Una vez comenzado el desarrollo de un incremento, los requerimientos son congelados


de modo que requerimientos para incrementos posteriores puedan continuar evolucionando.

Se evitan proyectos largos y se entrega Algo de valor a los usuarios con cierta
frecuencia, el usuario se involucra ms en el proyecto se evalan y el resultado puede ser muy
positivo.

Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto


esencial (ncleo). Es decir, se afrontan requisitos bsicos, pero muchas funciones suplementarias
(algunas conocidas) quedan sin extraer.
Como resultado de utilizacin y/o de evaluacin, se desarrolla un plan para el incremento
afrontando la modificacin del producto central a fin de cumplir: Las necesidades del cliente, la
entrega de funciones, y caractersticas adicionales. Este proceso se repite siguiendo la entrega de
cada incremento, hasta que se elabore el producto completo.

Desarrollo de Software Unificado (USDP): es un producto del proceso de ingeniera de


software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro
de una organizacin del desarrollo. Su meta es asegurar la produccin del software de alta
calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo
establecidos.

Es conocido tambin como Rational Unified Process (Proceso Unificado Racional), y


define claramente quien, cmo, cundo y qu debe hacerse en el proyecto

Segn Jacobson, I., Booch, G., Rumbaugh J. (1998). El nombre Proceso Unificado se usa
para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora
de los refinamientos existentes. Tambin permite evitar problemas legales ya que Proceso
Unificado Rational o RUP son marcas registradas por IBM (desde su compra de Rational
Software Corporation en 2003).

Fases:

Fase de 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 visin del producto, como se enmarca en
el negocio, el alcance del proyecto. El objetivo en esta etapa es determinar la visin del proyecto.

Fase de Elaboracin: Se realiza el plan de proyecto, donde se completan los casos de


uso y se mitigan los riesgos. Planificar las actividades necesarias y los recursos requeridos,
especificando las caractersticas y el diseo de la arquitectura. En esta etapa el objetivo es
determinar la arquitectura ptima.
Fase de Construccin: Se basa en la elaboracin de un producto totalmente operativo y
en la elaboracin del manual de usuario. Construir el producto, la arquitectura y los planes, hasta
que el producto est listo para ser enviado a la comunidad de usuarios. En esta etapa el objetivo
es llevar a obtener la capacidad operacional inicial.

Etapa de Transicin: El objetivo es llegar a obtener el release del proyecto. Se realiza la


instalacin del producto en el cliente y se procede al entrenamiento de los usuarios. Realizar la
transicin del producto a los usuarios, lo cual incluye: manufactura, envo, entrenamiento,
soporte y mantenimiento del producto, hasta que el cliente quede satisfecho, por tanto en esta
fase suelen ocurrir cambios.

FASES DEL RUP

Modelo Cluster: El modelo cluster es un conjunto de tcnicas multivariantes utilizadas


para clasificar a un conjunto de individuos en grupos homogneos. Pertenece, al igual que otras
tipologas y que el anlisis discriminante al conjunto de tcnicas que tiene por objetivo la
clasificacin de los individuos. La diferencia fundamental entre el anlisis cluster y el
discriminante reside en que en el anlisis cluster los grupos son desconocidos a priori y son
precisamente lo que queremos determinar; mientras que en el anlisis discriminante, los grupos
son conocidos y lo que pretendemos es saber en qu medida las variables disponibles nos
discriminan esos grupos y nos pueden ayudar a clasificar o asignar los individuos en/a los grupos
dados. As pues, el objetivo es obtener clasificaciones (clusterings), teniendo, por lo tanto, el
anlisis un marcado carcter exploratorio. Como puede comprenderse fcilmente el modelo
cluster tiene una extraordinaria importancia en la investigacin cientfica, en cualquier rama del
saber. Tngase presente que la clasificacin es uno de los objetivos fundamentales de la ciencia.
Y en la medida en que el anlisis cluster nos proporciona los medios tcnicos para realizarla, se
nos har imprescindible en cualquier investigacin.
Modelo Grady Booch: tambin llamado diseo orientado a objetos de Grady Booch
(OOD). Provee una forma de desarrollar anlisis y diseo de un sistema orientado a objetos.

La metodologa de Booch es secuencial en el sentido que la fase de anlisis es


completada y posteriormente la fase de diseo tambin. Es cclica en el sentido que cada fase
est compuesta de pasos cclicos ms pequeos. Se enfoca en el anlisis y el diseo y no en la
implementacin o la prueba del resultado de estos.

Define seis tipos de diagramas: clase, objeto, estado de transicin, interaccin, modulo y
proceso.

Diagramas de clases: En este tipo de diagramas se muestran las clases con sus
relaciones, o lo que es lo mismo, la estructura de clases.

El grfico correspondiente a una clase en la notacin de Booch es una especie de nube a


trazos en cuyo interior se escribe el nombre de la misma, separado por una lnea de sus atributos
(estado) y mtodos (comportamiento). Cada clase lleva asociado un nombre que en general debe
ser nico. No se especifican todos los mtodos y atributos siempre, sino solamente aquellos que
son relevantes para la parte del diseo que tratamos de describir.

Diagrama de mdulos: muestra la asignacin de clases y objetos o mdulos en el diseo


fsico de un sistema. Un solo diagrama de mdulos representa una vista de la estructura de
mdulos de un sistema. Los dos elementos esenciales de un diagrama de mdulos son los
mdulos y sus dependencias.

Diagrama de proceso: Es una representacin grfica de los pasos que se siguen en toda
una secuencia de actividades, dentro de un proceso o un procedimiento, identificndolos
mediante smbolos de acuerdo con su naturaleza; incluye, adems, toda la informacin que se
considera necesaria para el anlisis, tal como distancias recorridas, cantidad considerada y
tiempo requerido. Con fines analticos y como ayuda para descubrir y eliminar ineficiencias, es
conveniente clasificar las acciones que tienen lugar durante un proceso dado en cinco
clasificaciones. Estas se conocen bajo los trminos de operaciones, transportes, inspecciones,
retrasos o demoras y almacenajes.
Diagrama de Transicin de Estado (tambin conocido como DTE): enfatiza el
comportamiento dependiente del tiempo del sistema. Este tipo de modelo slo importaba para
una categora de sistemas conocido como sistemas de tiempo-real; como ejemplo de estos
sistemas se tienen el control de procesos, sistemas de conmutacin telefnica, sistemas de
captura de datos de alta velocidad y sistemas de control y mando militares.

Diagramas de interaccin: Muestran una interaccin, que consiste de un conjunto de


objetos y sus relaciones, incluyendo los mensajes que puedan ser realizados entre ellos. Son
importantes para modelar los aspectos dinmicos de un sistema y para construir sistemas
ejecutables a travs de ingeniera hacia adelante e ingeniera inversa.

BENEFICIOS DE MODELO
El objetivo de un proceso de desarrollo es incrementar la calidad del software a travs de
una mayor transparencia y control sobre el proceso. Para obtener calidad en el producto final, es
fundamental producir lo esperado en tiempo y costo estimados. Para tener un proceso de
produccin de software con el menor nmero de fallos, adecuado a las necesidades del cliente y
entregar a tiempo el producto, la produccin de software debe convertirse en un proceso
disciplinado. Es muy importante saber seleccionar un proceso para el desarrollo del sistema ya
que dependiendo del que elija se pueden obtener beneficios como:

Aumentar la velocidad de desarrollo.


Predecir tiempos y costos.
Mejorar la calidad, el control y el seguimiento del sistema.
Minimizar gastos y riesgo.
Mejorar las relaciones con los usuarios.
Definir roles y perfiles.
MAPAS MENTALES

Forma particular de pensar el software en trminos de funciones de transformacin de datos

APLICACIN UML ORIENTADO A OBJETOS


(Lenguaje unificado de modelado)
APLICACIN WEB
Se aplicar en el desarrollo de software gran Provee mejores conceptos y herramientas con
variedad de formas para dar soporte a la Permiten una comunicacin activa entre el usuario y la el cual modela y representa el mundo real tan
metodologa, para detallar los artefactos en el informacin. Esto permite que el usuario acceda a los cercano como le sea posible.
sistema y para documentar y construir. datos de modo interactivo, gracias a que la pgina
responder a cada una de sus acciones
Diagramas Herencia

Formas Abstraccin

Polimorfismo

Pginas
reas de edicin texto
Modularidad
Listas de seleccin

Encapsulamiento

Modelado
Mecanismo servidor Recoleccin de basura
Modelo de desarrollo de software unificado Modelo Espiral

Representacin abstracta de un proceso. Cada modelo


representa un proceso desde una perspectiva particular
y as proporcione informacin parcial sobre el proceso

Modelo Cluster

Pertenece, al igual que otras


tipologas y que el anlisis
Modelo incremento discriminante al conjunto de Modelo Cascada
tcnicas que tiene por
objetivo la clasificacin de los
individuos.
Modelo Grady Booch

Provee una forma de desarrollar anlisis y diseo de un


sistema orientado a objetos.
. Es cclica en el sentido que cada fase est compuesta de
pasos cclicos ms pequeos. Se enfoca en el anlisis y el
diseo y no en la implementacin o la prueba del
resultado de estos.
Clase
Tipos de diagramas:
Objeto
Estado de Transicin
Interaccin
Modulo
Proceso
CONCLUSIN
Un DFD se dice que es un diagrama en el que participan procesos (mtodos), flujo de
datos (argumentos) y archivos (base de datos). Pero existen diferentes niveles dependiendo la
complejidad del sistema que se analiza. Bien en cuanto a las desventajas una de ellas es que una
porcin de cdigo en lenguaje estructurado es difcil que pueda servir en otros proyectos. Desde
el punto de vista de sencillo mecanismo de resumen el anlisis estructurado crea una jerarqua
que emplea un nico mecanismo de resumen. El mtodo de anlisis estructurado puede emplear
IDEF, el cual es un proceso conducido, y comienza con un propsito y un punto de vista. Los
conceptos y herramientas Orientadas a Objeto son posibles tecnologas que permiten a problemas
del mundo real ser expresadas ms claramente. Las tecnologas Orientadas a Objeto proveen
mejor metodologa al construir sistemas de software complejos fuera de mdulos en unidades de
software reusable.

Una pgina Web puede contener elementos que permiten una comunicacin activa entre
el usuario y la informacin. Esto permite que el usuario acceda a los datos de modo interactivo,
gracias a que la pgina responder a cada una de sus acciones.
BIBLIOGRAFIA
Luciano, Jess. (2011). Paradigmas de La Ingeniera Del Software. (Disponible en:
https://www.scribd.com/document/54981594/Ensayo-3-1-Paradigmas-de-La-Ingeneria-Del-
Software. Consultado el 14 de octubre de 2017).

Sanoja, Leonard. (2012). Fundamentos Del Enfoque Orientado a Objetos. (Disponible


en: https://www.scribd.com/doc/95537114/Fundamentos-Del-Enfoque-Orientado-a-Objetos.
Consultado el 14 de octubre de 2017).

Fario, Galo. Modelo Espiral de un proyecto de desarrollo de software. (Disponible en:


http://www.ojovisual.net/galofarino/modeloespiral.pdf. Consultado el 13 de octubre de 2017).

Potrebbero piacerti anche