SlideShare una empresa de Scribd logo
1 de 42
Análisis y Diseño
Orientado a Objetos
Introducción



 Requisitos del usuario         Proceso de desarrollo        Sistema de software
                                    de software




  •    Proceso de desarrollo de software:
        – Forma disciplinada de asignar tareas y responsabilidades en una
          empresa de desarrollo (quién hace qué, cuándo y cómo).

  •    Objetivos:
        – Asegurar la producción de software de calidad dentro de plazos
            y presupuestos predecibles.
Introducción
Proceso de desarrollo de software


                    Planificación              Construcción              Aplicación




      Ciclo de                   Ciclo de                      ...
     desarrollo 1               desarrollo 2




         Perfeccionar
                               Análisis            Diseño        Construcción         Pruebas
             plan



                                          De dos semanas a dos meses
Introducción
Proceso de desarrollo de software


      Ciclo de         Ciclo de         Ciclo de       ...
     desarrollo 1     desarrollo 2     desarrollo 3


     Caso de uso A:   Caso de uso A:   Caso de uso B
     Versión          Versión          -------
     simplificada     completa         -------
     -------          -------          -------
     -------          -------          -------


                                       Caso de uso C
                                       -------
                                       -------
                                       -------
                                       -------
Introducción
Proceso de desarrollo de software


                    Planificación              Construcción              Aplicación




      Ciclo de                   Ciclo de                      ...
     desarrollo 1               desarrollo 2




         Perfeccionar
                               Análisis            Diseño        Construcción         Pruebas
             plan



                                          De dos semanas a dos meses
Análisis y Diseño OO

Algunas de las tareas a realizarse en la etapa de análisis
(dominio del problema) son las siguientes:


      Perfeccionar
                      Análisis          Diseño       Construcción       Pruebas
          plan




        Definir los    Definir los casos     Crear diagramas        Crear modelo
        requisitos    esenciales de uso      de casos de uso         conceptual


         Crear el       Definir diag.            Definir los
         glosario      de secuencia              contratos
Análisis y Diseño OO

Algunas de las tareas a realizarse en la etapa de diseño
(dominio de la solución) son las siguientes:


     Perfeccionar
                       Análisis             Diseño         Construcción      Pruebas
         plan




              Definir casos           Definir reportes,    Perfeccionar la
             reales de uso          interfaz de usuario,    arquitectura
                                  secuencia de pantallas


              Definir diag.         Definir diagramas      Definir esquema
             de interacción         diseño de clases        base de datos
Caso de estudio


 Caso de estudio: punto de venta

 Supongamos como caso de estudio el sistema de una terminal
 de punto de venta. Esta terminal es un sistema automatizado
 con el que se registran las ventas y se realizan los pagos.

 Por lo general este tipo de sistemas comprenden hardware (un
 computador y un lector de código barras) y software (el sistema
 que se ejecuta en la terminal).
Requisitos

  Los requisitos

  Los requisitos son una descripción de las necesidades
  o deseos de un producto.


  Se recomienda aquí definir al menos los siguientes puntos:

     · Panorama general
     · Metas
     · Funciones del sistema
Requisitos

a) Panorama general
   Este proyecto tiene por objeto crear un sistema de terminal para
   el punto de venta que se utilizará en las ventas de un supermercado.

b) Metas
   En términos generales, la meta es una mayor automatización del
   pago en las cajas registradoras, y dar soporte a servicios más
   rápidos, más baratos y mejores. Concretamente, la meta incluye:

       · Pago rápido de los clientes.
       · Análisis rápido y exacto de las ventas.
       · Control automático del inventario.
Requisitos


c) Funciones del sistema
   Las funciones del sistema son lo que éste deberá de hacer.

  Las funciones pueden clasificarse en tres categorías: evidentes,
  ocultas y superfluas. Las evidentes deben realizarse, y el usuario
  debe saber que se han realizado. Las ocultas también deben
  realizarse, y puede que no sean visibles para el usuario. Las
  superfluas son opcionales, y su inclusión no repercute significati-
  vamente en el costo ni en otras funciones.
Requisitos
Estas son algunas de las funciones del sistema de punto de venta:

 Ref.                                Función                                 Categoría


 R1.1   Registra la venta en proceso (actual): los productos comprados.       evidente
 R1.2   Calcula el total de la venta actual; se incluye el impuesto.          evidente
 R1.3   Captura la información sobre el objeto comprado usando su código
        de barras, o usando una captura manual del código de producto.        evidente
 R1.4   Reduce las cantidades del inventario cuando se realiza una venta.     oculta
 R1.5   Se registran las ventas efectuadas.                                   oculta
 R1.6   El cajero debe introducir una identificación y una contraseña para
        poder utilizar el sistema.                                            evidente
 R1.7   Ofrece un mecanismo de almacenamiento persistente.                    oculta
 R1.8   Ofrece mecanismos de comunicación entre los procesos y entre
        los sistemas.                                                         oculta
 R1.9   Muestra la descripción y el precio del producto registrado.           evidente
