SlideShare una empresa de Scribd logo
•   RAMOS CHAVEZ Marco
•   PAZCE LAZO Michael
•   SANCHEZ ALANYA Jose L.
•   ZACARIAS MUNGUIA Valeria
•   HIDALGO HINOJOSA Nilton
Enfoque estructurado y Enfoque OO  - Ingenieria de software
El modelado de procesos, así como
su nombre lo indica, tiene 2 aspectos
que lo definen: el modelado y los           EJEMPLO:
procesos.      Frecuentemente,
sistemas, conjuntos de procesos y
                                   los
                                            La reingeniería de
subprocesos integrados en una                procesos de
organización.
                                             negocios, la cual se
Un modelo es una representación de
una realidad compleja. Modelar es            encarga del rediseño
desarrollar una descripción lo más           de los procesos de
exacta posible de un sistema y de las
actividades llevadas a cabo en él.           negocios de las
Cuando un proceso es modelado, con           organizaciones con el
ayuda de una representación gráfica
(diagrama de proceso), pueden
                                             fin de hacerlos más
apreciarse     con     facilidad   las       eficientes.
interrelaciones    existentes    entre
distintas actividades, analizar cada
actividad, definir los puntos de
contacto con otros procesos, así
como identificar los subprocesos
comprendidos.
Representación
   Es la manera en que se
    representa la forma en
    que los datos cambian
    conforme se mueven a         Las transformaciones
    través del sistema.            que se aplican a los
                                  datos son funciones
                                  que debe realizar un
                                            programa.




        DESCRIPCIÓN
                             REPRESENTACIÓN
El Análisis se refiere al “extremo inicial”
de un proyecto de desarrollo de
sistemas, durante el tiempo en que los
requisitos del usuario son definidos y
documentados.
   El análisis de requisitos es el proceso de
    estudio de las necesidades de los usuarios
    para llegar a una definición de los requisitos
    del sistema de hardware o de software; así
    como su estudio y refinamiento.
   Tras haber estudiado las posibilidades con las
    que se cuenta para el desarrollo del
    sistema, así como sus limitaciones, se puede
    establecer una lista más firme de
    requisitos, tanto a nivel funcional como no
    funcional.
   El software se construye para procesar datos,
    para transformarlos es decir, para aceptar datos
    de entrada, manipularlos y producir información
    de salida. Pero el software también procesa
    acontecimientos, que controlan al sistema y no
    es más que un dato binario, tal como un sensor
    que envía al software una señal de alarma.
   Por tanto, los datos ( números, caracteres,
    imágenes, sonidos, etc. ) y el control (
    acontecimientos ) son parte del dominio de la
    información.
   1. Contenido de la Información



   2. Flujo de la Información



   3. Estructura de la Información
   El modelo de análisis debe cumplir tres
    objetivos primarios:
      1: Describe lo que requiere el cliente
      2: Establecer una base para la creación de
    un diseño de software
      3: Definir un conjunto de requisitos que
    puedan validarse una vez construido el
    software
   Es un esquema teórico de un sistema o realidad
    compleja que se elabora para facilitar su
    comprensión y estudio.
   Es una representación de los aspectos esenciales
    de una realidad compleja de acuerdo a un criterio
   Todo modelo es necesariamente una
    simplificación de la realidad
   ¿Por qué modelar?
    Para facilitar el estudio y analizar el
    comportamiento de un SI(sistema de
    información), y sus componentes
    Para rediseñar un SI, tal que satisfaga nuevos
    objetivos y requerimientos de gestión
   Las entidades son los objetos principales
    sobre los que se debe recoger información y
    generalmente denotan
    personas, lugares, cosas o eventos de interés.
    Las entidades aparecen reflejadas en el
    enunciado habitualmente como nombres.
    Gráficamente se simbolizan con un
    rectángulo.
   Los atributos se utilizan para detallar las entidades
    asignándoles propiedades descriptivas tales como
    nombre, color y peso. No solo es posible especificar
    atributos en las entidades sino también en las
    relaciones. Los atributos también aparecen reflejados
    en el enunciado, generalmente, como nombres.
   Las entidades pueden clasificarse por la fuerza de sus
    atributos identificadores, es decir, por su
    dependencia o no dependencia respecto a otras
    entidades. Las entidades fuertes tienen existencia
    propia, es decir, poseen identificadores internos que
    determinan de manera única la existencia de sus
    ocurrencias. Las entidades débiles pueden tienen
    existencia en la base de datos dependiendo de una
    entidad fuerte. Gráficamente los atributos se
    simbolizan con una elipse.
   Las relaciones representan asociaciones en el
    mundo real entre una o más entidades. Las
    relaciones se caracterizan por su nombre, el
    grado (número de entidades que participan
    en la relación), el tipo de cardinalidad
    (número máximo de ejemplares de una
    entidad asociados a una combinación de
    ejemplares de las otras entidades de la
    relación, que pueden ser 1 ó N). Gráficamente
    las relaciones se simbolizan con un rombo.
En este modelo se presenta la vista unificada de los
datos, centrándose en la estructura lógica y abstracta
de los datos, como representación del mundo real, con
independencia de consideraciones del mundo físico.
 Un modelo Entidad-Relación tiene los siguientes
  elementos:
 Entidad es “una
  persona, lugar, cosa, concepto, suceso, real o
  abstracto de interés para la empresa”. Es aquel objeto
  acerca del cual queremos almacenar información en
  la base de datos.
 Interrelación se define como la asociación o
  correspondencia entre entidades.
 Atributos
   • El modelo funcional describe los
    comportamientos y operaciones de los objetos.
   • El modelo funcional muestra la dependencia de
    datos en el sistema.
   • El modelo funcional describe la computación
    dentro del sistema, cómo los valores de salida se
   derivan de los valores de entrada, sin importar el
    orden en que son computados.
   • El modelo funcional consiste de múltiples
    diagramas de flujo de datos.
   El diagrama de flujo de datos ( DFD ) es una
    técnica gráfica que representa el flujo de la
    información y las transformaciones que se
    aplican a los datos al moverse desde la
    entrada a la salida.

   La notación básica para construir DFD’s es la
    siguiente:
   Un rectangulo representa a un elemento del
    sistema ( por ejemplo un hardware, una
    persona, un programa ) o un sistema que
    produce o recibe información que es
    transformada por el software.

   Un circulo representa un proceso o
    transformación que se aplica a los datos y los
    cambia de alguna forma.
   La flecha representa a un elemento o una
    colección de elementos de datos.




   Representa información almacenada y que
    utiliza el software.
   El diagrama de transición de estados DTE
    representa el comportamiento de un sistema
    que muestra los estados y los sucesos que
    hacen que el sistema cambie de estado.
   Un estado es un modo observable de
    comportamiento, por ejemplo
    monitoreando, comprobando, calculando, etc
    . Cada estado representa un modo de
    comportamiento y el DTE indica cómo se
    mueve el sistema de un estado a otro.
   Un Diccionario de Datos es una lista con
    todos los detalles y descripciones de los
    elementos incluidos en los Diagramas de
    Flujo de Datos que describen al sistema.
   1. Descripción   de los almacenamientos de
    datos
   2. Descripción   de   los procesos
   3. Descripción   de   las estructuras de datos
   4. Descripción   de   los elementos de datos
   5. Descripción   de   los flujos de datos
