Estndares para la creacin de software

Un estndar contiene un conjunto de procesos, tareas y actividades diseadas que

son utilizadas en los proyectos de desarrollo de software, los cuales estn acordes con
metodologas normalizadas.
Los dos estndares ms difundidos en la actualidad, con los cuales es posible
asegurar la funcionalidad, usabilidad, fiabilidad, eficiencia, mantenibilidad, portabilidad y
conformidad en todo nivel, son CMMI (modelo para medir capacidades y madurez de los
procesos) y las Normas ISO 9000 (referentes a los modelos de calidad). En ellas es posible
encontrar especificaciones para asegurar la calidad de un producto de software. Estos
estndares estn normalmente asociados a proyectos de gran envergadura y complejidad,
lo que implica que el equipo de desarrollo debe poseer experiencia y un nivel de
abstraccin mayor. Es por eso que existen estndares como UML y RUP que, igualmente,
proponen modelos de desarrollo claramente definidos, pero son usados con frecuencia en
desarrollo de productos de software en los que se necesita privilegiar el tiempo. Es comn,
hoy en da, contar con stas y otras metodologas conocidas como metodologas giles.

UML
La relacin de los objetos y su comportamiento puede ser vista desde distintas aristas:
segn la percepcin de quien realiza el estudio, o bien de quien hace entrega de la
informacin. Pero dicha relacin puede tornarse subjetiva si no se realiza utilizando modelos
definidos y universales que representen esa problemtica en forma concreta. Para ello se ha
definido el Lenguaje de Modelado Unificado UML (Unified Model Language), que
corresponde a un lenguaje visual que se basa en la utilizacin de smbolos representativos,
que permiten disear, construir y documentar cualquier prototipo de software.

UML permite la representacin de un sistema desde el punto de vista esttico y/o

dinmico, siendo la parte esttica representada por diagramas de relaciones entre objetos,

INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

y la dinmica la que permite mostrar, entre otros, el flujo de la informacin y el

comportamiento de los objetos partes del sistema.
UML ha sido creado como estndar para el modelamiento de soluciones, por tanto,
puede ser aplicado en cualquier mbito, no solo desde el punto de vista computacional. Su
estructura permite tener una visin completa del proyecto, aplicando para ello las tcnicas
definidas en su estructura.
UML ha sido aprobado como estndar por la ISO desde el ao 2005. (ISO/IEC
19501:2005 Information technology Open Distributed Processing Unified Modeling
Language (UML) Versin 1.4.2 ).

El propsito de los diagramas UML, fundamentalmente, se basa en:

Desarrollar soluciones visuales que permitan la creacin de modelos significativos.

Permitir la extensin y especializacin de dichos modelos.

Ser independientes al proceso de desarrollo en lenguajes de programacin.

Entregar una base formal para entender el lenguaje de modelado en s.

Incrementar el uso de tecnologas orientadas a objetos.

Permitir el desarrollo en mltiples plataformas o frameworks.

Usar buenas prcticas en el desarrollo de prototipos o proyectos de gran

envergadura.

INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

Diagramas UML

UML permite modelar los aspectos estticos y dinmicos de un sistema. Se distinguen

las siguientes categoras de diagramas:

Diagramas de estructura.

Diagrama de comportamientos.

Diagramas de interaccin.

Diagrama de tiempo.

Diagramas de estructura
Los diagramas de estructura permiten visualizar el conjunto de clases y objetos
relevantes, que forman parte del sistema, indicando las relaciones existentes entre ellos.
Los diagramas que pertenecen a esta categora son:

Diagrama de clases.

Diagrama de objetos.

Diagrama de estructura compuesta.

Diagrama de componentes.

Diagrama de despliegue.

Diagrama de paquetes.

Diagrama de clases: este diagrama es de tipo esttico y describe la estructura de un

sistema indicando sus clases, atributos, mtodos y las relaciones entre ellos.

INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

Se compone de los siguientes elementos:

Una vez definida la clase es necesario identificar atributos y mtodos.

Los atributos son las caractersticas que permiten saber acerca de la clase, en sntesis:
qu es, por su parte, los mtodos son los comportamientos a los cuales puede responder la
clase en determinadas situaciones, es decir: qu hace. A continuacin se observa un
ejemplo:

Atributos

Mtodos

