PASO2-COLABORATIVO1

DISEÑO DE SISTEMAS

DANIELA RAMIREZ ZULUAGA COD 1143845172

JHEYSON SANCHEZ DIAZ COD 1065576753
OSCAR DARIO PEREZ JIMENEZ COD 77181989
GABRIEL FELIPE ROA Cod 1024559306

GRUPO
301309_47

PRESENTADO A
MOISES DE JESUS RODRIGUEZ
DIRECTOR DE CURSO

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

BARRANQUILLA
OCTUBRE
 INTRODUCCION

.
Por medio de este se pretende dar respuesta a las preguntas formuladas dentro
de la actividad teniendo en cuenta las referencias dadas y la investigación
realizada por cada estudiante referente al diseño de software, calidad del diseño
de software, patrones, estilos, características, implementación y demás temas
relacionados con la manera en la que se realiza un diseño de software y como se
implemente.
 OBJETIVOS
 Interiorizar la teoría sobre arquitectura del software, estructuras de datos,
interfaces y componentes que se necesitan para implementar el sistema
 Desarrollar el diseño para un sistema de información o producto informático
de alta calidad
 Identificar las distintas representaciones de un software tomando como
características la resistencia, la funcionalidad y la belleza.
 DESARROLLO DE ACTIVIDADES

1. Cuando se “escribe” un programa, ¿se diseña software? ¿En qué difieren

el diseño de software y la codificación?

Cuando se “escribe” un programa se diseña software dependiendo del nivel de

abstracción ya que el escribir software es un paso más del diseño del software es
un complemento ya que solo se está expresando en código o lenguaje el
programa ya que el lenguaje de programación representa detalles tales como
estructura de datos y algoritmos que se podría decir que es la parte funcional del
producto.
El diseño de software se basa en 3 parámetros básicos, los principios que se
basan en la filosofía que guía el trabajo y desarrollo del diseño, la práctica que
define la creación de distintas representaciones del diseño, y los conceptos que se
debe tener conocimiento de este antes de aplicar la mecánica a este.
La codificación busca la transformación del código fuente en el lenguaje de
programación escogido, requerimientos y el diseño funcional planteado.

2. ¿Cómo se evalúa la calidad del diseño del software?

Un software se debe evaluar de una forma iterativa ya que de este proceso

depende la calidad, resistencia, funcionalidad y belleza.
La calidad del software se evalúa por medio de revisiones técnicas, y estas
revisiones técnicas son celebradas en una reunión conformada por miembros del
equipo de creación del diseño o producto, es organizado y delegado una serie de
roles a cada integrante con el fin de revisar algún tipo de error o errores del
producto revisando toda la información del producto , es entregado a cada
integrante del grupo un pre proyecto o borrador para ser revisado por cada uno de
los integrantes revisando cualquier error en el producto antes de que comience su
implementación, esta revisión técnica tiene un tiempo de 90 minutos y 2 horas al
finalizar el equipo determinara si es necesario otro tipo de acciones , a fin de que
se apruebe el producto como porción del modelo del diseño final.
3. Dé ejemplos de tres abstracciones de datos y de las abstracciones de
procedimiento que se usan para manipularlas.

 Abstracción de procedimiento: Contestar (escuchar sonido, caminar hacia

el teléfono, alzar bocina, hablar)
 Abstracción de datos: Teléfono (diseño, peso, tipo, color, dimensiones)
 Abstracción de procedimiento: Comer (sentir hambre, caminar, buscar
galletas, abrir paquete, tomar galleta, masticar)
 Abstracción de datos: Galletas (marca, consistencia, ingredientes, tamaño,
sabor, textura)
 Abstracción de procedimiento: Lavar (Tomar jabón, enjabonar, restregar
ropa, quitar jabón con agua, escurrir, colgar, secar, recoger)
 Abstracción de datos: Ropa (color, diseño, tamaño, material)

