Análisis y Diseño de Sistemas

Prof. Gilberto Elias Vittini

Nombre: Ámbar Rocío Caraballo R. Matrícula: 2019 – 7408 Fecha: 22/07/2020

Análisis y diseño de sistemas orientado a objetos Mediante el uso de UML.

Las técnicas orientadas a objetos funcionan muy bien en situaciones en las que los sistemas
de información complicados pasan a través de un proceso continuo de mantenimiento, adaptación
y rediseño.
El lenguaje unificado de modelado es el mejor conocido como UML, es el estándar que se
utiliza en la industria para modelar sistemas orientados a objetos. El conjunto de herramientas
pertenecientes a éste lenguaje incluye diagramas que permiten la visualización de la construcción
de un sistema orientado a objetos. Cada iteración aborda de manera cada vez más detallada del
diseño del sistema , hasta que las cosas y las relaciones en el sistema estén definidas con claridad
y precisión en documentos UML.
Conceptos orientados a objetos
La programación orientada a objetos difiere de la programación tradicional por
procedimientos en cuanto a que examina los objetos que forman parte de un sistema. Cada objeto
es una representación de alguna cosa o evento real.

Los objetos se pueden definir como entidades; ejemplos de estos son: son clientes, artículos,
pedidos, entre otros.

Las clases son los objetos pertenecientes a un conjunto de elementos similares. En otras palabras
es la plantilla que contiene todas las propiedades y atributos de los objetos que se creen de dicha
clase en otra parte del programa.
Lo que distingue a la programación orientada a objetos (y por ende al análisis y diseño orientado
a objetos) de la programación clásica es la técnica de colocar todos los atributos y métodos de un
objeto dentro de una estructura autocontenida, la clase en sí. Cada clase debe tener un nombre que
la distinga de las demás. Por lo general, los nombres de las clases son sustantivos o frases cortas y
empiezan con mayúscula.

En el diagrama de la parte superior se puede ver como cada clase se va relacionando con otras
por medio de flechas; bueno cada fecha tiene su significado en el caso de las flechas normales
estas representan la herencia entre clases, la cual es otro concepto clave para la programación
orientada a objetos. Las clases pueden tener hijos; es decir, se puede crear una clase a partir de
otra.
CONCEPTOS Y DIAGRAMAS DEL LENGUAJE UNIFICADO DE
MODELADO (UML)

El conjunto de herramientas de UML incluye diagramas que permiten a las personas

visualizar la construcción de un sistema orientado a objetos, algo similar a la forma en que los
planos de construcción permiten a las personas visualizar la construcción de un edificio. Ya sea
que usted trabaje de manera independiente o con un extenso equipo de desarrollo de sistemas, la
documentación que puede crear con UML. Provee un medio efectivo de comunicación entre el
equipo de desarrollo y el equipo de negocios en un proyecto.

Los seis diagramas de UML que se utilizan con más frecuencia son:

1. Un diagrama de casos de uso, que describe la forma en que se utiliza el sistema.

2. Un escenario de caso de uso (aunque técnicamente no es un diagrama). Este escenario es una

articulación verbal de excepciones para el comportamiento principal descrito por el caso de uso
principal.

3. Un diagrama de actividad, que ilustra el flujo de actividades en general. Cada caso de uso puede
crear un diagrama de actividad.

4. Los diagramas de secuencia, que muestran la secuencia de las actividades y las relaciones entre
las clases. Cada caso de uso puede crear uno o más diagramas de secuencia. El diagrama de
comunicación es la alternativa a un diagrama de secuencia, el cual contiene la misma información
pero enfatiza la comunicación en vez de la sincronización.

5. Los diagramas de clases, que muestran las clases y sus relaciones. Los diagramas de secuencia
se utilizan (junto con las tarjetas CRC) para determinar las clases. El diagrama de
generalización/especialización (gen/ spec) es un derivado del diagrama de clases.

6. Los diagramas de estados, que muestran las transiciones de estado. Cada clase puede crear un
diagrama de estados, el cual es útil para determinar los métodos de la clase.

MODELADO DE CASOS DE USO

UML se basa fundamentalmente en una técnica de análisis orientado a objetos conocida