Casos de uso


 Casos de uso

 Los casos de uso requieren tener al menos un conocimiento parcial
 de los requerimientos del sistema. Un caso de uso es un documento
 narrativo que describe la secuencia de eventos de un actor (agente
 externo) que utiliza un sistema para completar un proceso.
Casos de uso

El formato para la descripción de los casos de uso es el siguiente:


Caso de uso: Nombre
Actores:        Lista de actores (agentes externos)
Propósito:      Intención del caso de uso
Resumen:        Repetición del caso de uso de alto nivel o alguna síntesis.
Tipo:          Primario, secundario u opcional. Esencial o real.
Referencias
cruzadas:      Casos de uso relacionados y funciones relacionadas del sistema.
Descripción: Descripción del caso de uso.
Casos de uso
Ejemplo: el siguiente caso de uso describe el proceso de comprar
artículos en una tienda, a través de un terminal de punto de venta.


Caso de uso:   Comprar productos
Actores:       Cliente, cajero
Tipo:          Primario
Descripción:   Un Cliente llega a la caja registradora con los artículos
               que va a comprar. El Cajero registra los artículos y
cobra
               el importe. Al terminar la operación, el Cliente se
marcha
              con los productos.
Es conveniente comenzar con los casos de uso de más alto nivel para
lograr comprender mejor los principales procesos globales.
Casos de uso
Diagrama UML de casos de uso para el sistema de punto de venta:




 Este esquema tiene por objeto ofrecer un diagrama contextual que nos
 permita conocer rápidamente los actores externos de un sistema y las formas
 básicas en que éstos lo utilizan.
Casos de uso

Un diagrama de casos
de uso más refinado
seria el siguiente:
Modelo conceptual

Modelo conceptual

Un modelo conceptual explica los conceptos significativos en un
dominio del problema, identificando los atributos y las asociaciones,
y es la herramienta más importante del análisis orientado a objetos.

Los casos de uso son una importante herramienta para el análisis de
requerimientos, pero realmente no están orientados a objetos. Un
modelo conceptual representa cosas del mundo real, no componentes
del software. En los diagramas UML se muestran conceptos (objetos),
asociaciones entre conceptos (relaciones) y atributos de conceptos
(atributos).
Modelo conceptual
La siguiente figura muestra un modelo conceptual parcial del
dominio de la tienda y las ventas.
Modelo conceptual
  La siguiente lista muestra un conjunto de conceptos idóneos para ser
  incluidos en el modelo conceptual.

      Objetos físicos o tangibles
      Especificaciones, diseño o descripciones de cosas
      Lugares
      Transacciones
      Línea o renglón de un elemento de transacciones
      Rol de las personas
      Contenedores de otras cosas
      Cosas dentro de un contenedor
      Otros sistemas de cómputo o electromecánicos externos al sistema
      Organizaciones
      Eventos
      Procesos
      Reglas y políticas
      Catálogos
      Registros de finanzas, de trabajo, de contratos, de asuntos legales
      Instrumentos y servicios financieros
      Manuales y libros
Modelo conceptual

A partir de esta lista de categorías de conceptos podemos generar
un conjunto de conceptos para nuestro problema del punto de venta:


          TDPV               EspecificaciondeProducto
          Producto           VentasLineadeProductos
          Tienda             Cajero
          Venta              Cliente
          Pago               Gerente
          CatalogodeProductos
Modelo conceptual

Por tanto, el modelo conceptual inicial del sistema de punto
de venta (sin incluir atributos ni asociaciones) sería:
Modelo conceptual

Asociaciones

Una asociación es una relación entre dos conceptos que indica
alguna conexión significativa entre ellos. Las asociaciones útiles
a determinar, suelen incluir el conocimiento de una relación que
ha de preservarse por algún tiempo: puede tratarse de milisegundos
o de años (según el contexto). Por ejemplo, ¿debemos recordar
cuales instancias de VentasLineadeProducto están asociadas a
Venta? Si, porque de lo contrario no sería posible reconstruir la venta,
imprimir la boleta ni calcular el total de la venta.
Modelo conceptual

Para identificar las asociaciones más comunes, la siguiente lista
es de gran ayuda.

A es una parte física o lógica de B
A está lógica o físicamente contenido en B
A es una descripción de B
A es un elemento de línea (o renglón) en una transacción o reporte B
A se conoce/introduce/registra/presenta/captura en B
A es miembro de B
A es una unidad organizacional de B
A usa o dirige a B
A se comunica con B
A se relaciona con una transacción B
A es una transacción relacionada con otra transacción B
A es propiedad de B
Modelo conceptual
La multiplicidad define cuántas instancias de un tipo A pueden asociarse
a una instancia del tipo B en determinado momento. Las expresiones de
multiplicidad son las siguientes:

        *        cero o más, muchos
        1..*     uno o más
        1..40    de uno a cuarenta
        5        exactamente cinco
         2,4,6   exactamente dos, cuatro o seis

Por ejemplo:
Modelo conceptual