CONCEPTOS:
   Definición:
    ◦ La representación de las características esenciales de
      algo sin incluir antecedentes o detalles irrelevantes
      [Graham, 1994]
   Ventajas:
    ◦ Define y refuerza las restricciones de acceso
    ◦ Facilita el mantenimiento y la evolución de los sistemas
      software
    ◦ Reduce los efectos laterales
    ◦ Limita el impacto global de las decisiones de diseño
      locales
    ◦ Favorece la encapsulación, uno de los elementos de un
      buen diseño
    ◦ Descripción de una función de un programa en el nivel
      de detalle adecuado
    ◦ Cada paso en el proceso del software es un refinamiento
      del nivel de abstracción de la solución software
      (abstracciones funcionales y abstracciones de datos)
    ◦ Refinamiento y modularidad son conceptos cercanos al
      concepto de abstracción
   Similitud con el procedimiento de partición y
    refinamiento del análisis de requisitos
    ◦ La diferencia está en el nivel de detalle, no en el enfoque
   El refinamiento es un procedimiento de elaboración
    ◦ Función descrita a un nivel conceptual
    ◦ Refinamientos sucesivos que incorporan más detalles
   Gestiona la complejidad dividiendo problemas grandes
    en problemas pequeños
    ◦ Permite que personas diferentes puedan trabajar con cada parte
    ◦ Permite la especialización de los ingenieros del software
    ◦ Cada componente individual es más pequeño y, por tanto, su
      comprensión es más sencilla
    ◦ Las partes se pueden remplazar o cambiar sin tener que
      remplazar o cambiar de forma generalizada el resto de las
      partes
   Propiedad de un sistema que ha sido
    descompuesto en un conjunto de módulos
    coherentes e independientes
   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 proveedor.
MODULARIDAD
La modularidad del
software facilita el
desarrollo del
mismo, pero hasta
un cierto
límite, porque si
llegáramos a dividir
el problema en
infinitos
módulos, los
módulos tendrían
una complejidad y
un esfuerzo mucho
menor, pero crecería
el coste asociado a
la creación de
interfaces entre los
módulos,
   La arquitectura del software alude a la
    “estructura global del SW y a las formas en
    que la estructura proporciona la integridad
    conceptual de un sistema”
   La arquitectura del SW es la estructura
    jerárquica de los componentes del programa
    (módulos), la manera en que los
    componentes interactúan y la estructura de
    datos que van a utilizar los componentes.
Enfoque estructurado y Enfoque OO  - Ingenieria de software
   La jerarquía de control, denominada también
    “estructura del programa”, representa la
    organización de los componentes del
    programa (módulos) e implica una jerarquía
    de control.
   No representa los aspectos procedimentales
    del software, ni se puede aplicar
    necesariamente a todos los estilos
    arquitectónicos.
Enfoque estructurado y Enfoque OO  - Ingenieria de software
   La estructura de un programa debe partirse
    horizontal y verticalmente
   La partición horizontal define ramas separadas de la
    jerarquía modular para cada función principal del
    programa
    ◦ Módulos de control
    ◦ Enfoque entrada/proceso/salida
   Beneficios de la partición horizontal
    ◦   Proporciona software más fácil de probar
    ◦   Lleva a un software más fácil de mantener
    ◦   Propaga menos efectos secundarios
    ◦   Proporciona software más fácil de ampliar
   Puntos en contra de la partición horizontal
    ◦ Aumenta la comunicación entre módulos, pudiendo
      complicar el control global del flujo del programa
   Partición vertical o descomposición en factores
    (factoring)
   La partición vertical expresa que el control, toma
    de decisiones, y el trabajo se distribuyan de forma
    descendente en la arquitectura del programa
   Los módulos de nivel superior deben realizar
    funciones de control y poco trabajo de
    procesamiento
   Los módulos que residen en la parte baja de la
    arquitectura deben de ser los que realicen las
    tareas de entrada, cálculo y salida
Enfoque estructurado y Enfoque OO  - Ingenieria de software
Enfoque estructurado y Enfoque OO  - Ingenieria de software
   La estructura de datos e una representación
    de la relación lógica entre elementos
    individuales de datos .
   Como la estructura de la información afectara
    invariablemente al diseño procedimental
    final, la estructura de datos es tan importante
    como la estructura de programa para la
    representación de la arquitectura de software
   La estructura del programa define la jerarquía de
    control sin tener en consideración la secuencia
    de proceso y de decisiones.
   El procedimiento de software se centra en el
    procesamiento de cada modulo individualmente.
   El procedimiento debe proporcionar una
    especificación precisa de
    procesamiento, incluyendo la secuencia de
    sucesos , los puntos de decisión exactos, las
    operaciones repetitivas e incluso la estructura
    , organizándole datos.
   “Los módulos de un sistema deben diseñarse
    de modo que la información contenida en
    ellos sea inaccesible a todos aquellos
    módulos que no necesiten tal información”
    David Parnas, 1970
    ◦ Los módulos deberán especificarse y diseñarse de
      manera que la información (procedimientos y datos)
      que está dentro de un módulo sea inaccesible a
      otros módulos que no necesiten esa información
   El ocultamiento de la información es un buen
    medio para conseguir abstracción
   Restricciones de acceso
    ◦ Detalle procedimental dentro del módulo
    ◦ Estructura de datos local empleada por el módulo
   El diseñador de cada módulo debe
    seleccionar un subconjunto de las
    propiedades del módulo como información
    oficial del módulo, para ponerlas a
    disposición de los autores de módulos o de
    módulos clientes
   Las decisiones de diseño sujetas a cambio deben
    ocultarse detrás de interfaces abstractas
    ◦ Las aplicaciones software han de comunicarse
      únicamente a través de interfaces bien definidas
    ◦ La interfaz de un módulo debe revelar lo menos posible
      de su funcionamiento interno
    ◦ Intercambio de módulos mientras que se mantengan
      intactas las interfaces
    ◦ Ventajas a la hora de hacer cambios
   Ocultación significa que se puede conseguir una
    modularidad efectiva definiendo un conjunto de
    módulos independientes que se comunican
    intercambiando la información necesaria para
    realizar la función software
La cohesión hace referencia a la forma en que
agrupamos unidades de software
(módulos, subrutinas) en una unidad mayor.

 Por ejemplo: la forma en la que agrupamos
funciones en una librería.
El acoplamiento informático indica el nivel de dependencia entre las unidades de software
de un sistema informático, es decir, el grado en que una unidad puede funcionar sin
recurrir a otras; dos funciones son absolutamente independientes entre sí (el nivel más
bajo de acoplamiento) cuando una puede hacer su trabajo completamente sin recurrir a la
otra. En este caso se dice que ambas están desacopladas.

   Ejemplo:
   Dos métodos completamente desacoplados, es decir ninguno necesita del otro para
    realizar su tarea.
                              int metodo1(int a, int b)
                              {
                                      return a * b;
                              }


                              int metodo2(int a, int b)
                              {
                                     return a + b;
                              }
El diseño de datos consiste en descubrir y la definir completamente de
los procesos y características de los datos de la aplicación. El diseño
de datos es un proceso de perfeccionamiento gradual que abarca
desde la cuestión más elemental, "¿Qué datos requiere la
aplicación?", hasta los procesos y estructuras de datos precisos que
proporcionan dichos datos. Si el diseño de datos es bueno, el acceso a
los datos de la aplicación será rápido y fácil de mantener, y podrá
aceptar sin problemas las futuras mejoras de los datos.
   Define la relación entre los principales
    elementos estructurales del programa. Se
    obtiene a partir del modelo de análisis y de la
    interacción de subsistemas definidos dentro
    del modelo de análisis.
   La arquitectura de software nos proporciona
    una visión global del sistema a construir.
   Marca decisiones de diseño tempranas y
    proporciona el mecanismo para evaluar los
    beneficios de las estructuras de sistema
    alternativas.
   La información debe introducirse y obtenerse del
    software en forma de mundo exterior, la
    información entra en el sistema a lo largo de
    caminos que transforman los datos externos a un
    formato interno. Estos caminos se identifican
    como flujo de entrada. La información entrante
    se pasa a través de un centro de transformación
    y empieza a moverse a lo largo de caminos que
    ahora conducen hacia fuera del software. Los
    datos que se mueven a lo largo de este camino
    se denominan flujo de salida.
   El flujo de transacción se caracteriza por
    datos que se mueven a lo largo de un camino
    de entrada que convierte la información del
    mundo exterior en una transacción. La
    transacción se evalúa y, basándose en ese
    valor, se inicia el flujo a lo largo de uno de
    muchos caminos de acción. El centro de flujo
    de información del que parten muchos de los
    caminos de acción se denomina centro de
    transacción.
   Describe como se comunica el software
    consigo mismo, con los sistemas que operan
    con él y con los operadores que lo emplean.
    Los diagramas de flujo de datos y control
    proporcionan la información necesaria para el
    diseño de la interfaz.
   Transforma elementos estructurales de la
    arquitectura del programa en una descripción
    procedimental de los componentes del
    software. Se obtiene a partir de la
    especificación del proceso, la especificación
    del control y el diagrama de transición de
    estados