4. Describa con sus propias palabras la arquitectura de software.

La arquitectura del software se puede definir como las técnicas metodológicas que
son usadas para facilitar la programación de un producto, a través de un grupo de
abstracciones o patrones que nos guían con un esquema de referencia y con la
compatibilidad necesaria para lograr estos objetivos.
El software debe contener parámetros que mantengan su calidad y rendimiento
como lo son: mantenibilidad, fácilmente analizable, modificable y corregible.
La arquitectura del software es la estructuración del sistema de esta
restructuración representa un diseño de alto nivel del sistema que tiene dos
propósitos primarios: satisfacer los atributos de calidad y servir como guía en el
desarrollo, la omisión de dicho procedimiento de la arquitectura puede llegar a
limitar severamente el producto ya que en la arquitectura el costo de correcciones
relacionadas con problemas es demasiado elevado.

5. Sugiera un patrón de diseño que encuentre en una categoría de objetos

cotidianos (por ejemplo, electrónica de consumo, automóviles, aparatos,
etc.). Describa el patrón en forma breve.

El patrón Abstract Factory proporciona una interfaz para crear familias de objetos

relacionados o que dependen entre sí, sin especificar sus clases concretas.
Este patrón se encuentra en el equipamiento de cuño de metal utilizado en las
fábricas de automóviles japonesas. El equipamiento de cuño es un Abstract
Factory que crea partes de un automóvil. La misma maquinaria se utiliza para
estampar la puerta derecha e izquierda, defensa delantera y trasera, etc., para
diferentes modelos de autos. Mediante el uso de rodillos para cambiar los fines de
estampado, las "clases concretas" producidas por la maquinaria pueden
cambiarse en 3 minutos [Duell97].
En la Figura 10, que se muestra a continuación, vemos un ejemplo de esta
situación (utilizando una notación basada en UML):

https://msdn.microsoft.com/es-

Figura : Ejemplo del mundo real del patrón "Abstract Factory"

6. ¿Cuándo debe implementarse un diseño modular como software

monolítico? ¿Cómo se logra esto? ¿El rendimiento es la única justificación
para la implementación de software monolítico?
Cuando estas cualidades de la descomposición modular presentan deficiencias.
1. Independencia funcional
2. Acoplamiento
3. Cohesión
4. Compresibilidad
5. Adaptabilidad
Surge la necesidad del software monolítico diseñado para ser autónomo; los
componentes del programa están interconectados e independientemente en lugar
de estar débilmente acoplados.
Sim embargo, también hay beneficios para las arquitecturas monolíticas. Los
programas monolíticos suelen tener un mejor rendimiento que los enfoques
modulares y pueden ser más fácil de probar y depurar porque, con menos
elementos, hay menos variables que entran en juego.

7. ¿Cómo se relacionan los conceptos de acoplamiento y portabilidad del

software? Dé ejemplos que apoyen su punto de vista.

Portabilidad es la flexibilidad con la que el software puede ser transferido a

diferentes ambientes de hardware o software y Acoplamiento una acción, un
conocimiento, una comunicación, una decisión, a ser tomada por un sistema, el
grado de acoplamiento entre dos responsabilidades se mide como la probabilidad
en la que el cambio de una responsabilidad implica un cambio en la otra y la
relación está en la afectación que puede generar dificultad de implantar, probar y
dar mantenimiento al software, un objetivo mantener acoplamiento en niveles
bajos
Ej. Puppy Linux Este sistema operativo entra perfectamente bien en dispositivos
USB sin quitar ninguna de sus funcionalidades. Pesa menos de 100 megas, por lo
que puede cargarse en CDs y dispositivos USB sin inconvenientes. La interfaz de
usuario es amigable hasta para usuarios no familiarizados con Linux, y las
herramientas básicas que se requieren para operaciones de software portátil están
disponibles de antemano. También es muy útil para navegar por internet y efectuar
operaciones de ordenador básicas, sistema monolítico con bajo acoplamiento.