Los nombres de las asociaciones deben ser lo más claros posibles, y deben
permitir leer y entender fácilmente las relaciones entre conceptos. Por ej.:
Modelo conceptual
Diagramas de secuencia

 El diagrama de secuencia de un sistema muestra gráficamente los
 eventos que originan los actores y que impactan al sistema.


 La creación de los diagramas de secuencia depende de la formulación
 de los casos de uso.


 Durante la operación del sistema, los actores generan eventos,
 solicitando alguna operación a cambio. Ejemplo: cuando un cajero
 ingresa un código de barras de un artículo, está pidiendo al sistema de
 TPV que registre esa compra. Con este evento se inicia una operación
 en el sistema.
Diagramas de secuencia

 Antes de hacer el diseño lógico de la aplicación de software,
 es conveniente investigar y definir su comportamiento como
 una "caja negra".


 Se estudia el comportamiento del sistema, desde la
 perspectiva de qué es lo que hace, y no de cómo lo hace.


 Definición: El diagrama de secuencia de un sistema es una
 representación que muestra, en determinado escenario de un
 caso de uso, los eventos generados por actores externos, su
 orden y los eventos internos del sistema. En esta fase del
 proyecto, el sistema mismo es una caja negra.
Diagramas de secuencia

 Recordemos el caso de uso Comprar productos:

 Caso de uso:   Comprar productos
 Actores:       Cliente, cajero
 Tipo:          Primario
 Descripción:   Un Cliente llega a la caja registradora con los artículos que va a
                comprar. El Cajero registra los artículos y cobra el importe. Al
                terminar la operación, el Cliente se marcha con los productos.
Diagramas de secuencia

El diagrama de secuencia del caso de uso ComprarProductos
podría ser el siguiente:
Análisis y Diseño OO

Las herramientas usadas en la etapa de análisis (investigación
del problema) se pueden resumir en la siguiente tabla.



Herramienta de análisis             Preguntas que contesta

 Casos de uso             ¿Cuáles son los procesos del dominio?

 Modelo conceptual        ¿Cuáles son los conceptos, los términos?

 Diagramas de secuencia   ¿Cuáles son los eventos y las operac. del sistema?
Diagramas de colaboración

 Diagramas de colaboración

 Los diagramas de interacción (diagramas de secuencia y diagramas
 de colaboración) explican gráficamente cómo los objetos interactúan
 a través de mensajes para realizar las tareas.

 Antes de definir estos diagramas, hay que generar el modelo
 conceptual y los casos de uso reales (estos últimos se generan a
 partir de los casos de uso definidos en el análisis).
Diagramas de colaboración


Los diagramas de colaboración explican gráficamente las interacciones
entre las instancias del modelo (objetos). Por ejemplo:
Diagramas de colaboración


  Diseño de la solución

  Para cada evento del sistema se debe construir un diagrama
  de colaboración cuyo mensaje inicial sea el de sus eventos.
  En el caso del punto de venta, tendremos tres diagramas,
  uno para cada evento: pasarProducto, terminarVenta, y
  efectuarPago.
Diagramas de colaboración
El diagrama de colaboración del caso de uso pasarProducto sería
el siguiente:
Diagramas de clases
Análisis y Diseño OO
Análisis y Diseño OO

Nombre: Modelo-Vista-Controlador (MVC) [Buschmann 96].
Problema: Las interfaces de usuario son especialmente propensas a
cambios de requerimientos. Cuando se extiende la funcionalidad de una
aplicación, se deben modificar cosas, por ejemplo: menús, botones,
ventanas, etc.
Solución: MVC divide una aplicación en tres áreas: procesamiento, entrada y
salida. El componente modelo encapsula los datos y la funcionalidad
principales de la aplicación. El componente Vista despliega la información al
usuario, a partir de los datos del Modelo. Cada Vista tiene un componente
Controlador asociado, que se encarga de recibir las entradas del usuario
(movimiento del mouse, activación de los botones o entradas de teclado).
Esta separación de componentes, permite, entre otras cosas, tener distintas
vistas del mismo modelo.
Análisis y Diseño OO

Ejemplo: La mayoría de aplicaciones con interfaz gráfica utilizan este
esquema. La programación con herramientas visuales como Visual Basic,
JBuilder, Delphi, etc. sigue este esquema.
Beneficios: Es posible tener múltiples vistas de un mismo modelo. Es
posible sincronizar las vistas cuando varios usuarios usan la misma
aplicación (juegos multiusuario, sistemas colaborativos, etc). La separación
conceptual permite intercambiar la vista y el controlador de un determinado
modelo (plug and play).
Análisis y Diseño OO


 El patrón MVC separa dos conceptos fundamentales en toda
 aplicación: la interfaz (vista y controlador) y el modelo (datos y
 funcionalidad).
 Usando este patrón podríamos implementar la interfaz de nuestra
 aplicación de punto de venta como un applet Java, como un programa
 Java stand-alone, y de otras formas (no necesariamente en Java).
Fin

Más contenido relacionado

La actualidad más candente

Uml lenguaje unificado de modelado
Uml lenguaje unificado de modeladoUml lenguaje unificado de modelado
Uml lenguaje unificado de modelado
Marvin Zumbado
 
