UNIVERSIDAD POLITECNICA DE

TAPACHULA

CARRERA: INGENIERIA DE SOFTWARE.

MATERIA: DISEO DE SISTEMAS.

TEMA: LINEAMIENTOS Y PRINCIPIOS DE DISEOS.

INTEGRANTES : BENJAMIN RAFAEL ESPINOSA ESTRADA.

JOSE LEONARDO SANCHEZ MEJIA.

GRADO Y GRUPO: 7MO A

PROFESOR: ALFREDO CASTILLO SOLIS

11 DE SEPTIEMBRE DE 2016

INTRODUCION.
El trmino lenguaje ha generado bastante confusin respecto a lo que es
UML. En realidad el trmino lenguaje quizs no es el ms apropiado, ya que no
es un lenguaje propiamente dicho, sino una serie de normas y estndares
grficos respecto a cmo se deben representar los esquemas relativos al
software. Mucha gente piensa por confusin que UML es un lenguaje de
programacin y esta idea es errnea: UML no es un lenguaje de programacin.
Como decimos, UML son una serie de normas y estndares que dicen cmo se
debe representar algo.
La programacin orientada a objetos o POO, como bien sabemos, es un
paradigma de programacin cuyo manejo hoy se considera de los
conocimientos ms importantes para desarrollar software. En resumen, la
tcnica consiste en hacer abstracciones de los conceptos ms importantes de
un problema y representarlos en unidades llamadas objetos. En ellos se
representan las caractersticas de la abstraccin y su comportamiento.
Para desarrollar programas eficientes con esta tcnica, es necesario conocer
algunas reglas importantes al respecto, puesto que no es slo importante
conocer la construccin correcta de los objetos sino tambin la relacin que
tienen entre ellos. Un buen diseo de POO significa que a la hora de darle
mantenimiento al programa, va a ser mucho ms entendible y sencillo adems
de tener alta facilidad para hacer cambios.
Para ayudarnos con estas reglas, el profesional en software Robert Cecil
Martin, ha inventado el acrnimo S.O.L.I.D. que en ingles cada letra representa
un principio de la POO

EL LENGUAJE UNIFICADO DE MODELADO (UML)

En todas las disciplinas de la Ingeniera se hace evidente la importancia de los

modelos ya que describen el aspecto y la conducta de "algo". Ese "algo" puede
existir, estar en un estado de desarrollo o estar, todava, en un estado de
planeacin. Es en este momento cuando los diseadores del modelo deben
investigar los requerimientos del producto terminado y dichos requerimientos
pueden incluir reas tales como funcionalidad, performance y confiabilidad.
Adems, a menudo, el modelo es dividido en un nmero de vistas, cada una de
las cuales describe un aspecto especfico del producto o sistema en
construccin.
El modelado sirve no solamente para los grandes sistemas, aun en
aplicaciones de pequeo tamao se obtienen beneficios de modelado, sin
embargo es un hecho que entre ms grande y ms complejo es el sistema,
ms importante es el papel de que juega el modelado por una simple razn: "El
hombre hace modelos de sistemas complejos porque no puede entenderlos en
su totalidad".
UML es una tcnica para la especificacin sistemas en todas sus fases. Naci
en 1994 cubriendo los aspectos principales de todos los mtodos de diseo
antecesores y, precisamente, los padres de UML son Grady Booch, autor del
mtodo Booch; James Rumbaugh, autor del mtodo OMT e Ivar Jacobson,
autor de los mtodos OOSE y Objectory. La versin 1.0 de UML fue liberada en
Enero de 1997 y ha sido utilizado con xito en sistemas construidos para toda
clase de industrias alrededor del mundo: hospitales, bancos, comunicaciones,
aeronutica, finanzas, etc.

Los principales beneficios de UML son:

Mejores tiempos totales de desarrollo (de 50 % o ms).

Modelar sistemas (y no slo de software) utilizando conceptos

orientados a objetos.

Establecer conceptos y artefactos ejecutables.

Encaminar el desarrollo del escalamiento en sistemas complejos de

misin crtica.

Crear un lenguaje de modelado utilizado tanto por humanos como por

mquinas.

Mejor soporte a la planeacin y al control de proyectos.

Alta reutilizacin y minimizacin de costos.

UML, Mtodo o Lenguaje de Modelado?

UML es un lenguaje para hacer modelos y es independiente de los mtodos de

