Estado del arte de

Tecnicas basicas de
modelado de objetos

Presenta: Gómez Pérez

Jesús Francisco
Ing. En Sistemas
Computacionales
Horario: 09:00 a 10:00
 2.1 Definición de clases, atributos,
métodos y objetos
Clases

• Las clases son modelos o prototipos que definen

las variables y métodos comunes a todos los
objetos de cierta clase. También se puede decir
que una clase es una plantilla genérica para un
conjunto de objetos de similares características.
Clase
vaso
Cristal

Unicel Plástico
 Métodos
• El método es una implementación específica de una
operación ejecutable por una cierta clase. Un algoritmo
asociado a un objeto (o a una clase de objetos), cuya
ejecución se desencadena tras la recepción de un
“mensaje”. Desde el punto de vista del comportamiento,
es lo que el objeto puede hacer. Un método puede
producir un cambio en las propiedades del objeto, o la
generación de un “evento” con un nuevo mensaje para
otro objeto del sistema.
 Atributos
• Los datos se encapsulan dentro de una clase declarando variables
entre las llaves de apertura y cierre de la declaración de la clase,
variables que se conocen como atributos. Se declaran igual que las
variables locales de un método en concreto.

• Es decir que los atributos son todas las características por las que se
compone un objeto, todos sus comportamientos, que lo diferencian
de los demás objetos, pero que a su vez hacen que interactúen entre
si los objetos.
 Objetos
• Entidad provista de un conjunto de
propiedades o atributos (datos) y de
comportamiento o funcionalidad
(métodos), compuestos por variables y
métodos relacionados. Corresponden
a los objetos reales del mundo que
nos rodea, o a objetos internos del
sistema (programa).
2.2 El modelo como resultado de la
abstracción
• Existe una serie de principios fundamentales para comprender cómo se modela la
realidad al crear un programa bajo el paradigma de la orientación a objetos, uno de los
principales es la abstracción.

• Mediante la abstracción se va modelando la realidad en forma de objetos, para lo cual

se buscan parecidos con la realidad para poder lograr la implementación de objetos del
programa y su correcto funcionamiento.

• Con la abstracción se logra comprender cada característica de cada objeto para al

momento de decidir como será implementado, un correcto uso de la abstracción nos
permitirá obtener todas las ventajas de este modelo orientado a objetos, ya que
sabemos para que sirve cada instancia.
 2.3 El UML como una herramienta de
modelado de objetos
• El Unified Modeling Language es el lenguaje de modelado de sistemas de
software mas utilizado en la actualidad aun cuando no es un estándar oficial
esta respaldado por el OMG (Object Management Group).
•
• Es un lenguaje grafico para visualizar, especificar, construir y documentar un
sistema de software y ofrece un estándar para describir un plano del sistema.
• Este lenguaje permite mas que nada poder centrarnos en el modelo del
sistema que vamos a elaborar, ya que nos permite enfocarnos en las funciones
y aspectos concretos para poder construir y documentar el software.
 2.3 El UML como una herramienta de
modelado de objetos
• Este lenguaje cuenta con distintos tipos de diagramas para el modelaje
de software los cuales están clasificados de la siguiente manera:

• Diagramas de estructura: enfatizan en los elementos que deben existir

en el sistema de modelado.

• -Diagrama de clases
• -Diagrama de componentes
• -Diagrama de objetos
• -Diagrama de estructura compuesta
• -Diagrama de despliegue
• -Diagrama de paquetes
 2.3 El UML como una herramienta de
modelado de objetos
• Diagramas de comportamiento: enfatizan en lo que debe suceder en
el sistema modelado.
• -Diagrama de actividades
• -Diagrama de casos de uso
• -Diagrama de estados

• Diagramas de interacción: un subtipo de diagramas de

comportamiento, que enfatiza sobre el flujo de control y de datos
entre los elementos del sistema modelado.
•
• -Diagrama de secuencia
• -Diagrama de colaboración
• -Diagrama de tiempos
• -Diagrama de vista de interacción
 Casos de uso