Especificación de requisitos de software
Especificación de requisitos de softwareEspecificación de requisitos de software
Especificación de requisitos de software
481200601
 
diagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistemadiagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistema
Universidad Tecnológica
 
Cuadro comparativo
Cuadro comparativo Cuadro comparativo
Cuadro comparativo
Seba Briones
 
2. requerimientos del software
2. requerimientos del software2. requerimientos del software
2. requerimientos del software
univ of pamplona
 

La actualidad más candente (20)

Uml lenguaje unificado de modelado
Uml lenguaje unificado de modeladoUml lenguaje unificado de modelado
Uml lenguaje unificado de modelado
 
Desarrollo de un sistema con rup uml
Desarrollo de un sistema con rup umlDesarrollo de un sistema con rup uml
Desarrollo de un sistema con rup uml
 
Uml - Caso práctico
Uml - Caso prácticoUml - Caso práctico
Uml - Caso práctico
 
Especificación de requisitos de software
Especificación de requisitos de softwareEspecificación de requisitos de software
Especificación de requisitos de software
 
2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso
 
Requerimientos Funcionales y no Funcionales
Requerimientos Funcionales y no FuncionalesRequerimientos Funcionales y no Funcionales
Requerimientos Funcionales y no Funcionales
 
diagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistemadiagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistema
 
Modelo Ciclo de Vida Clasico o en Cascada
Modelo Ciclo de Vida Clasico o en CascadaModelo Ciclo de Vida Clasico o en Cascada
Modelo Ciclo de Vida Clasico o en Cascada
 
Analisis de requerimiento
Analisis de requerimientoAnalisis de requerimiento
Analisis de requerimiento
 
Modelos dinamicos Orientado a Objetos
Modelos dinamicos Orientado a ObjetosModelos dinamicos Orientado a Objetos
Modelos dinamicos Orientado a Objetos
 
Cuadro comparativo
Cuadro comparativo Cuadro comparativo
Cuadro comparativo
 
Metodología RUP
Metodología RUPMetodología RUP
Metodología RUP
 
Diagrama de dominio armando
Diagrama de dominio armandoDiagrama de dominio armando
Diagrama de dominio armando
 
8b Curso de POO en java - paso de diagrama clases a java 1
8b Curso de POO en java - paso de diagrama clases a java 18b Curso de POO en java - paso de diagrama clases a java 1
8b Curso de POO en java - paso de diagrama clases a java 1
 
Caso De Uso
Caso De UsoCaso De Uso
Caso De Uso
 
Unidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De UsoUnidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De Uso
 
Diagramas de clases
Diagramas de clasesDiagramas de clases
Diagramas de clases
 
2. requerimientos del software
2. requerimientos del software2. requerimientos del software
2. requerimientos del software
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientos
 
Requerimientos no funcionales
Requerimientos no funcionalesRequerimientos no funcionales
Requerimientos no funcionales
 

Destacado

Diseño orientado a objetos
Diseño orientado a objetosDiseño orientado a objetos
Diseño orientado a objetos
Julio Pari
 
Ppt4 presentacion ip_algoritmia_2011
Ppt4 presentacion ip_algoritmia_2011Ppt4 presentacion ip_algoritmia_2011
Ppt4 presentacion ip_algoritmia_2011
Andres Garcia
 
Proyecto de analisis y diseño
Proyecto de analisis y diseñoProyecto de analisis y diseño
Proyecto de analisis y diseño
dreyco3030
 

Destacado (10)

Diseño orientado a objetos
Diseño orientado a objetosDiseño orientado a objetos
Diseño orientado a objetos
 
02 uml diagramaactividades
02 uml diagramaactividades02 uml diagramaactividades
02 uml diagramaactividades
 
Informe de informatica
Informe de informaticaInforme de informatica
Informe de informatica
 
Ppt4 presentacion ip_algoritmia_2011
Ppt4 presentacion ip_algoritmia_2011Ppt4 presentacion ip_algoritmia_2011
Ppt4 presentacion ip_algoritmia_2011
 
Analisis Y DiseñO Orientado Objetos
Analisis Y DiseñO Orientado ObjetosAnalisis Y DiseñO Orientado Objetos
Analisis Y DiseñO Orientado Objetos
 
6.modelado de los requerimientos escenarios y clases
6.modelado de los requerimientos  escenarios y clases6.modelado de los requerimientos  escenarios y clases
6.modelado de los requerimientos escenarios y clases
 
Modelo de requerimientos
Modelo de requerimientosModelo de requerimientos
Modelo de requerimientos
 
Proyecto de analisis y diseño
Proyecto de analisis y diseñoProyecto de analisis y diseño
Proyecto de analisis y diseño
 
Diagrama de flujo
Diagrama de flujo Diagrama de flujo
Diagrama de flujo
 
El Proyecto de investigación. marco teórico Diapositivas Investigación Cient...
 El Proyecto de investigación. marco teórico Diapositivas Investigación Cient... El Proyecto de investigación. marco teórico Diapositivas Investigación Cient...
El Proyecto de investigación. marco teórico Diapositivas Investigación Cient...
 

