Capitulo II UML

Ingeniería De Software I VI Ciclo
2.1METODOLOGÍAS DE DESARROLLO ORIENTADO A

OBJETOS
Las metodologías orientadas a objetos, surgieron a razón de problemas

que se presentaban en las de tipo estructurado, tales como:
 Generación de extensivas líneas de código, lo cual incrementaba el

costo de fabricación del Software.
 No se podía reutilizar el código.
 No daba facilidad al mantenimiento del sistema.
 Cuando se modificaba los componentes en el sistema, se afectaban
los demás componentes del mismo, creando un gran problema.
Como respuesta a estos problemas, se desarrolló las metodologías

orientadas a objetos. En estas metodologías se cobra mucho más
importancia el aspecto de "modelado" del sistema, examinando el
dominio del problema como un conjunto de objetos que interactúan
entres sí.
Existen muchas metodologías tales como: OMT, RUP, OBJECTORY,

FUSION, GRAPPLE, XP, MSF, usando la notación UML del cual
hablaremos mas adelante. Se dice que las metodologías más importantes
son:
o La Metodología RUP es más adaptable para proyectos de largo

plazo.
o La Metodología XP en cambio, se recomienda para proyectos de

corto plazo.
o La Metodología MSF se adapta a proyectos de cualquier

dimensión y de cualquier tecnología.
2.2INTRODUCCIÓN A UML
2.2.1 PARADIGMA BASADO EN OBJETOS
La programación estructurada era la corriente principal en los días

más tempranos del software. Los diseñadores de programas
empezaron desarrollando bloques normales de código para los
procedimiento y luego copiaban ese código en cada aplicación. Si
bien esto redujo el tiempo de desarrollo para las nuevas
Capítulo II 11 Metodologías OO -UML

aplicaciones, era difícil realizar un cambio en un bloque de código,

porque el diseñador tenía que hacer el cambio en todas aquellas
partes donde ese código había sido copiado. La programación
estructurada presento entonces algunos desafíos que la
programación orientada a objetos fue diseñada para resolver.
Con la programación basada en objetos, los diseñadores crean

bloques de código. Los llamados Objetos. Estos objetos se usan
para varias aplicaciones. Si uno de los objetos requiere de una
modificación, el diseñador necesita hacer el cambio una sola vez.
Esta sola característica redujo considerablemente los costos, en la
fabricación de software, Es por ello que en la actualidad las
compañías están apresurándose en adoptar esa tecnología para ser
integradas en sus aplicaciones existentes. De hecho la mayoría de
aplicaciones que se desarrollan hoy en día, son basadas en objetos.
Algunos lenguajes como java, por ejemplo requieren de una
estructura basada en objetos.
El paradigma basado en objetos es una manera diferente de ver las

aplicaciones. Con este enfoque, usted divide una aplicación en
muchos fragmentos cortos y pequeños u objetos, que son entre si
bastante independientes.
2.2.2 CONCEPTOS Y PRINCIPIOS DE ORIENTACIÓN A OBJETOS
A. OBJETOS: es la representación de una entidad sea real o

conceptual. Un objeto puede representar algo concreto (una
persona, un auto, una computadora, etc.), o un concepto (un
proceso químico, una transacción bancaria, una orden de
compra, etc.). Un objeto tiene tres características:
a. Estado: Representado por una colección de propiedades o

atributos, por ejemplo el objeto Curso puede estar en uno
de dos estados: “Abierto” o “Cerrado”.
b. Conducta: Representa todo lo que el objeto puede hacer

(Operaciones), por ejemplo un curso disponible podría
tener las operaciones: AgregarEstudiante() y
EliminarEstudiante()

c. Identidad: Representa la unicidad de un objeto con

respecto a otros objetos, por ejemplo: Matemática 001-
Sección 1 y Matemática 001 Sección 2 son dos objetos del
Sistema de Registro Curso. Aunque ambos cursos están
disponibles, cada uno tiene una única identidad.
En UML, los objetos son representados con rectángulos y el

nombre del objeto es subrayado:
Matematica 001 -Seccion 1
B. CLASES: es una descripción de un grupo de objetos la cual

consta de: propiedades comunes (los atributos), conductas
comunes(los funcionamientos), relaciones comunes y
semántica común. Así una clase es una plantilla para crear
objetos. Cada objeto es una instancia de alguna clase u objeto.
Por ejemplo, la clase “Curso Disponible” puede definirse con
las siguientes características:
i. Atributos: ubicación, horas disponibles.