Estructuras Basicas

Da bienvenida Clases y objetos

Muestra menú Estructuras
principal Basicas JAVA

Selecciona opción
Bienvenida

Muestra inf. Nombre alumno,

num. control.
Usuario Lee inf. Sistema

Menú
Escoge regresar
o salir
-Est. Seuencial
-Est. Selectivas
-Est. Repetitivas
-Bibliografia
-Salir;

Estructuras Estructuras Estructuras Bibliografia

Secuenciales Selectivas Repetitivas
Informacion
Informacion -if -while
-if-else -do-while
-switch -for
-try-catch

if while

if-else do-while

switch for

try-catch
 Colaboración
Ejecuta Lee Lee
Estructuras Basicas Bienvenida Menu principal

Usuario
Escoge
Escoge Escoge

Escoge

Est. Secuencial Est. Selectiva Est. Repetitiva Bibliografia

Componentes

Bienvenida
Regresa a menú o salir

Menú de selección

Seleccion del
Muestra el tema Regresar o salir?
tema

Salida
 Comunicación
ejecuta
programa lee
Bienvenida Menu Principal

Usuario
escoge escoge opcion
opcion

Actividades Est. secuencial Est. Selectiva Est. Repetitiva

Inicio

Escoge Escoge
opcion opcion

if if-else case try-catch while do-while for

Bienvenida

escoge regresar
o salir

Menú Principal
regresar o salir

Est. Secuencial Est. Selectivas Est. Repetitivas Bibliografia

Fin
 Despliegue

Estructura
Secuencial

If

If-else
Menú Principal Estructuras
Bienvenida
Selectivas
Case Informacion y
ejemplos

Try-catch

Estructuras
Repetitivas While

Do-While Regresar o salir

For
 Estado
inicio

Bienvenida

Menu principal

Est. Repetitivas Est. Selectivas Est. Secuencial

while do-while for

if if-else case try-catch

volver a menu

fin
 Secuencial

Estructuras Menu
Bienvenida
Basicas principal
usuario
ejecuta
Muestra
Muestra

submenu
Pide elegir opcion
Muestra
Elige opcion Submenu Informacion

Pide opcion de submenu

Elige opcion Muestra

informacion Salir o regresar

Pregunta si salir o regresar

Elige regresar a menu o salir

ejecuta opcion
 2.4 Planteamiento del problema

• Primeramente debemos conocer el problema, necesidades o inquietudes,

posteriormente comenzar a hacernos preguntas como ¿Quién? ¿Cómo? ¿Cuándo?
¿Dónde? ¿Por qué?, para poder encaminarnos a resolver dicho problema.
•
• Debe ser una exposición de nuestras necesidades, y no una propuesta de solución. El
solicitante debería indicar qué características son obligatorias, así
• como las que sean opcionales, para evitar restringir en demasía las decisiones de diseño
y evitar describir las características internas del sistema, por cuanto esto le resta
flexibilidad a la implementación. Los estándares de ingeniería del software, tal como una
construcción modular, un diseño adecuado para las pruebas, y la previsión de futuras
extensiones, son también adecuados.
 2.4.1 Analizar el enunciado del
problema
• Es el punto mas importante en la redacción del planteamiento, ya que
en forma declarativa o interrogativa comunica lo que será investigado
y delimita o especifica el problema. Cuando se expresa a través de
una o mas preguntas, hay que cuidar la ambigüedad y la indefinición de
algunos adverbios interrogativos.

• Es necesario analizar determinadamente el problema que se piense

investigar, antes de acometer cualquier otra acción que acarree
gastos, tiempo, o esfuerzo personal
 2.4.2 Identificar funciones del
sistema
• Los investigadores han identificado los problemas y sus causas y han desarrollado reglas
y procedimientos para resolverlos. Cada método de análisis tiene una notación y un
punto de vista únicos. Sin embargo, todos los métodos de análisis están relacionados
por un conjunto de principios fundamentales:

• 1. Representar y comprender el ámbito de información del problema

• 2. Desarrollar los modelos que representen la información, función y el
comportamiento del sistema
• 3. Subdividir los modelos (y el problema) de forma que se descubra los detalles de una
manera progresiva (o jerárquica).
• 4. El proceso de análisis debe ir de la información esencial hacia el detalle de la
implementación.
 2.5 Análisis
• El análisis es una actividad que engloba la mayoría de las tareas que hemos llamado colectivamente
Ingeniería de sistemas basados en computadora. Este se realiza teniendo presentes los siguientes
objetivos:

• Identificar las necesidades

• Evaluar la viabilidad del sistema
• Realizar un análisis técnico
• Asignar funciones
• Establecer restricciones de costo y tiempo
• Crear una definición del sistema que sea la base de todo para el trabajo posterior de la aplicación

• Consta de los siguientes pasos:

• Identificar objetos y clases

• Identificar atributos de objetos y relaciones
• Identificar y depurar relaciones (métodos)
2.5.1 Descubrir objetos en el dominio
del problema
• Los objetos son las unidades básicas de construcción, para conceptualización, diseño o
programación, son instancias organizadas en clases con características comunes. Estas características
comprenden los atributos y procedimientos denominados operaciones o métodos.

• Estos objetos deben estar basados, hasta donde sea posible, en entidades del mundo real y en
conceptos de la aplicación o dominio.

• Hay que identificar objetos potenciales que formaran el diseño y es tan fácil como buscar
sustantivos. A veces no resulta tan obvio ya que los objetos pueden manifestarse de diversas
maneras:

• Cosas
• Entidades externas
• Eventos
• Roles
• Lugares
• Organizaciones
 2.5.2 Identificar los atributos de los
objetos
• Los atributos son propiedades o características de objetos individuales, como
el nombre, velocidad o color. Los atributos no deben ser objetos. Los
atributos suelen corresponderse con nombres seguidos por frases posesivas,
tal como “el color del coche” o “la posición del cursor”.

• Los adjetivos suelen representar valores de atributos específicos, como

pueden ser rojo, encendido o caducado. A diferencia de las clases y de las
asociaciones, es menos probable que los atributos se describan por completo
en la definición del problema.
2.5.3 Identificar métodos en los objetos

• Los métodos son subrutinas que definen la interfaz de una clase, sus
capacidades y comportamiento. Un método ha de tener por nombre
cualquier identificador legal distinto de los ya utilizados por los nombres de la
clase en que está definido. Los métodos se declaran al mismo nivel que las
variables de instancia dentro de una definición de clase.

• Los métodos permiten al programador modular sus programas. Todas las

variables declaradas en las definiciones de métodos son variables locales: sólo
se conocen en el método en el que se definen. Casi todos los métodos tienen
una lista de parámetros que permiten comunicar información entre métodos.
Los parámetros de un método también son variables locales.
2.6 Introducción al diseño de la solución

• El diseño es una actividad en la que se toman decisiones importantes,

frecuentemente de una naturaleza estructural. Con la programación,
comparte los aspectos relativos a la abstracción de la representación de la
información y de las secuencias de procesamiento, pero el nivel de detalle es
muy diferente en ambos casos. El diseño construye representaciones
coherentes y bien planificadas de los programas, centrándose en las
interrelaciones de los componentes de mayor nivel y en las operaciones
lógicas implicadas en los niveles inferiores.
2.6.1 Representación Grafica De Una
Clase
• El objetivo básico de un gráfico es transmitir la información de forma tal que pueda ser captada
rápidamente, de un golpe de vista. Luego, un gráfico debe ser ante todo sencillo y claro, a pesar de
su aspecto artístico, ya que se elabora para ser incluido en un trabajo científico.
• Encontramos muy útil representar de forma grafica los objetos que conforman nuestra aplicación,
cada clase se representa por una caja en la que se realizan tres divisiones.

• En la superior se especifica el nombre del objeto.