anlisis y diseo. Existen diferencias importantes entre un mtodo y un
lenguaje de modelado. Un mtodo es una manera explcita de estructurar el
pensamiento y las acciones de cada individuo. Adems, el mtodo le dice al
usuario qu hacer, cmo hacerlo, cundo hacerlo y por qu hacerlo; mientras
que el lenguaje de modelado carece de estas instrucciones. Los mtodos
contienen modelos y esos modelos son utilizados para describir algo y
comunicar los resultados del uso del mtodo.
Un modelo es expresado en un lenguaje de modelado. Un lenguaje de
modelado consiste de vistas, diagramas, elementos de modelo los smbolos
utilizados en los modelos y un conjunto de mecanismos generales o reglas
que indican cmo utilizar los elementos. Las reglas son sintcticas, semnticas
y pragmticas

Vistas:
Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es
una grfica, pero s una abstraccin que consiste en un nmero de diagramas y
todos esos diagramas juntos muestran una "fotografa" completa del sistema.
Las vistas tambin ligan el lenguaje de modelado a los mtodos o procesos
elegidos para el desarrollo. Las diferentes vistas que UML tiene son:

Vista Use-Case: Una vista que muestra la funcionalidad del sistema

como la perciben los actores externos.

Vista Lgica: Muestra cmo se disea la funcionalidad dentro del

sistema, en trminos de la estructura esttica y la conducta dinmica del
sistema.

Vista de Componentes: Muestra la organizacin de los componentes de

cdigo.

Vista Concurrente: Muestra la concurrencia en el sistema, direccionando

los problemas con la comunicacin y sincronizacin que estn presentes
en un sistema concurrente.

Vista de Distribucin: muestra la distribucin del sistema en la

arquitectura fsica con computadoras y dispositivos llamados nodos.

Diagramas:
Los diagramas son las grficas que describen el contenido de una vista. UML
tiene nueve tipos de diagramas que son utilizados en combinacin para proveer
todas las vistas de un sistema: diagramas de caso de uso, de clases, de
objetos, de estados, de secuencia, de colaboracin, de actividad, de
componentes y de distribucin.

Tipos de diagramas:

Diagramas de estructura

Diagrama de clases: Describe los diferentes tipos de objetos en un

sistema y las relaciones existentes entre ellos. Dentro de las clases muestra
las propiedades y operaciones, as como las restricciones de las conexiones
entre objetos.

Diagrama de objetos: (Tambin llamado Diagrama de instancias) Foto de

los objetos en un sistema en un momento del tiempo.

Diagrama de paquetes: Muestra la estructura y dependencia entre

paquetes, los cuales permiten agrupar elementos (no solamente clases)
para la descripcin de grandes sistemas.

Diagrama de despliegue: Muestra la relacin entre componentes o

subsistemas software y el hardware donde se despliega o instala.

Diagrama de estructura compuesta: Descompone jerrquicamente una

clase mostrando su estructura interna.

Diagrama de componentes: Muestra la jerarqua y relaciones entre

componentes de un sistema software.

2) Diagramas de comportamiento

Diagrama de casos de uso: Permite capturar los requerimientos

funcionales de un sistema.

Diagrama de estado: Permite mostrar el comportamiento de un objeto a

lo largo de su vida.

Diagrama de actividad: Describe la lgica de un procedimiento, un

proceso de negocio o workflow.

Diagramas de interaccin (Subgrupo dentro de los diagramas de

comportamiento): Describen cmo los grupos de objetos colaboran para
producir un comportamiento. Son los siguientes:

Diagrama de secuencia: Muestra los mensajes que son pasados entre

objetos en un escenario.

Diagrama de comunicacin: Muestra las interacciones entre los

participantes haciendo nfasis en la secuencia de mensajes.

Diagrama de colaboracin: (Solamente en UML 1.X) Muestra las

interacciones organizadas alrededor de los roles.

Diagrama de (visin de conjunto o resumen de) interaccin: Se trata de

mostrar de forma conjunta diagramas de actividad y diagramas de
secuencia.

Diagrama de tiempo: Pone el foco en las restricciones temporales de un

objeto o un conjunto de objetos.

Smbolos o Elementos de modelo

: Los conceptos utilizados en los diagramas son los elementos de modelo que
representan conceptos comunes orientados a objetos, tales como clases,
objetos y mensajes, y las relaciones entre estos conceptos incluyendo la
asociacin, dependencia y generalizacin. Un elemento de modelo es utilizado
en varios diagramas diferentes, pero siempre tiene el mismo significado y
simbologa.