Similar a 3 analisis y diseño resumen

10 Clase Captura De Los Requisitos Cap.6
10 Clase Captura De Los Requisitos  Cap.610 Clase Captura De Los Requisitos  Cap.6
10 Clase Captura De Los Requisitos Cap.6
Julio Pari
 
10 Clase Captura De Los Requisitos Cap[1].6
10 Clase Captura De Los Requisitos Cap[1].610 Clase Captura De Los Requisitos Cap[1].6
10 Clase Captura De Los Requisitos Cap[1].6
Julio Pari
 
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO    Contratos Y Casos De Uso RealesUnidad 7 Mad Modelado DiseñO    Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
Sergio Sanchez
 
Introducción a la Programación
Introducción a la ProgramaciónIntroducción a la Programación
Introducción a la Programación
Pablo Parola
 
modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software
Brihany Rossell
 

Similar a 3 analisis y diseño resumen (20)

Diseño orientado a objeto
Diseño orientado a objetoDiseño orientado a objeto
Diseño orientado a objeto
 
Semana13-AOO.ppt
Semana13-AOO.pptSemana13-AOO.ppt
Semana13-AOO.ppt
 
10 Clase Captura De Los Requisitos Cap.6
10 Clase Captura De Los Requisitos  Cap.610 Clase Captura De Los Requisitos  Cap.6
10 Clase Captura De Los Requisitos Cap.6
 
10 Clase Captura De Los Requisitos Cap[1].6
10 Clase Captura De Los Requisitos Cap[1].610 Clase Captura De Los Requisitos Cap[1].6
10 Clase Captura De Los Requisitos Cap[1].6
 
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de usoPrimeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
 
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO    Contratos Y Casos De Uso RealesUnidad 7 Mad Modelado DiseñO    Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
 
Introducción a la Programación
Introducción a la ProgramaciónIntroducción a la Programación
Introducción a la Programación
 
Introducción A La Programación
Introducción A La ProgramaciónIntroducción A La Programación
Introducción A La Programación
 
Guide to the software engineering body of knowledge
Guide to the software engineering body of knowledgeGuide to the software engineering body of knowledge
Guide to the software engineering body of knowledge
 
4 adoo
4 adoo4 adoo
4 adoo
 
Metodologiasad 1
Metodologiasad 1Metodologiasad 1
Metodologiasad 1
 
Ciclo de vida cascada
Ciclo de vida cascadaCiclo de vida cascada
Ciclo de vida cascada
 
Ingenieria De Software
Ingenieria De SoftwareIngenieria De Software
Ingenieria De Software
 
102036902 tesis-jhordan-desarrollode-sistema-de-ventas-para-libreria
102036902 tesis-jhordan-desarrollode-sistema-de-ventas-para-libreria102036902 tesis-jhordan-desarrollode-sistema-de-ventas-para-libreria
102036902 tesis-jhordan-desarrollode-sistema-de-ventas-para-libreria
 
Tema 1 Ingeniería de Requisitos
Tema 1 Ingeniería de RequisitosTema 1 Ingeniería de Requisitos
Tema 1 Ingeniería de Requisitos
 
Desarrollo de aplicaciones con rup y uml
Desarrollo de aplicaciones con rup y umlDesarrollo de aplicaciones con rup y uml
Desarrollo de aplicaciones con rup y uml
 
Metodologia MeRinde
Metodologia MeRindeMetodologia MeRinde
Metodologia MeRinde
 
Iso112 evaluacion a distancia (2012 0) (ed 02) (rpta) mundo motors
Iso112 evaluacion a distancia (2012 0) (ed 02) (rpta) mundo motorsIso112 evaluacion a distancia (2012 0) (ed 02) (rpta) mundo motors
Iso112 evaluacion a distancia (2012 0) (ed 02) (rpta) mundo motors
 
Analisis y diseño de sistemas proceso unificado henriquez malla santiago alberto
Analisis y diseño de sistemas proceso unificado henriquez malla santiago albertoAnalisis y diseño de sistemas proceso unificado henriquez malla santiago alberto
Analisis y diseño de sistemas proceso unificado henriquez malla santiago alberto
 
modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software
 

Más de felixzenon

Sistema control de inventario
Sistema control de inventarioSistema control de inventario
Sistema control de inventario
felixzenon
 
Sistema control de inventario
Sistema control de inventarioSistema control de inventario
Sistema control de inventario
felixzenon
 
Sistema control de inventario
Sistema control de inventarioSistema control de inventario
Sistema control de inventario
felixzenon
 
Sistema control de inventario
Sistema control de inventarioSistema control de inventario
Sistema control de inventario
felixzenon
 
Sistema control de inventario
Sistema control de inventarioSistema control de inventario
Sistema control de inventario
felixzenon
 
Juegos olímpicos de atenas 1896
Juegos olímpicos de atenas 1896Juegos olímpicos de atenas 1896
Juegos olímpicos de atenas 1896
felixzenon
 
Juegos olímpicos de atenas 1896
Juegos olímpicos de atenas 1896Juegos olímpicos de atenas 1896
Juegos olímpicos de atenas 1896
felixzenon
 