La figura muestra una clase identificada por una cantidad finita de atributos y
mtodos.
Ahora bien, las clases no son objetos aislados, por lo tanto, necesitan interactuar con
otros objetos, esta interaccin se conoce como asociacin de clases. La asociacin de
clases permite identificar qu clases se relacionan y cul es su multiplicidad. Esto quiere
decir la cantidad de veces que puede ocurrir una en relacin a la otra. Es correcto decir
que un cliente se asocia a una cuenta bancaria, o bien una cuenta bancaria pertenece a
un cliente.

INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

En la figura se aprecia la relacin entre un cliente y una cuenta. Para que exista dicha
cuenta es necesario que exista un cliente asociado a ella.

En el ejemplo anterior se denota la relacin existente entre un cliente y una cuenta,

por tanto, es posible definir en qu sentido estos objetos estn relacionados, indicando para
ello el concepto de multiplicidad, que indica la o las ocurrencias asociadas a cada objeto y
en qu sentido es posible verificarlas. stas son:

Uno a uno: existe cuando la asociacin de clases es uno a uno en ambos sentidos.

Por ejemplo: un pas posee una capital y ese capital corresponde solo a un pas.

Uno a muchos: un objeto puede tener asociacin a ms de un tipo, perteneciente a

otra clase.

Por ejemplo: un cliente puede poseer cero, una o muchas cuentas.

INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

Uno a una cantidad limitada de elementos: la asociacin est acotada a dos objetos,
de los cuales uno de ellos debe tener una cantidad mnima y mxima de ocurrencias
durante su existencia.

En el escenario de atencin mdica, por ejemplo, un doctor debe atender diariamente un

mnimo de 2 pacientes y un mximo de 5. No sera vlida de considerar la atencin en el
eventual caso de que no existiesen pacientes, pues en ese escenario las ocurrencias seran
nulas.

Muchos a muchos: la asociacin es uno a muchos en ambos sentidos.

Por ejemplo, un doctor puede tener ms de una especialidad y esa especialidad la pueden
tener muchos doctores, tal como lo muestra la siguiente figura:

Diagrama de objetos
Una vez definidas las clases y sus asociaciones es posible construir el diagrama de
objetos, que corresponde a las instancias de una clase, por tanto, es posible representar sus
atributos con valores especficos (los que ya han sido definidos en la clase). Este diagrama
no representa relaciones ni multiplicidades, sino que muestra al objeto tal cmo se vera si
fuese construido.
INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

La siguiente imagen denota un ejemplo que indica una instancia de la clase Cliente,
llamada Mi cliente, indicando los valores especficos para cada atributo definido en la clase.

Diagrama de estructura compuesta

Corresponde a un tipo de diagrama de estructura esttica, que permite mostrar la
estructura interna de una clase y las colaboraciones que existen en ella. Normalmente, se
incluyen elementos internos, mediante los cuales, las partes internas pueden interactuar unas
con otras y, a su vez, estas partes pueden colaborar con el mundo exterior.
La siguiente imagen expone la estructura compuesta de una clase llamada Vehculo.

INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

Se sabe que parte de los componentes internos del vehculo son las ruedas y el motor,
pero queda de manifiesto que dicho motor solo mueve las ruedas delanteras del objeto,
situacin que no puede ser observada si este elemento hubiese sido visto solo como objeto.

Diagrama de componentes
Permite modelar los elementos (componentes) del software y las dependencias que
existen entre ellos. Los componentes fsicos incluyen, por lo general, archivos, bibliotecas
compartidas, mdulos o paquetes.
Previo a la elaboracin de este diagrama, es necesario disponer del diagrama de
clases y haber identificado sus respectivos mtodos, los cuales pasarn a ser mdulos de
cdigo, independiente que en definitiva sern los componentes del diagrama.
Para que un componente pueda interactuar con otro es necesario crear una interfaz, que
permite la comunicacin entre ellos.
La siguiente figura define un componente llamado MiComponente.

El Componente1 requiere funcionalidad del Componente2 usando una interfaz.

Imagen 10:
Diagrama de despliegue: este diagrama permite identificar la relacin que tendrn los
componentes del software y hardware dentro del sistema. Los elementos que este diagrama
utiliza son nodos y componentes.
INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

En el ejemplo se ilustra un componente para bases de datos y otro componente que