• En la intermedia se incluyen las propiedades del objeto.
• En la inferior se indican las operaciones que realiza el objeto.
2.6.2 Diagramas De Interacción Entre
La Aplicación Y Una Clase
• Para la elaboración de un diagrama de interacción es necesario tomar
en cuenta lo siguiente:
•
• las clases son estáticas, forman parte del texto del programa y no
cambian durante su ejecución y los objetos por el contrario son
totalmente dinámicos, se crean, cambian su estado y se destruyen.
 Diagrama de Casos de Uso

• Se emplean para visualizar el comportamiento del sistema, una parte

de el o de una sola clase. De forma que se pueda conocer como
responde esa parte del sistema. El diagrama de uso es muy útil para
definir como debería ser el comportamiento de una parte del sistema,
ya que solo especifica como deben comportarse y no como están
implementadas las partes que define.
 Diagrama de Clases

• En el diagrama de clases definiremos las características de cada una de

las clases, interfaces, colaboraciones y relaciones de dependencia y
generalización. Es decir, es donde daremos rienda suelta a nuestros
conocimientos de diseño orientado a objetos, definiendo las clases e
implementando las ya típicas relaciones de herencia y agregación.
 Diagramas de componentes

• Un diagrama de componentes muestra

la organización y las dependencias
entre un conjunto de componentes.
No es necesario que un diagrama
incluya todos los componentes del
sistema, normalmente se realizan por
partes. Cada diagrama describe un
apartado del sistema.
 Diagramas de despliegue

• En el diagrama de despliegue se indica

la situación física de los componentes
lógicos desarrollados. Es decir se sitúa
el software en el hardware que lo
contiene. Cada Hardware se
representa como un nodo.
 Diagramas de Secuencia

• En el diagrama de secuencia se muestra el orden de las llamadas en el sistema. Se utiliza

un diagrama para cada llamada a representar. Es imposible representar en un solo
diagrama de secuencia todas las secuencias posibles del sistema, por ello se escoge un
punto de partida. El diagrama se forma con los objetos que forman parte de la
secuencia, estos se sitúan en la parte superior de la pantalla, normalmente en la
izquierda se sitúa al que inicia la acción. De estos objetos sale una línea que indica su
vida en el sistema. Esta línea simple se convierte en una línea gruesa cuando representa
que el objeto tiene el foco del sistema, es decir cuando él esta activo.
• En esta figura tenemos cuatro objetos, y un actor, situado a la izquierda que es el que
inicia la acción. Como podemos ver el objeto 1 y el objeto 3 de más a la derecha
aparecen mas abajo que los otros existentes. Esto se debe a que recibe una llamada de
creación. Es decir el objeto no existe en el sistema hasta que recibe la primera petición.
 Diagrama de Actividades

• Un diagrama de actividades es provechoso para entender el comportamiento

de alto nivel de la ejecución de un sistema, sin profundizar en los detalles
internos de los mensajes. Los parámetros de entrada y salida de una acción se
pueden mostrar usando las relaciones de flujo que conectan la acción y un
estado de flujo de objeto.
 2.6.3 Diagramas De Estado De Una
Clase
• Un diagramas de estado representa la secuencia de estados por los que un objeto o una
interacción entre objetos pasa durante su tiempo de vida en respuesta a estímulos
(eventos) recibidos.
• La elaboración de un diagrama de estados para que las clases de objetos tengan un
comportamiento dinámico no trivial, deberá mostrar los sucesos enviados y recibidos
por el objeto. Cada rama del flujo de control es representada por un estado con más
de una transición de salida.
• Un estado identifica un periodo de tiempo del objeto (no instantáneo) en el cual el
objeto está esperando alguna operación, tiene cierto estado característico o puede
recibir cierto tipo de estímulos. Se representa mediante un rectángulo con los bordes
redondeados, que puede tener tres compartimientos: uno para el nombre, otro para el
valor característico de los atributos del objeto en ese estado y otro para las acciones
que se realizan al entrar, salir o estar en un estado (entry, exit o do, respectivamente).