Enfoque estructurado y Enfoque OO  - Ingenieria de software
   1. Conceptos
   2. Análisis del Sistema Descripción
   3. Diseño del Sistema descripción
   Un objeto es aquello que tiene estado (propiedades
    más valores), comportamiento (acciones y reacciones
    a mensajes) e identidad (propiedad que lo distingue
    de los demás objetos).
   Conjunto de objetos (Clase).
   Ejemplo: la clase Humanos, puede tener dos
    subclases Hombres y Mujeres. Luego como objetos
    podríamos poner hombre1, hombre2, que pertenecen
    a la clase Hombres y mujer1, mujer2 pertenecientes a
    la clase Mujeres.
   Conjunto de objetos que comparten una
    estructura y comportamiento en común
   Plantilla o prototipo para crear objetos de
    ese tipo, la cual contiene las características y
    acciones comunes del objeto
   Ejemplo:
   La clase Humanos, puede tener dos subclases
    Hombres y Mujeres.
    Es una especificación que define una
    propiedad de un objeto diferenciándolo así
    de los otros objetos.
   Describen la clase o el objeto de alguna
    manera, la cual esta definida por un
    dominio(conjunto de valores específicos).
   Ejemplo:
    A la colección de entidades Alumnos, con el
    siguiente conjunto de atributos en
    común, (id, nombre, edad, semestre),
   un método son las operaciones asociadas a
    un objeto.
   Por ejemplo, la casa puede estar cerrada o
    abierta (siendo "estado De La Puerta" un
    atributo con posibles valores "abierta" o
    "cerrada"), y posee un método "abrir Puerta" o
    "cerrar Puerta“
   Son las funciones o acciones del objeto en
    caso de la persona, los métodos
    son, caminar, hablar, reír, pensar, gritar,
  Los mensajes son el medio a través del cual
   interactúan los objetos.
  Los mensajes y los métodos son dos caras de la
   misma moneda LOS METODOS SON LOS
   PROCEDIMIENTOS INVOCADOS CUANDO UN
   OBJETO RECIBE UN MENSAJE ( Greg Voss)
  tres partes que componen un mensaje:
       1. El objeto al cual se manda el mensaje (Tu
Bicicleta).
       2. El método o función miembro que debe
ejecutar      (Cambiar De Marcha).
       3. Los parámetros que necesita ese método
(Marcha)
   Es empaquetar o proteger las variables de un
    objeto con la protección de sus métodos.
   Es guardar atributos y funcionalidades de una
    clase. No se puede acceder a los datos desde
    fuera de la clase teniendo acceso a ello solo
    los métodos que se encuentren dentro de la
    clase, dividiéndola en interfaces e
    implementación
   La herencia es la capacidad que tiene una
    clase de derivar las propiedades y métodos
    de otra, adoptando sus atributos y métodos
    de la clase padre o primaria.
    Pero además pueden introducir
    características particulares propias que las
    diferencian.
   Clases diferentes que tienen métodos o
    atributos denominados de forma
    idéntica, pero que se comportan de manera
    distinta, pueden compartir el mismo
    nombre, al llamarlos por ese nombre se
    utilizará el comportamiento correspondiente
    al objeto que se esté usando
   Utilizado para conservar o mantener una
    cierta característica o interfaz en común.
   Representan los escalones más elevados de
    algunas jerarquías de clases y solo sirven
    para derivar otras clases, en las que se van
    implementando detalles y concreciones
1. MetaClase
- Es una clase cuyas instancias son clases.
 - En otras palabras, como los objetos son
instancias de una clase, las clases son
instancias de una meta clase.
2. Subclase
- Una subclase hereda ciertas características de
las clases padres (e incluso pueden redefinirse
o agregarse nuevas características de la clase
superior también)
   Asociación entre Objetos:

      1. Generalización
        2. Agregación
       3. Composición
   Permite una estructuración jerárquica de las
    clases que comparten estructuras o
    comportamientos
   Consiste en crear clases genéricas llamadas
    súper clases o clases padre, con los elementos
    comunes a un conjunto de subclases. Las
    subclases heredan (recogen) los atributos y
    comportamiento de la clase padre pudiendo
    agregar atributos y comportamiento propios, y
    modificar los atributos y comportamiento que
    vienen del padre.
   La agregación es un tipo especial de relación
    en el que se modela una semántica del tipo
    “tiene” o “es parte de”, en la que una entidad
    represente una entidad de mayor tamaño (el
    “todo”), compuesta de entidades más
    pequeñas (las “partes”)
                                   Libro




                         CDLibro           FormatoSuscripcion
   La agregación es enteramente conceptual y lo
    único que hace es distinguir un “todo” de
    una “parte”
   La composición representa una pertenencia
    fuerte y una existencia coincidente entre el
    “todo” y la “parte”
1. Estados de un objeto
2. Eventos, tipos de eventos
3. Operaciones
   Se refiere al conjunto de los valores de sus
    atributos en un instante de tiempo dado, la
    apariencia que el objeto presenta al usuario, y
    depende del valor que tenga sus
    propiedades.
   Los objetos interactúan unos con otros y
    como consecuencia de esas interacciones
    cambian de estado.
   Los eventos producen cambios en el estado
    de un objeto. Los eventos sirven como
    indicadores de los instantes en que ocurren
    los cambios de estado.
   Todos los objetos se relacionan con el mundo
    que los rodea, esto significa que ningún
    objeto está aislado y siempre recibe el influjo
    de otros objetos. Los eventos son los
    estímulos que un objeto ejerce sobre otro
   Los tipos de eventos indican los cambios
    sencillos en el estado de un objeto
   Definen el comportamiento de un objeto.
   Las operaciones definen el comportamiento
    de un objeto y cambian, de alguna manera,
    los atributos de dicho objeto.
        1. Operaciones de manipulación
        2. Operaciones de estado
       3. Operaciones que monitorizan
   El objetivo del análisis orientado a objetos es desarrollar una
    serie de modelos que describan el software de computadora al
    trabajar para satisfacer un conjunto de requisitos definidos por
    el cliente.

   «    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 » [booch 94].

   El diseño Orientado a Objetos (DOO) difiere considerablemente
    del diseño estructurado ya que en DOO no se realiza un
    problema en términos de tareas (subrutinas) ni en términos de
    datos, sino se analiza el problema como un sistema de objetos
    que interactúan entre sí.
   El    análisis    del     dominio     del   software     es  la
    identificación, análisis y especificación de requisitos comunes
    de un dominio de aplicación específico, normalmente para su
    reutilización en múltiples proyectos dentro del mismo
    dominio de aplicación.




                                   Pressman ing. Software quinta
                                              edición
   Los componentes estáticos son estructurales por
    naturaleza, e indican características que se mantienen
    durante toda la vida operativa de una aplicación.

   Los componentes dinámicos se centran en el control, y son
    sensibles al tiempo y al tratamiento de sucesos.