Reglas o Mecanismos generales:

Proveen comentarios extras, informacin o semntica acerca del elemento de
modelo; adems proveen mecanismos de extensin para adaptar o extender
UML a un mtodo o proceso especfico, organizacin o usuario.

FASES DEL DESARROLLO DE UN SISTEMA

Las fases del desarrollo de sistemas que soporta UML son: Anlisis de
requerimientos, Anlisis, Diseo, Programacin y Pruebas.

Anlisis de Requerimientos
UML tiene casos de uso (use-cases) para capturar los requerimientos del
cliente. A travs del modelado de casos de uso, los actores externos que tienen
inters en el sistema son modelados con la funcionalidad que ellos requieren
del sistema (los casos de uso). Los actores y los casos de uso son modelados
con relaciones y tienen asociaciones entre ellos o stas son divididas en
jerarquas. Los actores y casos de uso son descritos en un diagrama use-case.
Cada use-case es descrito en texto y especifica los requerimientos del cliente:
lo que l (o ella) espera del sistema sin considerar la funcionalidad que se

implementar. Un anlisis de requerimientos puede ser realizado tambin para

procesos de negocios, no solamente para sistemas de software.

Anlisis
La fase de anlisis abarca las abstracciones primarias (clases y objetos) y
mecanismos que estn presentes en el dominio del problema. Las clases que
se modelan son identificadas, con sus relaciones y descritas en un diagrama de
clases. Las colaboraciones entre las clases para ejecutar los casos de uso
tambin se consideran en esta fase a travs de los modelos dinmicos en
UML. Es importante notar que slo se consideran clases que estn en el
dominio del problema (conceptos del mundo real) y todava no se consideran
clases que definen detalles y soluciones en el sistema de software, tales como
clases para interfaces de usuario, bases de datos, comunicaciones,
concurrencia, etc.

Diseo
En la fase de diseo, el resultado del anlisis es expandido a una solucin
tcnica. Se agregan nuevas clases que proveen de la infraestructura tcnica:
interfaces de usuario, manejo de bases de datos para almacenar objetos en
una base de datos, comunicaciones con otros sistemas, etc. Las clases de
dominio del problema del anlisis son agregadas en esta fase. El diseo resulta
en especificaciones detalladas para la fase de programacin.

Programacin
En esta fase las clases del diseo son convertidas a cdigo en un lenguaje de
programacin orientado a objetos. Cuando se crean los modelos de anlisis y
diseo en UML, lo ms aconsejable es trasladar mentalmente esos modelos a
cdigo.

Pruebas
Normalmente, un sistema es tratado en pruebas de unidades, pruebas de
integracin, pruebas de sistema, pruebas de aceptacin, etc. Las pruebas de
unidades se realizan a clases individuales o a un grupo de clases y son
tpicamente ejecutadas por el programador. Las pruebas de integracin
integran componentes y clases en orden para verificar que se ejecutan como
se especific. Las pruebas de sistema ven al sistema como una "caja negra" y
validan que el sistema tenga la funcionalidad final que le usuario final espera.
Las pruebas de aceptacin conducidas por el cliente verifican que el sistema
satisface los requerimientos y son similares a las pruebas de sistema.

S.O.L.I.D.
Solid es un acrnimo inventado por Robert C.Martin para establecer los
cinco principios bsicos de la programacin orientada a objetos y diseo.
Este acrnimo tiene bastante relacin con los patrones de diseo, en
especial, con la alta cohesin y el bajo acoplamiento.
El objetivo de tener un buen diseo de programacin es abarcar la fase de
mantenimiento de una manera ms legible y sencilla as como conseguir
crear nuevas funcionalidades sin tener que modificar en gran medida
cdigo antiguo. Los costes de mantenimiento pueden abarcar el 80% de
un proyecto de software por lo que hay que valorar un buen diseo.

S-Responsabilidad simple (Single responsibility)

Este principio trata de destinar cada clase a una finalidad sencilla y
concreta. En muchas ocasiones estamos tentados a poner un mtodo
reutilizable que no tienen nada que ver con la clase simplemente porque lo