ii. Operaciones: recuperar ubicación, recuperar horas al día,
agregar estudiante.
Así: Matemática 001 – Sección 1 y Matemática 001 – Sección

2 son objetos pertenecientes a la clase “Curso Disponible”.
Cada objeto debería tener valores para sus atributos y
acceso a las operaciones especificadas en la clase “Curso
Disponible”.
En UML, las clases se representan con rectángulos

divididos en tres partes.
Curso disponible Nombre de clase

-Ubicacion Estructura
+Agregar Estudiante()
Conducta

C. ENCAPSULACIÓN: en los sistemas basados en objetos, la

combinación y empaquetamiento de fragmentos de
información y conducta específica en un objeto se llama
encapsulación.
Los objetos encapsulan sus operaciones y su estado, son islas

de estado y comportamiento.
1. El comportamiento del objeto está definido por las

operaciones.
2. El estado está definido por los datos o atributos del
objeto .
La Encapsulación es un concepto de orientación a objetos que

describe la vinculación de unas operaciones y estado a un
objeto particular. La encapsulación está íntimamente
relacionada con la ocultación de la información, definiendo
qué partes de un objeto son visibles y qué partes están ocultas.
La encapsulación abarca a la ocultación de la información:
• Algunas partes son visibles (el interfaz público)

• Otras partes son ocultas (o privadas)
Ejemplo: “El volante de un auto”, El volante es una interfaz

pública hacia el mecanismo de giro de un coche, la
implementación del coche es privada y sobre ella solo puede
actuar el propio volante.
D. Herencia: es un mecanismo que le permite crear nuevos

objetos basados en otros creados con anterioridad como por
ejemplo: un niño hereda las características de un objeto padre.
Uno de los mayores beneficios de la herencia es la facilidad de

mantenimiento. Por ejemplo: cuando algunos cambios afectan
a todos los mamíferos, solo se efectuara el cambio en el objeto
padre y los objetos hijo heredaran los cambios
automáticamente. Si los mamíferos de repente se convirtieran
en seres de sangre fría, solo el objeto mamífero necesitaría ser
modificado. El gato, perro, humano, ballena, y otros hijos
heredaran automáticamente la característica de seres de sangre
fría.

Mamifero
Gato Perro Ballena Humano
E. POLIMORFISMO: significa tener muchas formas o

aplicaciones de una funcionalidad particular. Como con la
herencia, el polimorfismo puede verse en el mundo natural.
Ejemplo dada la orden o función “Hable()”, un humano puede
contestar “Como esta usted”, un perro puede contestar
“ladrando”, un gato puede contestar “maullado” o
probablemente el mensaje sea ignorado.
En condiciones de un sistema basado en objetos, esto significa

que nosotros podemos tener muchas aplicaciones de una
funcionalidad particular.
Por ejemplo, podríamos estar construyendo un sistema de

dibujos gráficos. Cuando el usuario quiere dibujar algo, sea
una línea, un circulo o rectángulo, el sistema emite una orden
de dibujo. El sistema esta compuesto por muchos tipos de
formas cada uno de los cuales contienen la conducta respectiva
de dibujo. Así, cuando el usuario quiere dibujar un circulo, el
objeto circulo dibuja la orden que es invocada. Usando el
polimorfismo, el sistema deduce como se esta ejecutando y que
tipo de forma esta siendo trazada.
2.3PRINCIPIOS DE UML

Siglas de Unified Modeling Language(Lenguaje Unificado de

Construcción de modelos).
UML es el resultado de los estudios de parte de Grady Booch, James

Rumbaugh e Ivar Jacobson, estos señores apodados como los “tres
amigos”, cada uno de ellos en los años ochenta trabajaron en empresas
distintas con sus propias metodologías de análisis orientada a objetos,
predominando entre sus competidores; sin embargo a mediados de los
años noventa empezaron a intercambian ideas y emprendieron lo que es
hoy el UML. Fueron también los creadores de Rational Software
Corporation.
Después de tantas discusiones fue presentado el proyecto de UML al
OMG (grupo de Administración de Objetos) quienes adoptaron a UML
como estándar en la industria del software y continua evolucionando.
2.3.1 SIMBOLOGÍA
2.3.1.1 PAQUETES
Permiten dividir un modelo, reagrupar y encapsular los

elementos de modelado y se representa con una carpeta con
nombre.
Gráficamente un paquete viene representado como se

indica en la Figura:
Cualquier sistema grande se debe dividir en unidades más

pequeñas, de modo que las personas puedan trabajar con
una cantidad de información limitada, a la vez y de modo
que los equipos de trabajo no interfieran con el trabajo de
los otros.

Los paquetes ofrecen un mecanismo general para la

organización de los modelos/subsistemas agrupando
elementos de modelado. Cada paquete corresponde a un
submodelo (subsistema) del modelo (sistema). Los paquetes
son unidades de organización jerárquica de uso general de
los modelos de UML. Pueden ser utilizados para el
almacenamiento, el control de acceso, la gestión de la
configuración y la construcción de bibliotecas que
contengan fragmentos reutilizables del modelo.
2.3.1.2 CASOS DE USO

Un Caso de Uso es representado por una elipse y es una

descripción de la secuencia de interacciones que se
producen entre un actor y el sistema, cuando el actor usa el
sistema para llevar a cabo una tarea específica.
Representan la funcionalidad del sistema y los requisitos

del sistema desde la perspectiva del usuario.
Los objetivos de los casos de uso son los siguientes:
• Capturar los requisitos funcionales del sistema y

expresarlos desde el punto de vista del usuario.
• Guiar todo el proceso de desarrollo del sistema de
información.
Los casos de uso proporcionan, por tanto, un modo claro y

preciso de comunicación entre cliente y desarrollador.
Desde el punto de vista del cliente proporcionan una visión
de “caja negra” del sistema, esto es, cómo aparece el
sistema desde el exterior sin necesidad de entrar en los
detalles de su construcción. Para los desarrolladores,
suponen el punto de partida y el eje sobre el que se apoya
todo el desarrollo del sistema en sus procesos de análisis y
diseño.
2.3.1.3 ACTORES
Un actor es una entidad externa al sistema que realiza

algún tipo de interacción con el mismo. Se representa
mediante una figura humana dibujada con palotes.
Esta representación sirve tanto para actores que son

personas como para otro tipo de actores (otros sistemas,
sensores, etc.).

Si se habla de usuarios, un actor es el papel que puede

llevar a cabo en cuanto a su forma de interactuar con el
sistema, es decir, un único actor puede representar a
muchos usuarios diferentes y de la misma forma, un
usuario puede actuar como actores diferentes.
2.3.1.4 RELACIONES
Las relaciones pueden tener lugar entre actores y casos de

uso o entre casos de uso.
La relación entre un actor y un caso de uso es una relación

de comunicación, que indica que un actor interviene en el
caso de uso. Normalmente, el actor aporta información para
la realización de un caso de uso o recibe información como
resultado de la realización del mismo, por ello, esta relación
puede ser unidireccional o bidireccional, aunque
generalmente se muestra como bidireccional, ya que no es
necesario especificar en detalle estas relaciones.
La relación entre casos de uso es una relación

unidireccional. Esta relación puede presentar uno de los
dos siguientes tipos: “usa” y “extiende”.
A. LA RELACIÓN “INCLUDE” (INCLUYE). Una

instancia del Caso de uso origen incluye también el
comportamiento descrito por el Caso de Uso destino.
«include» reemplazó al denominado «uses», por
ejemplo: si un actor realiza una interacción con un caso
de uso A, automáticamente lo hará con el caso de uso
B.

B. LA RELACIÓN “EXTEND” (EXTIENDE). Se utiliza

cuando se quiere reflejar un comportamiento opcional
de un caso de uso. Por ejemplo, se tiene el caso de
uso A que representa un comportamiento habitual del
sistema. Sin embargo, dependiendo de algún factor,
este caso de uso puede presentar un comportamiento
adicional o ligeramente diferente, que se podría reflejar
en un caso de uso B. En este caso, habrá una relación
“extiende” del caso de uso B al A.
2.3.2 DIAGRAMAS DE UML
UML permite a las personas desarrollar diferentes tipos de

diagramas visuales que representan varios aspectos de los
sistemas, cada diagrama tiene un propósito y una intencionalidad.
Object Domain apoya el desarrollo de la mayoría, de tales como:
2.3.2.1 DIAGRAMA DE CASO DE USO DEL NEGOCIO
Los diagramas de Caso de Uso de negocio se usan para

representar la funcionalidad proporcionada en conjunto por
una organización. Durante esta etapa, se contestan
preguntas como: ¿Qué hace el negocio? O ¿Por qué estamos
construyendo el sistema?