acta en la parte web. El servidor de base de datos realiza todas las acciones pertinentes a
la manipulacin de los datos contenidos en algn lugar fsico, mientras que las peticiones
web son almacenadas en otro repositorio, por medio del componente historial del
contenedor web.

Imagen 11:
Los componentes pueden estar distribuidos fsicamente, por lo tanto, la comunicacin
entre ellos es de vital importancia a la hora de necesitar respuestas por parte de uno de
ellos.
Diagrama de paquete
Permite visualizar la divisin del sistema como agrupaciones lgicas, mostrando las
dependencias de esas agrupaciones. Un paquete es un esquema parecido a un
directorio, que tiene una jerarqua pre-definida.
Los paquetes deben estar organizados para optimizar la coherencia que existe dentro
de ellos, minimizando de esta manera el acoplamiento externo entre los paquetes.
Un error de dependencia entre paquetes podra afectar el normal curso o funcionamiento
del sistema, por lo cual es necesario dejar en claro cul es el espectro de funcionalidad de
cada paquete y con quien tiene interaccin.

INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

10

La dependencia que tenga un paquete de otro tendr exclusiva relacin con la

funcionalidad y la prioridad que tengan los elementos que definen en s el paquete.
Por ejemplo, es imposible que un componente de pago entregue una respuesta del
resultado de una operacin del mismo, si el componente que realiza, la conexin a la base
de datos para validar la informacin, no ha sido inicializado.
En tal caso, es vlido acotar que, si la lgica ha sido mal diseada, puede que el
sistema simplemente no funcione, dado que la separacin de la funcionalidad no ha sido
realizada en forma coherente, por tanto, la operacin del sistema en s se ve afectada por
el componente en cuestin. Esto quiere decir que si el componente de pago no est
funcionando, no impide que se realicen acciones pertinentes a otros componentes como,
por ejemplo, obtener el listado de los ltimos pagos realizados.
La siguiente figura muestra un diagrama de paquetes. Cada componente realiza
tareas especficas, lo que permite separar la funcionalidad del sistema.

Imagen 12:

INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

11

Diagramas de comportamiento

Los diagramas de comportamiento se emplean para visualizar, especificar, construir y

documentar los aspectos dinmicos de un sistema. Estos aspectos dinmicos incluyen
traspaso de mensajes a travs del tiempo y el movimiento fsico de componentes.
Los diagramas que pertenecen a esta categora son:

Diagrama de casos de uso.

Diagrama de estados.

Diagrama de actividades.

Diagrama de casos de uso

Permite definir en forma grfica las acciones y los participantes de dichas acciones.
Para ello se definen actores, quienes interactan con el sistema y realizan las acciones
dispuestas.
Dependiendo del escenario, la lista de actividades a realizar puede ser variada, con
accione tpicas como: consultar, agregar, eliminar, modificar, solicitar, enviar, etc.
No se requiere, en este diagrama, el detalle de cada una de estas acciones, sino solo
la accin en s. Este diagrama es til para apoyar el proceso de anlisis del cual forma parte
importante el cliente final de la solucin.
Un caso de uso involucra funcionalidad atmica y la percepcin el actor. A su vez, el
caso de uso representa un conjunto de acciones

que se ejecutan en el sistema, cuyo

resultado es observable por los actores, con valores asociados a las respuestas de cada
accin. El mnimo y mximo de actores estar determinado por la cantidad de acciones
necesarias de abordar, por tanto, no existe una cantidad mnima ni mxima de actores por
defecto.
La simbologa usada en este diagrama es la siguiente:
INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

12

Algunas de las posibles preguntas vlidas para identificar actores seran:

Quin utilizar en forma primaria y/o secundaria el sistema?

Qu dispositivos de hardware son necesarios para que el sistema opere?

Con qu otros sistemas necesitar interactuar la solucin?

Quines podran beneficiarse con los resultados obtenidos de los procesos del
sistema?
Respecto a los casos de uso se podra mencionar:

Qu es necesario que realicen los actores?

Cules son las tareas fundamentales del sistema?

Solicitan, guardan, envan mensajes o dan de baja datos los actores?

Qu entradas y salidas necesita el sistema?

De dnde vienen o hacia dnde van las entradas/salidas del sistema?

Ejemplos:

INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

13

El paciente tiene a su disposicin dos acciones relevantes segn la definicin del