1.   La inteligencia del sistema debe distribuirse de manera
     igualitaria.
2.   Cada responsabilidad debe establecerse lo más general
     posible.
3.   La información y el comportamiento asociado a
     ella, debe encontrarse dentro de la misma clase.
4.   La información sobre un elemento debe estar
     localizada dentro de una clase, no distribuida a través
     de varias clases.
5.   Compartir responsabilidades entre clases relacionadas
     cuando sea apropiado.
   Diseño orientado a objetos es una fase de la metodología
    orientada a objetos para el desarrollo de Software. Su uso
    induce a los programadores a pensar en términos de
    objetos, en vez de procedimientos, cuando planifican su
    código
   El diseño orientado a objetos transforma el modelo de
    análisis creado usando análisis orientado a objetos , en un
    modelo de diseño que sirve como anteproyecto para la
    construcción de software teniendo el uso de capaz.
               1.Diseño de responsabilidades
                   2.Diseño de mensajes
                3.Diseño de clases y objetos
                  4.Diseño de subsistemas
   La capa de responsabilidades.- Estructuras de datos y el
    diseño algorítmico para todo los atributos y operaciones.
   La capa del subsistema.- representación de los subsistemas
    que le permiten al software (requisitos e infraestructura
    técnica que lo soportara)
   La capa de clases y Objetos.- jerarquías de clase que
    permiten crear el sistema usando generalizaciones y
    especializaciones mejor definidas.
   La capa de mensajes.- detalles que le permiten a cada objeto
    comunicarse con sus colaboradores. Esta capa establece las
    interfaces externas e internas para el sistema.
Enfoque estructurado y Enfoque OO  - Ingenieria de software
Se siguen los siguientes pasos:
  Partición del modelo de análisis en subsistemas.
  Identificar la concurrencia dictada por el problema.
  Asignar subsistemas a procesadores y tareas.
  Desarrollar un diseño para la interfaz de usuario.
  Elegir una estrategia básica para implementar la
   administración (gestión) de datos.
  Identificar recursos globales y los mecanismos de control
   requeridos para su acceso.
  Diseñar un mecanismo de control apropiado para el
   sistema, incluyendo administración de tareas.
  Considerar cómo deben manejarse las condiciones de
   frontera.
• El diseño de objetos tiene que ver con el diseño detallado
  de los objetos y sus interacciones.
• Se completa dentro de la arquitectura global, definida
  durante el diseño del sistema y de acuerdo con las reglas y
  protocolos de diseño aceptados.

Más contenido relacionado

La actualidad más candente

Diagrama de Flujo de Datos (DFD)
Diagrama de Flujo de Datos (DFD)Diagrama de Flujo de Datos (DFD)
Diagrama de Flujo de Datos (DFD)
Yaskelly Yedra
 
Analisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A ObjetosAnalisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A Objetos
yoiner santiago
 
Tópicos Avanzados de Programación - Unidad 3 programacion concurrente
Tópicos Avanzados de Programación - Unidad 3 programacion concurrenteTópicos Avanzados de Programación - Unidad 3 programacion concurrente
Tópicos Avanzados de Programación - Unidad 3 programacion concurrente
José Antonio Sandoval Acosta
 
Estándares para el Modelado de Procesos de Negocios
Estándares para el Modelado de Procesos de NegociosEstándares para el Modelado de Procesos de Negocios
Estándares para el Modelado de Procesos de Negocios
UNIVERSIDAD PERUANA DE INVESTIGACIÓN Y NEGOCIOS
 
Arquitectura 3 Capas
Arquitectura 3 CapasArquitectura 3 Capas
Arquitectura 3 Capas
Fani Calle
 
Fundamentos de la arquitectura de software
Fundamentos de la arquitectura de softwareFundamentos de la arquitectura de software
Fundamentos de la arquitectura de software
Roger Villegas
 
Cuadro comparativo de enfoque estructurado y enfoque orientado
Cuadro comparativo de enfoque estructurado y enfoque orientadoCuadro comparativo de enfoque estructurado y enfoque orientado
Cuadro comparativo de enfoque estructurado y enfoque orientado
FreddySantiago32
 
Enfoque estructurado enfoque oo
Enfoque estructurado   enfoque ooEnfoque estructurado   enfoque oo
Enfoque estructurado enfoque oo
karlanm07
 
Unidad 4 graficación
Unidad 4 graficaciónUnidad 4 graficación
Unidad 4 graficación
Andhy H Palma
 
UNIDAD 2 PROGRAMACIÓN BASICA
UNIDAD 2 PROGRAMACIÓN BASICAUNIDAD 2 PROGRAMACIÓN BASICA
UNIDAD 2 PROGRAMACIÓN BASICA
Instituto Tecnológico de Tuxtla Gutiérrez
 
Fundamentos de BD - Unidad 5 algebra relacional
Fundamentos de BD - Unidad 5 algebra relacionalFundamentos de BD - Unidad 5 algebra relacional
Fundamentos de BD - Unidad 5 algebra relacional
José Antonio Sandoval Acosta
 
Modelo entidad
Modelo entidadModelo entidad
Fundamentos de ingenieria del software (2)
Fundamentos de ingenieria del software (2)Fundamentos de ingenieria del software (2)
Fundamentos de ingenieria del software (2)
manuel alfredo chacon valero
 
Unidad 6 Protección y seguridad.
Unidad 6 Protección y seguridad.Unidad 6 Protección y seguridad.
Unidad 6 Protección y seguridad.
Juan Anaya
 
Modelado del sistema
Modelado del sistemaModelado del sistema
Modelado del sistema
Israel Rey
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
landeta_p
 
Diagramas de paquetes
Diagramas de paquetesDiagramas de paquetes
Diagramas de paquetes
Moises Cruz
 
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosFundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
José Antonio Sandoval Acosta
 
Técnicas para la Obtención de Requerimientos
Técnicas para la Obtención de RequerimientosTécnicas para la Obtención de Requerimientos
Técnicas para la Obtención de Requerimientos
Juan Carlos Olivares Rojas
 
Diagramas de despliegue
Diagramas de despliegueDiagramas de despliegue
Diagramas de despliegue
gmjuan
 

La actualidad más candente (20)

Diagrama de Flujo de Datos (DFD)
Diagrama de Flujo de Datos (DFD)Diagrama de Flujo de Datos (DFD)
Diagrama de Flujo de Datos (DFD)
 
Analisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A ObjetosAnalisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A Objetos
 
Tópicos Avanzados de Programación - Unidad 3 programacion concurrente
Tópicos Avanzados de Programación - Unidad 3 programacion concurrenteTópicos Avanzados de Programación - Unidad 3 programacion concurrente
Tópicos Avanzados de Programación - Unidad 3 programacion concurrente
 
Estándares para el Modelado de Procesos de Negocios
Estándares para el Modelado de Procesos de NegociosEstándares para el Modelado de Procesos de Negocios
Estándares para el Modelado de Procesos de Negocios
 
Arquitectura 3 Capas
Arquitectura 3 CapasArquitectura 3 Capas
Arquitectura 3 Capas
 
Fundamentos de la arquitectura de software
Fundamentos de la arquitectura de softwareFundamentos de la arquitectura de software
Fundamentos de la arquitectura de software
 
Cuadro comparativo de enfoque estructurado y enfoque orientado
Cuadro comparativo de enfoque estructurado y enfoque orientadoCuadro comparativo de enfoque estructurado y enfoque orientado
Cuadro comparativo de enfoque estructurado y enfoque orientado
 
