Sie sind auf Seite 1von 25

INACAP VIRTUAL

COPYRIGHT 2014 TODOS LOS DERECHOS RESERVADOS INACAP | INACAP VIRTUAL

SISTEMAS DE INFORMACIN II
TI1216

SISTEMAS DE INFORMACIN II
TI1216
Unidad 1: Principios del diseo

UNIDAD 1: PRINCIPIOS DEL DISEO

INACAP VIRTUAL

ndice
Introduccin 

Contenidos 

Tema 1. Gestin empresarial 

1.1 Los factores de la gestin empresarial 

1.2. Relacin entre los factores de la gestin empresarial 

22

1.3. El factor humano o capital humano 

23

1.3.1. Modelos de comportamiento: individual, organizacional y relaciones laborales 24

1.3.2. Modelos de gestin de personas: gestin por competencias, gestin del conocimiento, gestin del talento, gestin del capital humano y gestin del cambio 

26

1.3.3. El capital intelectual y el talento humano: una reflexin 

32

CONCLUSIONES 

36

BIBLIOGRAFA 

37

SISTEMAS DE INFORMACIN II

SISTEMAS DE INFORMACIN II
TI1216

Introduccin
El presente documento se organiza en cinco temas que entregan elementos tericos
y prcticos relacionados con el diseo de soluciones integrales de los sistemas de
informacin, sobre los cuales las empresas basan su funcionamiento; automatizando
procesos, actividades y tareas desarrolladas en todos los niveles de la organizacin.
De esta forma, el contenido de esta unidad considera elementos para reconocer la
diferencia entre soluciones genricas y a la medida, adems de los conceptos de
diseo y los patrones que pueden ser utilizados en el desarrollo de software.
Con este propsito, el primer tema, Tipos de soluciones, nos introduce en la relacin
entre los tipos de soluciones genricas y soluciones a medida, mostrando las ventajas del uso de una u otra solucin y los contextos donde se pueden aplicar.
Diseo de soluciones, el segundo tema del documento, presenta fundamentos y
principios del diseo, dando a conocer conceptos claves, tales como abstraccin,
acoplamiento, modularidad, etc. Adems de aspectos que se deben considerar al
momento de disear un software.
El tercer tema, Estandarizacin del diseo, da cuenta de la importancia de la estandarizacin y las tendencias actuales a nivel del desarrollo de software, tales como el
UML, tema que viene a ser ampliado en el cuarto tema al darse a conocer el Modelo
4+1 y todas sus vistas.
El ltimo tema, Patrones de diseo, contempla la definicin de los principales patrones a modo de introduccin.
Con el objetivo de ampliar la informacin que se entrega en este documento introductorio, se han incorporado, en la bibliografa, enlaces a sitios web, que amplan la
informacin dada a conocer en los temas presentados.

UNIDAD 1: PRINCIPIOS DEL DISEO

INACAP VIRTUAL

Contenidos
Tema 1. Tipos de soluciones
1.1 El contexto de las soluciones
El software se ha transformado en un elemento clave en la gestin. Desde hace varias dcadas, las organizaciones
de todo tipo, independientemente de su tamao, vienen implementando el software como una herramienta imprescindible dentro de los procesos. Esto es, porque el software aplicado al mbito empresarial ha permitido avances
indudables y significativos en el terreno de la gestin de la informacin, logrando de esta forma convertir los procesos
productivos y comerciales en operaciones realmente eficaces y precisas.
Punto de reflexin
Hace solo unas dcadas cuando una persona realizaba depsitos en efectivo para que
fuesen retirados en otra ciudad, no podan
ser cobrados el mismo da, dado que los sistemas
eran en gran parte manual y no estaban en lnea.

Es fundamental que las empresas seleccionen adecuadamente las herramientas de software que se van a utilizar
al momento de realizar sus actividades comerciales, ya
que depende de esta decisin el que se desarrollen de
forma adecuada y previsible. Hoy en da, existen desarrollos de software destinados a satisfacer las necesidades
de todas las reas de una empresa, desde herramientas
que permitan mantener un control actualizado del stock,
de la produccin y de la gestin adecuada de la distribucin de productos, adems de mantener una comunicacin constante con la cartera de clientes.
El software de gestin empresarial se ha convertido en
una herramienta necesaria para cualquier organizacin,
independiente de que se trate de una compaa multinacional o una microempresa que recin inicia sus actividades comerciales.

SISTEMAS DE INFORMACIN II

Dada la diversidad de necesidades que puede tener una


empresa, el software que requiere se debe ajustar a su
naturaleza para gestionar su informacin, la que estar
condicionada al flujo de datos de la organizacin. A raz
de esta realidad, las empresas deben decidir si optan por
software genrico o un sistema desarrollado a la medida.
En gran parte esta decisin pasa por los recursos disponibles para implementar una u otra alternativa.

Pregunta de reflexin
Utilizara software genrico en una solucin
que requiere gestionar informacin y que posee
parmetros muy particulares de la empresa?

SISTEMAS DE INFORMACIN II
TI1216