8. Describa en breves palabras cada uno de los cuatro elementos del modelo
del diseño.
 El elemento del diseño arquitectónico emplea información obtenida del dominio
de la aplicación, del modelo de requerimientos y de los catálogos disponibles
de patrones y estilos para obtener una representación estructural completa del
software, de sus subsistemas y componentes.
 Los elementos del diseño de la interfaz modelan las interfaces internas y
externas y la de usuario.
 Los elementos en el nivel de componentes definen cada uno de los módulos
(componentes) que constituyen la arquitectura.
 Por último, los elementos del diseño albergan la arquitectura, sus componentes
y las interfaces dirigidas hacia la configuración física en la que se alojará el
software.

9. Con el uso de la arquitectura de una casa o edificio como metáfora,

establezca comparaciones con la arquitectura del software. ¿En qué se
parecen las disciplinas de la arquitectura clásica y la del software? ¿En qué
difieren?
Existen proyectos de arquitectura clásica donde un arquitecto tiene carta blanca
para hacer lo que se le pide. Sin ningún tipo de preocupación o restricción, Si
bien, es mejor trabajar en un proyecto donde no hay limitantes a la creatividad,
son contados los casos. Por lo general un arquitecto trabaja con construcciones
existentes, muchas veces mal hechas o mal planeadas, con valor histórico, en
deterioro, etc. Esto implica tomar decisiones para encausar proyectos de
mantenimiento o rediseño que den continuidad al proyecto.
Con la arquitectura de software pasa algo Parecido. Se trabaja con infraestructura
lógica y física existente. Por lo general de no muy buena calidad. Es trabajo del
arquitecto encausar el funcionamiento de los sistemas hacia el cumplimiento de
estos 4 puntos:
Liberaciones de software, confiables, rápidas y estables.
Bajos costes de mantenimiento y soporte.
Bajos costes de desarrollo sobre las aplicaciones.
Cumplimiento de los casos de uso o historias de usuario. O sea, cubrir las
necesidades de los usuarios.
Pienso que en ese aspecto no difieren puesto que la idea es basarse en un diseño
para asegurar la mejor forma de arquitectura posible ya sea que se base en la
arquitectura existente o inicie de 0, finalmente el objetivo es darle satisfacción al
cliente llevando a cabo las mejores decisiones en cuanto a sostenibilidad,
rendimiento del producto.

10. De ejemplos de:

 Arquitecturas centradas en los datos:

En el centro de esta arquitectura se halla un almacenamiento de datos al
que acceden con frecuencia otros componentes que actualizan, agregan,
eliminan o modifican los datos de cierto modo dentro del almacenamiento.
Promueven la integrabilidad.
 Figura2: http://3.bp.blogspot.com/-
GbGHqZphflI/Ul2lSLSSwFI/AAAAAAAABZc/NenvU9u46fw/s1600/repositori
o.png

 Arquitecturas de flujo de datos:

Se aplica cuando datos de entrada van a transformarse en datos de salida
a través de una serie de componentes computacionales o manipuladores.
Se basan en un patrón de tubo/filtro que tiene un conjunto de componentes,
llamados filtros, conectados por tubos que transmiten datos de un
componente al siguiente.

Figura3

 Arquitecturas orientadas a objetos

Los componentes de un sistema incluyen datos y las operaciones que
deben aplicarse para manipularlos. La comunicación y coordinación entre
los componentes se consigue mediante la transmisión de mensajes.

Figura4:https://userscontent2.emaze.com/images/b3e894ba-05c7-4a68-
a29b-dd386d252f3d/71b1b97c-649c-4040-a882-6c5853723a05.png
  Arquitecturas en capas.
