7/04/2014

Sistema II
Unidad 1: UML.
Unidad 2: Estructura esttica.
Unidad 3: Metadatos.
Unidad 4: Modelo conceptual.
Unidad 5: Diagrama de caso de uso.
Unidad 6: Diagrama de secuencia.
Unidad 7: Diagrama de comunicacin.

1 trabajo de investigacin.
Modelos de Ciclo de Vida.
Las formas de organizar y estructurar la secuencia de ejecucin de las tareas en
las diferentes fases de cada uno de los mtodos puede dar lugar a un tipo de ciclo
de vida diferente; Las principales diferencias entre distintos modelos de ciclo de
vida estn divididas en 3 grandes visiones:
1.-El alcance de ciclo de vida: depende de hasta donde deseamos llegar con el
proyecto.
2.-La cualidad y cantidad de las etapas: que ciclo de vida se escoger y el
proyecto al cual se adaptara.
3.-La estructura y la sucesin de las etapas: si hay realimentacin entre las etapas
y hay libertad para repetirlas.

Ciclo de Vida en Cascada.

El ciclo de vida inicialmente propuesto por Winston Royce en 1970, es el
ms seguido por las organizaciones. Es un ciclo de vida que admite interacciones,
es decir, durante las modificaciones que se hacen en el mantenimiento se puede
ver por ejemplo la necesidad de cambiar algo en el diseo, lo cual significa que se
harn los cambios necesarios en la codificacin y se tendrn que realizar de
nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores
al mantenimiento hay que recorrer de nuevo el resto de las etapas. Despus de

cada etapa se realiza una o varias revisiones para comprobar si se puede pasar a
la siguiente. Este sirvi de base para el resto de los ciclos de vida.

Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un

tipo de documento especfico. Idealmente, cada fase podra hacerla un equipo
diferente gracias a la documentacin generada entre las fases. Algunas de sus
ventajas son las siguientes:

La planificacin es sencilla.

La calidad del producto resultante es alta.

Permite trabajar con personal poco calificado.

Algunos de sus Inconvenientes

Generalmente no se cuenta con todos los requisitos y las especificaciones al

principio y surgen necesidades imprevistas.

Si se cmete algn error ya avanzada una etapa es difcil regresar a corregir.

El cliente no ver resultados hasta el final. No se tiene el producto hasta el

final.

No se tienen indicadores fiables del progreso del trabajo.

Es comparativamente ms lento que los dems y el coste es mayor tambin.

La necesidad de conocer los requerimientos al principio del proyecto es
primordial al elegir este modelo a pesar de permitir iteraciones.

Ciclo de Vida en V.
Propuesto por Alan Davis, tiene las mismas etapas del ciclo de vida de
cascada solo que a este se le agregaron dos sub-etapas de retroalimentacin
entre la etapa de anlisis y mantenimiento y entre las de diseo y depuracin.

Las
ventajas y
desventajas de este ciclo son las mismas que las de cascada, con el agregado de
los controles entre etapas para lograr una mayor correccin. Este modelo lo
podemos utilizar en aplicaciones simples pero de alta confiabilidad como por
ejemplo en facturacin. Este modelo nos ofrece mayor garanta de correccin al
terminar el proyecto.

Ciclo de Vida Tipo Sashimi.

Segn el modelo en cascada, una fase solo puede empezar cuando ha
terminado la anterior. En este caso sin embargo, se permite un solapamiento entre
fases. Por ejemplo, sin tener terminado del todo el diseo se comienza a
implementar. El nombre ``sashimi deriva del modo del estilo de presentacin de
rodajas de pescado crudo en Japn. Una ventaja de este modelo es que no
necesita generar tanta documentacin como el ciclo de vida en cascada debido a
la continuidad del mismo personal entre fases.
Los problemas planteados son:

Es an ms difcil controlar el progreso del proyecto debido a que los finales

de fase ya no son un punto de referencia claro.

Al hacer cosas en paralelo si hay problemas de comunicacin pueden surgir

inconsistencias.
La fase de ``concepto consiste en definir los objetivos del proyecto,
beneficios, tipo de tecnologa y el tipo de ciclo de vida. El diseo arquitectnico es
el de alto nivel, el detallado el de bajo nivel.

Cuando necesitemos realizar una aplicacin que comparta los recursos CPU,
memoria y espacio de almacenamiento, con otras aplicaciones tratando de
mantener un ambiente productivo, este modelo de ciclo de vida es una opcin muy
vlida. El solapamiento de sus etapas nos permite jugar con el modelo de tres
capas ahorrando recursos.
El modelo de tres capas es un modelo de programacin para aplicaciones
de acceso a datos que busca separar la arquitectura del programa en tres capas.
En la capa de datos solo nos preocupamos por el almacenamiento de estos, en la
capa de negocios situamos todas las transacciones y validaciones y en la capa
de presentacin solo encontramos las rutinas de visualizacin e interaccin con el
usuario.
Ciclo de Vida en Cascada con Subproyectos.
Una vez que se ha llegado al diseo arquitectnico, se comprueba que el
sistema se divide en varios subsistemas independientes entre s, sera razonable
suponer que a partir de ese punto cada uno se puede desarrollar por separado y
en consecuencia en paralelo con los dems. Cada uno tendr seguramente fechas
de terminacin distintas. Una vez que han terminado todos se integran y se prueba
el sistema en su conjunto.
Es ideal cuando se cuenta con un plantel numeroso de programadores, es una
ventaja tener ms gente trabajando al mismo tiempo. Pero la desventaja es que
pueden surgir ciertas dependencias entre las distintas subetapas que detengan el
proyecto temporalmente si no es gestionado de manera correcta, es un modelo
donde hay que administrar y poner demasiada atencin a los tiempos.