El software genrico, tambin conocido como paquete comercial, es un sistema cerrado que viene con herramientas
propias, las cuales no pueden ser modificadas, por ejemplo el software comercializado por Microsoft. En el otro extremo, nos encontramos con el software a medida, el cual es personalizado o configurado de acuerdo a las necesidades
reales de la empresa. Ambos tienen aspectos positivos y desventajas que se explican a continuacin.

1.2 Software genrico (propietario)


Para muchas empresas el software genrico en la actualidad es una solucin ideal, principalmente porque tiende
a ser relativamente ms econmico en el corto plazo que
las herramientas que se desarrollan a medida para una
determinada organizacin.
En general, se trata de software sofisticado y estable,
lo que hace que se convierta en una solucin inmediata para cualquier tipo de negocio, siempre y cuando se
trate de una organizacin donde la forma de trabajo se
caracterice por la simplicidad y el orden, ya que en estos

casos solo se requieren modificaciones sencillas sobre


los parmetros del sistema. Cualquier otra modificacin
mayor encarece significativamente el costo final del software adquirido, lo mismo sucede con las mantenciones
peridicas derivadas de las actualizaciones propias que
realiza el fabricante o cambios en variables legislativas,
por ejemplo la modificacin en tablas de impuesto o
nuevas leyes gubernamentales que afectan los sistemas.
Todas estas adecuaciones necesarias de realizar hacen
que el software genrico tienda a tener mayor costo que
una solucin a medida, (Gallegos, 2008).

Punto de reflexin
El software genrico proporciona un nivel de solucin que puede ser adecuado a las necesidades de la organizacin. En este sentido, se puede ver que muchas microempresas realizan sus procesos a travs de software de
planilla electrnica Microsoft Office, Open Office o Libre Office. Desde esta misma mirada se puede observar
que empresas de gran envergadura tambin pueden lograr gestionar sus procesos a travs de la utilizacin de
un software ERP desarrollado por empresas internacionales.
No obstante, muchas veces la decisin de implementar un software genrico en lugar de llevar adelante un desarrollo a medida, se debe a la escasez de recursos humanos que pueda conducir los procesos.

1.3 Orientacin del software genrico


El software genrico est orientado a aquellas empresas
que llevan su trabajo ordenado y con procesos simples;
dado que sus requerimientos son mnimos, solicitan tambin un nivel mnimo de personalizacin de sus sistemas
de informacin.
Aunque es importante destacar que existen productos
genricos orientados a mercados verticales, porque las
exigencias son mayores y el volumen de mercado lo justifica, estos son ideales para las empresas de dicho sector

porque responden a todas las necesidades del negocio


y claramente lo podemos observar en el sector de distribucin donde encontramos software genricos para
gestin de distribucin y soluciones mviles para fuerza de ventas, hoy en da herramientas imprescindibles
para el desarrollo de las operaciones diarias. Obtener
los mismos beneficios desarrollando soluciones a medida para estas dos reas neurlgicas de las empresas de
distribucin es muy difcil y resultara muy costoso (en
tiempo y dinero) de hacer y mantener.

UNIDAD 1: PRINCIPIOS DEL DISEO

INACAP VIRTUAL

1.4 El software a medida


El software a medida es bsicamente una solucin diseada de forma especfica para las necesidades precisas
de una empresa. Se desarrolla en base a la manera en
que la organizacin desea llevar adelante sus operaciones, debido a que, como su nombre lo indica, son herramientas que pueden ser perfectamente adaptadas para
los requerimientos exactos que posee una organizacin.
Siempre que sea posible, se debe contar con el cdigo
fuente de la aplicacin. Este procedimiento garantiza un
mayor nivel de seguridad, de lo contrario cuando no se
dispone del cdigo fuente del sistema de informacin,
la empresa queda expuesta y se vuelve dependiente de
los desarrolladores. Para evitar esto, algunas empresas
contratan un equipo de desarrollo que proporciona el
cdigo fuente del software. Esta ltima accin no est
exenta de riesgos, debido a que si los desarrolladores no
conocen los alcances y limitaciones del producto final se
pierde confiabilidad.
Cabe destacar que una de las principales razones por las
que en muchas ocasiones gran cantidad de empresas se
rehsan a utilizar este tipo de solucin reside en que, en
general, la inversin necesaria para la adquisicin de un
software a medida suele ser mayor a la que se requiere
para un software genrico. Claro est que los beneficios
otorgados tambin pueden ser importantes segn el
caso, por lo que vale la pena evaluar la utilizacin de este
tipo de herramientas.
Entre las grandes ventajas que reporta un software a medida, destaca que encontramos una solucin que se ajus-

ta a las necesidades especficas de cada empresa, lo que


indudablemente proporciona mejoras en el rendimiento. Asimismo, se trata de un sistema realmente flexible,
ya que permite ser modificado a lo largo del tiempo, de
acuerdo a los cambios que se vayan produciendo en relacin a las necesidades y prcticas comerciales de la empresa. Esto, a su vez, hace posible incorporar los procesos
de negocio que son especficos para la organizacin.