Se define un número de capas diferentes
• En la capa externa: los componentes atienden las operaciones de la
interfaz de usuario.
• En la interna: los componentes realizan la interfaz con el sistema
operativo.
• Las capas intermedias: proveen servicios de utilerías y funciones de
software de aplicación.

Figura5:
http://arevalomaria.files.wordpress.com/2010/12/ejemplo_mvc1.png

11. Algunos de los estilos arquitectónicos citados en la pregunta 10, tienen

naturaleza jerárquica, mientras que otros no. Elabore una lista de cada tipo.
En los inicios de la arquitectura de software se alentaba la idea de que todas las
estructuras posibles en diseño de software serían susceptibles de reducirse a una
media docena de estilos básicos, lo que en realidad sucedió fue que en los
comienzos del siglo XXI se alcanza una fase barroca y las enumeraciones de
estilos se tornan más y más detalladas y exhaustivas. Considerando solamente los
estilos que contemplan alguna forma de distribución o topología de red, Roy
Fielding [Fie00] establece la siguiente taxonomía:
1. Estilos de flujo de datos
1.1. Tubería-filtros
1.2. Tubería-filtros uniforme
2. Estilos de replicación
2.1. Repositorio replicado
2.2. Cache
3. Estilos jerárquicos
3.1. Cliente-servidor
3.2. Sistemas en capas y Cliente-servidor en capas
3.3. Cliente-Servidor sin estado
3.4. Cliente-servidor con cache en cliente
3.5. Cliente-servidor con cache en cliente y servidor sin estado
3.6. Sesión remota
3.7. Acceso a datos remoto
4. Estilos de código móvil
4.1. Máquina virtual
4.2. Evaluación remota
4.3. Código a demanda
4.4. Código a demanda en capas
4.5. Agente móvil
5. Estilos peer-to-peer
5.1. Integración basada en eventos
5.2. C2
5.3. Objetos distribuidos
5.4. Objetos distribuidos brokered
6. Transferencia de estado representacional (REST)

¿Cómo se implementarían los estilos arquitectónicos que no son

jerárquicos?

Estilo Flujo de datos

Esta familia de estilos enfatiza la reutilización y la modificabilidad. Es apropiada
para sistemas que implementan transformaciones de datos en pasos sucesivos.
Ejemplares de esta serían las arquitecturas de tubería-filtros y las de proceso
secuencial en lote.
Una tubería (pipeline) es una popular arquitectura que conecta componentes
computacionales (filtros) a través de conectores (pipes), de modo que las
computaciones se ejecutan a la manera de un flujo. Los datos se transportan a
través de las tuberías entre los filtros, transformando gradualmente las entradas
en salidas. […] Debido a su simplicidad y su facilidad para captar una
funcionalidad, es una arquitectura mascota cada vez que se trata de demostrar
ideas sobre la formalización del espacio de diseño arquitectónico. El sistema
tubería-filtros se percibe como una serie de transformaciones sobre sucesivas
piezas de los datos de entrada. Los datos entran al sistema y fluyen a través de
los componentes.

Estilos de Código Móvil

Esta familia de estilos enfatiza la portabilidad. Ejemplos de la misma son los
intérpretes, los sistemas basados en reglas y los procesadores de lenguaje de
comando.

Máquinas Virtuales

Se puede decir que un intérprete incluye un seudo-programa a interpretar y una

máquina de interpretación. El seudo-programa a su vez incluye el programa
mismo y el análogo que hace el intérprete de su estado de ejecución (o registro de
activación). La máquina de interpretación incluye tanto la definición del intérprete
como el estado actual de su ejecución. De este modo, un intérprete posee por lo
general cuatro componentes:
(1) una máquina de interpretación que lleva a cabo la tarea,
(2) una memoria que contiene el seudo-código a interpretar,
(3) una representación del estado de control de la máquina de interpretación,
(4) una representación del estado actual del programa que se simula.
El estilo comprende básicamente dos formas, ambas abarcan, un extenso
espectro que va desde los llamados lenguajes de alto nivel hasta los paradigmas
no secuenciales de programación, que implementan un proxy que encubren al
usuario operaciones que en última instancia se resuelven en instrucciones de
máquinas afines al paradigma secuencial imperativo de siempre.

