SlideShare una empresa de Scribd logo
INGENIERÌA DE SOFTWARE I
El Lenguaje de Modelamiento Unificado
(UML - Unified Modeling Language) es un
lenguaje gráfico para visualizar, especificar y
documentar cada una de las partes que
comprende el desarrollo de software.
clases
CLASE
     Es la unidad básica que encapsula toda
 la información de un Objeto (un objeto es
 una instancia de una clase). A través de ella
 podemos modelar el entorno en estudio
 (una     Casa,    un  Auto,   una     Cuenta
 Corriente, etc.).
En UML, una clase es representada por
un rectángulo que posee tres divisiones:


                     Superior: Contiene el nombre de la Clase

                     Intermedio: Contiene los atributos (o variables
                     de instancia) que caracterizan a la Clase
                     (pueden ser private, protected o public).

                     Inferior: Contiene los métodos u operaciones,
                     los cuales son la forma como interactúa el
                     objeto con su entorno (dependiendo de la
                     visibilidad: private, protected o public).
Objeto: es una cosa, generalmente extraída del
vocabulario del espacio del problema o del
espacio de la solución.

Atributo: Es una característica concreta de una
clase.

Método: Es una operación concreta de una
determinada clase.
Instancia: Es una manifestación concreta de
una clase
ATRIBUTOS Y MÉTODOS

   Atributos: Los atributos o características de una Clase pueden
    ser de tres tipos, los que definen el grado de comunicación y
    visibilidad de ellos con el entorno, estos son:

    ◦ public (+,     ): Indica que el atributo será visible tanto
      dentro como fuera de la clase, es decir, es accesesible
      desde todos lados.
    ◦ private (-, ): Indica que el atributo sólo será accesible
      desde dentro de la clase (sólo sus métodos lo pueden
      accesar).
    ◦ protected (#, ): Indica que el atributo no será accesible
      desde fuera de la clase, pero si podrá ser accesado por
      métodos de la clase además de las subclases que se
      deriven (ver herencia).
ATRIBUTOS Y MÉTODOS

   Métodos: Los métodos u operaciones de una clase son la forma
    en como ésta interactúa con su entorno, éstos pueden tener las
    características:

    ◦ public (+,   ): Indica que el método será visible tanto
      dentro como fuera de la clase, es decir, es accsesible
      desde todos lados.
    ◦ private (-, ): Indica que el método sólo será accesible
      desde dentro de la clase (sólo otros métodos de la clase
      lo pueden accesar).
    ◦ protected (#, ): Indica que el método no será accesible
      desde fuera de la clase, pero si podrá ser accesado por
      métodos de la clase además de métodos de las
      subclases que se deriven (ver herencia).
RELACIONES    ENTRE CLASES
   Ahora ya definido el concepto de Clase, es
    necesario    explicar    como      se   pueden
    interrelacionar dos o más clases (cada uno
    con características y objetivos diferentes).
   Antes es necesario explicar el concepto de
    cardinalidad de relaciones: En UML, la
    cardinalidad de las relaciones indica el grado
    y nivel de dependencia, se anotan en cada
    extremo de la relación y éstas pueden ser:

                        uno o muchos: 1..* (1..n)
                        0 o muchos: 0..* (0..n)
                        número fijo: m (m denota el número).
Indica que una subclase hereda los métodos y
atributos especificados por una Super
Clase, por ende la Subclase además de poseer
sus propios métodos y atributos, poseerá las
características y atributos visibles de la Super
Clase (public y protected)
Para modelar objetos complejos, no
bastan los tipos de datos básicos que
proveen los lenguajes: enteros, reales y
secuencias de caracteres. Cuando se requiere
componer objetos que son instancias de
clases definidas por el desarrollador de la
aplicación, tenemos dos posibilidades
   Por Valor: Es un tipo de relación estática, en
    donde el tiempo de vida del objeto incluido
    esta condicionado por el tiempo de vida del
    que lo incluye. Este tipo de relación es
    comúnmente llamada Composición (el Objeto
    base se construye a partir del objeto
    incluido, es decir, es "parte/todo").
   Por   Referencia: Es un tipo de relación
    dinámica, en donde el tiempo de vida del
    objeto incluido es independiente del que lo
    incluye. Este tipo de relación es comúnmente
    llamada Agregación (el objeto base utiliza al
    incluido para su funcionamiento).
Ejemplo:




           En donde se destaca que:
           •Un Almacén posee Clientes y Cuentas (los rombos van en el
           objeto que posee las referencias).
           •Cuando se destruye el Objeto Almacén también son
           destruidos los objetos Cuenta asociados, en cambio no son
           afectados los objetos Cliente asociados.
           •La composición (por Valor) se destaca por un rombo relleno.
           •La agregación (por Referencia) se destaca por un rombo
           transparente.
           •La flecha en este tipo de relación indica la navegabilidad del
           objeto referenciado. Cuando no existe este tipo de
           particularidad la flecha se elimina.
La relación entre clases conocida como
Asociación, permite asociar objetos que
colaboran entre si. Cabe destacar que no es
una relación fuerte, es decir, el tiempo de
vida de un objeto no depende del otro.




                Ejemplo
                          Un cliente puede tener asociadas muchas
                          Ordenes de Compra, en cambio una orden de
                          compra solo puede tener asociado un cliente.
   Representa un tipo de relación muy
    particular, en la que una clase es
    instanciada    (su     instanciación es
    dependiente de otro objeto/clase). Se
    denota por una flecha punteada.

   El uso más particular de este tipo de
    relación es para denotar la dependencia que
    tiene una clase de otra
Ejemplo:




    Cabe destacar que el objeto creado (en este caso la
    Ventana gráfica) no se almacena dentro del objeto que lo
    crea (en este caso la Aplicación).
Estos métodos establecieron los fundamentos
para la notación moderna de DOO.

          El método de Rumbaugh.

El diseño de sistema se centra en el esquema
de los componentes que se necesitan para
construir un sistema o producto completo.
El modelo de análisis se divide en
subsistemas, los cuales se asignan a
procesadores y tareas.
 Se define una estrategia para implementar la
  administración de datos.
 Se identifican los recursos y mecanismos de
  control requeridos para accesarlos.
 El diseño de objetos enfatiza el esquema
  detallado de un objeto individual.
 Se seleccionan las operaciones del modelo de
  análisis, y los algoritmos se definen para cada
  operación
   Se representan las estructuras de datos
    apropiadas para atributos y algoritmos.
   Las clases y atributos de clase son diseñados
    de manera que se optimice el acceso a los
    datos,    y    se    mejore     la   eficiencia
    computacional.
Es una versión simplificada del método
propietario Objectory, también desarrollado
por Jacobson.
 En principio, el modelo idealizado de análisis
  se adapta para acoplarse al ambiente del
  mundo real.
 Después los objetos de diseño
  primarios, llamados bloques’, son creados y
  catalogados como bloques de
  interfaz, bloques de entidades y bloques de
  control
   La comunicación entre bloques durante la
    ejecución se define y los bloques se
    organizan en subsistemas.
   La orientacion a objetos es tan iportante para
    el diseño de software que el OMG (Grupo de
    Administracion de Objetos), una coorporacion
    no lucrativa que establece las normas para el
    desarrollo orientado a objetos, predice que
    los ingresos obtenidos por el software
    orientado a objetos seran de 3 millardos de
    dolares en los siguientes tres a cinco años.
   El UML influye en esto permitirle generar
    modelos de objetos faciles de usar y
    comprender para que los desarrolladores
    puedan convertirlos en software.
   Es una descripción de un conjunto de objetos
    similares.
   Una clase es una descripción de un conjunto
    de objetos que comparten los mismos
    atributos,    operaciones,    relaciones    y
    semántica.
   Una clase puede representarse de forma
    esquemática (plegada), con los detalles como
    atributos y operaciones suprimidos, siendo
    entonces tan solo un rectángulo con el
    nombre de la clase
   Gráficamente se representa como      un
    rectángulo que incluye su nombre,   sus
    atributos y sus operaciones

                 VENTANA



                  ORIGEN
                 TAMAÑO



                   ABRIR
                  CERRAR
                  MOVER
                  DIBUJAR
   Una clase activa es igual que una clase,
    excepto que sus objetos representan
    elementos     cuyo     comportamiento      es
    concurrente con otros elementos.
   Se representa igual que una clase pero con
    líneas más gruesas

             GESTOR DE EVENTOS

             SUSPENDER ()
             VACIAR COLA ()
   Los objetos concretos y virtuales, están a
    nuestro alrededor, ellos conforman nuestro
    mundo.
   Un objeto es la instancia de una clase
    (categoría).
   Cuenta con una estructura, es decir atributos
    (propiedades) y acciones.
   Las acciones son todas las actividades que el
    objeto es capaz de realizar .
   Los atributos y acciones, en conjunto se
    conocen como características o rasgos.
   Asociación:
        Es el tipo de relación más básica que indica la
    invocación desde un actor o caso de uso a otra
    operación (caso de uso). Dicha relación se denota
    con una flecha simple .
   Se le puede añadir un pequeño rectángulo negro
    que indique la dirección de la asociación.
   Dependencia o Instanciación
        Es una forma muy particular de relación
    entre clases, en la cual una clase depende de
    otra, es decir, se instancia (se crea). Dicha
    relación se denota con una flecha punteada.
   Generalización
    Este tipo de relación esta orientado exclusivamente para
    casos de uso (y no para actores). Los casos de uso pueden
    tener relaciones con otros casos de uso.

   Los tipos de relaciones más comunes entre casos de uso
    son:
    ◦ <<include>> que especifica una situación en la que un caso de
      uso tiene lugar dentro de otro caso de uso
    ◦ <<extends>> que especifica que en ciertas situaciones, o en
      algún punto (llamado punto de extensión) un caso de uso será
      extendido por otro.

    Generalización que especifica que un caso de uso hereda
    las características del «super» caso de uso, y puede volver
    a especificar algunas o todas ellas de una forma muy
    similar a las herencias entre clases.
   Un sistema de bases de datos es básicamente
    un sistema computarizado para llevar
    registros. Es posible considerar a la propia
    base de datos como una especie de armario
    electrónico para archivar.
   El DBMS es, por mucho, el componente de
    software más importante del sistema en gene
    ral, aunque no es el único
Los sistemas relaciónales están basados en una
teoría formal denominada el modelo de datos
relacional, de acuerdo con el la cual:
 En tablas, los datos son representados por
  medio de filas y estas filas pueden interpretarse
  directamente como proposiciones verdaderas.
 Se proporcionan operadores para operar sobre
  las columnas de las tablas, y estos operadores
  soportan directamente el proceso de inferir
  proposiciones verdaderas adicionales a partir de
  las ya dadas
    la respuesta a estas preguntas depende de si
    el sistema en cuestión es de un solo usuario
    o multi-usuario.
   Compactación: No hay necesidad de archivos en
    papel voluminosos.
   Velocidad: La máquina puede recuperar y
    actualizar datos más rápidamente que un
    humano. En particular, las consultas específicas
    sin mucha elaboración .
   Menos trabajo laborioso; Se puede eliminar gran
    parte del trabajo de llevar los archivos a mano.
   Actualidad: En el momento que la
    necesitemos, tendremos a nuestra disposición
    informa-ción precisa y actualizada
   Los datos pueden compartirse
    Es posible reducir la redundancia
    Es posible (hasta cierto grado) evitar la
    inconsistencia
    Es posible brindar un manejo de
    transacciones
   Es posible mantener la integridad
    Es posible hacer cumplir la seguridad
    Es posible hacer cumplir los estándares
clases
Introducción
      El diagrama de casos de uso representa la
  forma en como un Cliente (Actor) opera con el
  sistema en desarrollo, además de la forma, tipo y
  orden en como los elementos interactúan
  (operaciones o casos de uso).

        Un diagrama de casos de uso consta de los
    siguientes elementos:
   Actor.
   Casos de Uso.
   Relaciones de Uso, Herencia y Comunicación.
Cuando se trabaja con casos de uso, es
importante tener presentes algunas sencillas
reglas:
◦ Cada caso de uso está relacionado como mínimo
  con un actor
◦ Cada caso de uso es un iniciador (es decir, un
  actor)
◦ Cada caso de uso lleva a un resultado relevante
  (un resultado con «valor intrínseco»)
Una definición previa, es que un Actor es
un rol que un usuario juega con respecto al
sistema. Es importante destacar el uso de la
palabra rol, pues con esto se especifica que
un Actor no necesariamente representa a una
persona en particular, sino más bien la labor
que realiza frente al sistema.

                      Esto significa que cuando una
                      persona interactúa con el sistema de
                      diferentes   maneras      (asumiendo
                      diferentes      papeles),      estará
                      representado por varios actores.
Como       ejemplo    a      la     definición
 anterior, tenemos el caso de un sistema de
 ventas en que el rol de Vendedor con
 respecto al sistema puede ser realizado por
 un Vendedor o bien por el Jefe de Local.


                           Un caso de uso describe, —desde
                           el punto de vista de los actores—
                           , un grupo de actividades de un
                           sistema que produce un resultado
                           concreto y tangible.
Jefe de Local   Vendedor
Es una operación/tarea específica que se
realiza tras una orden de algún agente
externo, sea desde una petición de un actor o
bien desde la invocación desde otro caso de
uso.

                     Los casos de uso son descriptores de
                     las interacciones típicas entre los
                     usuarios de un sistema y ese mismo
                     sistema.   Representan   el   interfaz
                     externo del sistema y especifican qué
                     requisitos de funcionamiento debe
                     tener este (recuerde, únicamente el
                     qué, nunca el cómo).
Como una primera aproximación identificamos a
   los actores que interactúan con el sistema:




  Luego, tenemos que un Cliente puede Depositar
Ítems y un Operador puede cambiar la información
   de un ítem o bien puede Imprimir un informe:
Además podemos notar que un ítem puede ser
                  una Botella, un Tarro o una Jaba.




Otro aspecto es la impresión de
comprobantes, que puede ser
realizada después de depositar
algún ítem por un cliente o bien
puede ser realizada a petición de
un operador.
Entonces, el diseño completo del diagrama Use Case es:
clases
clases

Más contenido relacionado

La actualidad más candente

Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clases
jmachado614
 
DIAGRAMA DE CLASES
DIAGRAMA DE CLASESDIAGRAMA DE CLASES
DIAGRAMA DE CLASES
BiingeSof
 
UML
UMLUML
DIAGRAMAS DE CLASE
DIAGRAMAS DE CLASEDIAGRAMAS DE CLASE
DIAGRAMAS DE CLASE
Juan Raul Vergara
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clases
still01
 
Implementación de clases
Implementación de clasesImplementación de clases
Implementación de clases
Fernando Solis
 
Poo Java
Poo JavaPoo Java
Poo Java
eccutpl
 
7 Curso de POO en java - diagrama de clases
7 Curso de POO en java - diagrama de clases7 Curso de POO en java - diagrama de clases
7 Curso de POO en java - diagrama de clases
Clara Patricia Avella Ibañez
 
Conceptos básicos de programación orientada a objetos (poo)
Conceptos básicos de programación orientada a objetos (poo)Conceptos básicos de programación orientada a objetos (poo)
Conceptos básicos de programación orientada a objetos (poo)
Maria Garcia
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Fundamentos de POO
Fundamentos de POOFundamentos de POO
Fundamentos de POO
gueritamala
 
Diagramas Analisis
Diagramas AnalisisDiagramas Analisis
Diagramas Analisis
innovalabcun
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clases
mireya2022
 
Prog.orientada a objeto
Prog.orientada a objetoProg.orientada a objeto
Prog.orientada a objeto
Ruben Balza Moya
 
Encapsulamiento en JAVA-NETBEANS
Encapsulamiento en JAVA-NETBEANSEncapsulamiento en JAVA-NETBEANS
Encapsulamiento en JAVA-NETBEANS
Universidad Tecnológica Intercontinental
 
Programación orientada al objeto
Programación orientada al objetoProgramación orientada al objeto
Programación orientada al objeto
boncastell
 
P.O.O.
P.O.O.P.O.O.
Conceptos de POO (Programacion Orientada a Objetos)
Conceptos de POO (Programacion Orientada a Objetos)Conceptos de POO (Programacion Orientada a Objetos)
Conceptos de POO (Programacion Orientada a Objetos)
Josue Lara Reyes
 
1. introduccion a la programación orientada a objeto (poo)
1.  introduccion a la programación orientada a objeto (poo)1.  introduccion a la programación orientada a objeto (poo)
1. introduccion a la programación orientada a objeto (poo)
Roberto Rojas
 
Conceptos poo
Conceptos pooConceptos poo
Conceptos poo
Xavii Torres
 

La actualidad más candente (20)

Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clases
 
DIAGRAMA DE CLASES
DIAGRAMA DE CLASESDIAGRAMA DE CLASES
DIAGRAMA DE CLASES
 
UML
UMLUML
UML
 
DIAGRAMAS DE CLASE
DIAGRAMAS DE CLASEDIAGRAMAS DE CLASE
DIAGRAMAS DE CLASE
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clases
 
Implementación de clases
Implementación de clasesImplementación de clases
Implementación de clases
 
Poo Java
Poo JavaPoo Java
Poo Java
 
7 Curso de POO en java - diagrama de clases
7 Curso de POO en java - diagrama de clases7 Curso de POO en java - diagrama de clases
7 Curso de POO en java - diagrama de clases
 
Conceptos básicos de programación orientada a objetos (poo)
Conceptos básicos de programación orientada a objetos (poo)Conceptos básicos de programación orientada a objetos (poo)
Conceptos básicos de programación orientada a objetos (poo)
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clases
 
Fundamentos de POO
Fundamentos de POOFundamentos de POO
Fundamentos de POO
 
Diagramas Analisis
Diagramas AnalisisDiagramas Analisis
Diagramas Analisis
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clases
 
Prog.orientada a objeto
Prog.orientada a objetoProg.orientada a objeto
Prog.orientada a objeto
 
Encapsulamiento en JAVA-NETBEANS
Encapsulamiento en JAVA-NETBEANSEncapsulamiento en JAVA-NETBEANS
Encapsulamiento en JAVA-NETBEANS
 
Programación orientada al objeto
Programación orientada al objetoProgramación orientada al objeto
Programación orientada al objeto
 
P.O.O.
P.O.O.P.O.O.
P.O.O.
 
Conceptos de POO (Programacion Orientada a Objetos)
Conceptos de POO (Programacion Orientada a Objetos)Conceptos de POO (Programacion Orientada a Objetos)
Conceptos de POO (Programacion Orientada a Objetos)
 
1. introduccion a la programación orientada a objeto (poo)
1.  introduccion a la programación orientada a objeto (poo)1.  introduccion a la programación orientada a objeto (poo)
1. introduccion a la programación orientada a objeto (poo)
 
Conceptos poo
Conceptos pooConceptos poo
Conceptos poo
 

Similar a clases

Tutorial uml
Tutorial umlTutorial uml
Tutorial uml
Manuel Hormechea
 
encuesta
encuestaencuesta
encuesta
deliamartinez
 
Exposición Diagrama de Clases
Exposición Diagrama de ClasesExposición Diagrama de Clases
Exposición Diagrama de Clases
Universidad Técnica del Norte
 
Clase 17
Clase 17Clase 17
Clase 17
victdiazm
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clases
Nedoww Haw
 
U1 s3 introducción a uml parte 1
U1 s3 introducción a uml parte 1U1 s3 introducción a uml parte 1
U1 s3 introducción a uml parte 1
Giovanni Mézquita Hoyos
 
Diagramas uml
Diagramas umlDiagramas uml
Diagramas uml
Andrei Hortúa
 
Introduccion a UML
Introduccion a UMLIntroduccion a UML
Introduccion a UML
Pablo Andres Cáceres Ferreira
 
31096724 diagrama-de-clases-en-uml
31096724 diagrama-de-clases-en-uml31096724 diagrama-de-clases-en-uml
31096724 diagrama-de-clases-en-uml
Darry Piñeiro
 
Clases 2
Clases 2Clases 2
Clases
ClasesClases
Diagrama de clases y diagrama de objetos
Diagrama de clases y diagrama de objetosDiagrama de clases y diagrama de objetos
Diagrama de clases y diagrama de objetos
Ricardo Garcia
 
PROGRAMACIÓN ORIENTADA A OBJETOS
PROGRAMACIÓN ORIENTADA A OBJETOSPROGRAMACIÓN ORIENTADA A OBJETOS
PROGRAMACIÓN ORIENTADA A OBJETOS
GREINDER MARCHENA & LIZ VASQUEZ
 
Asociaciones entre objetos-generalización especialización
Asociaciones entre objetos-generalización especializaciónAsociaciones entre objetos-generalización especialización
Asociaciones entre objetos-generalización especialización
UVM
 
Análisis y diseño de sistemas de información
Análisis y diseño de sistemas de informaciónAnálisis y diseño de sistemas de información
Análisis y diseño de sistemas de información
jovy2905
 
Introducción a las bases de datos relacionales
Introducción a las bases de datos relacionalesIntroducción a las bases de datos relacionales
Introducción a las bases de datos relacionales
kdulcey
 
Cap3.0
Cap3.0Cap3.0
Programacion orientada a objetos
Programacion orientada a objetosProgramacion orientada a objetos
Programacion orientada a objetos
Angel Laverde ID
 
Diagramas de clases_y_casos_de_uso
Diagramas de clases_y_casos_de_usoDiagramas de clases_y_casos_de_uso
Diagramas de clases_y_casos_de_uso
Gomez Gomez
 
D Iagramas U Ml
D Iagramas U MlD Iagramas U Ml
D Iagramas U Ml
jessica
 

Similar a clases (20)

Tutorial uml
Tutorial umlTutorial uml
Tutorial uml
 
encuesta
encuestaencuesta
encuesta
 
Exposición Diagrama de Clases
Exposición Diagrama de ClasesExposición Diagrama de Clases
Exposición Diagrama de Clases
 
Clase 17
Clase 17Clase 17
Clase 17
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clases
 
U1 s3 introducción a uml parte 1
U1 s3 introducción a uml parte 1U1 s3 introducción a uml parte 1
U1 s3 introducción a uml parte 1
 
Diagramas uml
Diagramas umlDiagramas uml
Diagramas uml
 
Introduccion a UML
Introduccion a UMLIntroduccion a UML
Introduccion a UML
 
31096724 diagrama-de-clases-en-uml
31096724 diagrama-de-clases-en-uml31096724 diagrama-de-clases-en-uml
31096724 diagrama-de-clases-en-uml
 
Clases 2
Clases 2Clases 2
Clases 2
 
Clases
ClasesClases
Clases
 
Diagrama de clases y diagrama de objetos
Diagrama de clases y diagrama de objetosDiagrama de clases y diagrama de objetos
Diagrama de clases y diagrama de objetos
 
PROGRAMACIÓN ORIENTADA A OBJETOS
PROGRAMACIÓN ORIENTADA A OBJETOSPROGRAMACIÓN ORIENTADA A OBJETOS
PROGRAMACIÓN ORIENTADA A OBJETOS
 
Asociaciones entre objetos-generalización especialización
Asociaciones entre objetos-generalización especializaciónAsociaciones entre objetos-generalización especialización
Asociaciones entre objetos-generalización especialización
 
Análisis y diseño de sistemas de información
Análisis y diseño de sistemas de informaciónAnálisis y diseño de sistemas de información
Análisis y diseño de sistemas de información
 
Introducción a las bases de datos relacionales
Introducción a las bases de datos relacionalesIntroducción a las bases de datos relacionales
Introducción a las bases de datos relacionales
 
Cap3.0
Cap3.0Cap3.0
Cap3.0
 
Programacion orientada a objetos
Programacion orientada a objetosProgramacion orientada a objetos
Programacion orientada a objetos
 
Diagramas de clases_y_casos_de_uso
Diagramas de clases_y_casos_de_usoDiagramas de clases_y_casos_de_uso
Diagramas de clases_y_casos_de_uso
 
D Iagramas U Ml
D Iagramas U MlD Iagramas U Ml
D Iagramas U Ml
 

clases

  • 2. El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software.
  • 4. CLASE Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).
  • 5. En UML, una clase es representada por un rectángulo que posee tres divisiones: Superior: Contiene el nombre de la Clase Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public). Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).
  • 6. Objeto: es una cosa, generalmente extraída del vocabulario del espacio del problema o del espacio de la solución. Atributo: Es una característica concreta de una clase. Método: Es una operación concreta de una determinada clase. Instancia: Es una manifestación concreta de una clase
  • 7. ATRIBUTOS Y MÉTODOS  Atributos: Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son: ◦ public (+, ): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesesible desde todos lados. ◦ private (-, ): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar). ◦ protected (#, ): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia).
  • 8. ATRIBUTOS Y MÉTODOS  Métodos: Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características: ◦ public (+, ): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados. ◦ private (-, ): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden accesar). ◦ protected (#, ): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia).
  • 9. RELACIONES ENTRE CLASES  Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes).  Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser: uno o muchos: 1..* (1..n) 0 o muchos: 0..* (0..n) número fijo: m (m denota el número).
  • 10. Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected)
  • 11. Para modelar objetos complejos, no bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades
  • 12. Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo").
  • 13. Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).
  • 14. Ejemplo: En donde se destaca que: •Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias). •Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados. •La composición (por Valor) se destaca por un rombo relleno. •La agregación (por Referencia) se destaca por un rombo transparente. •La flecha en este tipo de relación indica la navegabilidad del objeto referenciado. Cuando no existe este tipo de particularidad la flecha se elimina.
  • 15. La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro. Ejemplo Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente.
  • 16. Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.  El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra
  • 17. Ejemplo: Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se almacena dentro del objeto que lo crea (en este caso la Aplicación).
  • 18. Estos métodos establecieron los fundamentos para la notación moderna de DOO. El método de Rumbaugh. El diseño de sistema se centra en el esquema de los componentes que se necesitan para construir un sistema o producto completo.
  • 19. El modelo de análisis se divide en subsistemas, los cuales se asignan a procesadores y tareas.  Se define una estrategia para implementar la administración de datos.  Se identifican los recursos y mecanismos de control requeridos para accesarlos.  El diseño de objetos enfatiza el esquema detallado de un objeto individual.  Se seleccionan las operaciones del modelo de análisis, y los algoritmos se definen para cada operación
  • 20. Se representan las estructuras de datos apropiadas para atributos y algoritmos.  Las clases y atributos de clase son diseñados de manera que se optimice el acceso a los datos, y se mejore la eficiencia computacional.
  • 21. Es una versión simplificada del método propietario Objectory, también desarrollado por Jacobson.  En principio, el modelo idealizado de análisis se adapta para acoplarse al ambiente del mundo real.  Después los objetos de diseño primarios, llamados bloques’, son creados y catalogados como bloques de interfaz, bloques de entidades y bloques de control
  • 22. La comunicación entre bloques durante la ejecución se define y los bloques se organizan en subsistemas.
  • 23. La orientacion a objetos es tan iportante para el diseño de software que el OMG (Grupo de Administracion de Objetos), una coorporacion no lucrativa que establece las normas para el desarrollo orientado a objetos, predice que los ingresos obtenidos por el software orientado a objetos seran de 3 millardos de dolares en los siguientes tres a cinco años.
  • 24. El UML influye en esto permitirle generar modelos de objetos faciles de usar y comprender para que los desarrolladores puedan convertirlos en software.
  • 25. Es una descripción de un conjunto de objetos similares.  Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica.  Una clase puede representarse de forma esquemática (plegada), con los detalles como atributos y operaciones suprimidos, siendo entonces tan solo un rectángulo con el nombre de la clase
  • 26. Gráficamente se representa como un rectángulo que incluye su nombre, sus atributos y sus operaciones VENTANA ORIGEN TAMAÑO ABRIR CERRAR MOVER DIBUJAR
  • 27. Una clase activa es igual que una clase, excepto que sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos.  Se representa igual que una clase pero con líneas más gruesas GESTOR DE EVENTOS SUSPENDER () VACIAR COLA ()
  • 28. Los objetos concretos y virtuales, están a nuestro alrededor, ellos conforman nuestro mundo.  Un objeto es la instancia de una clase (categoría).  Cuenta con una estructura, es decir atributos (propiedades) y acciones.  Las acciones son todas las actividades que el objeto es capaz de realizar .  Los atributos y acciones, en conjunto se conocen como características o rasgos.
  • 29. Asociación: Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple .  Se le puede añadir un pequeño rectángulo negro que indique la dirección de la asociación.
  • 30. Dependencia o Instanciación Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.
  • 31. Generalización Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores). Los casos de uso pueden tener relaciones con otros casos de uso.  Los tipos de relaciones más comunes entre casos de uso son: ◦ <<include>> que especifica una situación en la que un caso de uso tiene lugar dentro de otro caso de uso ◦ <<extends>> que especifica que en ciertas situaciones, o en algún punto (llamado punto de extensión) un caso de uso será extendido por otro. Generalización que especifica que un caso de uso hereda las características del «super» caso de uso, y puede volver a especificar algunas o todas ellas de una forma muy similar a las herencias entre clases.
  • 32. Un sistema de bases de datos es básicamente un sistema computarizado para llevar registros. Es posible considerar a la propia base de datos como una especie de armario electrónico para archivar.  El DBMS es, por mucho, el componente de software más importante del sistema en gene ral, aunque no es el único
  • 33. Los sistemas relaciónales están basados en una teoría formal denominada el modelo de datos relacional, de acuerdo con el la cual:  En tablas, los datos son representados por medio de filas y estas filas pueden interpretarse directamente como proposiciones verdaderas.  Se proporcionan operadores para operar sobre las columnas de las tablas, y estos operadores soportan directamente el proceso de inferir proposiciones verdaderas adicionales a partir de las ya dadas
  • 34. la respuesta a estas preguntas depende de si el sistema en cuestión es de un solo usuario o multi-usuario.
  • 35. Compactación: No hay necesidad de archivos en papel voluminosos.  Velocidad: La máquina puede recuperar y actualizar datos más rápidamente que un humano. En particular, las consultas específicas sin mucha elaboración .  Menos trabajo laborioso; Se puede eliminar gran parte del trabajo de llevar los archivos a mano.  Actualidad: En el momento que la necesitemos, tendremos a nuestra disposición informa-ción precisa y actualizada
  • 36. Los datos pueden compartirse  Es posible reducir la redundancia  Es posible (hasta cierto grado) evitar la inconsistencia  Es posible brindar un manejo de transacciones  Es posible mantener la integridad  Es posible hacer cumplir la seguridad  Es posible hacer cumplir los estándares
  • 38. Introducción El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso). Un diagrama de casos de uso consta de los siguientes elementos:  Actor.  Casos de Uso.  Relaciones de Uso, Herencia y Comunicación.
  • 39. Cuando se trabaja con casos de uso, es importante tener presentes algunas sencillas reglas: ◦ Cada caso de uso está relacionado como mínimo con un actor ◦ Cada caso de uso es un iniciador (es decir, un actor) ◦ Cada caso de uso lleva a un resultado relevante (un resultado con «valor intrínseco»)
  • 40. Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema. Esto significa que cuando una persona interactúa con el sistema de diferentes maneras (asumiendo diferentes papeles), estará representado por varios actores.
  • 41. Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local. Un caso de uso describe, —desde el punto de vista de los actores— , un grupo de actividades de un sistema que produce un resultado concreto y tangible. Jefe de Local Vendedor
  • 42. Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso. Los casos de uso son descriptores de las interacciones típicas entre los usuarios de un sistema y ese mismo sistema. Representan el interfaz externo del sistema y especifican qué requisitos de funcionamiento debe tener este (recuerde, únicamente el qué, nunca el cómo).
  • 43. Como una primera aproximación identificamos a los actores que interactúan con el sistema: Luego, tenemos que un Cliente puede Depositar Ítems y un Operador puede cambiar la información de un ítem o bien puede Imprimir un informe:
  • 44. Además podemos notar que un ítem puede ser una Botella, un Tarro o una Jaba. Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún ítem por un cliente o bien puede ser realizada a petición de un operador.
  • 45. Entonces, el diseño completo del diagrama Use Case es: