Está en la página 1de 20

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


Ingeniería De Software I VI Ciclo

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()

Capítulo II 12 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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

Capítulo II 13 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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.

Capítulo II 14 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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

Capítulo II 15 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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.

Capítulo II 16 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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

Capítulo II 17 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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.).

Capítulo II 18 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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.

Capítulo II 19 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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?

Capítulo II 20 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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.

Capítulo II 21 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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

Capítulo II 22 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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.

Capítulo II 23 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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

Capítulo II 24 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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

Capítulo II 25 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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.

Capítulo II 26 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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.

Capítulo II 27 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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.

Capítulo II 28 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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

Capítulo II 29 Metodologías OO -UML


Ingeniería De Software I VI Ciclo

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).

Capítulo II 30 Metodologías OO -UML