Sofware de aplicacion
Sofware de aplicacionSofware de aplicacion
Sofware de aplicacion
felixzenon
 
Sofware de aplicacion
Sofware de aplicacionSofware de aplicacion
Sofware de aplicacion
felixzenon
 

Más de felixzenon (15)

Servidores
ServidoresServidores
Servidores
 
Sistema control de inventario
Sistema control de inventarioSistema control de inventario
Sistema control de inventario
 
Sistema control de inventario
Sistema control de inventarioSistema control de inventario
Sistema control de inventario
 
Sistema control de inventario
Sistema control de inventarioSistema control de inventario
Sistema control de inventario
 
Sistema control de inventario
Sistema control de inventarioSistema control de inventario
Sistema control de inventario
 
Sistema control de inventario
Sistema control de inventarioSistema control de inventario
Sistema control de inventario
 
Juegos olímpicos de atenas 1896
Juegos olímpicos de atenas 1896Juegos olímpicos de atenas 1896
Juegos olímpicos de atenas 1896
 
Juegos olímpicos de atenas 1896
Juegos olímpicos de atenas 1896Juegos olímpicos de atenas 1896
Juegos olímpicos de atenas 1896
 
Sofware de aplicacion
Sofware de aplicacionSofware de aplicacion
Sofware de aplicacion
 
Sofware de aplicacion
Sofware de aplicacionSofware de aplicacion
Sofware de aplicacion
 
Colores html
Colores htmlColores html
Colores html
 
Resumen rup
Resumen rupResumen rup
Resumen rup
 
Resumen rup
Resumen rupResumen rup
Resumen rup
 
Resumen rup
Resumen rupResumen rup
Resumen rup
 
Resumen rup
Resumen rupResumen rup
Resumen rup
 