como modelado de casos de uso. Un diagrama de casos de uso es una forma de diagrama de
comportamiento UML mejorado, éste provee a los desarrolladores un panorama sobre lo que desean
los usuarios. Está libre de detalles técnicos o de implementación. Podemos pensar en un caso de
uso como una secuencia de transacciones en un sistema. El modelo de casos de uso se basa en las
interacciones y relaciones de los casos de uso individuales. Un caso de uso siempre describe tres
cosas: un actor que inicia un evento, el evento que desencadena un caso de uso y el caso de uso
que realiza las acciones desencadenadas por el evento. En un caso de uso, un actor que utiliza el
sistema inicia un evento que a su vez genera una serie relacionada de interacciones en el sistema.
Los casos de uso se utilizan para documentar una transacción o evento individual. Como en el
ejemplo a continuación, tenemos el diagrama de un caso de uso de un catálogo telefónico.
DIAGRAMAS DE ACTIVIDAD
Los diagramas de actividad muestran la secuencia de actividades en un proceso, incluyendo
las actividades secuenciales de actividades en un proceso, incluyendo las actividades secuenciales
y paralelas, además de las decisiones que se toman. Por lo general se crea un diagrama de actividad
para un caso de uso y puede mostrar los distintos escenarios posibles.

A continuación podemos ver como es la simbología de los elementos a la hora de hacer un

diagrama de actividades.

Una flecha representa a un evento. Los eventos representan cosas que ocurren en cierto momento y lugar.
Un diamante representa una decisión (también conocida como ramificación) o una fusión. En las decisiones
hay una flecha que entra al diamante y varias que salen de él. Se puede incluir una condición de guardia,
que muestra los valores de la condición. Las fusiones muestran varios eventos que se combinan para formar un evento.

Un rectángulo largo y plano representa una barra de sincronización. Estas barras se utilizan para mostrar las
actividades paralelas, donde puede haber un evento que entre a la barra de sincronización y varios eventos que
salgan de ella, a lo cual se le denomina bifurcación. Una sincronización en la que varios eventos se fusionan en
uno solo se denomina unión. Hay dos símbolos que muestran el inicio y fin del diagrama. El estado inicial se muestra
como un círculo relleno. El estado final se muestra como un círculo negro rodeado por un círculo blanco.

Los rectángulos que rodean otros círculos se denominan carriles. Estos carriles indican particionamiento y se utilizan
para mostrar qué actividades se realizan en cada plataforma, como un navegador, servidor o computadora mainframe;
también muestran las actividades que realizan distintos grupos de usuarios. Los carriles son zonas que pueden describir
tanto la lógica como la responsabilidad de una clase.
Otro ejemplo de un diagrama de Actividad

Los carriles son útiles para mostrar cómo se debe transmitir o convertir datos, tales como los que
van del sitio Web al servidor, o del servidor a la mainframe. Por ejemplo, el diagrama de
actividad de Cambiar registro de estudiante tiene tres carriles.

Los diagramas de actividad no se utilizan para todos los casos. Debe usar diagramas de actividad
cuando:

1. Le ayude a comprender las actividades de un caso de uso.

2. El flujo de control sea complejo.
3. Exista la necesidad de modelar el flujo de trabajo.
4. Haya que mostrar todos los escenarios.
DIAGRAMAS DE SECUENCIA
Un diagrama de interacción puede ser un diagrama de secuencia o un diagrama de
comunicación, ambos de los cuales muestran esencialmente la misma información. Estos
diagramas, junto con los diagramas de clases, se utilizan para la realización de un caso de uso, lo
cual es una forma de lograr o realizar un caso de uso.

Una línea vertical representa la línea de vida de la

clase u objeto, que corresponde al tiempo a partir del
que se creó
hasta el momento en que se destruye. Una X en la
parte inferior de la línea de vida representa el
momento en que
se destruye el objeto. Una barra lateral o un
rectángulo vertical en la línea de vida muestran el
foco de control
cuando el objeto está ocupado haciendo cosas.
Las flechas horizontales muestran mensajes o
señales que se envían entre las clases. Los mensajes
pertenecen
a la clase receptora. Hay algunas variaciones en las
flechas de los mensajes. Las puntas de flecha sólidas
representan llamadas sincrónicas, que son las más
comunes. Éstas se utilizan cuando la clase emisora
espera una
respuesta de la clase receptora y el control se
devuelve a la clase emisora cuando la clase receptora
que recibe el
mensaje termina de ejecutarse. Las medias puntas de
flecha (o abiertas) representan llamadas asíncronas:
aquellas
que se envían sin esperar que la clase emisora las
devuelva.
Ejemplo de un Diagrama de secuencia para la web
DIAGRAMAS DE COMUNICACIÓN

Un diagrama de comunicación consta de tres partes: los objetos (también llamados

participantes), los enlaces de comunicación y los mensajes que se pueden pasar a través
de esos enlaces. Los diagramas de comunicación muestran la misma información que
un diagrama de secuencia, pero pueden ser más difíciles de leer.