problema en primera instancia. Estas acciones se pueden complementar usando nuevos
casos de uso, que permitan resolver la problemtica en forma integral.

INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

14

El proceso registrar pago utiliza la clusula include, para referirse a que,

independiente de la forma de pago, es obligacin seleccionar una de ellas. En el caso de
que la operacin sea llevada a efecto con efectivo no hay procesos adicionales, en
cambio, al pagar con cheque o tarjeta bancaria se requieren procesos adicionales que
usan la clusula extend, dado que no siempre sern llevados a efecto. Todo tiene relacin
con la forma de pago seleccionada en el proceso correspondiente. Ntese que la forma de
pago es excluyente, por tanto, he aqu que toma sentido la generalizacin, es decir, el
operador podr seleccionar solo una forma de pago para completar la transaccin.
Diagrama de estados
Son utilizados para describir el comportamiento del sistema. Describen, como su
nombre lo indica, los estados posibles en los que se puede encontrar un objeto en particular
y los cambios a los que ste est afecto. Normalmente se describe el comportamiento del
objeto durante todo el ciclo de vida que sea usado.
Se debe indicar el estado inicial del objeto, acompaado de flechas que llevan el
nombre del evento, asociado al cambio de estado, para finalizar en un nuevo estado.

El smbolo

se utiliza para indicar el inicio del diagrama, el smbolo

indica el trmino.

En el ejemplo se aprecia el cambio de estado de los objetos en cuestin, puede

haber ms transiciones que involucren ms cambios a lo largo del ciclo de vida del objeto.

INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

15

Diagrama de actividades
Este diagrama permite visualizar el o los flujos de informacin que afectan a los
objetos. Se debe indicar el inicio de la actividad y el trmino de la misma.
Durante la vida til de dicha actividad pueden ocurrir situaciones en las que es necesario
decidir qu hacer con el flujo de informacin, iniciando o terminando otra actividad.
Las condiciones dependern de los factores a evaluar y los estados posibles a los que
se espera llegar, dado o no el cumplimiento de estas condiciones.
Las acciones pueden converger o divergir segn sea el caso.
En el ejemplo, el cliente puede cancelar la reserva, o bien ser cancelada al comienzo
si la condicin de quien solicita no cumple con los requisitos.

Diagramas de interaccin

Este tipo de diagramas muestra las interacciones y relaciones que involucran a un

conjunto de objetos, incluyendo los mensajes que pueden enviarse entre ellos, cubriendo la
vista dinmica del sistema.

INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

16

Los diagramas que conforman esta categora son:

Diagrama de secuencia.

Diagrama de colaboracin (comunicacin).

Diagrama de secuencia
Este diagrama permite mostrar la interaccin de varios objetos a travs del tiempo.
Por cada caso de uso es necesario un diagrama de secuencia. Tngase presente que el
diagrama de casos de uso da cuenta de la vista del negocio en trminos funcionales, pero
solo a nivel general, en cambio el diagrama de secuencia contiene los detalles de la
implementacin de esa vista, incluyendo los objetos y clases necesarias para implementar la
interaccin entre ellos.
El diagrama de secuencia muestra los objetos interactuantes en forma horizontal,
cada uno con

lneas discontinuas verticales, usando, para la interaccin, el paso de

mensajes con flechas horizontales.

Observa el siguiente ejemplo que presenta un diagrama de secuencia de acuerdo a
lo descrito:

INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

17

Los objetos participantes de la transaccin se envan informacin unos con otros, en

resumen, este diagrama representara en forma bsica el caso de uso prstamo.
La descripcin de cada caso de uso es mostrada como una secuencia de muchos
pasos sobre los cuales es posible navegar, esto permite visualizar a cada objeto como parte
de esa secuencia, en la que tambin es posible apreciar su interaccin con otros objetos
que forman parte de ella.

Diagrama de colaboracin (Comunicacin)

Este diagrama muestra una interaccin organizada de los objetos que forman parte
de la solucin, generando interacciones entre ellos. Estas interacciones modelan los
aspectos dinmicos del sistema.

Las relaciones se denotan uniendo los objetos y las flechas indican el flujo de
informacin.
INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

18