3 analisis y diseño resumen

  • 2. Introducción Requisitos del usuario Proceso de desarrollo Sistema de software de software • Proceso de desarrollo de software: – Forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quién hace qué, cuándo y cómo). • Objetivos: – Asegurar la producción de software de calidad dentro de plazos y presupuestos predecibles.
  • 3. Introducción Proceso de desarrollo de software Planificación Construcción Aplicación Ciclo de Ciclo de ... desarrollo 1 desarrollo 2 Perfeccionar Análisis Diseño Construcción Pruebas plan De dos semanas a dos meses
  • 4. Introducción Proceso de desarrollo de software Ciclo de Ciclo de Ciclo de ... desarrollo 1 desarrollo 2 desarrollo 3 Caso de uso A: Caso de uso A: Caso de uso B Versión Versión ------- simplificada completa ------- ------- ------- ------- ------- ------- ------- Caso de uso C ------- ------- ------- -------
  • 5. Introducción Proceso de desarrollo de software Planificación Construcción Aplicación Ciclo de Ciclo de ... desarrollo 1 desarrollo 2 Perfeccionar Análisis Diseño Construcción Pruebas plan De dos semanas a dos meses
  • 6. Análisis y Diseño OO Algunas de las tareas a realizarse en la etapa de análisis (dominio del problema) son las siguientes: Perfeccionar Análisis Diseño Construcción Pruebas plan Definir los Definir los casos Crear diagramas Crear modelo requisitos esenciales de uso de casos de uso conceptual Crear el Definir diag. Definir los glosario de secuencia contratos
  • 7. Análisis y Diseño OO Algunas de las tareas a realizarse en la etapa de diseño (dominio de la solución) son las siguientes: Perfeccionar Análisis Diseño Construcción Pruebas plan Definir casos Definir reportes, Perfeccionar la reales de uso interfaz de usuario, arquitectura secuencia de pantallas Definir diag. Definir diagramas Definir esquema de interacción diseño de clases base de datos
  • 8. Caso de estudio Caso de estudio: punto de venta Supongamos como caso de estudio el sistema de una terminal de punto de venta. Esta terminal es un sistema automatizado con el que se registran las ventas y se realizan los pagos. Por lo general este tipo de sistemas comprenden hardware (un computador y un lector de código barras) y software (el sistema que se ejecuta en la terminal).
  • 9. Requisitos Los requisitos Los requisitos son una descripción de las necesidades o deseos de un producto. Se recomienda aquí definir al menos los siguientes puntos: · Panorama general · Metas · Funciones del sistema
  • 10. Requisitos a) Panorama general Este proyecto tiene por objeto crear un sistema de terminal para el punto de venta que se utilizará en las ventas de un supermercado. b) Metas En términos generales, la meta es una mayor automatización del pago en las cajas registradoras, y dar soporte a servicios más rápidos, más baratos y mejores. Concretamente, la meta incluye: · Pago rápido de los clientes. · Análisis rápido y exacto de las ventas. · Control automático del inventario.
  • 11. Requisitos c) Funciones del sistema Las funciones del sistema son lo que éste deberá de hacer. Las funciones pueden clasificarse en tres categorías: evidentes, ocultas y superfluas. Las evidentes deben realizarse, y el usuario debe saber que se han realizado. Las ocultas también deben realizarse, y puede que no sean visibles para el usuario. Las superfluas son opcionales, y su inclusión no repercute significati- vamente en el costo ni en otras funciones.
  • 12. Requisitos Estas son algunas de las funciones del sistema de punto de venta: Ref. Función Categoría R1.1 Registra la venta en proceso (actual): los productos comprados. evidente R1.2 Calcula el total de la venta actual; se incluye el impuesto. evidente R1.3 Captura la información sobre el objeto comprado usando su código de barras, o usando una captura manual del código de producto. evidente R1.4 Reduce las cantidades del inventario cuando se realiza una venta. oculta R1.5 Se registran las ventas efectuadas. oculta R1.6 El cajero debe introducir una identificación y una contraseña para poder utilizar el sistema. evidente R1.7 Ofrece un mecanismo de almacenamiento persistente. oculta R1.8 Ofrece mecanismos de comunicación entre los procesos y entre los sistemas. oculta R1.9 Muestra la descripción y el precio del producto registrado. evidente
  • 13. Casos de uso Casos de uso Los casos de uso requieren tener al menos un conocimiento parcial de los requerimientos del sistema. Un caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso.
  • 14. Casos de uso El formato para la descripción de los casos de uso es el siguiente: Caso de uso: Nombre Actores: Lista de actores (agentes externos) Propósito: Intención del caso de uso Resumen: Repetición del caso de uso de alto nivel o alguna síntesis. Tipo: Primario, secundario u opcional. Esencial o real. Referencias cruzadas: Casos de uso relacionados y funciones relacionadas del sistema. Descripción: Descripción del caso de uso.
  • 15. Casos de uso Ejemplo: el siguiente caso de uso describe el proceso de comprar artículos en una tienda, a través de un terminal de punto de venta. Caso de uso: Comprar productos Actores: Cliente, cajero Tipo: Primario Descripción: Un Cliente llega a la caja registradora con los artículos que va a comprar. El Cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los productos. Es conveniente comenzar con los casos de uso de más alto nivel para lograr comprender mejor los principales procesos globales.
  • 16. Casos de uso Diagrama UML de casos de uso para el sistema de punto de venta: Este esquema tiene por objeto ofrecer un diagrama contextual que nos permita conocer rápidamente los actores externos de un sistema y las formas básicas en que éstos lo utilizan.
  • 17. Casos de uso Un diagrama de casos de uso más refinado seria el siguiente:
  • 18. Modelo conceptual Modelo conceptual Un modelo conceptual explica los conceptos significativos en un dominio del problema, identificando los atributos y las asociaciones, y es la herramienta más importante del análisis orientado a objetos. Los casos de uso son una importante herramienta para el análisis de requerimientos, pero realmente no están orientados a objetos. Un modelo conceptual representa cosas del mundo real, no componentes del software. En los diagramas UML se muestran conceptos (objetos), asociaciones entre conceptos (relaciones) y atributos de conceptos (atributos).
  • 19. Modelo conceptual La siguiente figura muestra un modelo conceptual parcial del dominio de la tienda y las ventas.
  • 20. Modelo conceptual La siguiente lista muestra un conjunto de conceptos idóneos para ser incluidos en el modelo conceptual. Objetos físicos o tangibles Especificaciones, diseño o descripciones de cosas Lugares Transacciones Línea o renglón de un elemento de transacciones Rol de las personas Contenedores de otras cosas Cosas dentro de un contenedor Otros sistemas de cómputo o electromecánicos externos al sistema Organizaciones Eventos Procesos Reglas y políticas Catálogos Registros de finanzas, de trabajo, de contratos, de asuntos legales Instrumentos y servicios financieros Manuales y libros
  • 21. Modelo conceptual A partir de esta lista de categorías de conceptos podemos generar un conjunto de conceptos para nuestro problema del punto de venta: TDPV EspecificaciondeProducto Producto VentasLineadeProductos Tienda Cajero Venta Cliente Pago Gerente CatalogodeProductos
  • 22. Modelo conceptual Por tanto, el modelo conceptual inicial del sistema de punto de venta (sin incluir atributos ni asociaciones) sería:
  • 23. Modelo conceptual Asociaciones Una asociación es una relación entre dos conceptos que indica alguna conexión significativa entre ellos. Las asociaciones útiles a determinar, suelen incluir el conocimiento de una relación que ha de preservarse por algún tiempo: puede tratarse de milisegundos o de años (según el contexto). Por ejemplo, ¿debemos recordar cuales instancias de VentasLineadeProducto están asociadas a Venta? Si, porque de lo contrario no sería posible reconstruir la venta, imprimir la boleta ni calcular el total de la venta.
  • 24. Modelo conceptual Para identificar las asociaciones más comunes, la siguiente lista es de gran ayuda. A es una parte física o lógica de B A está lógica o físicamente contenido en B A es una descripción de B A es un elemento de línea (o renglón) en una transacción o reporte B A se conoce/introduce/registra/presenta/captura en B A es miembro de B A es una unidad organizacional de B A usa o dirige a B A se comunica con B A se relaciona con una transacción B A es una transacción relacionada con otra transacción B A es propiedad de B
  • 25. Modelo conceptual La multiplicidad define cuántas instancias de un tipo A pueden asociarse a una instancia del tipo B en determinado momento. Las expresiones de multiplicidad son las siguientes: * cero o más, muchos 1..* uno o más 1..40 de uno a cuarenta 5 exactamente cinco 2,4,6 exactamente dos, cuatro o seis Por ejemplo:
  • 26. Modelo conceptual Los nombres de las asociaciones deben ser lo más claros posibles, y deben permitir leer y entender fácilmente las relaciones entre conceptos. Por ej.:
  • 28. Diagramas de secuencia El diagrama de secuencia de un sistema muestra gráficamente los eventos que originan los actores y que impactan al sistema. La creación de los diagramas de secuencia depende de la formulación de los casos de uso. Durante la operación del sistema, los actores generan eventos, solicitando alguna operación a cambio. Ejemplo: cuando un cajero ingresa un código de barras de un artículo, está pidiendo al sistema de TPV que registre esa compra. Con este evento se inicia una operación en el sistema.
  • 29. Diagramas de secuencia Antes de hacer el diseño lógico de la aplicación de software, es conveniente investigar y definir su comportamiento como una "caja negra". Se estudia el comportamiento del sistema, desde la perspectiva de qué es lo que hace, y no de cómo lo hace. Definición: El diagrama de secuencia de un sistema es una representación que muestra, en determinado escenario de un caso de uso, los eventos generados por actores externos, su orden y los eventos internos del sistema. En esta fase del proyecto, el sistema mismo es una caja negra.
  • 30. Diagramas de secuencia Recordemos el caso de uso Comprar productos: Caso de uso: Comprar productos Actores: Cliente, cajero Tipo: Primario Descripción: Un Cliente llega a la caja registradora con los artículos que va a comprar. El Cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los productos.
  • 31. Diagramas de secuencia El diagrama de secuencia del caso de uso ComprarProductos podría ser el siguiente:
  • 32. Análisis y Diseño OO Las herramientas usadas en la etapa de análisis (investigación del problema) se pueden resumir en la siguiente tabla. Herramienta de análisis Preguntas que contesta Casos de uso ¿Cuáles son los procesos del dominio? Modelo conceptual ¿Cuáles son los conceptos, los términos? Diagramas de secuencia ¿Cuáles son los eventos y las operac. del sistema?
  • 33. Diagramas de colaboración Diagramas de colaboración Los diagramas de interacción (diagramas de secuencia y diagramas de colaboración) explican gráficamente cómo los objetos interactúan a través de mensajes para realizar las tareas. Antes de definir estos diagramas, hay que generar el modelo conceptual y los casos de uso reales (estos últimos se generan a partir de los casos de uso definidos en el análisis).
  • 34. Diagramas de colaboración Los diagramas de colaboración explican gráficamente las interacciones entre las instancias del modelo (objetos). Por ejemplo:
  • 35. Diagramas de colaboración Diseño de la solución Para cada evento del sistema se debe construir un diagrama de colaboración cuyo mensaje inicial sea el de sus eventos. En el caso del punto de venta, tendremos tres diagramas, uno para cada evento: pasarProducto, terminarVenta, y efectuarPago.
  • 36. Diagramas de colaboración El diagrama de colaboración del caso de uso pasarProducto sería el siguiente:
  • 39. Análisis y Diseño OO Nombre: Modelo-Vista-Controlador (MVC) [Buschmann 96]. Problema: Las interfaces de usuario son especialmente propensas a cambios de requerimientos. Cuando se extiende la funcionalidad de una aplicación, se deben modificar cosas, por ejemplo: menús, botones, ventanas, etc. Solución: MVC divide una aplicación en tres áreas: procesamiento, entrada y salida. El componente modelo encapsula los datos y la funcionalidad principales de la aplicación. El componente Vista despliega la información al usuario, a partir de los datos del Modelo. Cada Vista tiene un componente Controlador asociado, que se encarga de recibir las entradas del usuario (movimiento del mouse, activación de los botones o entradas de teclado). Esta separación de componentes, permite, entre otras cosas, tener distintas vistas del mismo modelo.
  • 40. Análisis y Diseño OO Ejemplo: La mayoría de aplicaciones con interfaz gráfica utilizan este esquema. La programación con herramientas visuales como Visual Basic, JBuilder, Delphi, etc. sigue este esquema. Beneficios: Es posible tener múltiples vistas de un mismo modelo. Es posible sincronizar las vistas cuando varios usuarios usan la misma aplicación (juegos multiusuario, sistemas colaborativos, etc). La separación conceptual permite intercambiar la vista y el controlador de un determinado modelo (plug and play).
  • 41. Análisis y Diseño OO El patrón MVC separa dos conceptos fundamentales en toda aplicación: la interfaz (vista y controlador) y el modelo (datos y funcionalidad). Usando este patrón podríamos implementar la interfaz de nuestra aplicación de punto de venta como un applet Java, como un programa Java stand-alone, y de otras formas (no necesariamente en Java).
  • 42. Fin