<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>SAGASOFT &#187; ISI</title>
	<atom:link href="http://www.blog.sagasoft.es/category/isi/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.blog.sagasoft.es</link>
	<description>CoNqUeR tHe WoRlD!!</description>
	<lastBuildDate>Sun, 06 Sep 2009 16:05:55 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>ISI 18-10-2007: Principios de diseño:</title>
		<link>http://www.blog.sagasoft.es/2007/10/isi-18-10-2007-principios-de-diseno/</link>
		<comments>http://www.blog.sagasoft.es/2007/10/isi-18-10-2007-principios-de-diseno/#comments</comments>
		<pubDate>Sat, 20 Oct 2007 18:41:00 +0000</pubDate>
		<dc:creator>SalMax</dc:creator>
				<category><![CDATA[ISI]]></category>

		<guid isPermaLink="false">http://www.blog.sagasoft.es/2007/10/isi-18-10-2007-principios-de-diseno/</guid>
		<description><![CDATA[PRINCIPIOS DE DISEÑO:


Hay que tener en cuenta enfoques alternativos.
Debemos poder rastrear el diseño hasta el modelo del análisis.
No hay que reinventar lo ya inventado (patrones de diseño).
La separación entre dominio del problema y dominio de la solución debe ser minimizada.
El diseño debe ser uniforme e íntegro.
Se tiene que estructurar el diseño para facilitar los cambios.
Debe [...]]]></description>
			<content:encoded><![CDATA[<p><span style="font-weight: bold;">PRINCIPIOS DE DISEÑO:</span>
<div>
<ul>
<li>Hay que tener en cuenta enfoques alternativos.</li>
<li>Debemos poder rastrear el diseño hasta el modelo del análisis.</li>
<li><span style="font-weight: bold;">No hay que reinventar lo ya inventado (patrones de diseño)</span>.</li>
<li>La separación entre dominio del problema y dominio de la solución debe ser minimizada.</li>
<li>El diseño debe ser uniforme e íntegro.</li>
<li>Se tiene que estructurar el diseño para facilitar los cambios.</li>
<li>Debe ser flexible para que pueda admitir los cambios con facilidad.</li>
<li>El diseño no es escribir código y escribir código no es diseñar.</li>
<li>La calidad de un diseño hay que evaluarla durante su realización, no una vez terminado.</li>
<li>Es importante revisar el diseño en busca de errores conceptuales (semánticos)</li>
</ul>
<p> La I.S. tiene estos principios universales en los que basarse. Lo más destacable es que tenemos que plantearnos si el problema está ya resuelto y documentado: &#8220;no inventes lo que ya está inventado&#8221;.<br />Principios específicos de diseño: son cuatro (trans):
<ul>
<li>Modularidad</li>
<li>Abstracción</li>
<li>Independencia funcional</li>
<li>Ocultamiento de información</li>
</ul>
<p>Hay que tratar de conseguirlos.</p>
<p><span style="font-weight: bold;">Modularidad:</span><br />¿Qué es la modularidad? ¿Cómo tienen que ser nuestros diseños? Nuestro diseños debe de componer de piezas y sus relaciones entre ellas.<br />Es necesario dividir el software, de manera lógica, en un conjunto de módulos, donde cada uno realiza una sola actividad y con una interfaz bien definida.<br />Estos módulos tienen una serie de características:
<ul>
<li>Debe de tener un nombre que lo identifique.</li>
<li>Debe tener algo que diga donde empieza y donde acaba</li>
</ul>
<p>Lo mínimo que nos podemos encontrar con forma de módulo es una función. Una pieza un poco más grande sería una clase, ya que incluye un conjunto de funciones. Lo siguiente que nos podemos encontrar son los paquetes, que son un conjunto de clases relacionadas y en las que definimos relaciones de jerarquía. Por encima de estos están los componentes, conjuntos de paquetes que representan nuestros subsistemas.<br />Beneficios de la modularidad:
<ul>
<li>Son mas fáciles de entender y de documentar.</li>
<li>Facilitamos los cambios.</li>
<li>Reducimos la complejidad.</li>
<li>Obtenemos implementación mas sencillas.</li>
<li>Posibilitamos el desarrollo en paralelo.</li>
<li>Posibilitamos la prueba independiente.</li>
</ul>
<p>¿Qué grado de modularidad es necesario?<br />Mientras más módulos tengamos, menos esfuerzo tendremos que emplear para hacer cada módulo. Sin embargo más esfuerzo tendremos que emplear en la comunicación entre tantas piezas. Esta relación la podemos ver en la siguiente gráfica.</p>
<p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_MBtX4xp51RM/Rx4imnWQWHI/AAAAAAAAADU/siJsGZo3q40/s1600-h/2-1_Modularidad.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://3.bp.blogspot.com/_MBtX4xp51RM/Rx4imnWQWHI/AAAAAAAAADU/siJsGZo3q40/s400/2-1_Modularidad.PNG" alt="" id="BLOGGER_PHOTO_ID_5124571472786905202" border="0" /></a><span style="font-weight: bold;">Abstracción:</span><br />Mediante la abstracción vamos destacando los elementos importantes del sistema, para después ir detallándolos en distintos niveles de abstracción, volviendo a identificar los elementos importantes en cada nivel. Es decir, la abstracción es el mecanismo que nos permite determinar qué es relevante y qué no lo es en un nivel de detalle determinado.<br />Mecanismos de abstracción en el diseño:
<ul>
<li><span style="font-weight: bold;">Abstracción procedimental</span>: Estructura modular basada en procedimientos. Se abstrae sobre el funcionamiento. Describimos a grandes rasgos qué hace nuestro módulo, sin decir cómo lo hace.</li>
<li><span style="font-weight: bold;">Abstracción de datos:</span> Abstraemos el estado de nuestro módulo (atributos) y su funcionamiento. Aquí definimos por ejemplo las clases.</li>
<li><span style="font-weight: bold;">Abstracción de control:</span> Abstrae el flujo de control de cualquier proceso en general. Por ejemplo, los iteradores son un mecanismo de abstracción de control sobre estructuras repetitivas. De hecho las mismas estructuras repetitivas son una abstracción de control</li>
<li><span style="font-weight: bold;">Refinamiento por pasos:</span> Desarrollar un programa paso a paso partiendo de sentencias macroscópicas hasta llegar a nivel de sentencia en un lenguaje de programación</li>
</ul>
<p><span style="font-weight: bold;">Independencia funcional:</span><br />Está referido a las piezas y a que sean lo más independientes posibles entre ellas. Que cada módulo se ocupe de una tarea específica o un conjunto de tareas relacionadas entre ellas.<br />¿Por qué independencia funcional?
<ul>
<li>Se pueden compartir las funciones.</li>
<li>Es más fácil de reutilizar.</li>
<li>Son mas fáciles de mantener y probar.</li>
<li>Se reduce la propagación de errores.</li>
<li>Se simplifican las interfaces.</li>
</ul>
<p>La independencia funcional se mide mediante dos parámetros:
<ul>
<li>COHESIÓN.</li>
<li>ACOPLAMIENTO.</li>
</ul>
<p><span style="font-weight: bold;">Ocultamiento de información:</span><br />Que a los datos privados de cada módulo sólo tenga acceso el propio módulo. Entre módulos se comunican mediante envío de mensajes, nunca dejando acceso directo a los datos privados. Es conveniente distinguir entre encapsulación y ocultamiento de de información. Encapsulación es el concepto de coger determinados elementos y agruparlos como una entidad, mientras que el oculta miento consiste en hacer que parte de esos elementos no sean accesibles desde fuera del módulo.<br />Ventajas del ocultamiento de información:
<ul>
<li>Reduce la probabilidad de “efectos colaterales”.</li>
<li>Limita el impacto global de las decisiones de diseño local.</li>
<li>Enfatiza la comunicación a través de interfaces controladas.</li>
<li>Disminuye el uso de datos globales.</li>
<li>Conduce al encapsulamiento (un atributo de diseño de alta calidad).</li>
<li>Produce software de alta calidad</li>
</ul>
</div>
<div class="blogger-post-footer"><img width='1' height='1' src='http://res1.blogblog.com/tracker/5015849064577464973-5401075456935529713.gif?l=diarioetsiit.blogspot.com'/></div>
]]></content:encoded>
			<wfw:commentRss>http://www.blog.sagasoft.es/2007/10/isi-18-10-2007-principios-de-diseno/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>ISI 18-10-2007: Diseño de Interfaces</title>
		<link>http://www.blog.sagasoft.es/2007/10/isi-18-10-2007-diseno-de-interfaces/</link>
		<comments>http://www.blog.sagasoft.es/2007/10/isi-18-10-2007-diseno-de-interfaces/#comments</comments>
		<pubDate>Thu, 18 Oct 2007 18:01:00 +0000</pubDate>
		<dc:creator>SalMax</dc:creator>
				<category><![CDATA[ISI]]></category>

		<guid isPermaLink="false">http://www.blog.sagasoft.es/2007/10/isi-18-10-2007-diseno-de-interfaces/</guid>
		<description><![CDATA[El otro día terminamos el diseño arquitectónico. Hoy veremos el diseño de interfaces:
DISEÑO DE INTERFACES:

El diseño de la interfaz de la base de datos lo dejamos fuera ya que se ve con más detalle en la asignatura de Bases de Datos.
- Interfaz de usuario:Permite la comunicación entre el sistema y el usuario. Para diseñarla tenemos [...]]]></description>
			<content:encoded><![CDATA[<p>El otro día terminamos el diseño arquitectónico. Hoy veremos el diseño de interfaces:</p>
<p><span style="FONT-WEIGHT: bold">DISEÑO DE INTERFACES:</span></p>
<p>
<p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_MBtX4xp51RM/RxjMQHWQWCI/AAAAAAAAACs/GFhncUQl_2U/s1600-h/2-1_Interfaces_Design.PNG"><img id="BLOGGER_PHOTO_ID_5123069153356306466" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="http://3.bp.blogspot.com/_MBtX4xp51RM/RxjMQHWQWCI/AAAAAAAAACs/GFhncUQl_2U/s400/2-1_Interfaces_Design.PNG" border="0" /></a>El diseño de la interfaz de la base de datos lo dejamos fuera ya que se ve con más detalle en la asignatura de Bases de Datos.</p>
<p><span style="FONT-WEIGHT: bold">- Interfaz de usuario</span>:<br />Permite la comunicación entre el sistema y el usuario. Para diseñarla tenemos muchas herramientas que nos ayudan, de las cuales una de las más usadas el diseño de prototipos:<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_MBtX4xp51RM/RxjNiHWQWDI/AAAAAAAAAC0/6EYkwN3wD-k/s1600-h/2-1_Interfaz+de+usuario.PNG"><img id="BLOGGER_PHOTO_ID_5123070562105579570" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="http://3.bp.blogspot.com/_MBtX4xp51RM/RxjNiHWQWDI/AAAAAAAAAC0/6EYkwN3wD-k/s400/2-1_Interfaz+de+usuario.PNG" border="0" /></a><br />Casi todos los elementos de la interfaz se colocan dentro de ese diseño usando determinados símbolos. Automáticamente diseñamos la interfaz en un entorno gráfico sin necesidad de programar código (jbuilder), definiendo las características de la ventana, menús, botones, acciones&#8230; etc. En definitiva tenemos muchas facilidades para el diseño de la interfaz y el esquema de prototipos permite un desarrollo rápido.</p>
<p><span style="FONT-WEIGHT: bold">- El diseño de los datos:</span><br />Tenemos que partir del análisis, de donde obtenemos un esquema u otro en el que esté representada la arquitectura de información que hay en el problema. En el análisis vamos a tener el conjunto de entidades y relaciones, por ejemplo. En el diseño nos preocupamos de ese esquema y de traducirlo, en este caso a un modelo relacional, que es un diseño de tablas donde contemplamos esas relaciones y entidades.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_MBtX4xp51RM/RxpGmHWQWFI/AAAAAAAAADA/3MFGVWcxXds/s1600-h/2-1_Datos_Design.PNG"><img id="BLOGGER_PHOTO_ID_5123485146708727890" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="http://1.bp.blogspot.com/_MBtX4xp51RM/RxpGmHWQWFI/AAAAAAAAADA/3MFGVWcxXds/s400/2-1_Datos_Design.PNG" border="0" /></a> Ya nos queda implementar esas tablas haciendo uso de algunas herramientas de bases de datos relacionales. Obviamente esto funciona cuando usamos un modelo entidad-relación, con otros son diferentes.</p>
<p><span style="FONT-WEIGHT: bold">- El diseño de componentes:</span><br />¿Donde se quedo el diseño arquitectónico? En el diseño de componentes, identificando cada uno de los subsistemas. ¿Ahora qué nos queda? Tenemos que definir esas piezas, y eso es lo que hace el diseño de componentes. Ahí tenemos cosas más elementales, en las que podamos usar herramientas de este tipo:<img id="BLOGGER_PHOTO_ID_5123488204725442658" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: hand; TEXT-ALIGN: center" alt="" src="http://1.bp.blogspot.com/_MBtX4xp51RM/RxpJYHWQWGI/AAAAAAAAADI/Ys6rZfRMU28/s400/2-1_Componentes_Design.PNG" border="0" /></p>
<p>En la imagen podemos ver el uso de dos herramientas (pseudocódigo y diagramas de flujo de control) para describir un módulo concreto (proceso de un registro). Formalmente el diseño de componentes se define como la descripción procedimental de cada uno de los componentes elementales de la arquitectura.</p>
<p>Y con esto acabamos con todas las tereas que hay que hacer en el diseño: Disepo <strong>arquitectónico</strong>, diseño <strong>de datos</strong>, de la <strong>interfaz de usuario</strong> y diseño de cada uno de los <strong>componentes</strong> del diseño arquitectónico.</p>
<div class="blogger-post-footer"><img width='1' height='1' src='http://res1.blogblog.com/tracker/5015849064577464973-7749076207911056294.gif?l=diarioetsiit.blogspot.com'/></div>
]]></content:encoded>
			<wfw:commentRss>http://www.blog.sagasoft.es/2007/10/isi-18-10-2007-diseno-de-interfaces/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>ISI 5-10-2007: Tema1.1</title>
		<link>http://www.blog.sagasoft.es/2007/10/isi-5-10-2007-tema11/</link>
		<comments>http://www.blog.sagasoft.es/2007/10/isi-5-10-2007-tema11/#comments</comments>
		<pubDate>Fri, 05 Oct 2007 16:51:00 +0000</pubDate>
		<dc:creator>SalMax</dc:creator>
				<category><![CDATA[ISI]]></category>

		<guid isPermaLink="false">http://www.blog.sagasoft.es/2007/10/isi-5-10-2007-tema11/</guid>
		<description><![CDATA[Tema 1.1Nada relevante la semana que viene ya habrá un listado de ejercicios. Primeras transparencias

]]></description>
			<content:encoded><![CDATA[<p>Tema 1.1<br />Nada relevante la semana que viene ya habrá un listado de ejercicios. Primeras transparencias
<div class="blogger-post-footer"><img width='1' height='1' src='http://res1.blogblog.com/tracker/5015849064577464973-8238340586100086553.gif?l=diarioetsiit.blogspot.com'/></div>
]]></content:encoded>
			<wfw:commentRss>http://www.blog.sagasoft.es/2007/10/isi-5-10-2007-tema11/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>ISI 2-10-2007: Presentación</title>
		<link>http://www.blog.sagasoft.es/2007/10/isi-2-10-2007-presentacion/</link>
		<comments>http://www.blog.sagasoft.es/2007/10/isi-2-10-2007-presentacion/#comments</comments>
		<pubDate>Tue, 02 Oct 2007 14:44:00 +0000</pubDate>
		<dc:creator>SalMax</dc:creator>
				<category><![CDATA[ISI]]></category>

		<guid isPermaLink="false">http://www.blog.sagasoft.es/2007/10/isi-2-10-2007-presentacion/</guid>
		<description><![CDATA[Presentación de ISI:
Tareas pendientes:

Apuntarse a las prácticas
Repasar NetBeans
Actualizar archivador (presentación)


]]></description>
			<content:encoded><![CDATA[<p>Presentación de ISI:</p>
<p>Tareas pendientes:
<ul>
<li>Apuntarse a las prácticas</li>
<li>Repasar NetBeans</li>
<li>Actualizar archivador (presentación)</li>
</ul>
<div class="blogger-post-footer"><img width='1' height='1' src='http://res1.blogblog.com/tracker/5015849064577464973-7952843396850712367.gif?l=diarioetsiit.blogspot.com'/></div>
]]></content:encoded>
			<wfw:commentRss>http://www.blog.sagasoft.es/2007/10/isi-2-10-2007-presentacion/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