Estos diagramas se usan extensivamente durante las

actividades de modelado del negocio, no solo para analizar
el contexto del sistema sino también para fundamentar el
por que de la creación de los casos de uso. Estos diagramas
no diferencian entre los procesos manuales y
automatizados; mientras que los Diagramas de Caso de Uso
si se enfocan en los procesos automatizados.
2.3.2.2 DIAGRAMA DE CASOS DE USO
Un diagrama de Casos de Uso muestra las distintas

operaciones que se esperan de una aplicación o sistema y
cómo se relaciona con su entorno (usuarios u otras
aplicaciones).
Los diagramas de caso de uso hacen que se muestren las

interacciones entre los casos de uso y los actores.

Se muestra como ilustración los casos de uso de la máquina

de café.
2.3.2.3 DIAGRAMA DE ACTIVIDADES
Los diagramas de actividad ilustran el flujo de

funcionalidad en un sistema. Estos diagramas definen
donde empieza y donde acaba el flujo del negocio y así
conocer que actividades ocurren durante el flujo y en que
orden ocurren. Sirven para representar transiciones

internas, sin hacer mucho énfasis en transiciones o eventos

externos. Generalmente modelan los pasos de un algoritmo.
Lo principales elementos que debe tener en cuenta

conforme avance a través de un flujo de trabajo:
- Las actividades son representadas por rectángulos

redondeados.
- Hay un estado de arranque o “star state” que
representa el inicio del flujo de trabajo y un estado
“end state” que representa el final del flujo de
trabajo.
- Los puntos de decisión son representados por
rombos.
2.3.2.4 DIAGRAMA DE SECUENCIAS
Los diagramas de secuencia se usan para mostrar el flujo de

la funcionalidad a través de un caso de uso
Un diagrama de secuencia muestra la interacción de un

conjunto de objetos en una aplicación a través del tiempo.

Esta descripción es importante porque puede dar detalle a

los casos de uso, aclarándolos al nivel de mensajes de los
objetos existentes, como también muestra el uso de los
mensajes de las clases diseñadas en el contexto de una
operación.
2.3.2.5 DIAGRAMA DE COLABORACIÓN
Un diagrama de colaboración es una forma de representar

interacción entre objetos. A diferencia de los diagramas de

secuencia, pueden mostrar el contexto de la operación

(cuáles objetos son atributos, cuáles temporales,...) y ciclos
en la ejecución.
2.3.2.6 DIAGRAMA DE CLASES
El diagrama de clases recoge las clases de objetos y sus

asociaciones. En este diagrama se representa la estructura
y el comportamiento de cada uno de los objetos del sistema

y sus relaciones con los demás objetos, pero no muestra

información temporal.
2.3.2.7 DIAGRAMA DE ESTADOS
Muestra el conjunto de estados por los cuales pasa un

objeto durante su vida en una aplicación, junto con los
cambios que permiten pasar de un estado a otro. Mientras
el diagrama de clases muestra un cuadro estático de las
clases y sus relaciones, lo diagramas de estado se usan para
modelar la conducta dinámica del sistema.

En un diagrama de estado encontramos dos estados

especiales, el estado de arranque “Start” y el estado de
parada “Stop”. El estado de arranque es representado por
un punto negro, e indica el estado del objeto cuando es
creado por primera vez. El estado de parada es
representada por un punto negro encerrado en un circulo, y
muestra el estado del objeto justo antes de que se destruya.
2.3.2.8 DIAGRAMA DE COMPONENTES
El diagrama de componentes proporciona una visión física

del modelo, Muestra la organización de los componentes
software, sus interfaces y las dependencias entre ellos.
Hay dos tipos de componentes en el diagrama: los
componentes ejecutables y las bibliotecas de código
Un componente es un módulo de software que puede ser

código fuente, código binario, un ejecutable, o una librería
con una interfaz definida. Una interfaz establece las
operaciones externas de un componente, las cuales
determinan una parte del comportamiento del mismo.
Además se representan las dependencias entre
componentes o entre un componente y la interfaz de otro,
es decir uno de ellos usa los servicios o facilidades del otro.

2.3.2.9 DIAGRAMA DE DESPLIEGUE
El objetivo de estos diagramas es mostrar la disposición de

las particiones físicas del sistema de información y la
asignación de los componentes software a estas particiones.
Es decir, las relaciones físicas entre los componentes
software y hardware en el sistema a entregar.