Enfoque estructurado enfoque oo
Enfoque estructurado   enfoque ooEnfoque estructurado   enfoque oo
Enfoque estructurado enfoque oo
 
Unidad 4 graficación
Unidad 4 graficaciónUnidad 4 graficación
Unidad 4 graficación
 
UNIDAD 2 PROGRAMACIÓN BASICA
UNIDAD 2 PROGRAMACIÓN BASICAUNIDAD 2 PROGRAMACIÓN BASICA
UNIDAD 2 PROGRAMACIÓN BASICA
 
Fundamentos de BD - Unidad 5 algebra relacional
Fundamentos de BD - Unidad 5 algebra relacionalFundamentos de BD - Unidad 5 algebra relacional
Fundamentos de BD - Unidad 5 algebra relacional
 
Modelo entidad
Modelo entidadModelo entidad
Modelo entidad
 
Fundamentos de ingenieria del software (2)
Fundamentos de ingenieria del software (2)Fundamentos de ingenieria del software (2)
Fundamentos de ingenieria del software (2)
 
Unidad 6 Protección y seguridad.
Unidad 6 Protección y seguridad.Unidad 6 Protección y seguridad.
Unidad 6 Protección y seguridad.
 
Modelado del sistema
Modelado del sistemaModelado del sistema
Modelado del sistema
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
 
Diagramas de paquetes
Diagramas de paquetesDiagramas de paquetes
Diagramas de paquetes
 
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosFundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
 
Técnicas para la Obtención de Requerimientos
Técnicas para la Obtención de RequerimientosTécnicas para la Obtención de Requerimientos
Técnicas para la Obtención de Requerimientos
 
Diagramas de despliegue
Diagramas de despliegueDiagramas de despliegue
Diagramas de despliegue
 

Similar a Enfoque estructurado y Enfoque OO - Ingenieria de software

Enfoques de desarrollo de sw
Enfoques de desarrollo de swEnfoques de desarrollo de sw
Enfoques de desarrollo de sw
WalterJes
 
Presentaciónclaraalvarez
PresentaciónclaraalvarezPresentaciónclaraalvarez
Presentaciónclaraalvarez
clarasolmaira
 
Modelos de BDD y modelos de datos
Modelos de BDD y modelos de datosModelos de BDD y modelos de datos
Modelos de BDD y modelos de datos
Valmore Medina
 
Diagramadeflujo 140115215731-phpapp02
Diagramadeflujo 140115215731-phpapp02Diagramadeflujo 140115215731-phpapp02
Diagramadeflujo 140115215731-phpapp02
Martin Eduardo Toro Suarez
 
Paradigmas
ParadigmasParadigmas
Paradigmas
guest9d4dd8
 
0 todo
0 todo0 todo
0 todo
yanqui0101
 
Diagramas de flujo
Diagramas de flujoDiagramas de flujo
Diagramas de flujo
lordXDie
 
Paraigma de la Ingenieria de Software.pdf
Paraigma de la Ingenieria de Software.pdfParaigma de la Ingenieria de Software.pdf
Paraigma de la Ingenieria de Software.pdf
Edecio R. Freitez R.
 
Planificacion de proyecto de software
Planificacion de proyecto de softwarePlanificacion de proyecto de software
Planificacion de proyecto de software
YORGELIS1608
 
Analisis de sistemas estructurados
Analisis de sistemas estructuradosAnalisis de sistemas estructurados
Analisis de sistemas estructurados
Andreina Martinez
 
Sistema de informacion gerencial diagrama de flujo
Sistema de informacion gerencial diagrama de flujoSistema de informacion gerencial diagrama de flujo
Sistema de informacion gerencial diagrama de flujo
RivasJuan1803
 
Capitulo 2
Capitulo 2Capitulo 2
Capitulo 2
Velasquezeduardo15
 
Segumiento del capitulo 2
Segumiento del capitulo 2Segumiento del capitulo 2
Segumiento del capitulo 2
Velasquezeduardo15
 
Capitulo 2
Capitulo 2Capitulo 2
Capitulo 2
Anthony1095
 
Análisis estructurado power
Análisis estructurado powerAnálisis estructurado power
Análisis estructurado power
A.C. Milan
 
Fundamentos y metodos analisis de requerimiento
Fundamentos y metodos analisis de requerimientoFundamentos y metodos analisis de requerimiento
Fundamentos y metodos analisis de requerimiento
Monica Naranjo
 
Alejandro soto ingeneria sistema
Alejandro soto ingeneria sistemaAlejandro soto ingeneria sistema
Alejandro soto ingeneria sistema
Alejandross1
 
Unidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del softwareUnidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del software
Andhy H Palma
 
Capitulo 2
Capitulo 2Capitulo 2
Capitulo 2
AlvaRado22
 
Seguimiento del Capitulo 2
 Seguimiento del Capitulo 2 Seguimiento del Capitulo 2
Seguimiento del Capitulo 2
Reynel199610
 

Similar a Enfoque estructurado y Enfoque OO - Ingenieria de software (20)

Enfoques de desarrollo de sw
Enfoques de desarrollo de swEnfoques de desarrollo de sw
Enfoques de desarrollo de sw
 
Presentaciónclaraalvarez
PresentaciónclaraalvarezPresentaciónclaraalvarez
Presentaciónclaraalvarez
 
Modelos de BDD y modelos de datos
Modelos de BDD y modelos de datosModelos de BDD y modelos de datos
Modelos de BDD y modelos de datos
 
Diagramadeflujo 140115215731-phpapp02
Diagramadeflujo 140115215731-phpapp02Diagramadeflujo 140115215731-phpapp02
Diagramadeflujo 140115215731-phpapp02
 
Paradigmas
ParadigmasParadigmas
Paradigmas
 
0 todo
0 todo0 todo
0 todo
 
Diagramas de flujo
Diagramas de flujoDiagramas de flujo
Diagramas de flujo
 
Paraigma de la Ingenieria de Software.pdf
Paraigma de la Ingenieria de Software.pdfParaigma de la Ingenieria de Software.pdf
Paraigma de la Ingenieria de Software.pdf
 
Planificacion de proyecto de software
Planificacion de proyecto de softwarePlanificacion de proyecto de software
Planificacion de proyecto de software
 
Analisis de sistemas estructurados
Analisis de sistemas estructuradosAnalisis de sistemas estructurados
Analisis de sistemas estructurados
 
Sistema de informacion gerencial diagrama de flujo
Sistema de informacion gerencial diagrama de flujoSistema de informacion gerencial diagrama de flujo
Sistema de informacion gerencial diagrama de flujo
 
Capitulo 2
Capitulo 2Capitulo 2
Capitulo 2
 
Segumiento del capitulo 2
Segumiento del capitulo 2Segumiento del capitulo 2
Segumiento del capitulo 2
 
Capitulo 2
Capitulo 2Capitulo 2
Capitulo 2
 
Análisis estructurado power
Análisis estructurado powerAnálisis estructurado power
Análisis estructurado power
 
Fundamentos y metodos analisis de requerimiento
Fundamentos y metodos analisis de requerimientoFundamentos y metodos analisis de requerimiento
Fundamentos y metodos analisis de requerimiento
 
Alejandro soto ingeneria sistema
Alejandro soto ingeneria sistemaAlejandro soto ingeneria sistema
Alejandro soto ingeneria sistema
 
Unidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del softwareUnidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del software
 
Capitulo 2
Capitulo 2Capitulo 2
Capitulo 2
 
Seguimiento del Capitulo 2
 Seguimiento del Capitulo 2 Seguimiento del Capitulo 2
Seguimiento del Capitulo 2
 