Ciclo de Vida en Cascada Incremental.

En este caso se va creando el sistema aadiendo pequeas

funcionalidades. Se realiza construyendo por mdulos que cumplen las diferentes
funciones del sistema; esto permite ir aumentando gradualmente las capacidades
del software. Este ciclo de vida facilita la tarea del desarrollo permitiendo a cada
del equipo desarrollar un mdulo del proyecto. Es una repeticin del ciclo de vida
en cascada, aplicando se este ciclo en cada funcionalidad del programa a
construir.

Cada uno de los pequeos incrementos es parecido a lo que ocurre dentro de la

fase de mantenimiento. La ventaja de este mtodo es que no es necesario tener
todos los requisitos en un principio. El inconveniente es que los errores en la
deteccin de requisitos se encuentran tarde.

Hay dos partes en el ciclo de vida, por un lado est el anlisis y el diseo global.
Por otra parte estn los pequeos incrementos, con las fases de diseo detallado,
codificacin y mantenimiento.

Ciclo de Vida en Espiral.

Propuesto inicialmente por Boehm en 1988. Consiste en una serie de ciclos que
se repiten. Cada uno tiene las mismas fases y cuando termina da un producto
ampliado con respecto al ciclo anterior. En este sentido es parecido al modelo
incremental, la diferencia importante es que tiene en cuenta el concepto de riesgo.
Un riesgo puede ser muchas cosas: requisitos no comprendidos, mal diseo,
errores en la implementacin, etc.
Hay cuatro actividades que envuelven a las etapas:

Determinar los objetivos a travs de una entrevista hecha directamente con

el cliente incluyendo todo tipo de requerimientos. La planificacin que es el
relevamiento de los requerimientos inciales o luego de una interaccin el anlisis
de riesgo que va de acuerdo con la planificacin para ver si es factible continuar
con el desarrollo y despus se procede a las pruebas y evaluacin.

Al terminar una iteracin se comprueba que lo que se ha hecho efectivamente

cumple con los requisitos establecidos, tambin se verifica que funciona
correctamente. El propio cliente evala el producto. No existe una diferencia muy
clara entre cuando termina y cuando empieza una fase. Cuando hay que hacer un
cambio,
este
puede
consistir
en
un
nuevo
ciclo.
Ventajas de este tipo de ciclo: No necesita una definicin completa de los
requisitos para empezar a funcionar. Al entregar productos desde el final de la
primera iteracin es ms fcil validar los requisitos. El riesgo en general es menor,
porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos en
una iteracin (las anteriores iteraciones estn bien). El riesgo de sufrir retrasos es
menor, ya que al identificar los problemas en etapas tempranas hay tiempo de
subsanarlos.
Algunas desventajas serian: Es difcil evaluar los riesgos. Necesita de la
participacin continua por parte del cliente. Cuando se subcontrata hay que
producir previamente una especificacin completa de lo que se necesita, y esto
lleva tiempo.

Ciclo de Vida Orientado a Objetos.

Pude considerarse como un modelo pleno a seguir, tcnica presentada en los 90

s, tal vez como una de las mejores metodologas para la creacin de productos
software. Cada funcionalidad o requerimiento solicitado por el usuario, es
considerado un objeto. Los objetos estn representados por un conjunto de
propiedades llamadas atributos, por otra parte el comportamiento que tendrn
estos objetos se denominaran mtodos.

Unidad 1.
UML: es un lenguaje grafico que permite modelar, construir y documentar los
elementos que contribuyen un sistema de software orientados a objetos.
Ofrece un conjunto de modelos, estndar utilizado para el diseo de proyectos.
Modelos: representacin abstracta de la realidad.
Nota: UML no describe la implementacin de esos modelos.

2 trabajo de investigacin.
La importancia de modelar en el desarrollo de un sistema.
De acuerdo al tipo de emprendimiento, tanto en su tamao como en
caractersticas necesitara de distintas herramientas, procesos, arquitectura,
recursos humanos y las tecnologas. El truco est en crear el software apropiado y
en imaginar cmo escribir menos en software. Un proyecto puede ser concebido
con respecto a su tamao en un programa pequeo, y crecer enormemente pero
si no se han tenido en cuenta, previamente la arquitectura, el proceso o las
herramientas, este colapse.
El modelado es comn en los proyectos de software exitosos.
El modelado es una tcnica de ingeniera probada y bien aceptada.
Nos ayuda a:
Visualizar a sus usuarios el producto final.
Comprender mejor el sistema.
Comunicar las ideas a otros.
Un modelo puede ser estructural destacando la organizacin del sistema o puede
ser de comportamiento, desatando su dinmica.