utiliza y nos pilla ms a mano. En ese momento pensamos "Ya que estamos
aqu, para que voy a crear una clase para realizar esto. Directamente lo
pongo aqu".
El problema surge cuando tenemos la necesidad de utilizar ese mismo
mtodo desde otra clase. Si no se refactoriza en ese momento y se crea
una clase destinada para la finalidad del mtodo, nos toparemos a largo
plazo con que las clases realizan tareas que no deberan ser de su
responsabilidad.
Con la anterior mentalidad nos encontraremos, por ejemplo, con un
algoritmo de formateo de nmeros en una clase destinada a leer de la
base de datos porque fue el primer sitio donde se empez a utilizar. Esto
conlleva a tener mtodos difciles de detectar y encontrar de manera que el
cdigo hay que tenerlo memorizado en la cabeza.

O-Abierto/Cerrado (Open/Closed)
Principio atribuido a Bertrand Meyer que habla de crear clases
extensibles sin necesidad de entrar al cdigo fuente a modificarlo. Es
decir, el diseo debe ser abierto para poderse extender pero cerrado
para poderse modificar. Aunque dicho parece fcil, lo complicado es
predecir por donde se debe extender y que no tengamos que
modificarlo. Para conseguir este principio hay que tener muy claro
como va a funcionar la aplicacin, por donde se puede extender y
como van a interactuar las clases.
El uso ms comn de extensin es mediante la herencia y la
reimplementacin de mtodos. Existe otra alternativa que consiste en
utilizar mtodos que acepten una interface de manera que podemos
ejecutar cualquier clase que implemente ese interface. En todos los
casos, el comportamiento de la clase cambia sin que hayamos tenido
que tocar cdigo interno.
Como ya he comentado llega un momento en que las necesidades
pueden llegar a ser tan imprevisibles que nos topemos que con los
mtodos definidos en el interface o en los mtodos extensibles, no

sean suficientes para cubrir las necesidades. En este caso no habr

ms remedio que romper este principio y refactorizar.

L-Sustitucion Liskov (Liskov substitution)

Este principio fue creado por Barbara Liskov y habla de la importancia
de crear todas las clases derivadas para que tambin puedan ser
tratadas como la propia clase base. Cuando creamos clases derivadas
debemos asegurarnos de no reimplementar mtodos que hagan que
los mtodos de la clase base no funcionases si se tratasen como un
objeto de esa clase base.

I-Segregacion del interface (Interface segregation)

Este principio fue formulado por Robert C. Martin y trata de algo

parecido al primer principio. Cuando se definen interfaces estos deben
ser especficos a una finalidad concreta. Por ello, si tenemos que
definir una serie de mtodos abstractos que debe utilizar una clase a
travs de interfaces, es preferible tener muchos interfaces que definan
pocos mtodos que tener un interface con muchos mtodos.
El objetivo de este principio es principalmente poder reaprovechar
los interfaces en otras clases. Si tenemos un interface que
compara y clona en el mismo interface, de manera ms complicada
se podr utilizar en una clase que solo debe comparar o en otra que
solo debe clonar.

D-Inversin de dependencias (Dependency inversion)

Tambin fue definido por Robert C. Martin. El objetivo de este

principio conseguir desacoplar las clases. En todo diseo siempre
debe existir un acoplamiento pero hay que evitarlo en la medida de lo
posible. Un sistema no acoplado no hace nada pero un sistema
altamente acoplado es muy difcil de mantener.
El objetivo de este principio es el uso de abstracciones para
conseguir que una clase interactue con otras clases sin que las
conozca directamente. Es decir, las clases de nivel superior no
deben conocer las clases de nivel inferior. Dicho de otro modo, no
debe conocer los detalles. Existen diferentes patrones como la
inyeccin de dependencias o service locator que nos permiten
invertir el control.

CONCLUSION.
La finalidad de los diagramas es presentar
diversas perspectivas de un sistema, a las cuales
se les conoce como modelo. Recordemos que un
modelo es una representacin simplificada de la
realidad; el modelo UML describe lo que
supuestamente har un sistema, pero no dice
cmo implementar dicho sistema.

SOLID es un conjunto de principios que puedes

seguir, de manera total, o en parte, para
desarrollar eficientemente tu aplicacin.

REFERENCIAS:

http://www.teatroabadia.com/es/uploads/docume
ntos/iagramas_del_uml.pdf

http://joaquinoriente.com/2014/07/09/uml-2cuantos-tipos-de-diagramas-existen/

https://www.video2brain.com/mx/tutorial/introdu
ccion-a-principios-solid

http://profesores.fib.unam.mx/carlos/aydoo/uml.html

https://jorgeluispattoni.wordpress.com/2011/08/
22/s-o-l-i-d-los-principios-de-la-programacionorientada-a-objetos/

http://elvex.ugr.es/decsai/java/pdf/3E-UML.pdf