Punto de reflexin
Para desarrollar un software a medida, se requiere
hacer uso de diversas competencias: por una parte
se debe poseer habilidades de desarrollo de software tales como anlisis, diseo, programacin;
y por otra se debe contar con dominio de la especialidad que se desea automatizar.

El software a medida permite la personalizacin de las


interfaces grficas, adecuando los sistemas nuevos a los
que actualmente utiliza la empresa. De esta forma, el
proceso no requiere de una profunda capacitacin del
personal. Al mismo tiempo, este tipo de herramientas
puede funcionar de manera integrada con otro software,
lo que permite lograr disponer de un sistema plenamente articulado para la infraestructura de TI.
Con este tipo de solucin es recomendable el contacto
directo con los desarrolladores, puesto que si surgen
requerimientos sobre el software, se canaliza en forma
directa y adems se obtienen herramientas de gestin
personalizadas que otorgan ventajas sobre los competidores debido al nivel de detalle que se puede gestionar.

SISTEMAS DE INFORMACIN II

SISTEMAS DE INFORMACIN II
TI1216

1.5 Orientacin del software a medida


El software a medida se orienta en general hacia grandes empresas que buscan solucionar problemas que no
resuelven mediante software ERP. Tambin es usado por
compaas que buscan promover las ventas y las ganancias de forma progresiva a travs del aprovechamiento
del potencial que ofrecen los sistemas de informacin
especializados, ya que este tipo de solucin permite obtener ventajas competitivas que el software genrico no
suele proporcionar.
Este tipo de software tambin se orienta a empresas que
llevan a cabo modificaciones frecuentes o cuyas normas

pueden cambiar. A partir de esta realidad, con la utilizacin de este tipo de software, se pueden obtener ventajas, pues es una solucin que se puede ampliar y personalizar, permitiendo hacer modificaciones a medida y
que cambian el modo de trabajo de la organizacin, ya
sea por su crecimiento o bien por la variedad de sus productos y servicios.
Es altamente recomendable que aquellas empresas que
poseen una actividad especializada opten por este tipo
de solucin, ya que es una alternativa que brinda respuestas especficas a las necesidades concretas de su
operatoria.

Es recomendable que se utilice una solucin a la medida, cuando la forma de operar de la empresa no se
ajusta a ningn sistema que se comercializa en el mercado o bien resulta muy difcil ajustar los procesos de
la empresa a las soluciones de mercado existentes.

Tema 2. Diseo de soluciones


En este segundo apartado del documento, se abordarn las definiciones y propuestas presentadas en el documento
SWEBOK (Software Engineering Body of Knowledge) de Bourque & Fairley (2014), que corresponden a guas y definiciones proporcionadas por la IEEE para el diseo de software.

2.1 Fundamentos del diseo de software


La etapa de diseo en el proceso de construccin de software est organizada en dos fases:

El diseo arquitectnico; que describe cmo el software es descompuesto y organizado


en componentes, la arquitectura de software.
El diseo detallado; que se describe como el comportamiento especfico de estos
componentes.
El resultado de este proceso es un conjunto de modelos y artefactos que contienen las decisiones ms importantes
adoptadas durante el anlisis del software.

UNIDAD 1: PRINCIPIOS DEL DISEO

INACAP VIRTUAL

2.2 Principios de diseo

Abstraccin: es enfocarse sobre un objeto para un propsito en particular, con el fin de obtener la informacin
relevante no considerando el resto de la informacin.

En el ejemplo que se muestra, se observa una clase que representa a


un usuario humano. La forma de caracterizarlo ha sido representndolo
solamente con el nombre de usuario y la contrasea.

Acoplamiento y cohesin: el acoplamiento es definido como una medida de la interdependencia entre los

mdulos de un programa computacional; la cohesin es una medida que define cun fuertemente asociados se encuentran los elementos de un mdulo.

El presente ejemplo se encuentra asociado a la gestin de los pedidos


de un restaurant. En este se puede observar un paquete llamado
GestionPedidos que contiene varias clases estrechamente asociadas.

Descomposicin y la modularizacin: un proyecto de software grande puede ser dividido en compo-

nentes ms pequeos, con interfaces bien definidas que describen la interaccin entre los componentes. La forma de
hacerlo es colocar diferentes funcionalidades y responsabilidades en componentes diferentes.

En este caso vemos cmo las


funcionalidades del controlador
principal son organizadas en
paquetes diferentes.

10

SISTEMAS DE INFORMACIN II

SISTEMAS DE INFORMACIN II
TI1216

Encapsulacin u ocultamiento de informacin: consiste en agrupar y empaquetar los detalles in-

ternos de una abstraccin y hacerlos directamente inaccesibles a entidades externas; para su acceso se deben usar
interfaces de acceso.

A continuacin se presenta un ejemplo en el cdigo