Estilos Peer-to-Peer

También llamada de componentes independientes, enfatiza la modificabilidad por

medio de la separación de las diversas partes que intervienen en la computación.
Consiste por lo general en procesos independientes o entidades que se
comunican a través de mensajes. Cada entidad puede enviar mensajes a otras
entidades, pero no controlarlas directamente. Los mensajes pueden ser enviados
a componentes nominados o propalados mediante broadcast.
Las arquitecturas basadas en eventos se vinculan con sistemas basados en
actores, daemons y redes de conmutación de paquetes. Los conectores de estos
sistemas incluyen procedimientos de llamada tradicionales y vínculos entre
anuncios de eventos e invocación de procedimientos. La idea dominante en la
invocación implícita es que, en lugar de invocar un procedimiento en forma directa
un componente de un sistema puede anunciar su interés en un evento
determinado asociando un procedimiento con la manifestación de dicho evento.
Cuando el evento se anuncia, el sistema invoca todos los procedimientos que se
han registrado para él. De este modo, el anuncio de un evento implícitamente
ocasiona la invocación de determinados procedimientos en otros módulos. Los
procedimientos se pueden invocar a la manera usual en modelos orientados a
objeto, o mediante el sistema de suscripción que se ha descrito.

12. Los términos estilo arquitectónico, patrón arquitectónico surgen con

frecuencia en los análisis de la arquitectura del software. Investigue y
describa en qué difiere cada uno de ellos de los demás.
Figura6: https://encrypted-tbn0.gstatic.com/images?
q=tbn:ANd9GcSpyyWSjk4VOUUJuTOBxWxPBIwQ0p8tQLhpTpjfqKuA7P6ZcGkf.

13. Seleccione una aplicación con la que esté familiarizado. Responda:

Control. ¿Cómo se administra el control dentro de la arquitectura? ¿Existe una
jerarquía de control distinta?

Datos. ¿Cómo se comunican los datos entre los componentes? ¿El flujo de datos
es continuo o los objetos de datos pasan al sistema en forma esporádica?

14. En ocasiones resulta difícil definir el término componente. Primero dé una

definición general y luego otras más explícitas para el software orientado a objetos
y para el tradicional. Por último, elija tres lenguajes de programación con los que
esté familiarizado e ilustre la manera en la que cada uno define un componente.

15. ¿Por qué son necesarios los componentes de control en el software tradicional
y por qué en general no se requieren en el orientado a objetos?

16. Investigue sobre los tipos de cohesión y los tipos de acoplamiento

Tipos de acoplamiento:

El acoplamiento es la forma y nivel de interdependencia entre módulos de

software; una medida de qué tan cercanamente conectados están dos rutinas o
módulos de software.
Algunos tipos de acoplamiento, de mayor a menor, son los siguientes:

