Embed Size (px)
DESCRIPTION
metologias
Citation preview
UNIVERSIDAD DE IXTLAHUACA CUIINCORPORADA A LA UAEM
INGENIERÍA EN COMPUTACIÓN.Materia:
Análisis de SistemasTema:
Metodologías estructurada y Orientada a objetos
Presenta:Empresa Making Great Systems
INTEC Semestre: 8° Grupo: “A”
Ixtlahuaca México a 16 de Febrero de 2015
Metodología clásica o
estructurada
Definición
Es la primera aproximación al problema. Está orientada a procesos, es
decir, se centra en especificar y descomponer la funcionalidad del
sistema.
Define totalmente el sistema en términos de funciones, estableciendo los
datos de E/S correspondientes
Herramientas de modelado
Diagramas de flujo de datos
Representan la forma en la que los datos se mueven y se transforman. Incluye:
–Procesos
–Flujos de datos
–Almacenes de datos
Diagramas entidad-relación
Herramienta para el modelado de datos que permite
representar las entidades relevantes de un sistema de
información así como sus interrelaciones y propiedades.
Carta estructurada
Es también conocida como el modelo de producto.
Es una metodología de análisis y diseño de
sistemas.
Lo que muestra es un mapa de diseño de arriba
hacia abajo (top-down) de tipo jerárquico en el que
se asienta cómo será programado el proyecto,
construido, integrado y probado.
Metodologías de evaluación de
proyectos(P.E.)
Método Gane y Sarson
Método estructurado del análisis de sistemas desarrollado por Chris Gane y
Trish Sarson. Se empezó a desarrollar en 1977 con el objetivo de facilitar y
agilizar el desarrollo de grandes proyectos. Esta metodología se utilizo para
implementar diagramas de flujo de datos, con las cuales poder realizar
representaciones graficas que muestren información acerca del
funcionamiento de un sistema (Microsoft Visio). Esta metodología no se
sabe si pertenece al campo de la tecnología o al campo de las
herramientas, su mayor apogeo fue en la década de los 80.
Fases
Construcción del modelo lógico actual: Desarrollo de una representación que muestra los objetos del mundo real y como se relacionan estos (modelo conceptual) orientando al método de Gane y Sarson.
Construcción el modelo del nuevo sistema: Desarrollo de la especificación y de un modelo lógico, así como la descripción de los contenedores de los datos.
Selección el modelo lógico: Una representación del funcionamiento de la empresa que conecta los resultados obtenidos con los procesos del programa y los casos teóricos planteados para el desarrollo de este modelo.
Creación del nuevo modelo físico: Descripción de la manera de almacenamiento de la información así como los dispositivos físicos donde se almacenara y los métodos de acceso a la información.
Empaquetado de la especificación: Se crea un contenedor de información que contiene los modelos y diseños creados en las fases anteriores así como el resultado del análisis.
Metodología De Marco:Consta de los pasos siguientes pasos:
• Estudio del entorno físico actual: modelo del sistema actual con sus procedimientos. A través de un conjunto de DFD
• Derivación del correspondiente modelo lógico actual: modelo derivado del anterior sin connotación física.
• Derivación del nuevo modelo lógico: tomar en cuenta las nuevas necesidades. Formado por un DFD, diccionario de datos y especificaciones de proceso del sistema.
• Crear un conjunto de modelos físicos alternativos: del modelo lógico se establecen alternativas se enoje el más conveniente.
• Valorar cada opción: costos y beneficios de los modelos físicos.
• Seleccionar una opción: selecciona modelo físico
• Empaquetar la especificación: se recopila toda la documentación.
MODELO JACKSON
• Se basa en el principio de que la base inicial del diseño del
programa son los datos del problema y no los requisitos
funcionales exigidos.
• Permite una mayor objetividad.
• Partir de una buena especificación del problema que
queremos resolver: datos de entrada, datos de salida y
algoritmos aplicables.
• Una vez obtenida una estructura objetiva del problema,
que constituye un reflejo del mundo real con el que trata el
programa, resulta más fácil asignar las distintas funciones a
realizar
• Formar las estructuras de datos de salida (estructura lógica de salida) y de
entrada (estructura lógica de entrada) a partir de los datos del problema.
• Determinar las correspondencias (o los elementos comunes) entre ambas
estructuras de datos.
• En función de las correspondencias obtener una estructura única para el
programa, que puede traducirse fácilmente a un diagrama de flujo de
control.
• Asignar a la estructura del programa las operaciones ejecutables de
programa derivadas de las especificaciones funcionales
• Traducir el conjunto estructura-operaciones a un formato de pseudocódigo
(lógica esquemática) cuya codificación resulta bastante sencilla.
Las estructuras de datos de entrada y salida y la estructura
del programa se documentan mediante Diagramas de
Estructura de Jackson
MODELO JACKSON
Metodología de diseño
estructurado de Yourdon
Esta metodología proporciona una manera para
diseñar paso a paso sistemas y programas
detallados.
Cabe mencionar que unos pasos
involucran el análisis
otros el desarrollo del diseño
otros más la medición y la mejora de la calidad
del diseño.
La principal herramienta generada en el diseño estructurado es el “diagrama de
estructura” donde muestra los componentes de procedimientos del programa, su
ordenación jerárquica y los datos conectados a ellos
El diagrama de estructura es un diagrama de árbol o jerárquico que, en términos
generales, define la arquitectura global de un programa que muestra los procedimientos y
sus interrelaciones. En dicho diagrama se utilizan bloques básicos, como son cajas que
representan los componentes de procedimientos y las flechas que muestran como se
conectan.
1.-Trazar el diagrama de flujo de datos
El objetivo es representar el problema de diseño como el flujo de datos
a través de un sistema. Un sistema se compone de procesos que
transforman a los datos. Estos procesos y los datos que los enlazan
forman los cimientos para definir los componentes del programa.
2.-Trazar el diagrama de estructura
En este punto se desea representar el diseño del programa como una
jerarquía de componentes de procedimiento. El diagrama de
estructura se deriva del diagrama de flujo de datos obtenido
previamente. El diseño estructurado proporciona dos estrategias de
diseño para guiar la transformación respectiva, las cuales son: los
análisis de transformación y los análisis de transacción. Estas dos
estrategias nos ayudan a dirigir el diseño jerárquico, así como un
proceso paso a paso de transformación por cada estrategia.
Análisis de transformación
Este modelo de flujo de información divide al diagrama de flujo de
datos (DFD) en tres partes: la entrada que recibe el nombre de rama aferente el proceso
lógico llamado transformación central y la salida denominada rama diferente.
Análisis de transacción
Este modelo se utiliza cuando se diseñan programas con proceso de
transacciones. El diagrama de estructura general para un programa
con procesos de transacciones se representa en la parte superior por
el módulo de la transacción central y en la parte inferior hay varios
módulos de transacciones para cada tipo distinto de transacción.
3.-Evaluación del diseño
En este punto la medición de la calidad de diseño es
fundamental,
para ello se utilizan dos técnicas ya conocidas, como son el
acoplamiento y la cohesión.
El acoplamiento mide el grado de independencia entre
los componentes de los procedimientos (módulos) en el
diagrama de estructura.
La cohesión mide la fuerza de las relaciones entre los
elementos dentro de un módulo.
4.-Preparación del diseño para la
implantación
Esta parte también es conocida como empaquetar el diseño.
Empaquetar es es el proceso de dividir el diseño del programa lógico en
unidades físicas de implantación llamadas unidades de carga. De hecho
es un diseño físico del programa.
El MOO es la construcción de modelos de un sistema por medio de la identificación
y especificación de un conjunto de objetos relacionados, que se comportan y colaboran
entre si de acuerdo a los requerimientos establecidos por el sistema de objetos.
FORMA DE DESCRIBIR EL MOO:
Diagrama de clases
Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran
el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.
Un diagrama de clases esta compuesto por los siguientes elementos:
Clase: atributos, métodos y visibilidad.
Relaciones: Herencia, Composición, Agregación, Asociación y Uso.
En UML, una clase es representada por un rectángulo que posee tres divisiones:
Ejemplo:
Una Cuenta Corriente que posee como característica:
Balance
Puede realizar las operaciones de:
Depositar
Girar
y Balance
El diseño asociado es:
Atributos y métodos
Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de
ellos con el entorno, estos son:
public (+,): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.
private (-,): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar).
protected (#,): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de
la clase además de las subclases que se deriven (ver herencia).
Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las
características:
public (+,): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.
private (-,): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden
accesar).
protected (#,): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de
la clase además de métodos de las subclases que se deriven (ver herencia).
Relaciones entre clases
En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser:
Uno o muchos: 1..* (1..n)
0 o muchos: 0..* (0..n)
Número fijo: m (m denota el número).
Herencia (Especialización/Generalización):
Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected), ejemplo:
Agregación:
Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los
lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer
objetos que son instancias de clases definidas por el desarrollador de la aplicación,
tenemos dos posibilidades:
Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido
esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es
comunmente llamada Composición (el Objeto base se contruye a partir del objeto
incluido, es decir, es "parte/todo").
Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto
incluido es independiente del que lo incluye. Este tipo de relación es comunmente
llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).
Un Ejemplo es el siguiente:
Asociación:
La relación entre clases conocida como Asociación, permite asociar objetos que
colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de
vida de un objeto no depende del otro.
Ejemplo:
Dependencia o Instanciación (uso):
Representa un tipo de relación muy particular, en la que una clase es instanciada (su
instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.
El uso más particular de este tipo de relación es para denotar la dependencia que tiene
una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana
(la creación del Objeto Ventana esta condicionado a la instanciación proveniente
desde el objeto aplicación):
Diagrama de casos de uso
El diagrama de casos de uso representa la forma en como un Cliente
(Actor) opera con el sistema en desarrollo, además de la forma, tipo y
orden en como los elementos interactúan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
Actor.
Casos de Uso.
Relaciones de Uso, Herencia y Comunicación.
Actor:
Una definición previa, es que un Actor es un rol que un usuario juega con respecto al
sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un
Actor no necesariamente representa a una persona en particular, sino más bien la labor
que realiza frente al sistema.
Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el
rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por
el Jefe de Local.
Caso de Uso:
Es una operación/tarea específica que se realiza tras una orden de algún agente externo,
sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.
relaciones
Asociación
Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.
Dependencia o Instanciación
Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.
Generalización
Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).
Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).
extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).
uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.
De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.
RDD(diseño responsabilidad
impulsado)
Técnica de diseño en la POO
Propuesto por Rebecca Wirsfs-Brock
Análisis orientado a objetos y
diseño(OOAD)
Enfoque técnico para realizar, diseñar una
aplicación, sistema o negocio mediante la aplicación
del paradigma orientada a objetos.
OMT(técnica objeto de modelado )
Objeto de lenguaje de modelado de software y diseño.
Principales modelos.
1. Objeto
2. Dinámico.
3. Funcional.
OOSE ()
Técnica de diseño de software utilizada en la
programación orientada a objetos.
Desarrollada en 19992 por Ivan Jacobson.
Emplea casos de uso en el diseño de software.
Análisis del Sistema Orientado a
Objetos
“Es un método de análisis que examina los
requisitos desde la perspectiva de las clases y
objetos que se encuentran en el vocabulario
del dominio del problema”
Documentos básicos de análisis orientado a
objetos
Documentos de análisis
Especificación de requisitos o requerimientos
Diagramas de casos de uso
Escenarios y subescenarios
Prototipos y su evaluación
Proceso de Desarrollo del Sistema
Orientado a objetos
Se va a seguir el método de desarrollo orientado a objetos que propone
Craig Larman [Larman99]. Define una serie de actividades que pueden
realizarse en cada fase, las cuales deben adaptarse según las condiciones
del proyecto que se esté llevando a cabo.
Proceso de Desarrollo
Enfoque ICONIX
Modelado de objetos conducido por casos de uso.
Centrado en datos: se descompone en fronteras de datos.
Basado en escenarios que descomponen los casos de uso.
Enfoque iterativo e incremental.
Ofrece trazabilidad.
Uso directo de UML(estándar del Object
Management Group)
DIAGRAMA DE
COLABORACIÓN
Que es
Un diagrama de colaboración es una forma de
representar interacción entre objetos .
En que consiste
Muestra cómo las instancias específicas de las clases trabajan
juntas para conseguir un objetivo común.
Consiste especificar un contrato entre objetos
Implementa las asociaciones del diagrama de clases
mediante el paso de mensajes de un objeto a otro. Dicha
implementación es llamada "enlace"
Un Diagrama de Colaboración muestra una interacción organizada basándose en los objetos que toman parte en la interacción y los enlaces entre los mismos (en cuanto a la interacción se refiere).
UML –Interacciones
Los objetos interactúan entre sí pasándose mensajes.
Los objetos se conectan a través de enlaces.
Mensaje: especifica transmisión de información entre objetos.
Enlace: especifica un camino a lo largo del cual un objeto puede enviar un mensaje a otro objeto.
Es una conexión semántica entre objetos.
Es una instancia de una relación.
Puede contener los adornos de la relación.
Las Interacciones modelan aspectos
dinámicos del sistema
Llamada.-Invoca una operación sobre un objeto. Puede ser a sí mismo.
Retorno.-El receptor de una llamada devuelve un valor al emisor, si es necesario.
Envío.- Envía una señal a un objeto.
Creación.- Para crear un objeto.
Destrucción.- Para destruir un objeto. Puede destruirse a sí mismo.
Secuenciación● El flujo de mensajes forma una secuencia.
● La secuencia es indicada por un número antes del mensaje y una flecha dirigida.
● Para modelar caminos alternativos, se coloca el mismo número de secuencia seguido de un número de subsecuencia.
Secuenciación
Parámetros . Reales Se pueden modelar los parámetros reales
enviados y también los retornos. Ej: 1.2.1: x:=operación(‘m’)
Ejemplo
Definición del problema
PROPUESTA DE SOLUCIÓN
Respecto a la solución se cuenta con la fórmula general para resolver una ecuación de segundo
grado la cual es:
En donde la formula según sea se suma o se resta, por lo cual obtendremos dos resultados que serán:
Raiz1 y
Raiz2
Recurrimos a esta forma de dar solución por los elementos con los que cuenta nuestra ecuación, pues usando
esta fórmula obtendremos los resultados que buscamos (Raíz 1 y Raíz 2), además de ser una formula sencilla a la
hora de adecuarla en el programa en el que se planea implementar, buscando que este maneje todos y cada uno
de los términos que componen la ecuación y a partir de las operaciones que realice entre estos, arroje dos
resultados correctos que serán: Raiz1 y Raiz2.
Análisis
Elementos de los objetos de estudio
Atributos del quien:
Coeficiente del término cuadrático (a)
Coeficiente del término lineal (b).-
•Si es menor que los resultados de X serán dos valores con parte real y parte imaginaria. Es
decir, el resultado séra un número complejo.
•Si es mayor que obtendremos dos valores distintos de X reales.
•Si es igual que obtendremos dos valores de X reales e iguales.
Coeficiente del término independiente (c)
Raiz1.- primer resultado de la formula general
Raiz2.- segundo resultado de la formula general
METODOS REQUERIDOS PARA LA OBTENCION DE RESULTADOS
-METODOS PARA COLOCAR VALORES
Método colocar_a(co_cudratico:real)
método colocar_b(co_lineal:real)
método colocar_c(co_inde:real)
método colocar_raiz1(raiz_1:real)
método colocar_raiz2(raiz_2:real)
- METODOS PARA OBTENER VALORES DESDE LOS ELEMENTOS
DEL OBJETO DE ESTUDIO
método obtener_a:real
método obtener_b:real
método obtener_c:real
método obtener_raiz1:real
método obtener_raiz2:real
-Métodos requeridos para realizar operaciones
método caldular__raiz1
método calcular_raiz2
Formato de Salida
La información que se va a obtener son los resultado de las dos raíces una con coeficiente positivo
y otra con coeficiente negativo.
Diagrama de clases
Diagrama de secuencia
Pseudocodigo
Clase ecuación
inicio
ATRIBUTOS
a:real
b:real
c:real
raiz1:real
raiz2:real
METODOS
Método colocar_a(co_cudratico:real)
inicio
a←co_cuadratico
fin colocar_a
método colocar_b(co_lineal:real)
inicio
b←co_lineal
fin colocar_b
método colocar_c(co_inde:real)
inicio
c←co_lineal
fin colocar_c
método colocar_raiz1(raiz_1:real)
inicio
raiz1←raiz_1
fin colocar_raiz1
método colocar_raiz2(raiz_2:real)
inicio
raiz2←raiz_2
fin colocar_raiz2
método obtener_a:real
inicio
Regresa a
fin obtener_a
método obtener_b:real
inicio
Regresa b
fin obtener_b
método obtener_c:real
inicio
Regresa c
fin obtener_c
método obtener_raiz1:real
inicio
Regresa raiz1
fin obtener_raiz1
método obtener_raiz2:real
inicio
Regresa raiz2
fin obtener_raiz
método caldular__raiz1
inicio
raiz1←a
fin obtener_a
método calcular_raiz2
inicio
raiz1← 𝑎
fin obtener_a
Fin clase ecuación
Pseudocodigo
clase cl_vista
Método enviar_mansaje
Inicio
Escribir mensaje
Fin método enviar_mensaje
Método recibri_mensaje:real
Inicio
Lee(dato_entrada)
Fin método recibri_mensaje
Fin clase cl_vista
Método obtener_dato_entrada:real
x← regresar dato_entrada
Fin método obtener_dato_entada
Clase re_ecuacion
Variables
RA1:REAL
RA2:REAL
Ve_dato:variable
Comienza
Método principal
inicio
vista=nuevo objeto de cl_vista
vista.colocar_mensaje(“ingresa el termino cuadratico”)
vista.enviar_mensaje
vista.recibir_mensaje
Ve_dato←vista.obtener_dato_entrada
Resolver_ecu=nuevo objeto de cl_ecuacion
Resolver_ecu. colocar_a(ve_dato)
vista.colocar_mensaje(“ingresa el termino lineal”)
vista.enviar_mensaje
vista.recibir_mensaje
Ve_dato←vista.obtener_dato_entrada
Resolver_ecu. colocar_b(ve_dato)
vista.colocar_mensaje(“ingresa el termino independiente”)
vista.enviar_mensaje
vista.recibir_mensaje
Ve_dato←vista.obtener_dato_entrada
Bibliografía
http://aputsc.bligoo.com.mx/content/view/795496/Metodologia-
Estructurada.html#.VOJ8o-Eof2s
https://sites.google.com/site/aessl18g3/practica-2/metodologia-2/1-1---
descripcion-caracteristicas-y-fases
http://85517amdsi.blogspot.mx/2010/08/metodologias-estructuradas.html
http://mundoinformatico321.blogspot.mx/2013/01/carta-estructurada.html
http://eii.ucv.cl/pers/gbustos/PDF/Evalua.PDF
http://users.dcc.uchile.cl/~psalinas/uml/casosuso.html
http://users.dcc.uchile.cl/~psalinas/uml/modelo.html