3 trabajo de investigacin.

Definicin y concepto de modelado orientado objeto.

Es la construccin de modelos de un sistema por medio de la identificacin y
especificacin de un conjunto de objetos relacionados, que se comportan y
colaboran entre s de acuerdo a los requerimientos establecidos para el sistema
de
objetos.
En otras palabras Las tcnicas orientadas a objetos permiten que el software se
construya
a
partir
de
objetos
de
compartimiento
especfico.
Los propios objetos se pueden constituir a partir de otros , que a su vez pueden
estar formados por otros objetos .Esto nos recuerda a una maquina compleja
construida
por
partes
,
subpartes
y
sub-subpartes,
etc.
La metodologa de desarrollo de software orientada a objetos es cada da ms
usada, pues permite desarrollar software fcilmente extensible y reusable.
Es importante conocer la base del diseo y programacin de buenas clases, tanto
por si solas como a travs del uso de herencia. As como el concepto de subtipos,
como concepto terico que est detrs de las distintas implementaciones de
herencia que proveen los lenguajes y provee el marco conceptual de cuando usar
referencia. Ms tarde presenta el proceso de desarrollo de software orientado a
objetos, primero enfocado en la etapa de diseo, en donde se dan a conocer las
distintas relaciones entre clases que podemos encontrar, proveer mecanismos
para verificar si una clase y las relaciones entre ellas estn bien diseadas, y en
particular
si
la
herencia
est
bien
usada.
Esto es fundamental para que los diseos a objetos no sean ms complicados de
entender que los de procedimientos y para que el software que se disee sea
reusable y fcil de extender. Finalmente presenta los aspectos ms importantes de
la etapa de anlisis, dando nfasis a la especificacin de casos de uso y a cmo
detectar
objetos
y
clases
relevantes
en
el
problema.
El objetivo del anlisis orientado a objetos es desarrollar una serie de modelos que
describan el software de computadora al trabajar para satisfacer un conjunto de
requisitos definidos por el cliente. El AOO, como los mtodos de anlisis
convencionales descritos, forma un modelo de anlisis cultiparle para satisfacer
este
objetivo.
El modelo de anlisis ilustra informacin, funcionamiento y comportamiento dentro
del
contexto
de
los
elementos
del
modelo
de
objetos.
Anlisis y diseo orientados al objeto es la tecnologa de dotacin lgica. Cada
objeto representa alguna entidad del inters en el sistema que es modelado, este
es caracterizado por su clase, su estado y su comportamiento. Los varios modelos
se pueden crear para demostrar la estructura esttica, el comportamiento
dinmico y el despliegue de estos objetos de colaboracin. Una de las notaciones
para representar estos modelos es el UML (unificado modelando lengua).
El anlisis orientado a objetos aplica objeto-modelar tcnicas para analizar los

requisitos funcionales para un sistema. El sistema orientado al objeto elabora los

modelos del anlisis para producir especificaciones para la puesta en prctica.
El Anlisis y el Diseo de sistema, tienen como fin estudiar sistemticamente la
operacin de ingreso de los datos, el flujo de los mismos y la salida de la
informacin; todo ello dentro del contexto de una empresa en particular.
Un modelo se utiliza para:
Visualizar: la comunicacin entre los modelos, entender el sistema que
puede ser complejo, documentando el cdigo de esa informacin.
Para especificar: contribuyendo modelos precisos, no ambiguos
y
completos.
UML cubre la especificacin de todas las decisiones de anlisis, diseo e
implementacin que debe realizarse al desarrollar y desplegar un sistema con
gran cantidad de software.
Para construir: produce una ingeniera de ida y vuelta entendiendo
por esto la posibilidad de trabajar en una vista grafica o en una textual
(el cdigo) mientras las herramientas mantienen la consistencia entre
ambos.
Para documentar: toda la informacin necesaria, requisitos,
arquitectura, diseo, cdigo fuente, planificacin de proyectos, pruebas,
prototipo donde utilizar UML.
Se ha utilizado de manera efectiva en diferentes dominios:
Sistema de informacin empresarias, bancos y servicios financieros, transportes,
mbitos cientficos, etc.
Finalidades de UML.
Representar sistemas complejos.
Establecer una relacin explicita entre los conceptos y los artefactos
ejecutables.
Tener en cuenta los factores de escala inherentes o los sistemas complejos
y crticos.
crear un modelo utilizable tanto como para humanos, como para las
maquinas.
Ventajas de UML.

La utilizacin del cdigo simple de entender.

Alta cohesin y bajo acoplamiento.
Escalabilidad.

Limitaciones de UML.

UML no es un modelo de proceso de desarrollo de software.

UML no define un ciclo de vida, ni objetivo, ni actividades.
UML no es una metodologa.
UML fue concebido para construir modelo de software.
UML est fuertemente vinculado a orientado objeto.
Modelos y diagramas.