Programación estructurada
Un módulo hace referencia a una subrutina de cualquier tipo. Por ejemplo, un
conjunto de una o más secciones de código que tiene un nombre y
preferiblemente su propio conjunto de nombres de variable.
Acoplamiento de contenido (alto)
El acoplamiento de contenido ocurre cuando un módulo modifica o se apoya en el
funcionamiento interno de otro módulo.
Acoplamiento común
El acoplamiento común ocurre cuando dos módulos comparten los mismos datos
globales; Cambiar el recurso compartido implica cambiar todos los módulos que lo
usen.
Acoplamiento externo
El acoplamiento externo ocurre cuando dos módulos comparten un formato de
datos impuesto externamente, protocolo de comunicación, o interfaz de
dispositivo. Esto está básicamente relacionado con la comunicación a
herramientas externas y dispositivos.
Acoplamiento de control
El acoplamiento de control es un módulo controlando el flujo de otro, mediante el
paso de información sobre lo que debe hacer
Acoplamiento sellado
El acoplamiento sellado ocurre cuando los módulos comparten una estructura de
datos compuesta y usan solo una parte de ella, posiblemente una parte diferente.
Esto podría llevar a cambiar la forma en la que un módulo lee un registro debido a
que un campo que el módulo no necesita ha sido modificado.
Acoplamiento de datos
El acoplamiento de datos ocurre cuando los módulos comparten datos entre ellos,
por ejemplo, parámetros. Cada dato es una pieza elemental y dicho parámetro es
la única data compartida.
Acoplamiento de mensajes
Este es el más bajo tipo de acoplamiento. Se puede lograr por la descentralización
de estados y la comunicación de componentes se realiza mediante parámetros o
paso de mensajes.
Sin acoplamiento
Módulos que no se comunican para nada uno con otro.

Programación orientada a objetos

En programación orientada a objetos tenemos:
Acoplamiento de subclases
Describe la relación entre una clase hija y su clase padre. La hija se conecta a su
padre, pero el padre no se conecta al hijo.
Acoplamiento temporal
Cuando dos acciones se agrupan en un módulo sólo porque suceden al mismo
tiempo.
En un trabajo reciente varios otros conceptos de acoplamiento se han investigado
y utilizado como indicadores para diferentes principios de modularización
utilizados en la práctica.
Tipos de Cohesión
La cohesion se refiere al grado en que los elementos de un módulo permanecen
juntos. Por lo tanto, la cohesión mide la fuerza de la relación entre las piezas de
funcionalidad dentro de un módulo dado. Por ejemplo, en sistemas altamente
cohesivo de funcionalidad están muy relacionados.
Tipos de Cohesión
La cohesión en un sistema de información puede ser de los siguientes tipos:
 Cohesión casual
 Cohesión lógica
 Cohesión temporal
 Cohesión procedural
 Cohesión de comunicaciones
 Cohesión secuencial
 Cohesión funcional
En la programación orientada a objetos, si los métodos que sirven a una clase
tienden a ser similares en muchos aspectos, entonces se dice que la clase tiene
una alta cohesión. En un sistema altamente cohesivo, la legibilidad y reusabilidad
del código es mayor, mientras que la complejidad se mantiene manejable.
La cohesión es mayor si:

 Las funcionalidades embebidas en una clase, accedidas a través de sus

métodos, tienen mucho en común.
 Los métodos realizan un pequeño número de actividades relacionadas,
para evitar los trozos grandes de grano o no relacionados con los conjuntos de
datos.

17. ¿Qué es un componente de webapp?

Las aplicaciones web (web app) se ejecutan en un navegador web, lo que hacen
que sean compatibles con la gran mayoría de los dispositivos existentes, y sólo
necesitan ser programadas una vez. Se las consideran aplicaciones híbridas.
Al mostrarse en un navegador web, el código que se utiliza es el mismo que el de
las páginas web (HTML, JavaScript y CSS).

Pero no nos equivoquemos, una aplicación web no es una página web, mientras la
primera ofrece una serie de servicios y es totalmente interactiva, las páginas webs
son, en general, un modo informativo y estático de mostrar una información
concreta.
No necesitan estar instaladas en el terminal, a excepción de algunas funciones
básicas en algunos casos, ya que se ejecutan desde un servidor. Esta cualidad
hace que necesitemos una conexión a internet para poder utilizarlas, aunque
puede haber alguna función que no lo requiera. Desde el punto de vista del
almacenamiento, nos ahorran mucho espacio en el terminal.

Una Web App o Aplicación Web no es otra cosa que la manera moderna de llamar
a una página web de toda la vida. Por supuesto, esa Aplicación Web debe realizar
algún tipo de tarea, normalmente complementada por un servidor que realiza
tareas en backend, si no, estaríamos hablando de una simple página web estática
como puede ser una página informativa y no de una aplicación propiamente dicha.