de la clase usuario mostrada anteriormente, el
nombre y la clave son privados.
public class Usuario {
private String Nombre;
private Integer Clave;
public void Usuario() {
}
public void setNombre(String x) {
this.Nombre=x;
}
public String getNombre() {
return this.Nombre;

Para cambiar el nombre no se puede realizar la


modificacin directamente, sino que debe utilizarse
la funcin setNombre asociada para estos fines.

Separacin de la interfaz y de la implementacin: consiste en definir un componente mediante la


especificacin de una interfaz pblica (para el cliente) y otra con los detalles de su implementacin.

Suficiencia, integridad y primitivismo:

el logro de la suficiencia e integridad significa asegurar que un


componente de software captura nicamente todas las caractersticas importantes de una abstraccin. Con respecto a
la primitividad el diseo debe estar basado en patrones que son fciles de implementar.

UNIDAD 1: PRINCIPIOS DEL DISEO

11

INACAP VIRTUAL

2.3 Aspectos claves a considerar durante el diseo


A continuacin se presenta una serie de elementos a considerar al momento de enfrentar la fase de diseo, estos elementos son los siguientes:

ASPECTOS CLAVE
Concurrencia: cmo se debe descomponer el software en procesos, tareas e hilos y
tratar temas relacionados con la eficiencia, la atomicidad, la sincronizacin, y los asuntos
de planificacin.

Control y manejo de eventos:

cmo organizar los datos y controlar el flujo,


cmo manejar eventos reactivos y temporales a travs de diversos mecanismos, tales
como invocacin implcita y call-back.

Distribucin de los componentes:


hardware.

cmo distribuir el software a travs

Manejo de errores: excepciones y tolerancia a fallos, cmo prevenir y tolerar los


fallos, adems hacer frente a condiciones excepcionales.

Interaccin y Presentacin: cmo estructurar y organizar las interacciones


con los usuarios y la presentacin de la informacin.

Persistencia de datos: cmo manejar los datos a travs del tiempo.

ASPECTOS A CONSIDERAR
Los lenguajes de programacin implementan los elementos de diseo que se han
descrito, como consecuencia es necesario tenerlos en cuenta al momento del diseo.
Por ejemplo el uso de las estructuras de captura de errores y recuperacin try-catch en
java, C#, javascript, etc.

2.4 Notaciones del diseo de software


Muchas notaciones y lenguajes existen para representar los artefactos del diseo de software. Algunos se utilizan
principalmente para describir un diseo de organizacin estructural, otros para representar el comportamiento del
software. Algunas notaciones se utilizan sobre todo en el diseo arquitectnico y otros, principalmente, durante el
diseo detallado. Aunque algunas notaciones pueden ser utilizadas en ambas etapas.

12

SISTEMAS DE INFORMACIN II

SISTEMAS DE INFORMACIN II
TI1216

2.4.1 Descripcin estructural (vista esttica)


Describe y representa los aspectos estructurales del diseo de software, es decir, se describen los principales componentes y la forma en que se interconectan.

Lenguajes de descripcin Son textuales, tienden a ser formales, son lenguajes usados para describir una arquide arquitecturas (ADLs).
tectura de software en trminos de componentes y conectores.

Diagramas de clases y de
objetos.

Se utiliza para representar un conjunto de clases (y objetos) y sus interrelaciones.

Diagramas de
componentes.

Se usa para representar un conjunto de componentes.

Tarjetas de clase
responsabilidad y
colaboracin (CRCs).

Se usan para indicar los nombres de los componentes (clase), sus responsabilidades, y
los nombres de los componentes que colaboran.

Diagramas de despliegue.

Se utilizan para representar un conjunto de nodos (fsica) y sus interrelaciones, y, por


tanto, para moldear los aspectos fsicos de un sistema.

Diagramas de entidadrelacin (ERDs).

Se utilizan para representar los modelos conceptuales de los datos almacenados en


sistemas de informacin.

Lenguajes descripcin de Lenguajes de programacin que se utilizan para definir las interfaces (nombres y tipos
Interfaz (IDLs).
de operaciones de exportacin) de los componentes de software.

Diagramas de
estructurales de Jackson.

Se utilizan para describir las estructuras de datos en trminos de secuencia, seleccin


e iteracin.

Diagramas de estructura.

Se utilizan para describir la estructura de llamada de los programas (En el cual describe
el llamado de los mdulos, y como un mdulo es llamado por otro modulo).

UNIDAD 1: PRINCIPIOS DEL DISEO

13

INACAP VIRTUAL

2.4.2 Descripcin del comportamiento


Las siguientes notaciones y los lenguajes grficos y textuales, se utilizan para describir el comportamiento dinmico
del software y sus componentes. Muchas de estas notaciones son tiles sobre todo durante el diseo detallado.

14

Diagramas de actividad.

Se utilizan para mostrar el flujo de control de una actividad.

Diagramas de
colaboracin.

Se utilizan para mostrar el resultado de las interacciones que se producen entre un


grupo de objetos, sus vnculos y los mensajes de intercambio en estos enlaces.

Diagramas de flujo de
datos (DFDs).

Se utilizan para mostrar el flujo de datos entre un conjunto de procesos.

Diagramas y tablas de
decisin.

Se utilizan para representar combinaciones complejas de condiciones y acciones

Diagramas de flujo
y diagramas de flujo
estructurado.

Se utilizan para representar el flujo de control y las acciones realizadas asociadas.

Diagramas de secuencia.

Se utilizan para mostrar el resultado de las interacciones entre un grupo de objetos,


con nfasis en el tiempo-pedido de mensajes.

Diagramas de estados y
transicin de estados.

Se utilizan para mostrar el flujo de control de estado a estado en una mquina de estados.

Lenguajes de
especificacin formal.

Lenguajes textuales que utilizan conceptos bsicos de las matemticas (por ejemplo,
lgica, ju, secuencia) de forma rigurosa y abstracta. Definen el software interfaces,
componentes y comportamiento, a menudo en trminos de pre y poscondiciones.

Pseudo-cdigo
y lenguajes de
programacin de diseo
(PDLs).

Lenguajes estructurados, como los lenguajes de programacin utilizados para describir el comportamiento de un procedimiento o mtodo generalmente en la fase de
proyecto.

SISTEMAS DE INFORMACIN II

SISTEMAS DE INFORMACIN II
TI1216

2.5 Estrategias y mtodos de diseo del software


Las estrategias consisten en descripciones generales de un proceso y directrices, dando origen a mtodos que pueden
ser usados como referencia por los ingenieros del software al momento de desarrollar un sistema de informacin.

Estrategias generales
Algunas estrategias generales tiles ocupadas para el proceso de diseo son: dividir para lograr ptimos resultados;
realizar un refinamiento paso a paso; la estrategia de arriba hacia abajo versus las de abajo hacia arriba; la extraccin
de datos y ocultamiento de informacin; el uso de la heurstica; el uso de patrones y patrones de lenguajes; y el uso de
un enfoque iterativo e incremental.

Diseo orientado a funciones (diseo estructurado)


Este es uno de los mtodos clsicos de diseo de software, donde los centros de descomposicin se realizan en la
identificacin de las principales funciones del software y, a continuacin, se procede con la elaboracin y refinacin de
arriba hacia abajo.
El diseo estructurado se utiliza generalmente despus de un anlisis estructurado, lo que produce, entre otras cosas,
los datos de diagramas de flujo y descripciones de procesos asociados.

Diseo orientado a objetos


En el mundo de la informtica se han propuesto numerosos mtodos de diseo de software basados en objetos. Es
as como el campo del diseo ha evolucionado a partir del diseo de objetos desde mediados de 1980 (sustantivo =
objeto; verbo = mtodo; adjetivo = atributo), avanzando cada vez ms hacia el diseo orientado a objetos, en el que la
herencia y el polimorfismo desempean un papel clave.

Diseo centrado en datos


Es un diseo centrado en la estructura de datos, en este tipo de diseo el ingeniero de software describe, en primer
lugar, los datos de entrada y salida de estructura (por ejemplo, usando diagramas de estructura de Jackson) y, a continuacin, se desarrolla la estructura del control de programa sobre la base de estos diagramas.

Diseo basado en componentes (CDB)


Un componente de software es una unidad independiente, que tiene bien definida interfaces y dependencias que se
pueden componer y desplegar en forma independiente. El diseo basado en componentes aborda temas relacionados
con la prestacin, desarrollo y la integracin de dichos componentes con el fin de mejorar la reutilizacin.

UNIDAD 1: PRINCIPIOS DEL DISEO

15

INACAP VIRTUAL

2.6 Tipos de diseo


Diseo a la medida

Diseo genrico

El diseo a la medida se fundamenta en los resultados


de los procesos de anlisis de requisitos que se han
efectuado sobre necesidades especficas de los
El diseo genrico, utiliza los resultados de diseos
clientes que no pueden ser cubiertas por un software anteriores que por sus caractersticas pueden ser
genrico.
ajustados a un desarrollo determinado, tal es el caso
de los patrones de diseo, que pueden ser utilizados
Tambin se lleva adelante un proceso de diseo a
en diversos proyectos informticos cada vez que se
la medida cuando los clientes buscan una solucin
requiera
novedosa con requisitos propios.

Aspectos a considerar
En el proceso previo al desarrollo de una solucin de cualquier tipo, genrica o a la medida, se realiza una fase de
diseo en la cual se pueden reusar componentes de diseo que han sido tiles en otras soluciones, esto permite
agilizar y fortalecer el proceso de desarrollo.

Tema 3. Estandarizacin del diseo


Hoy en da se cuenta con mltiples tcnicas, herramientas y plataformas de desarrollo. La forma de enfrentar
el diseo puede ser tan variada como se imagine, por lo
tanto es necesario documentar y establecer formas y mecanismos cuyo uso garantice que el diseo sea desarrollado desde perspectivas preestablecidas de acuerdo al
tipo de software que se quiera desarrollar.

Es recomendable seguir las siguientes fases


al momento de estandarizar:

En otras palabras, es fundamental seguir determinadas


normas establecidas para cada una de las etapas del desarrollo del software, como tambin al momento de implementar soluciones genricas.

Documentar el procedimiento de implementacin.

La estandarizacin proporciona marcos comunes de trabajo que pueden ser utilizados por los especialistas para
garantizar niveles adecuados de calidad, los cuales pueden ser verificados por otros procesos normados.
La estandarizacin garantiza que los procesos sern conducidos por parmetros de desarrollo definidos con anterioridad y, por lo tanto, la experiencia asociada a estos
procesos se ver fortalecida con cada nuevo proyecto, y
se realizarn los ajustes necesarios para lograr productos
de calidad.

16

SISTEMAS DE INFORMACIN II

Determinar el rea a estandarizar.


Seleccionar los estndares aplicables.
Implementar, capacitar y difundir.
Aplicar y controlar.

La estandarizacin del proceso de diseo ha venido de la


mano de UML y las tecnologas relacionadas.

SISTEMAS DE INFORMACIN II
TI1216

Tema 4. Modelo 4+1


Este apartado del documento presenta la propuesta desarrollada por Kruchten (1995) para llevar adelante las fases de
desarrollo del software usando un modelo que contempla 5 vistas.
Kruchten desarroll esta propuesta para sistemas de informacin, donde resulta complejo reflejar en un nico modelo
o diagrama su arquitectura. Para manejar esta complejidad se representan diferentes aspectos y caractersticas de la
arquitectura en mltiples vistas. Segn Kruchten, autor del Modelo 4+1, una vista es una presentacin de un modelo,
la cual es una descripcin completa de un sistema desde una particular perspectiva. Este modelo define 4 vistas principales:

Vista lgica (Logical View), modelo de objetos, clases, entidad-relacin, etc.


Vista de proceso (Process View), modelo de concurrencia y sincronizacin.
Vista de desarrollo (Development View), organizacin esttica del software
en su entorno de desarrollo (libreras, componentes, .ear, .jar, etc.).
Vista fsica (Physical View), modelo de correspondencia entre el software
y el hardware (aspectos de distribucin en mquinas, por ejemplo).

Figura 1: Vista modelo 4+1. Kruchten (1995).

La vista +1, que se muestra y traza en cada una de las anteriores, est formada por las necesidades funcionales que
cubre el sistema, y que en ocasiones identificamos como vista de casos de uso. A partir de la utilizacin de esta vista
se puede deducir que la utilizacin de este modelo, hace que la arquitectura sea en realidad evolucionada desde escenarios.

UNIDAD 1: PRINCIPIOS DEL DISEO

17

INACAP VIRTUAL

Informacin relevante a considerar


Cada vista se describe con una notacin que permite individualizarla ms adecuadamente (por ejemplo,
existen diagramas UML que se adaptan ms a una vista que otra). Para cada vista los arquitectos pueden
escoger cierto patrn arquitectnico, permitiendo la coexistencia de mltiples estilos en un sistema.

4.1 Vista lgica


Soporta el anlisis y la especificacin de los requisitos funcionales; lo que el sistema debera proporcionar en trminos
de servicios a sus usuarios. El sistema se descompone en un conjunto de abstracciones clave tomadas mayormente del
dominio del problema, en forma de objetos o clases. En esta vista se usan comnmente los diagramas de clases, los de
interaccin y objetos.
Caractersticas especficas

Notacin
La notacin ms usada es UML, y en su interior
diagramas de clases y paquetes.

Estilo
El estilo ms usado para la vista lgica es el orientado a
objetos.

4.2 Vista de procesos


Abordan algunos requisitos no funcionales, como la ejecucin, disponibilidad, tolerancia a fallos, integridad, etc. Esta
vista tambin especifica qu hilo de control ejecuta cada operacin identificada en cada clase de la vista lgica. La vista
se centra por tanto en la concurrencia y distribucin de procesos.
Caractersticas especficas

Notacin

La notacin ms usada es UML, y dentro de esta


diagramas estados, actividad y similares

18

SISTEMAS DE INFORMACIN II

Estilo
Pueden encajar varios estilos. Por ejemplo, es posible
usar tuberas y filtros (pipes and filtres) o cliente
servidor (con variantes de mltiples clientes simple
servidor y mltiples clientes mltiples servidores).

SISTEMAS DE INFORMACIN II
TI1216

4.3 Vista de implementacin


La vista de implementacin o desarrollo se enfoca
en la organizacin de los mdulos de software en el
entorno de desarrollo. El software es empaquetado en
pequeos trozos (libreras de programa, subsistemas,
componentes, etc.). Los subsistemas se organizan en
capas jerrquicas, y cada capa proporciona una interfaz
bien definida a sus capas superiores.
La vista de desarrollo toma, por tanto, requisitos
internos relacionados con facilidad de desarrollo,

gestin del software (reparto de requisitos, trabajo


del equipo), evaluacin de costes, planificacin,
monitorizacin del progreso del proyecto, reutilizacin,
portabilidad, seguridad y restricciones impuestas por las
herramientas o por el lenguaje de programacin.
Esta organizacin del software se suele apoyar en
diagramas de mdulos o de subsistemas que muestran
las relaciones de exportacin (export) e importacin
(import).

Solo se podr describir la vista de desarrollo por completo


despus de haber identificado todos los elementos software.

Caractersticas especficas

Notacin

La notacin ms usada es UML, y dentro de esta se


disponen diagramas de componentes y paquetes.

Estilo
Se recomienda definir de cuatro a seis capas de
subsistemas en la vista de desarrollo. Una regla
de diseo es que un subsistema puede solamente
depender de subsistemas en la misma capa o en
las menores. Esto minimiza las dependencias entre
mdulos a favor de una ms simple, esta estrategia se
llama capa-capa.

4.4 Vista de despliegue (fsica)


La vista de despliegue o fsica se centra en los requisitos
no funcionales, tales como la disponibilidad del sistema,
la fiabilidad (tolerancia a fallos), ejecucin y escalabilidad. Tambin presenta cmo los procesos, objetos, etc.,
corresponden a nodos de proceso:

Se pueden utilizar varias configuraciones fsicas, lo importante es la correspondencia del software a los nodos,
ya que debe ser altamente flexible y tener el mnimo impacto en el cdigo fuente.

Componentes: nodos de proceso.


Conectores: LAN, WAN, bus, etc.
Contenedores: subsistemas fsico.

UNIDAD 1: PRINCIPIOS DEL DISEO

19

INACAP VIRTUAL

4.5 Vista de casos de uso (escenarios)


La vista de escenarios corresponde a instancias de casos de uso que unifican todas las vistas. As, desde casos de uso
se debera poder hacer una trazabilidad a todos los componentes del sistema software, viendo, por ejemplo, qu mquinas, clases, componentes, .jar, o procesos, son los responsables de que el sistema cubra una cierta funcionalidad.

4.6 Relacin entre vistas


La vista de casos de muestra permite mirar los elementos estructurales que se analizan en la vista lgica y que se han
implementado en la vista de desarrollo. Los escenarios en la vista de casos de uso son realizados en la vista de proceso
y desplegados en la vista fsica.

4.7 Diagramas UML en 4+1

Figura 2: Despliegue de UML aplicado a la vista 4+1

20

SISTEMAS DE INFORMACIN II

SISTEMAS DE INFORMACIN II
TI1216

Tema 5. Patrones de diseo


A continuacin se presentan las definiciones de patrones de diseo que surgen a partir del libro desarrollado por
Gamma, Helm, Johnson & Vlissides (1994). Estas definiciones son ampliadas en el material de profundizacin de la
asignatura.

5.1 Concepto de patrn de diseo


Los patrones de diseo o Design Patterns son soluciones simples y elegantes a problemas especficos y comunes del
diseo orientado a objetos, basadas en la experiencia y el xito en su utilizacin.
Al momento de realizar el diseo de sistemas se presentan problemas que se repiten o que son comunes, es decir, que
responden a un cierto patrn. Para ello, se generan patrones con las soluciones ms ptimas para cada caso. Al comprender el funcionamiento de un patrn de diseo se puede obtener un diseo del software ms flexible, modular y
reutilizable. Los patrones de diseo han potenciado el diseo orientado a objetos y todo buen arquitecto de software
debera conocerlos.
Una lista con los patrones de diseo a objetos ms habituales fueron publicados en el libro Design Patterns, escrito
por un grupo de informticos que comnmente se conocen como GoF (Gang of Four; en espaol pandilla de los cuatro).

5.2 Patrones de creacin

Abstract Factory: proporciona una interfaz para crear familias de objetos o que dependen entre s, sin especificar sus clases concretas.

Builder: separa la construccin de un objeto complejo de su representacin, de forma que el mismo proceso de
construccin pueda crear diferentes representaciones.

Factory Method: define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qu
clase instanciar. Permite que una clase delegue en sus subclases la creacin de objetos.

Prototype: especifica los tipos de objetos a crear por medio de una instancia prototpica, y origina nuevos objetos
copiando este prototipo.

Singleton: garantiza que una clase solo tenga una instancia, y proporciona un punto de acceso global a ella.
5.3 Patrones estructurales

Adapter: convierte la interfaz de una clase en una distinta, que es la esperada por los clientes. Permitiendo que
cooperen clases que de otra manera no podran por tener interfaces incompatibles.

UNIDAD 1: PRINCIPIOS DEL DISEO

21

INACAP VIRTUAL

Bridge: desvincula una abstraccin de su implementacin, de manera que ambas puedan variar de forma independiente.

Composite: combina objetos en estructuras de rbol para representar jerarquas de parte-todo. Permite que los
clientes traten de manera uniforme a los objetos individuales y a los compuestos.

Decorator: aade dinmicamente nuevas responsabilidades a un objeto, proporcionando una alternativa flexible
a la herencia para extender la funcionalidad.

Facade: proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de
alto nivel que hace que el subsistema sea ms fcil de usar.

Flyweight: usa el compartimiento para permitir un gran nmero de objetos de grano fino de forma eficiente.
Proxy: proporciona un sustituto o representante de otro objeto para controlar el acceso a este.
5.4 Patrones de comportamiento

Chain of Responsibility: evita acoplar el emisor de una peticin a su receptor, al dar a ms de un objeto la posibilidad de responder a la peticin. Crea una cadena con los objetos receptores y pasa la peticin a travs de la cadena
hasta que esta sea tratada por algn objeto.

Command: encapsula una peticin en un objeto, permitiendo as parametrizar a los clientes con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer las operaciones.

Interpreter: dado un lenguaje, define una representacin de su gramtica junto con un intrprete que usa dicha
representacin para interpretar las sentencias del lenguaje.

Iterator: proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su
representacin interna.

Mediator: define un objeto que encapsula cmo interactan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explcitamente, y permite variar la interaccin entre ellos de
forma independiente.

Memento: representa y externaliza el estado interno de un objeto sin violar la encapsulacin, de forma que ste
puede volver a dicho estado ms tarde.

Observer: define una dependencia entre objetos, de uno-a-muchos, de forma que cuando un objeto cambia de
estado se notifica y actualizan automticamente todos los objetos.

State: permite que un objeto modifique su comportamiento cada vez que cambia su estado interno. Parecer que
cambia la clase del objeto.

Strategy: define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo vare independientemente de los clientes que lo usan.

Template Method: define en una operacin el esqueleto de un algoritmo, delegando en las subclases algunos
de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin cambiar su estructura.

22

SISTEMAS DE INFORMACIN II

SISTEMAS DE INFORMACIN II
TI1216

Visitor: representa una operacin sobre los elementos de una estructura de objetos. Permite definir una nueva operacin sin cambiar las clases de los elementos sobre los que opera.

RESUMEN: IDEAS FUERZA


Al momento de realizar el diseo del software es importante que se tenga en consideracin la forma como se
implementan las soluciones del software en la empresa,
es decir si se va a optar por software a la medida o software genrico, puesto que cada cual suple necesidades
especficas de las empresas.
Para realizar esta diferenciacin se deben contemplar
algunas ventajas de la implementacin de los tipos de
soluciones, con el objeto de poder distinguir entre las
diversas opciones que ofrece el mercado y tener una
base al momento de la toma de decisiones, respecto a si
se lleva adelante una solucin genrica o una solucin
a medida.
Continuando con la lnea lgica, tambin se deben
considerar los conceptos relacionados con el diseo
de soluciones, como los fundamentos y los principios,
adems de los aspectos relacionados con la notacin
presente en el diseo. Una vez establecido lo anterior,
es importante tener en cuenta los conceptos de estandarizacin y sus fases, ya que proporcionan marcos comunes de trabajo que pueden ser utilizados para garantizar niveles adecuados de calidad, los cuales pueden

ser verificados por otros procesos normados.


Los conceptos que se han abordado en el documento
presentan un recorrido por los diversos temas del diseo y dan a conocer herramientas que pueden ser profundizadas. El hecho de identificarlas las transforma en
una oportunidad que el estudiante puede aprovechar al
momento de llevar adelante un desarrollo.
El modelo 4+1 de Kruchten para la arquitectura de software permite modelar soluciones y ordenar el proceso
de diseo, adems de proporcionar un marco terico
que puede ser llevado a la prctica por el estudiante al
seguir las propuestas planteadas.
A continuacin te invitamos a utilizar todo el contenido
de la unidad, tomando en consideracin que los temas
tratados presentan la informacin de una manera que
permite ampliar tu conocimiento utilizando la bibliografa y materiales adicionales que se presentan durante el desarrollo de la asignatura.

BIBLIOGRAFA
Gutirrez, S. (2010). Integracin Social Digital: Social Media Internet. Publicaciones PACJ. 82-84.
Gallegos, J.C. (2008). Formacin Profesional Bsica: Operaciones auxiliares para la configuracin. Espaa: Editorial
Editex.
Fairley, R. E. D., Bourque, P. & Keppler, J. (2014). The impact of SWEBOK Version 3 on software engineering
education and training. In Software Engineering Education and Training (CSEE&T), 2014 IEEE 27th Conference on
(192-200). IEEE.
Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1994). Design patterns: elements of reusable object-oriented
software. Espaa: Pearson Education.
Kruchten, P. B. (1995). The 4+ 1 view model of architecture. Software, IEEE, 12(6), 42-50.

UNIDAD 1: PRINCIPIOS DEL DISEO

23

INACAP VIRTUAL

ENLACES EN LNEA
Patrones GoF
http://is.ls.fi.upm.es/docencia/proyecto/docs/patrones_gof.pdf
Patrones GRASP
http://prezi.com/di0m87zy1lpo/patrones-grasp/
Taller de Patrones de Diseo
http://webdiis.unizar.es/~jmerse/IS-2/TeoriaPatronesV2_2.pdf
Modelo4+1
http://alfredo.chacharaselnido.com/Desarrollo_proyectos/unidad1/4+1%5B1%5D.pdf

VIDEOS
Modelo 4+1
http://www.youtube.com/watch?v=infibXe42ng
Canal de Videos de Patrones de Diseo en Java
http://www.youtube.com/playlist?list=PLC238B0613515968F

24

SISTEMAS DE INFORMACIN II

INACAP VIRTUAL