Enfoque estructurado y Enfoque OO - Ingenieria de software

  • 1. RAMOS CHAVEZ Marco • PAZCE LAZO Michael • SANCHEZ ALANYA Jose L. • ZACARIAS MUNGUIA Valeria • HIDALGO HINOJOSA Nilton
  • 3. El modelado de procesos, así como su nombre lo indica, tiene 2 aspectos que lo definen: el modelado y los  EJEMPLO: procesos. Frecuentemente, sistemas, conjuntos de procesos y los  La reingeniería de subprocesos integrados en una procesos de organización. negocios, la cual se Un modelo es una representación de una realidad compleja. Modelar es encarga del rediseño desarrollar una descripción lo más de los procesos de exacta posible de un sistema y de las actividades llevadas a cabo en él. negocios de las Cuando un proceso es modelado, con organizaciones con el ayuda de una representación gráfica (diagrama de proceso), pueden fin de hacerlos más apreciarse con facilidad las eficientes. interrelaciones existentes entre distintas actividades, analizar cada actividad, definir los puntos de contacto con otros procesos, así como identificar los subprocesos comprendidos.
  • 5. Es la manera en que se representa la forma en que los datos cambian conforme se mueven a Las transformaciones través del sistema. que se aplican a los datos son funciones que debe realizar un programa. DESCRIPCIÓN REPRESENTACIÓN
  • 6. El Análisis se refiere al “extremo inicial” de un proyecto de desarrollo de sistemas, durante el tiempo en que los requisitos del usuario son definidos y documentados.
  • 7. El análisis de requisitos es el proceso de estudio de las necesidades de los usuarios para llegar a una definición de los requisitos del sistema de hardware o de software; así como su estudio y refinamiento.  Tras haber estudiado las posibilidades con las que se cuenta para el desarrollo del sistema, así como sus limitaciones, se puede establecer una lista más firme de requisitos, tanto a nivel funcional como no funcional.
  • 8. El software se construye para procesar datos, para transformarlos es decir, para aceptar datos de entrada, manipularlos y producir información de salida. Pero el software también procesa acontecimientos, que controlan al sistema y no es más que un dato binario, tal como un sensor que envía al software una señal de alarma.  Por tanto, los datos ( números, caracteres, imágenes, sonidos, etc. ) y el control ( acontecimientos ) son parte del dominio de la información.
  • 9. 1. Contenido de la Información  2. Flujo de la Información  3. Estructura de la Información
  • 10. El modelo de análisis debe cumplir tres objetivos primarios:  1: Describe lo que requiere el cliente  2: Establecer una base para la creación de un diseño de software  3: Definir un conjunto de requisitos que puedan validarse una vez construido el software
  • 11. Es un esquema teórico de un sistema o realidad compleja que se elabora para facilitar su comprensión y estudio.  Es una representación de los aspectos esenciales de una realidad compleja de acuerdo a un criterio  Todo modelo es necesariamente una simplificación de la realidad  ¿Por qué modelar? Para facilitar el estudio y analizar el comportamiento de un SI(sistema de información), y sus componentes Para rediseñar un SI, tal que satisfaga nuevos objetivos y requerimientos de gestión
  • 12. Las entidades son los objetos principales sobre los que se debe recoger información y generalmente denotan personas, lugares, cosas o eventos de interés. Las entidades aparecen reflejadas en el enunciado habitualmente como nombres. Gráficamente se simbolizan con un rectángulo.
  • 13. Los atributos se utilizan para detallar las entidades asignándoles propiedades descriptivas tales como nombre, color y peso. No solo es posible especificar atributos en las entidades sino también en las relaciones. Los atributos también aparecen reflejados en el enunciado, generalmente, como nombres.  Las entidades pueden clasificarse por la fuerza de sus atributos identificadores, es decir, por su dependencia o no dependencia respecto a otras entidades. Las entidades fuertes tienen existencia propia, es decir, poseen identificadores internos que determinan de manera única la existencia de sus ocurrencias. Las entidades débiles pueden tienen existencia en la base de datos dependiendo de una entidad fuerte. Gráficamente los atributos se simbolizan con una elipse.
  • 14. Las relaciones representan asociaciones en el mundo real entre una o más entidades. Las relaciones se caracterizan por su nombre, el grado (número de entidades que participan en la relación), el tipo de cardinalidad (número máximo de ejemplares de una entidad asociados a una combinación de ejemplares de las otras entidades de la relación, que pueden ser 1 ó N). Gráficamente las relaciones se simbolizan con un rombo.
  • 15. En este modelo se presenta la vista unificada de los datos, centrándose en la estructura lógica y abstracta de los datos, como representación del mundo real, con independencia de consideraciones del mundo físico.  Un modelo Entidad-Relación tiene los siguientes elementos:  Entidad es “una persona, lugar, cosa, concepto, suceso, real o abstracto de interés para la empresa”. Es aquel objeto acerca del cual queremos almacenar información en la base de datos.  Interrelación se define como la asociación o correspondencia entre entidades.  Atributos
  • 16. • El modelo funcional describe los comportamientos y operaciones de los objetos.  • El modelo funcional muestra la dependencia de datos en el sistema.  • El modelo funcional describe la computación dentro del sistema, cómo los valores de salida se  derivan de los valores de entrada, sin importar el orden en que son computados.  • El modelo funcional consiste de múltiples diagramas de flujo de datos.
  • 17. El diagrama de flujo de datos ( DFD ) es una técnica gráfica que representa el flujo de la información y las transformaciones que se aplican a los datos al moverse desde la entrada a la salida.  La notación básica para construir DFD’s es la siguiente:
  • 18. Un rectangulo representa a un elemento del sistema ( por ejemplo un hardware, una persona, un programa ) o un sistema que produce o recibe información que es transformada por el software.  Un circulo representa un proceso o transformación que se aplica a los datos y los cambia de alguna forma.
  • 19. La flecha representa a un elemento o una colección de elementos de datos.  Representa información almacenada y que utiliza el software.
  • 20. El diagrama de transición de estados DTE representa el comportamiento de un sistema que muestra los estados y los sucesos que hacen que el sistema cambie de estado.  Un estado es un modo observable de comportamiento, por ejemplo monitoreando, comprobando, calculando, etc . Cada estado representa un modo de comportamiento y el DTE indica cómo se mueve el sistema de un estado a otro.
  • 21. Un Diccionario de Datos es una lista con todos los detalles y descripciones de los elementos incluidos en los Diagramas de Flujo de Datos que describen al sistema.
  • 22. 1. Descripción de los almacenamientos de datos  2. Descripción de los procesos  3. Descripción de las estructuras de datos  4. Descripción de los elementos de datos  5. Descripción de los flujos de datos
  • 24. Definición: ◦ La representación de las características esenciales de algo sin incluir antecedentes o detalles irrelevantes [Graham, 1994]
  • 25. Ventajas: ◦ Define y refuerza las restricciones de acceso ◦ Facilita el mantenimiento y la evolución de los sistemas software ◦ Reduce los efectos laterales ◦ Limita el impacto global de las decisiones de diseño locales ◦ Favorece la encapsulación, uno de los elementos de un buen diseño ◦ Descripción de una función de un programa en el nivel de detalle adecuado ◦ Cada paso en el proceso del software es un refinamiento del nivel de abstracción de la solución software (abstracciones funcionales y abstracciones de datos) ◦ Refinamiento y modularidad son conceptos cercanos al concepto de abstracción
  • 26. Similitud con el procedimiento de partición y refinamiento del análisis de requisitos ◦ La diferencia está en el nivel de detalle, no en el enfoque  El refinamiento es un procedimiento de elaboración ◦ Función descrita a un nivel conceptual ◦ Refinamientos sucesivos que incorporan más detalles  Gestiona la complejidad dividiendo problemas grandes en problemas pequeños ◦ Permite que personas diferentes puedan trabajar con cada parte ◦ Permite la especialización de los ingenieros del software ◦ Cada componente individual es más pequeño y, por tanto, su comprensión es más sencilla ◦ Las partes se pueden remplazar o cambiar sin tener que remplazar o cambiar de forma generalizada el resto de las partes
  • 27. Propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes  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 proveedor.
  • 28. MODULARIDAD La modularidad del software facilita el desarrollo del mismo, pero hasta un cierto límite, porque si llegáramos a dividir el problema en infinitos módulos, los módulos tendrían una complejidad y un esfuerzo mucho menor, pero crecería el coste asociado a la creación de interfaces entre los módulos,
  • 29. La arquitectura del software alude a la “estructura global del SW y a las formas en que la estructura proporciona la integridad conceptual de un sistema”  La arquitectura del SW es la estructura jerárquica de los componentes del programa (módulos), la manera en que los componentes interactúan y la estructura de datos que van a utilizar los componentes.
  • 31. La jerarquía de control, denominada también “estructura del programa”, representa la organización de los componentes del programa (módulos) e implica una jerarquía de control.  No representa los aspectos procedimentales del software, ni se puede aplicar necesariamente a todos los estilos arquitectónicos.
  • 33. La estructura de un programa debe partirse horizontal y verticalmente  La partición horizontal define ramas separadas de la jerarquía modular para cada función principal del programa ◦ Módulos de control ◦ Enfoque entrada/proceso/salida  Beneficios de la partición horizontal ◦ Proporciona software más fácil de probar ◦ Lleva a un software más fácil de mantener ◦ Propaga menos efectos secundarios ◦ Proporciona software más fácil de ampliar  Puntos en contra de la partición horizontal ◦ Aumenta la comunicación entre módulos, pudiendo complicar el control global del flujo del programa
  • 34. Partición vertical o descomposición en factores (factoring)  La partición vertical expresa que el control, toma de decisiones, y el trabajo se distribuyan de forma descendente en la arquitectura del programa  Los módulos de nivel superior deben realizar funciones de control y poco trabajo de procesamiento  Los módulos que residen en la parte baja de la arquitectura deben de ser los que realicen las tareas de entrada, cálculo y salida
  • 37. La estructura de datos e una representación de la relación lógica entre elementos individuales de datos .  Como la estructura de la información afectara invariablemente al diseño procedimental final, la estructura de datos es tan importante como la estructura de programa para la representación de la arquitectura de software
  • 38. La estructura del programa define la jerarquía de control sin tener en consideración la secuencia de proceso y de decisiones.  El procedimiento de software se centra en el procesamiento de cada modulo individualmente.  El procedimiento debe proporcionar una especificación precisa de procesamiento, incluyendo la secuencia de sucesos , los puntos de decisión exactos, las operaciones repetitivas e incluso la estructura , organizándole datos.
  • 39. “Los módulos de un sistema deben diseñarse de modo que la información contenida en ellos sea inaccesible a todos aquellos módulos que no necesiten tal información” David Parnas, 1970 ◦ Los módulos deberán especificarse y diseñarse de manera que la información (procedimientos y datos) que está dentro de un módulo sea inaccesible a otros módulos que no necesiten esa información
  • 40. El ocultamiento de la información es un buen medio para conseguir abstracción  Restricciones de acceso ◦ Detalle procedimental dentro del módulo ◦ Estructura de datos local empleada por el módulo  El diseñador de cada módulo debe seleccionar un subconjunto de las propiedades del módulo como información oficial del módulo, para ponerlas a disposición de los autores de módulos o de módulos clientes
  • 41. Las decisiones de diseño sujetas a cambio deben ocultarse detrás de interfaces abstractas ◦ Las aplicaciones software han de comunicarse únicamente a través de interfaces bien definidas ◦ La interfaz de un módulo debe revelar lo menos posible de su funcionamiento interno ◦ Intercambio de módulos mientras que se mantengan intactas las interfaces ◦ Ventajas a la hora de hacer cambios  Ocultación significa que se puede conseguir una modularidad efectiva definiendo un conjunto de módulos independientes que se comunican intercambiando la información necesaria para realizar la función software
  • 42. La cohesión hace referencia a la forma en que agrupamos unidades de software (módulos, subrutinas) en una unidad mayor.  Por ejemplo: la forma en la que agrupamos funciones en una librería.
  • 43. El acoplamiento informático indica el nivel de dependencia entre las unidades de software de un sistema informático, es decir, el grado en que una unidad puede funcionar sin recurrir a otras; dos funciones son absolutamente independientes entre sí (el nivel más bajo de acoplamiento) cuando una puede hacer su trabajo completamente sin recurrir a la otra. En este caso se dice que ambas están desacopladas.  Ejemplo:  Dos métodos completamente desacoplados, es decir ninguno necesita del otro para realizar su tarea. int metodo1(int a, int b) { return a * b; } int metodo2(int a, int b) { return a + b; }
  • 44. El diseño de datos consiste en descubrir y la definir completamente de los procesos y características de los datos de la aplicación. El diseño de datos es un proceso de perfeccionamiento gradual que abarca desde la cuestión más elemental, "¿Qué datos requiere la aplicación?", hasta los procesos y estructuras de datos precisos que proporcionan dichos datos. Si el diseño de datos es bueno, el acceso a los datos de la aplicación será rápido y fácil de mantener, y podrá aceptar sin problemas las futuras mejoras de los datos.
  • 45. Define la relación entre los principales elementos estructurales del programa. Se obtiene a partir del modelo de análisis y de la interacción de subsistemas definidos dentro del modelo de análisis.  La arquitectura de software nos proporciona una visión global del sistema a construir.  Marca decisiones de diseño tempranas y proporciona el mecanismo para evaluar los beneficios de las estructuras de sistema alternativas.
  • 46. La información debe introducirse y obtenerse del software en forma de mundo exterior, la información entra en el sistema a lo largo de caminos que transforman los datos externos a un formato interno. Estos caminos se identifican como flujo de entrada. La información entrante se pasa a través de un centro de transformación y empieza a moverse a lo largo de caminos que ahora conducen hacia fuera del software. Los datos que se mueven a lo largo de este camino se denominan flujo de salida.
  • 47. El flujo de transacción se caracteriza por datos que se mueven a lo largo de un camino de entrada que convierte la información del mundo exterior en una transacción. La transacción se evalúa y, basándose en ese valor, se inicia el flujo a lo largo de uno de muchos caminos de acción. El centro de flujo de información del que parten muchos de los caminos de acción se denomina centro de transacción.
  • 48. Describe como se comunica el software consigo mismo, con los sistemas que operan con él y con los operadores que lo emplean. Los diagramas de flujo de datos y control proporcionan la información necesaria para el diseño de la interfaz.
  • 49. Transforma elementos estructurales de la arquitectura del programa en una descripción procedimental de los componentes del software. Se obtiene a partir de la especificación del proceso, la especificación del control y el diagrama de transición de estados
  • 51. 1. Conceptos  2. Análisis del Sistema Descripción  3. Diseño del Sistema descripción
  • 52. Un objeto es aquello que tiene estado (propiedades más valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los demás objetos).  Conjunto de objetos (Clase).  Ejemplo: la clase Humanos, puede tener dos subclases Hombres y Mujeres. Luego como objetos podríamos poner hombre1, hombre2, que pertenecen a la clase Hombres y mujer1, mujer2 pertenecientes a la clase Mujeres.
  • 53. Conjunto de objetos que comparten una estructura y comportamiento en común  Plantilla o prototipo para crear objetos de ese tipo, la cual contiene las características y acciones comunes del objeto  Ejemplo:  La clase Humanos, puede tener dos subclases Hombres y Mujeres.
  • 54. Es una especificación que define una propiedad de un objeto diferenciándolo así de los otros objetos.  Describen la clase o el objeto de alguna manera, la cual esta definida por un dominio(conjunto de valores específicos).  Ejemplo: A la colección de entidades Alumnos, con el siguiente conjunto de atributos en común, (id, nombre, edad, semestre),
  • 55. un método son las operaciones asociadas a un objeto.  Por ejemplo, la casa puede estar cerrada o abierta (siendo "estado De La Puerta" un atributo con posibles valores "abierta" o "cerrada"), y posee un método "abrir Puerta" o "cerrar Puerta“  Son las funciones o acciones del objeto en caso de la persona, los métodos son, caminar, hablar, reír, pensar, gritar,
  • 56.  Los mensajes son el medio a través del cual interactúan los objetos.  Los mensajes y los métodos son dos caras de la misma moneda LOS METODOS SON LOS PROCEDIMIENTOS INVOCADOS CUANDO UN OBJETO RECIBE UN MENSAJE ( Greg Voss)  tres partes que componen un mensaje: 1. El objeto al cual se manda el mensaje (Tu Bicicleta). 2. El método o función miembro que debe ejecutar (Cambiar De Marcha). 3. Los parámetros que necesita ese método (Marcha)
  • 57. Es empaquetar o proteger las variables de un objeto con la protección de sus métodos.  Es guardar atributos y funcionalidades de una clase. No se puede acceder a los datos desde fuera de la clase teniendo acceso a ello solo los métodos que se encuentren dentro de la clase, dividiéndola en interfaces e implementación
  • 58. La herencia es la capacidad que tiene una clase de derivar las propiedades y métodos de otra, adoptando sus atributos y métodos de la clase padre o primaria.  Pero además pueden introducir características particulares propias que las diferencian.
  • 59. Clases diferentes que tienen métodos o atributos denominados de forma idéntica, pero que se comportan de manera distinta, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando
  • 60. Utilizado para conservar o mantener una cierta característica o interfaz en común.  Representan los escalones más elevados de algunas jerarquías de clases y solo sirven para derivar otras clases, en las que se van implementando detalles y concreciones
  • 61. 1. MetaClase - Es una clase cuyas instancias son clases. - En otras palabras, como los objetos son instancias de una clase, las clases son instancias de una meta clase.
  • 62. 2. Subclase - Una subclase hereda ciertas características de las clases padres (e incluso pueden redefinirse o agregarse nuevas características de la clase superior también)
  • 63. Asociación entre Objetos: 1. Generalización 2. Agregación 3. Composición
  • 64. Permite una estructuración jerárquica de las clases que comparten estructuras o comportamientos  Consiste en crear clases genéricas llamadas súper clases o clases padre, con los elementos comunes a un conjunto de subclases. Las subclases heredan (recogen) los atributos y comportamiento de la clase padre pudiendo agregar atributos y comportamiento propios, y modificar los atributos y comportamiento que vienen del padre.
  • 65. La agregación es un tipo especial de relación en el que se modela una semántica del tipo “tiene” o “es parte de”, en la que una entidad represente una entidad de mayor tamaño (el “todo”), compuesta de entidades más pequeñas (las “partes”) Libro CDLibro FormatoSuscripcion
  • 66. La agregación es enteramente conceptual y lo único que hace es distinguir un “todo” de una “parte”  La composición representa una pertenencia fuerte y una existencia coincidente entre el “todo” y la “parte”
  • 67. 1. Estados de un objeto 2. Eventos, tipos de eventos 3. Operaciones
  • 68. Se refiere al conjunto de los valores de sus atributos en un instante de tiempo dado, la apariencia que el objeto presenta al usuario, y depende del valor que tenga sus propiedades.  Los objetos interactúan unos con otros y como consecuencia de esas interacciones cambian de estado.
  • 69. Los eventos producen cambios en el estado de un objeto. Los eventos sirven como indicadores de los instantes en que ocurren los cambios de estado.  Todos los objetos se relacionan con el mundo que los rodea, esto significa que ningún objeto está aislado y siempre recibe el influjo de otros objetos. Los eventos son los estímulos que un objeto ejerce sobre otro  Los tipos de eventos indican los cambios sencillos en el estado de un objeto
  • 70. Definen el comportamiento de un objeto.  Las operaciones definen el comportamiento de un objeto y cambian, de alguna manera, los atributos de dicho objeto. 1. Operaciones de manipulación 2. Operaciones de estado 3. Operaciones que monitorizan
  • 71. El objetivo del análisis orientado a objetos es desarrollar una serie de modelos que describan el software de computadora al trabajar para satisfacer un conjunto de requisitos definidos por el cliente.  « 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 » [booch 94].  El diseño Orientado a Objetos (DOO) difiere considerablemente del diseño estructurado ya que en DOO no se realiza un problema en términos de tareas (subrutinas) ni en términos de datos, sino se analiza el problema como un sistema de objetos que interactúan entre sí.
  • 72. El análisis del dominio del software es la identificación, análisis y especificación de requisitos comunes de un dominio de aplicación específico, normalmente para su reutilización en múltiples proyectos dentro del mismo dominio de aplicación. Pressman ing. Software quinta edición
  • 73. Los componentes estáticos son estructurales por naturaleza, e indican características que se mantienen durante toda la vida operativa de una aplicación.  Los componentes dinámicos se centran en el control, y son sensibles al tiempo y al tratamiento de sucesos.
  • 74. 1. La inteligencia del sistema debe distribuirse de manera igualitaria. 2. Cada responsabilidad debe establecerse lo más general posible. 3. La información y el comportamiento asociado a ella, debe encontrarse dentro de la misma clase. 4. La información sobre un elemento debe estar localizada dentro de una clase, no distribuida a través de varias clases. 5. Compartir responsabilidades entre clases relacionadas cuando sea apropiado.
  • 75. Diseño orientado a objetos es una fase de la metodología orientada a objetos para el desarrollo de Software. Su uso induce a los programadores a pensar en términos de objetos, en vez de procedimientos, cuando planifican su código  El diseño orientado a objetos transforma el modelo de análisis creado usando análisis orientado a objetos , en un modelo de diseño que sirve como anteproyecto para la construcción de software teniendo el uso de capaz. 1.Diseño de responsabilidades 2.Diseño de mensajes 3.Diseño de clases y objetos 4.Diseño de subsistemas
  • 76. La capa de responsabilidades.- Estructuras de datos y el diseño algorítmico para todo los atributos y operaciones.  La capa del subsistema.- representación de los subsistemas que le permiten al software (requisitos e infraestructura técnica que lo soportara)  La capa de clases y Objetos.- jerarquías de clase que permiten crear el sistema usando generalizaciones y especializaciones mejor definidas.  La capa de mensajes.- detalles que le permiten a cada objeto comunicarse con sus colaboradores. Esta capa establece las interfaces externas e internas para el sistema.
  • 78. Se siguen los siguientes pasos:  Partición del modelo de análisis en subsistemas.  Identificar la concurrencia dictada por el problema.  Asignar subsistemas a procesadores y tareas.  Desarrollar un diseño para la interfaz de usuario.  Elegir una estrategia básica para implementar la administración (gestión) de datos.  Identificar recursos globales y los mecanismos de control requeridos para su acceso.  Diseñar un mecanismo de control apropiado para el sistema, incluyendo administración de tareas.  Considerar cómo deben manejarse las condiciones de frontera.
  • 79. • El diseño de objetos tiene que ver con el diseño detallado de los objetos y sus interacciones. • Se completa dentro de la arquitectura global, definida durante el diseño del sistema y de acuerdo con las reglas y protocolos de diseño aceptados.