Un modelo captura una vista de sistema del mundo real. Es una extraccin de
dicho sistema considerando un cierto propsito, describiendo aspectos relevantes.
Diagramas.
Es una representacin grfica de una coleccin de elementos de modelado.
Diagrama de UML.
Lenguaje Unificado de Modelado (UML,) es el lenguaje de modelado de sistemas
de software ms conocido y utilizado en la actualidad; Es un lenguaje grfico para
visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar
para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales
tales como procesos de negocio, funciones del sistema, y aspectos concretos
como expresiones de lenguajes de programacin, esquemas de bases de datos y
compuestos reciclados. Es un "lenguaje de modelado" para especificar o para
describir mtodos o procesos. Se utiliza para definir un sistema, para detallar los
artefactos en el sistema y para documentar y construir.
UML significa Lenguaje Unificado de Modelado, no es programacin, solo se
diagrama la realidad de una utilizacin en un requerimiento. Mientras que,
programacin estructurada, es una forma de programar como lo es la orientacin a
objetos, la programacin orientada a objetos viene siendo un complemento
perfecto de UML, pero no por eso se toma UML slo para lenguajes orientados a
objetos.
Cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos
de las entidades representadas
Tipos de Diagramas de UML:
Diagrama de casos de uso.

Un diagrama de casos de uso es una especie de diagrama de comportamiento

UML mejorado. El UML, define una notacin grfica para representar casos de uso
llamada modelo de casos de uso. no define estndares para que el formato
escrito describa los casos de uso, esta notacin grfica define la naturaleza de un
caso de uso; sin embargo una notacin grfica puede solo dar una vista general
simple de un caso de uso o un conjunto de casos de uso.

La interaccin entre actores no se ve en el diagrama de casos de uso. Si esta

interaccin es esencial para una descripcin coherente del comportamiento
deseado, quizs los lmites del sistema o del caso de uso deban de ser reexaminados. Alternativamente, la interaccin entre actores puede ser parte de
suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie
de rol, un usuario humano u otra entidad externa pueden jugar varios papeles o
roles. As el Chef y el Cajero podran ser realmente la misma persona.
Diagrama de clases.

Un diagrama de clases es un tipo de diagrama esttico que describe la estructura

de un sistema mostrando sus clases, orientados a objetos.

El diagrama de clases incluye mucha ms informacin como la relacin

entre un objeto y otro, la herencia de propiedades de otro objeto, conjuntos
de operaciones/propiedades que son implementadas para una interfaz
grfica.

Presenta las clases del sistema con sus relaciones estructurales y de

herencia.

El diagrama de clases es la base para elaborar una arquitectura MVC o

MVP.

Diagrama de objetos