Diagramas de tiempo
Los diagramas de tiempos de UML se usan para mostrar el cambio en el estado o
valor de uno o ms elementos en el tiempo. Este tambin puede mostrar la interaccin entre
los eventos de tiempos, las restricciones de tiempos y la duracin que los gobiernan.
(Systems, 2012)
Los diagramas que componen esta categora son:

Lnea de vida del estado.

Lnea de vida del valor.

Lnea de vida del estado

Muestra el cambio de estado del tem en el tiempo. El eje-X muestra el tiempo
transcurrido en cualquier unidad que se elija, mientras que el eje-Y se nombra con una lista
de estados proporcionados. El siguiente es un ejemplo de una lnea de vida del estado.
(Systems, 2012)
Todo sistema automatizado tiene estados por los cuales pasa durante su vida til,
como ejemplo, ntese una lavadora automtica con funciones programables definidas
tales como: pesar ropa, llenar estanque, lavar, enjuagar y centrifugar.
Cada uno de esos estados tiene una duracin definida de acuerdo al programa de
lavado. En tal caso podra apreciarse la lnea de vida de estado como:

INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

19

Lnea de vida del valor

Muestra el cambio del valor de un tem en el tiempo. El eje-X muestra el tiempo transcurrido
en cualquier unidad que se elija, lo mismo que para la lnea de vida del estado. El valor se
muestra entre el par de lneas horizontales que se cruzan en cada cambio del valor. El
siguiente es un ejemplo de una lnea de vida del valor. (Systems, 2012).

INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

20

RUP ( Rational Unified Process)

Junto con el Lenguaje Unificado de Modelado (UML) constituye la metodologa
estndar ms utilizada para el anlisis, diseo, implementacin y documentacin de
sistemas orientados a objetos.
El Proceso Unificado de Racional (Rational Unified Process) ha sido creado por la
empresa Rational Software, hoy propiedad de IBM.
RUP se compone de un conjunto de metodologas que es posible adaptar al contexto
y necesidades de cada organizacin.
RUP consta de las siguientes fases:

Inicio.

Elaboracin.

Construccin o desarrollo.

Transicin o trmino.

Fase de inicio: se aborda la problemtica inicial, entendiendo el mbito del problema.

Normalmente, en esta etapa se definen los casos de uso (actores) y se genera el
planteamiento de los requisitos preliminares, teniendo presente la visin de la empresa o
entidad a la que se le resolver el problema.
Fase de elaboracin: en esta etapa se delimita el domino del problema en trminos lgicos
y fsicos. Se establecen los diagramas de clases, las vistas de entidad-relacin, diagramas de
secuencia, colaboracin y diagrama de estados. Desde el punto de vista fsico es necesario
elaborar los diagramas de comportamiento a nivel de hardware, desarrollar los casos de uso
y realizar pruebas completas a los casos de uso que tienen directa

relacin con la

especificacin de los requerimientos funcionales y no funcionales del proyecto.

INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

21

Es parte importante de esta fase la planificacin del proyecto, de tal forma que se incluyan
todas las tareas a realizar durante cada iteracin.
Fase de construccin: en esta fase es necesaria la construccin de todos los componentes y
aplicaciones restantes que deben ser integradas al producto. Se deben realizar pruebas
exhaustivas de tal manera que el nfasis est puesto en aquellos procesos que son
relevantes dentro de la organizacin y definidos como crticos al inicio del proyecto.
Adems, en esta fase se lleva a efecto la construccin del cdigo, y la configuracin de
plataformas de software y hardware con las que interacta el sistema.
Se realizan pruebas a los casos de uso desarrollados y pruebas de regresin segn sea el
caso.
Fase de transicin: en esta fase se lleva a efecto la implantacin del sistema, la integracin
con los usuarios y el acercamiento de la plataforma a quienes sern los actores principales
con quien el sistema interactuar. Tambin se realizan las pruebas de aceptacin, que dan
por aprobadas las condiciones de uso; los trminos impuestos al principio del proyecto han
sido desarrollados en forma exitosa.
Se entrega la documentacin final del producto y la interaccin con los usuarios generar la
retroalimentacin necesaria para que el sistema pueda darse por implantado al 100%,
teniendo presente que esa experiencia dar la posibilidad de realizar mejoras sustantivas,
que aumentarn las expectativas de quien lo use en forma permanente.

INACAP Virtual |Material de apoyo - Anlisis y diseo orientado a objetos

22