Ejemplo:
El diagrama representa una arquitectura compuesta por un

servidor central de lógica de negocio y acceso a datos, en un
monitor de teleproceso de tipo XXX, al cual hay conectados
10 servidores departamentales, con clientes (100) e
impresora conectados a cada uno de ellos. No interesa tanto
recoger en el diagrama la infraestructura real (la exactitud
de la configuración, número de procesadores que pueden

cambiar con el tiempo y en principio no afecta ni al diseño

ni a la construcción), como el tipo “genérico” de los
servidores, los volúmenes en el caso de que sean
significativos (por ejemplo: 100 puestos por departamento).

Capitulo II UML

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Capitulo II UML

Caricato da

Copyright:

Formati disponibili

Ingeniería De Software I VI Ciclo

2.1METODOLOGÍAS DE DESARROLLO ORIENTADO A

Las metodologías orientadas a objetos, surgieron a razón de problemas

 Generación de extensivas líneas de código, lo cual incrementaba el

Como respuesta a estos problemas, se desarrolló las metodologías

Existen muchas metodologías tales como: OMT, RUP, OBJECTORY,

o La Metodología RUP es más adaptable para proyectos de largo

o La Metodología XP en cambio, se recomienda para proyectos de

o La Metodología MSF se adapta a proyectos de cualquier

2.2.1 PARADIGMA BASADO EN OBJETOS

La programación estructurada era la corriente principal en los días

Capítulo II 11 Metodologías OO -UML

aplicaciones, era difícil realizar un cambio en un bloque de código,

Con la programación basada en objetos, los diseñadores crean

El paradigma basado en objetos es una manera diferente de ver las

2.2.2 CONCEPTOS Y PRINCIPIOS DE ORIENTACIÓN A OBJETOS

A. OBJETOS: es la representación de una entidad sea real o

a. Estado: Representado por una colección de propiedades o

b. Conducta: Representa todo lo que el objeto puede hacer

Capítulo II 12 Metodologías OO -UML

c. Identidad: Representa la unicidad de un objeto con

En UML, los objetos son representados con rectángulos y el

Matematica 001 -Seccion 1

B. CLASES: es una descripción de un grupo de objetos la cual

i. Atributos: ubicación, horas disponibles.

Así: Matemática 001 – Sección 1 y Matemática 001 – Sección

En UML, las clases se representan con rectángulos

Curso disponible Nombre de clase

Capítulo II 13 Metodologías OO -UML

C. ENCAPSULACIÓN: en los sistemas basados en objetos, la

Los objetos encapsulan sus operaciones y su estado, son islas

1. El comportamiento del objeto está definido por las

La Encapsulación es un concepto de orientación a objetos que

La encapsulación abarca a la ocultación de la información:

• Algunas partes son visibles (el interfaz público)

Ejemplo: “El volante de un auto”, El volante es una interfaz

D. Herencia: es un mecanismo que le permite crear nuevos

Uno de los mayores beneficios de la herencia es la facilidad de

Capítulo II 14 Metodologías OO -UML

Gato Perro Ballena Humano

E. POLIMORFISMO: significa tener muchas formas o

En condiciones de un sistema basado en objetos, esto significa

Por ejemplo, podríamos estar construyendo un sistema de

Capítulo II 15 Metodologías OO -UML

Siglas de Unified Modeling Language(Lenguaje Unificado de

UML es el resultado de los estudios de parte de Grady Booch, James

Permiten dividir un modelo, reagrupar y encapsular los

Gráficamente un paquete viene representado como se

Cualquier sistema grande se debe dividir en unidades más

Capítulo II 16 Metodologías OO -UML

Los paquetes ofrecen un mecanismo general para la

2.3.1.2 CASOS DE USO

Capítulo II 17 Metodologías OO -UML

Un Caso de Uso es representado por una elipse y es una

Representan la funcionalidad del sistema y los requisitos

Los objetivos de los casos de uso son los siguientes:

• Capturar los requisitos funcionales del sistema y

Los casos de uso proporcionan, por tanto, un modo claro y

Un actor es una entidad externa al sistema que realiza

Esta representación sirve tanto para actores que son

Capítulo II 18 Metodologías OO -UML

Si se habla de usuarios, un actor es el papel que puede

Las relaciones pueden tener lugar entre actores y casos de

La relación entre un actor y un caso de uso es una relación