Diagrama que muestra una vista completa o parcial de los objetos de un sistema
en un instante de ejecucin especfico.
Un diagrama de objetos es un grfico de instancias, incluyendo objetos y datos. Es
una instancia de un diagrama de clases; muestra una 'foto' del estado de un
sistema en un punto de tiempo determinado.
Estn ligados a los diagramas de clase y comparten virtualmente los mismos
smbolos para la notacin. Pertenecen a la categora de diagramas estructurales
en UML.
. Se utilizan para mostrar estructuras de datos y las interacciones que existen
entre objetos en tiempo de ejecucin.
Diagrama de comportamiento.
Diagrama de estado
Los diagramas de estado muestran el conjunto de estados por los cuales pasa un
objeto durante su vida en una aplicacin en respuesta a eventos (por ejemplo,
mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y
acciones. Tambin ilustran qu eventos pueden cambiar el estado de los objetos
de la clase. Normalmente contienen: estados y transiciones. Como los estados y
las transiciones incluyen, a su vez, eventos, acciones y actividades.
Al igual que otros diagramas, en los diagramas de estado pueden aparecer notas
explicativas y restricciones.
El diagrama de flujo o diagrama de actividades.
Es la representacin grfica del algoritmo o proceso. Se utiliza en disciplinas como
programacin, economa, procesos industriales y psicologa cognitiva.

En UML, un diagrama de actividades representa los flujos de trabajo paso a paso

de negocio y operacionales de los componentes en un sistema. muestra el flujo de
control general.
Estos diagramas utilizan smbolos con significados definidos que representan los
pasos del algoritmo, y representan el flujo de ejecucin mediante flechas que
conectan los puntos de inicio y de fin de proceso.

TIPOS DE DIAGRAMAS DE FLUJO.

Formato vertical

Formato horizontal

Formato panormico

Formato Arquitectnico

Diagrama de integracin.
Diagrama de secuencia
El diagrama de secuencia es un tipo de diagrama usado para modelar interaccin
entre objetos en un sistema segn UML.

Muestra la interaccin de un conjunto de objetos en una aplicacin a travs del

tiempo y se modela para cada caso de uso. El diagrama de secuencia contiene
detalles de implementacin del escenario, incluyendo los objetos y clases que se
usan para implementar el escenario y mensajes intercambiados entre los objetos.
. Un diagrama de secuencia muestra los objetos que intervienen en el escenario
con lneas discontinuas verticales, y los mensajes pasados entre los objetos como
flechas horizontales.
Diagrama de colaboracin
Un diagrama de colaboracin en las versiones de UML es esencialmente un
diagrama que muestra interacciones organizadas alrededor de los roles. los
diagramas de colaboracin, , muestran explcitamente las relaciones de los roles.
no muestra el tiempo como una dimensin aparte, por lo que resulta necesario
etiquetar con nmeros de secuencia tanto la secuencia de mensajes como los
hilos concurrentes.
Es tambin un diagrama de clases que contiene roles de clasificador y roles de
asociacin en lugar de slo clasificadores y asociaciones. Los roles de clasificador
y los de asociacin describen la configuracin de los objetos y de los enlaces que
pueden ocurrir cuando se ejecuta una instancia de la comunicacin. Cuando se
instancia una comunicacin, los objetos estn ligados a los roles de clasificador y
los enlaces a los roles de asociacin. El rol de asociacin puede ser desempeado
por varios tipos de enlaces temporales, tales como argumentos de procedimiento
o variables locales del procedimiento. Los smbolos de enlace pueden llevar
estereotipos para indicar enlaces temporales.
Un diagrama de comunicacin muestra relaciones entre roles geomtricamente y
relaciona los mensajes con las relaciones, pero las secuencias temporales estn
menos claras.

 Diagrama de implementacin.
Diagrama de despliegue
El Diagrama de Despliegue es un tipo de diagrama del UML que se utiliza para
modelar la disposicin fsica de los artefactos software en nodos (usualmente
plataforma de hardware.
Los elementos usados por este tipo de diagrama son nodos (representados como
un prisma), componentes (representados como una caja rectangular con dos
protuberancias del lado izquierdo) y asociaciones.
Modelo de Arquitectura.

La Arquitectura del Software es el diseo de ms alto nivel de la estructura

de un sistema.

Una Arquitectura de Software, consiste en un conjunto de patrones y

abstracciones coherentes que proporcionan el marco

se selecciona y disea con base en objetivos (requerimientos) y

restricciones. Los objetivos son aquellos prefijados para el sistema de
informacin. Las restricciones son aquellas limitaciones derivadas de las
tecnologas disponibles para implementar sistemas de informacin.

define, de manera abstracta, los componentes que llevan a cabo alguna

tarea de computacin, sus interfaces y la comunicacin entre ellos. Toda
arquitectura debe ser implementable en una arquitectura fsica, que
consiste simplemente en determinar qu computadora tendr asignada
cada tarea.
Modelos o vista.

Cada paradigma de desarrollo exige diferente nmero y tipo de vistas o modelos

para describir una arquitectura. No obstante, existen al menos tres vistas
absolutamente fundamentales en cualquier arquitectura:

La visin esttica: describe qu componentes tiene la arquitectura.

La visin funcional: describe qu hace cada componente.

La visin dinmica: describe cmo se comportan los componentes a lo

largo del tiempo y cmo interactan entre s.

Las vistas o modelos de una arquitectura de software pueden expresarse

mediante uno o varios lenguajes. El ms obvio es el lenguaje natural, pero existen
otros lenguajes tales como los diagramas de estado, los diagramas de flujo de
datos, etc. Estos lenguajes son apropiados nicamente para un modelo o vista.
Afortunadamente existe cierto consenso en adoptar UML como lenguaje nico
para todos los modelos o vistas.
Arquitecturas ms comunes.
Las arquitecturas ms universales son:

Monoltica: Donde el software se estructura en grupos funcionales muy

acoplados.

Cliente-servidor: Donde el software reparte su carga de cmputo en dos

partes independientes pero sin reparto claro de funciones.

Arquitectura de tres niveles: Especializacin de la arquitectura clienteservidor donde la carga se divide en tres partes con un reparto claro de
funciones: una capa para la presentacin (interfaz de usuario), otra para el
clculo (donde se encuentra modelado el negocio) y otra para el
almacenamiento (persistencia). Una capa solamente tiene relacin con la
siguiente.

1. Definicin Encapsulamiento.
Se denomina encapsulamiento al ocultamiento del estado, es decir, de los
datos miembros de un objeto de manera que slo se pueda cambiar mediante
las operaciones definidas para ese objeto.
Cada objeto est aislado del exterior, es un mdulo natural, y la aplicacin entera
se reduce a un agregado o rompecabezas de objetos. El aislamiento protege a los
datos asociados de un objeto contra su modificacin por quien no tenga derecho a
acceder a ellos, eliminando efectos secundarios e interacciones.

Al empaquetamiento de las variables de un objeto con la proteccin de sus

mtodos se le llama encapsulamiento. Es utilizado para esconder detalles de la
puesta en prctica no importantes de otros objetos

Formas de encapsular.
1. Estndar (Predeterminado)
2. Abierto: Hace que el miembro de la clase pueda ser accedido desde el
exterior de la Clase y cualquier parte del programa.
3. Protegido: Solo es accesible desde la Clase y las clases que heredan (a
cualquier nivel).
4. Semicerrado: Solo es accesible desde la clase heredada.
5. Cerrado: Solo es accesible desde la Clase.

2. Abstraccin.
La abstraccin consiste en aislar un elemento de su contexto o del resto de los
elementos que lo acompaan. El trmino se refiere al nfasis en el "qu hace?"
ms que en el "cmo lo hace?".
La abstraccin ofrecida por los lenguajes de programacin se puede dividir en dos
categoras: abstraccin de datos (pertenecientes a los datos) y abstraccin de
control (perteneciente a las estructuras de control). Permite que dispongamos de
las caractersticas de un objeto que necesitemos.

3. Herencia.
La herencia es, el mecanismo ms utilizado para alcanzar algunos de los
objetivos ms preciados en el desarrollo de software como lo son la reutilizacin y
la extensibilidad. A travs de ella los diseadores pueden crear nuevas clases
partiendo de una clase o de una jerarqua de clases preexistente (ya comprobadas
y verificadas) evitando con ello el rediseo, la modificacin y verificacin de la
parte ya implementada. Facilita la creacin de objetos a partir de otros ya

existentes e implica que una subclase obtiene todo el comportamiento (mtodos) y

eventualmente los atributos (variables) de su superclase.

4. Polimorfismo.
El polimorfismo se refiere a la propiedad por la que es posible enviar mensajes
sintcticamente iguales a objetos de tipos distintos. El nico requisito que deben
cumplir los objetos que se utilizan de manera polimrfica es saber responder al
mensaje que se les enva.
La apariencia del cdigo puede ser muy diferente dependiendo del lenguaje que
se utilice, ms all de las obvias diferencias sintcticas.
En lenguajes basados en clases y con un sistema de tipos de datos fuerte
(independientemente de si la verificacin se realiza en tiempo de compilacin o de
ejecucin), es posible que el nico modo de poder utilizar objetos de manera
polimrfica sea que compartan una raz comn, es decir, una jerarqua de clases,
ya que esto proporciona la compatibilidad de tipos de datos necesaria para que
sea posible utilizar una misma variable de referencia (que podr apuntar a objetos
de diversas subclases de dicha jerarqua) para enviar el mismo mensaje (o un
grupo de mensajes) al grupo de objetos que se tratan de manera polimrfica.
Aun as, en los lenguajes basados en clases, es habitual (y en algunos tal vez sea
el nico modo) que dichos objetos pertenezcan a subclases pertenecientes a una
misma jerarqua. el polimorfismo debe verse como una forma flexible de usar un
grupo de objetos (como si fueran slo uno). El polimorfismo en esencia refiere al
comportamiento de los objetos, no a su pertenencia a una jerarqua de clases (o a
sus tipos de datos).
Clasificacin.
Se puede clasificar el polimorfismo en dos grandes clases:

Polimorfismo dinmico: es aqul en el que el cdigo no incluye ningn

tipo de especificacin sobre el tipo de datos sobre el que se trabaja. As,
puede ser utilizado a todo tipo de datos compatible.

Polimorfismo esttico: es aqul en el que los tipos a los que se aplica el

polimorfismo deben ser explcitos y declarados uno por uno antes de poder
ser utilizados.

Unidad 2.
Diagrama de estructura esttica.
El diagrama de estructura esttica muestra el conjunto de clase de objetos
importantes que hacen parte de un sistema, junto con las relaciones existentes
entre esta clase y objetos.
Tambin muestra de una manera esttica la estructura de informacin de sistema
y la visibilidad que tiene cada una de las clases, dadas por sus relaciones con las
dems en el modelo.
El modelo de los objetos.
Permite describir objetos y las relaciones que intervienen en el marco de la
problemtica.
Brinda una descripcin doble.
Una descripcin de la estructura de los objetos y sus caractersticas.
Una descripcin de las asociaciones existentes entre los diferentes objetos.

4 trabajo de investigacin.
EJEMPLO.

Definicin de objeto para UML.

Es una abstraccin de un conjunto de clases del mundo real que tiene sentido en
el problema de aplicacin.
Definicin de clase.
Una clase es una definicin simplificada de las caractersticas comunes de un
conjunto de objetos semejantes.
Los objetos con la misma estructura de datos (atributos) y comportamientos
(operaciones) son agrupadas en clase.

Definicin de clase abstractas.

Una clase abstracta es una clase que no tiene instancias directas, pero cuya clase
descendientes poseen instancias directas una clase abstracta, no da lugar a

objetos sino que sirve de especificacin general. Su funcin es factorizar un cierto

nmero de caracterstica con el objeto de especializarla posteriormente.
Definicin de clase concreto.
Es una clase que tiene instancias directas. Las clases concretas pueden poseer
subclases abstractas.
Definicin de atributos.
Un atributo es una propiedad de los objetos de una clase. Es un valor de datos de
los objetos de una clase.
No debemos confundir los identificadores internos con los atributos del mundo
real.
_ Los identificadores internos son solo una conveniencia y no tienen significado en
el dominio del problema.

5 trabajo de investigacin.
Visibilidad, sintaxis y valor publica, protegida o privada d un atributo.
Identifican las caractersticas propias de cada clase. Generalmente son de tipos
simples, ya que los atributos de tipos compuestos se representan mediante
asociaciones de composicin con otras clases. La sintaxis de un atributo es
Visibility name: Type-expression = initial-value {property-string}
Donde visibility es uno de los siguientes:
+
Public visibility
# Protected visibility
private visibility

Type-expression es el tipo del atributo con nombre name. Puede especificarse

como se ve un valor inicial y un conjunto de propiedades del atributo.
Definicin Operacin.
Es el conjunto de operaciones que describe el comportamiento de los objetos de
un enlace.

6 trabajo de investigacin.

Visibilidad y sintaxis de una operacin.

El conjunto de operaciones describen el comportamiento de los objetos de una
clase. La sintaxis de una operacin en UML es
Visibility name (parameter-list): return-type-expression {property-string}
Cada uno de los parmetros en parameter-list se denota igual que un atributo. Los
dems elementos son los mismos encontrados en la notacin de un atributo.
Definicin de mtodos.
Las operaciones y los mtodos se declaran con la misma sintaxis:

Cuerpo del mtodo.

Especificaciones.
Consulta.
Polimorfismo.
Alcances.
Compulencia.
Seales.
Regla de estilo:

Los nombres de las operaciones comienzan con letras minsculas.

Los nombres de las operaciones se muestran con letras normales.
Las operaciones abstractas se muestran con letras cursivas.
Clase u objetos.
Una clase sirve para cargar las instancias en un objeto que puede
representarse en otro modelo de objeto.
La representacin de un objeto es parecida a la de una clase.
La relacin de la sintaxis se evidencian por una flecha puntuada que
va de la clase hacia la instancia.

7 trabajo de investigacin.
Asociaciones.
Una asociacin (relacin entre dos clases) se representa como una lnea continua
entre dos Clases, y puede tener el nombre de la relacin sobre esta lnea.
Ejemplo:

Para mostrar que la relacin slo tiene un sentido se muestra con una flecha que
indica el sentido de la relacin. Ejemplo:

Viaje
En este ejemplo un Pasajero conoce el Carro(o carros) con el cual viaja, pero el
Carro no tiene ninguna relacin con los Pasajeros.
Multiplicidad.
Es una restriccin que se pone a una asociacin, que limita el nmero de
instancias de una clase que pueden tener esa asociacin con una instancia de la
otra clase.

En este caso las relaciones son:

- Un chofer tiene relacin con cero o ms autobuses.
- Un autobs tiene relacin con uno o dos choferes.
- Una terminal de pasajero tiene relacin con cero o muchos autobuses.
- Un autobs tiene relacin con un terminal de pasajero.
Asociacin (rol, multiplicidad, calificador).
Una asociacin en general es una lnea que une dos o ms smbolos. Pueden
tener varios tipos de adornos, que definen su semntica y caractersticas. Los
tipos de asociaciones entre clases presentes en un diagrama esttico son:

1. Asociacin binaria
2. Asociacin n-aria
3. Composicin
4. Generalizacin
5. Refinamiento
Cada asociacin puede presentar algunos elementos adicionales que dan detalle
a la relacin, como son:
Rol: Identificado como un nombres al los finales de la lnea, describe la
semntica de la relacin en el sentido indicado. Por ejemplo, la asociacin
de composicin entre Maquina e Ingrediente recibe el nombre de
existencias, como rol en ese sentido

TIPOS DE ASOCIACIONES.
Agregacin.
La agregacin representa el objeto compuesto. Durante el desarrollo de una
aplicacin se nos presentara la necesidad de crear objetos complejos que no
encajan con los tipos de datos bsicos que proveen los lenguajes: tipo caracteres,
enteros, reales, entre otros. El smbolo de agregacin es un diamante colocado en
el extremo en el que est la clase que representa el todo. Podemos trabajar con
dos tipos de agregacin: Agregacin por Valor y Agregacin por Referencia.
Agregacin por o por valor (Composicin).
El contenedor contiene el objeto en s. Cuando creamos un objeto contenedor, se
crean tambin automticamente los contenidos. Ejemplo:

Agregacin por referencia

Se tienen punteros a objetos. No hay un acoplamiento fuerte. Los objetos se crean
y se destruyen dinmicamente.

Composicin.
Es una asociacin fuerte, que implica tres cosas:

Dependencia existencial. El elemento dependiente desaparece al destruirse

el que lo contiene y, si es de Cardinalidad, es creado al mismo tiempo.

Hay una pertenencia fuerte. Se puede decir que el objeto contenido es

parte constitutiva y vital del que lo contiene

Los objetos contenidos no son compartidos, esto es, no hacen parte del
estado de otro objeto.

Se denota dibujando un rombo relleno del lado de la clase que contiene a la otra
en la relacin. Existe tambin una relacin de composicin menos fuerte que es
denotada por un rombo sin rellenar en uno de los extremos. Un ejemplo puede
encontrarse entre Producto e Ingrediente.
Generalizacin.
La relacin de generalizacin denota una relacin de herencia entre clases. Se
representa dibujando un tringulo sin rellenar en el lado de la superclase. La
subclase hereda todos los atributos y mensajes descritos en la superclase.
Herencia.
La herencia es tomar caractersticas y funcionalidades definidas en otras clases.
Ejemplo: Auto hereda de vehculo motorizado. Como gra tambin hereda de
vehculo automotor. Las clases no estn aisladas, sino que se relacionan entre s,
formando una jerarqua de clasificacin. Los objetos heredan las propiedades y el
comportamiento de todas las clases a las que pertenecen. La herencia organiza y
facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser
definidos y creados como tipos especializados de objetos preexistentes.
La relacin de herencia se representa mediante un triangulo en el extremo de la
relacin que corresponde a la clase mas general o clase padre. Al plantear una
relacin de herencia con varias clases subordinadas, dentro de un diagrama
concreto, no se hace necesario colocarlas todas, podemos representar con
puntos suspensivos. Ejemplo:

Dependencia.

Denota una relacin semntica entre dos elementos (clases o paquetes, por el
momento) del modelo. Indica que cambiar el elemento independiente puede
requerir cambios en los dependientes. Se muestra como una lnea punteada
direccional, indicando el sentido de la dependencia. Puede tener por medio de
estereotipos una explicacin del tipo de dependencia presentada.
Refinamiento.
Es una relacin o asociacin entre dos descripciones del mismo elemento pero a
diferentes niveles de abstraccin.
Nota.
Es un comentario dentro de un diagrama. Puede estar relacionado con uno o mas
elementos en el diagrama mediantes lneas punteadas.
Pueden representar aclaraciones al diagrama o restricciones sobre los elementos
relacionados. Se grafica median5te un rectngulo con su borde superior derecho
doblado.
Clase perimtrica.
Una clase perimtrica representa el concepto de clase genrica en los conceptos
bsicos orientados a objeto. Permite construir colecciones universales con tipo de
parmetros efectivos.
Se grafica como una clase acompaado de un rectngulo en la esquina superior
derecha con los parmetros del caso.
Paquete.
Es una forma de agrupar clases (u otros elementos en otro tipo de diagramas) en
modelos grandes. Pueden tener ocasiones de dependencia o de generalizacin.
Un paquete puede componer varios tipos de entidades (clases, asociaciones,
otros paquetes).
Aquellas que pertenecen al paquete.
Aquellas donde se definen.
Aquellas que son referenciados por el paquete.
Puede representarse en 2 formas:

1- Puede describir explcitamente su contenido, el conjunto de las entidades

posedas y referenciales.
2- Puede representarse simplemente con un rectngulo y una pestaa que
contiene su nombre. Esta vista permite comprender la organizacin
funcional de modelo de objeto.
Esterotipo:
La clase y dems elementos notacionales en los diagramas pueden estar
clasificados de acuerdo a varios criterios, como por ejemplo su objetivo dentro
de un programa. Esta clasificacin adicional se expresa mediante un
esterotipo.
Los esterotipo cumplen 2 funciones:
1- Clasifica elementos del modelo. Por eso permiten crear familias de
elementos asociados a un mismo esterotipo.
2- Modifica la semntica de los elementos asociados y permiten la creacin de
nuevos conceptos propios de una aplicacin.

Esterotipo de interface.

Esterotipo de actor.
Interface
x

<<interface>>

entes esterotipos que ofrece UML.

Clase de control.

Entidad.

Interface.

Navegacin: los enlaces pueden ser vistos como canales de navegacin entre los
objetos. Estos canales permiten desplazarse y realizar las formas de colaboracin
que corresponden a los diferentes escenarios.

CLASE A

CLASE B

Interface: es una clase particular que solo contiene operaciones.

Asociacin OR:
En algunas ocasiones es necesario describir que una clase esta relacionada con
un objeto de una clase u otra clase. Este se denota por medio de una relacin OR
exclusivo.

Dueo

AUTOMOVIL.

PERSONA.

OR

Dueo

EMPRESA.

CLASE DE ASOCIACION.
Algunas veces es til modelar una relacin como una clase.

Cada enlace se convierte en una instancia de la clase.

Es una asociacin que tambin es una clase.
Tiene propiedades tales como la de las clases como la de asociaciones.
Sus instancias son enlaces que tienen valores de atributos a la vez que
referencian a otros objetos.
Una asociacin puede representarse por una clase para aadir atributos y
operaciones a la asociacin.
Una clase de asociacin es informacin detallada. Permite encapsular
datos y comportamientos que tienen razn de ser en el mareo de la
asociacin.

Por ejemplo:

MURO

Posicin.
X: int
Y: int

VENTANA

PERSONA

SUELDO

TARJETA
EFECTIV

Diagrama de clase.

PERSONA

ASOCIACION

AUTOR
1

DISCRIMINAD
ALUMNO

OR

ATRIBUTOS

ROL
SOLICITA

NAVEGAVILIDAD

LIBRO

OPERACIONES
CLASE

PRESTAMO

NOTA

GENERALIZA

CLASE DE ASOCIACION
MULTIPLICIDAD