18. Todos los lenguajes modernos de programación implementan las

construcciones de programación estructurada. Dé ejemplos de tres
lenguajes de programación.

 C++
o C++ es un lenguaje de programación diseñado en 1979 por Bjarne
Stroustrup. La intención de su creación fue el extender al lenguaje de
programación C mecanismos que permiten la manipulación de
objetos. En ese sentido, desde el punto de vista de los lenguajes
orientados a objetos, el C++ es un lenguaje híbrido.

 Java
o Java es un lenguaje de programación de propósito general,
concurrente, orientado a objetos, que fue diseñado específicamente
para tener tan pocas dependencias de implementación como fuera
posible. Su intención es permitir que los desarrolladores de
aplicaciones escriban el programa una vez y lo ejecuten en cualquier
dispositivo (conocido en inglés como WORA, o "write once, run
anywhere"), lo que quiere decir que el código que es ejecutado en
una plataforma no tiene que ser recompilado para correr en otra.
Java es, a partir de 2012, uno de los lenguajes de programación más
populares en uso, particularmente para aplicaciones de cliente-
servidor de web, con unos diez millones de usuarios reportados.

 Python
o Python es un lenguaje de programación interpretado cuya filosofía
hace hincapié en una sintaxis que favorezca un código legible.
Se trata de un lenguaje de programación multiparadigma, ya que
soporta orientación a objetos, programación imperativa y, en menor
medida, programación funcional. Es un lenguaje interpretado, usa
tipado dinámico y es multiplataforma.

19. Seleccione un componente codificado pequeño y represéntelo con 1) un

diagrama de actividades, 2) un diagrama de flujo, 3) una tabla de decisión y
4) LDP.
Los ejemplos que se usan en este tema están relacionados con un sitio web en el
que los clientes pueden hacer pedidos de comida de restaurantes locales.

1) un diagrama de actividades

2) un diagrama de flujo
Forma Elemento Descripción y propiedades principales

1 Acción Paso de la actividad en el que los usuarios o el

software realizan alguna tarea.

La acción se puede iniciar cuando un token llega a

todos sus flujos entrantes. Cuando termina, los
tokens se envían en todos los flujos salientes.

- Body: especifica la acción en detalle.

- Language: idioma de la expresión en el cuerpo.
- Local Postconditions: restricciones que deben
cumplirse cuando termina la ejecución. Objetivo
alcanzado por la acción.
- Local Preconditions: restricciones que deben
cumplirse antes de que empiece la ejecución.

2 Flujo de Conector que muestra el flujo de control entre las

control acciones. Para interpretar el diagrama, imagine que
un token fluye de una acción a la siguiente.

Para crear un flujo de control, use la

herramienta Conector.

3 Initial Node Indica la primera acción o las primeras acciones de

la actividad. Cuando se inicia la actividad, un token
fluye desde el nodo inicial.

4 Activity Final Fin de la actividad. Cuando llega un token, la

Node actividad finaliza.

5 Decision Bifurcación condicional de un flujo. Tiene una

entrada y dos o más salidas. Un token entrante solo
 Node emerge en una de las salidas.

6 Restricción Condición que especifica si un token puede fluir por

un conector. Se usa con más frecuencia en los
flujos salientes de un nodo de decisión.

Para establecer una restricción, haga clic con el

botón derecho en un flujo, haga clic
en Propiedades y, después, establezca la
propiedad Restricción.

7 Merge Node Necesario para combinar los flujos que se dividieron

mediante un nodo de decisión. Tiene dos o más
entradas y una salida. Un token en cualquier
entrada emerge en la salida.

8 Comentario Proporciona información adicional sobre los

elementos a los que está vinculado.

9 Call Behavior Acción que se define con más detalle en otro