Para poder mostrar el orden en el tiempo, debemos indicar un número de secuencia y

describir el mensaje. Un diagrama de comunicación hace énfasis en la organización de
los objetos, mientras que un diagrama de secuencia hace énfasis en el orden de los
mensajes en el tiempo. Un diagrama de comunicación mostrará una ruta para indicar
cómo está un objeto enlazado con otro.
DIAGRAMAS DE CLASES
Las metodologías orientadas a objetos trabajan para descubrir las clases, atributos, métodos y
relaciones entre las clases. Como la programación ocurre a nivel de clase, definir clases es una de
las tareas más importantes del análisis orientado a objetos. Los diagramas de clases muestran las
características estáticas del sistema y no representan ningún procesamiento en especial. Un
diagrama de clases también muestra la naturaleza de las relaciones entre las clases.

En un diagrama de clases, las clases se representan mediante un rectángulo. En el formato más

simple, el rectángulo puede incluir sólo el nombre de la clase, pero también puede incluir atributos
y métodos. Los atributos son lo que la clase conoce sobre las características de los objetos, y los
métodos (también llamados operaciones) son lo que la clase sabe acerca de cómo hacer las cosas.
Los métodos son pequeñas secciones de código que trabajan con los atributos.

Un ejemplo de la creación de un diagrama de clases es el que veremos a continuación, en el cual

se muestra un diagrama de clases de un sistema de gestión de un club de videojuegos:
Sobrecarga de métodos

La sobrecarga de métodos se refiere a incluir el mismo método (u operación) varias veces

en una clase. La firma del método incluye su nombre y los parámetros que incluye. El mismo
método se puede definir más de una vez en una clase dada, siempre y cuando los parámetros que
se envían como parte del mensaje sean distintos; es decir, debe haber una firma de mensaje distinta.
Puede haber un número distintos de parámetros, o éstos pueden ser de un tipo distinto, como un
número en un método y una cadena de texto en otro método.

Tipos de clases

Las clases se dividen en cuatro categorías: de entidad, de interfaz, abstracta y de control.

CLASES DE ENTIDAD

Las clases de entidad representan elementos del mundo real como personas o cosas, por ejemplo.
Las clases de entidad son las entidades representadas en un diagrama de entidad-relación. Las
herramientas CASE como Visible Analyst le permiten crear una clase de entidad de UML a partir
de una entidad en un diagrama E-R. El analista necesita determinar qué atributos debe incluir en
las clases. Cada objeto tiene muchos atributos, pero la clase debe incluir sólo aquellos que la
organización utilice. Por ejemplo, al crear una clase de entidad para un estudiante en una
universidad necesitamos conocer los atributos que identifican al estudiante, como la dirección de
su hogar y del campus al que pertenece, así como el promedio de sus calificaciones, los créditos
totales, etcétera. Si tuviera que llevar el registro del mismo estudiante para una tienda de ropa en
línea, tendría que conocer la información básica de identificación además de otros atributos
descriptivos como las medidas o preferencias de color.

CLASES DE LÍMITE O DE INTERFAZ

Las clases de límite o de interfaz proveen los medios para que los usuarios trabajen con el sistema.
Hay dos amplias categorías de clases de interfaz: humana y de sistema. Una interfaz humana puede
ser una pantalla, una ventana, un formulario Web, un cuadro de diálogo, un menú, un cuadro de
lista u otro control de visualización. También puede ser un teléfono de tonos, código de barras o
cualquier otra forma en que los usuarios puedan interactuar con el sistema. Hay que crear
prototipos de las interfaces humanas (como vimos en el capítulo 6) y a menudo se utiliza un guión
gráfico para modelar la secuencia de interacciones.

CLASES ABSTRACTAS Las clases abstractas son clases que no se pueden instanciar en forma
directa. Las clases abstractas están enlazadas a clases concretas en una relación de
generalización/especialización (gen/spec). Por lo general el nombre de una clase abstracta se
escribe en cursiva.

CLASES DE CONTROL Las clases de control o activas se utilizan para controlar el flujo de
actividades; actúan como un coordinador a la hora de implementar las clases. Para obtener clases
que se puedan reutilizar, un diagrama de clases puede incluir muchas clases de control pequeñas.
A menudo las clases de control se derivan durante el diseño del sistema.
Las capas de presentación, negocios y persistencia en los diagramas de secuencia

En el ejemplo anterior mostramos todas las clases en el mismo diagrama. Al escribir código para
sistemas es útil analizar los diagramas de secuencia como si tuvieran tres capas:

1. La capa de presentación, que representa lo que ve el usuario. Esta capa contiene las clases
de interfaz o de límite.

2. La capa de negocios, que contiene las reglas únicas para esta aplicación. Esta capa
contiene las clases de control.

3. La capa de persistencia o acceso a los datos, que describe la forma de obtener y

almacenar los datos. Esta capa contiene las clases de entidad.

Relaciones

Otra manera de mejorar los diagramas de clases es mostrar las relaciones. Éstas son conexiones
entre las clases, de manera similar a las que se encuentran en un diagrama de entidad-relación. Las
relaciones se muestran como líneas que conectan a las clases en un diagrama de clases. Hay dos
categorías de relaciones: asociaciones y relaciones entre un todo y sus partes.

ASOCIACIONES

El tipo más simple de relación es una asociación, o conexión estructural entre clases u objetos.
Las asociaciones se muestran como una simple línea en un diagrama de clases. Los puntos finales
de la línea se etiquetan con un símbolo que indica la multiplicidad, que es lo mismo que la
cardinalidad en un diagrama de entidad-relación. Un cero representa ninguno, un uno representa
uno y sólo uno; un asterisco representa muchos. La notación 0..1 representa de cero a uno y la
notación 1..* representa de uno a muchos.

Diagramas de generalización/especialización (gen/spec)

Un diagrama de generalización/especialización (gen/spec) se puede considerar un diagrama de

clases mejorado. Algunas veces es necesario separar las generalizaciones de las instancias
específicas. Como vimos al principio de este capítulo, un oso koala es parte de una clase de
marsupiales, que a su vez es parte de una clase de animales. Algunas veces necesitamos diferenciar
si un oso koala es un animal o si es un tipo de animal. Además, un oso koala puede ser un animal
de peluche. Por lo tanto, a menudo es necesario aclarar estas sutilezas.

GENERALIZACIÓN

Una generalización describe una relación entre un tipo general de cosa y un tipo más específico de
cosa. Este tipo de relación se describe comúnmente como una relación “es un”. Por ejemplo, un
auto es un vehículo y un camión es un vehículo. En este caso, el vehículo es la cosa general,
mientras que auto y camión son las cosas más específicas. Las relaciones de generalización se
utilizan para modelar la herencia y la especialización de las clases. A una clase general se le conoce
algunas veces como superclase, clase base o clase padre; a una clase especializada se le llama
subclase, clase derivada o clase hija.

POLIMORFISMO

El polimorfismo (que significa muchas formas) o redefinición de métodos (no es lo mismo que
sobrecarga de métodos) es la capacidad de un programa orientado a objetos de tener varias
versiones de un mismo método con el mismo nombre dentro de una relación superclase/subclase.
La subclase hereda un método padre pero le puede agregar elementos o modificarlo. La subclase
puede cambiar el tipo de los datos, o puede cambiar la forma en que trabaja el método. Por ejemplo,
podría haber un cliente que reciba un descuento adicional por volumen, con lo que se usaría un
método modificado para calcular el total del pedido. Se dice que el método de la subclase redefine
al método de la superclase. Cuando los atributos o métodos se definen más de una vez, se utiliza
el más específico (el más bajo en la jerarquía de clases). El programa compilado recorre la cadena
de clases en busca de los métodos.

CLASES ABSTRACTAS Las clases abstractas son clases generales y se utilizan cuando se
incluye la generalización/ especificación (gen/spec) en el diseño. La clase general se convierte en
la clase abstracta. La clase abstracta no tiene objetos directos o instancias de clase, y se utiliza sólo
en conjunto con clases especializadas. Por lo general las clases abstractas tienen atributos y pueden
tener unos cuantos métodos.

DIAGRAMAS DE ESTADOS

El diagrama de estados, o de transiciones de estado, es otra herramienta para determinar los

métodos de las clases. Se utiliza para examinar los distintos estados que puede tener un objeto.
Se crea un diagrama de estados para una sola clase. Por lo general los objetos se crean, pasan por
cambios y se eliminan o quitan.

Los objetos existen en estos diversos estados, que son las condiciones de un objeto en un momento
específico. Los valores del atributo de un objeto definen el estado en que se encuentra el objeto y
algunas veces hay un atributo tal como Estado del pedido (pendiente, en recolección,
empaquetado, enviado, recibido, etcétera) que indica el estado. Un estado tiene un nombre en el
que cada palabra empieza con mayúscula. El nombre debe ser único y descriptivo. Un estado
también tiene acciones de entrada y de salida: las cosas que el objeto debe hacer cada vez que entra
o sale de un estado específico.
Ejemplo de un diagrama de estados.