Action diagrama de actividades.

- IsSynchronous: si es true, la acción espera hasta

que la actividad finaliza.
- Behavior: actividad invocada.

(sin Call Acción que llama a una operación en una instancia

mostrar) Operation de una clase.
Action
 Actividad Flujo de trabajo que se representa mediante un
diagrama de actividades. Para ver las propiedades
de una actividad, debe seleccionarla en
el Explorador de modelos UML.

- Is Read Only: si es true, la actividad no debe

cambiar el estado de los objetos.
- Is Single Execution: si es true, a lo sumo hay una
ejecución de este diagrama a la vez.

Diagrama de Diagrama que muestra una actividad. Para ver sus

actividades propiedades, haga clic en una parte vacía del
UML diagrama. Note: Los nombres del diagrama de
actividades, el archivo que contiene el diagrama y la
actividad que se muestra en el diagrama pueden
ser diferentes.

3) una tabla de decisión

S= Si
N=No

Condiciones 1 2 3 4
Proporcionar Menú S S N N
Pedir Menú N S S N
Acciones
Entregar Menú X
Salir sin ordenar X

Se identifican los casos Imposibles con el fin de eliminarlos de la tabla.

Condiciones 1 2
Proporcionar Menú S S
Pedir Menú N S
Acciones
Entregar Menú X
Salir sin ordenar X

4) LDP
 Generado en C++

1
2
3
4
5
6 #include<iostream>
7 #include<string>
8 using namespace std;
9 int main()
10 {
11     int a=0,b=0,total=0;
12     cout<<"ingrese número de menus pedidos: ";cin>>a;
13 cout<<"ingrese Valor menus: ";cin>>b;
14
15     if (a>0)
16
17     tota=a*b;
18
19     cout<<"El total a pagar es: "<<tota<<endl;
20     }cin.ignore(); return 0;
21 }
22
23
24
25
26

20. ¿Por qué es importante la “lotificación” en el proceso de revisión del

diseño en el nivel de componentes?
La lotificación es importante porque permite una mayor facilidad a la hora de
comprender el diseño en el nivel de componentes.
Las construcciones estructuradas fueron propuestas para limitar el diseño del
software orientado al procedimiento a un número pequeño de estructuras lógicas
predecibles. La medición de la complejidad indica que el uso de las construcciones
estructuradas reduce la complejidad del programa y con ello mejora la legibilidad y
la facilidad de realizar pruebas y de dar mantenimiento. El uso de un número
limitado de construcciones lógicas también contribuye a un proceso de
comprensión humana que los sicólogos denominan lotificación. Para entender este
proceso, considere el lector la forma en la que está leyendo esta página. No
necesita leer las letras en lo individual, sino reconocer patrones o grupos de letras
que forman palabras o frases. Las construcciones estructuradas son grupos
lógicos que permiten al lector reconocer elementos de procedimiento de un
módulo, en vez de leer el diseño o el código línea por línea. La comprensión
mejora cuando se encuentran patrones lógicos que es fácil reconocer.
CONCLUSIONES
 REFERENCIAS

 Gilb, T., & Brodie, L. (2005). Competitive Engineering : A Handbook For

Systems Engineering, Requirements Engineering, and Software
Engineering Using Planguage. Oxford: Butterworth-Heinemann.
 Saltzer, J. H., & Kaashoek, F. (2009). Principles of Computer System
Design : An Introduction. Burlington, MA: Morgan Kaufmann. Recuperado
de:
 Sols Rodriguez – Candela, A. (2014). Systems engineering: theory and
practice. Pontifical Comillas University Recuperado de:
 [Fie00] Roy Thomas Fielding. “Architectural styles and the design of
network-based software architectures”. Tesis doctoral, University of
California, Irvine, 2000. http://cic.puj.edu.co/wiki/lib/exe/fetch.php?
media=materias:estiloypatron.pdf