ACTIVIDAD 12 (autoevaluacion)

1. ¿Qué es lo fundamental durante el diseño?

Durante el diseño, se toman decisiones acerca de la forma en que se resolverá el problema, primero desde un nivel un nivel elevado y después empleando niveles cada vez más detallados.


2. Escriba ocho decisiones que un diseñador debe tomar

• Organizar el sistema en subsistemas.


• Identificar la concurrencia inherente al problema.

• Asignar los subsistemas a los procesadores y tareas.

• Seleccionar una aproximación para la administración de almacenes de datos.

• Manejar el acceso a recursos globales.

• Seleccionar la implementación de control en software.

• Manejar las condiciones de contorno.

• Establecer la compensación de prioridades.


3. ¿Cómo pasar del análisis al diseño?.

Una vez que se ha analizado el problema, es preciso decidir la forma de aproximarse al diseño. El diseño del sistema es la estrategia de alto nivel para resolver el problema y construir una solución. Este incluye decisiones acerca de la organización del sistema en subsistemas, la asignación de subsistemas a componentes hardware y software, y decisiones fundamentales conceptuales y de política que son las que constituyen un marco de trabajo para el diseño detallado.

4. ¿Qué es la Arquitectura del sistema?

La arquitectura del sistema es la organización global del mismo en componentes llamados subsistemas. La arquitectura proporciona el contexto en el cual se toman decisiones más detalladas en una fase posterior del diseño.

ACTIVIDAD 12 (sugeridas)

o Explique que es la arquitectura del sistema

La arquitectura del sistema es la organización global del mismo en componentes llamados subsistemas.

o Explique que es la arquitectura global?

La arquitectura global de un sistema se puede se puede seleccionar basándose en su similitud con otros sistemas anteriores.

o ¿Cuál es la diferencia entre arquitectura del sistema y arquitectura global?


La arquitectura proporciona el contexto en el cual se toman decisiones más detalladas en una fase posterior del diseño.

ACTIVIDAD 12 (obligatorias)

o Explique brevemente con sus palabras ¿como pasar del analisis al diseño?.

El analisis debe indicarnos como realizar y aplicar el diseño

o Cuales son las decisiones que el diseñador deber tomar?

decisiones acerca de la organización del sistema en subsistemas, la asignación de subsistemas a componentes hardware y software, y decisiones fundamentales conceptuales y de política que son las que constituyen un marco de trabajo para el diseño detallado.

o Describa cada uno de ellas.

El diseño de sistemas es la primera fase de diseño en la cual se selecciona la aproximación básica para resolver el problema. Durante el diseño del sistema, se decide la estructura y el estilo global. La arquitectura del sistema es la organización global del mismo en componentes llamados subsistemas. La arquitectura proporciona el contexto en el cual se toman decisiones más detalladas en una fase posterior del diseño. Al tomar decisiones de alto nivel que se apliquen a todo el sistema, el diseñador desglosa el problema en subsistemas, de tal manera que sea posible realizar más trabajo por parte de varios diseñadores que trabajaran independientemente en distintos subsistemas.

ACTIVIDAD 11 (autoevaluacion)

1. ¿Qué es el diseño?


El diseño es el proceso de determinar cual de muchas posibles soluciones es la mejor para lograr lo que se necesita hacer, respetando las restricciones tecnológicas y de presupuesto del proyecto.
2. ¿En que consiste el diseño?

El diseño consiste en decidir la manera en que debe construirse el sistema para satisfacer los requerimientos de los usuarios.

3. ¿Cuáles son las tres características de las 5 buenas metodologías del diseño?

1. El buen diseño debe motivar la toma de decisiones ayudando a evaluar alternativas. Todo el diseño es acerca de compromisos. Una técnica de diseño debe permitir que el diseñador evalúe su decisión contra otras posibilidades. Por ejemplo, usando el modelo de análisis de eventos acoplado con el esquema de diseño de datos, el diseñador puede simular el volumen de lecturas y escrituras a la base de datos para cualquier evento de negocios dado. Esto permite que el equipo evalúe la factibilidad y desempeño proyectado de una disposición de tabla de base de datos dada y de un esquema de distribución de datos antes de construirlos.


2. El diseño necesita ser completo, de tal forma que cubra cada uno de los aspectos principales del software que necesita construirse. Esto causara que se tengan varios tipos diferentes de modelos en la documentación del diseño. Cada modelo está especializado para mostrar un aspecto particular del sistema. Encontrará que los modeladores son particularmente adeptos de la articulación de esos aspectos para los que está orientada la técnica de modelado, pero fallan miserablemente cuando se trata de estirar el modelo más allá de su propósito original. Ningún modelo puede mostrar todas las facetas del sistema funcional completo. Ese sería el sistema mismo.

3. El diseño debe ser verificable antes de su construcción. Uno de los propósitos principales del diseño es revisar y discutir la solución antes de lanzarse a la carga y codificarla. Parte del proceso de verificación es su rastreabilidad. Con una buena especificación del diseño se debe ser capaz de demostrar que se satisfarán los requerimientos del proyecto y así mismo se distinguirá entre varias versiones del diseño en cualquier momento.

4. Una buena metodología de diseño crea productos diferenciados que son mensurables. Una de las tareas más difíciles de cualquier proyecto es estimar cuando se terminará. Para hacer una estimación el gerente del proyecto debe tomar medidas, la cual involucra el conteo de cosas que necesitan hacerse y la aplicación de algún tipo de medida sobre ellas para estimar que tanto tiempo se llevara el hacerlas. La medición viene, por supuesto, de haber contado estas cosas en el pasado y haber medido que tanto tardo el hacerlas anteriormente. Por lo tanto, una metodología de diseño debe producir componentes discretos lo más pronto posible.

5. Por último, pero no menos importante, el diseño debe ser fácilmente aprovechado en el producto final. Debe expresar el uso y la estructura del sistema en una forma muy cercana al resultado pretendido. Este punto puede parecer obvio, pero se ha visto proyectos que trataron de usar técnicas de diseño que fueron completamente inadecuadas para el lenguaje de destino en el que se codifico el sistema. Usted no querría que su arquitecto casero le presentara un plano que fuera tan esotérico que no le diera idea de la forma que tendría la casa en su terreno. El lema de un diseñador es: hacer un mapa de la técnica hacia el destino. Si el sistema va a operar con una base datos relacional se deben escoger tecnicas que sean particularmente adecuadas para el diseño de bases de datos relacionales. Si el sistema empleara un lenguaje orientado a objetos, entonces se deberán usar técnicas de diseño orientado a objetos para las partes del sistema que requieren objetos para lograr sus tareas. Si el sistema incluirá componentes más tradicionales, tales como funciones estructuradas en las rutinas cliente o por lotes en el servidor, entonces son adecuadas técnicas de diseño estructurado más tradicionales para esas partes del sistema.


4. ¿Por qué el diseño debe ser verificable antes de su construcción?

para saber si el sistema cumple con los requerimientos y especificaciones requeridas

5. ¿Por qué el diseño debe ser aprovechado en el producto final?

1. Debe expresar el uso y la estructura del sistema en una forma muy cercana al resultado pretendido. Este punto puede parecer obvio, pero se ha visto proyectos que trataron de usar técnicas de diseño que fueron completamente inadecuadas para el lenguaje de destino en el que se codifico el sistema. Usted no querría que su arquitecto casero le presentara un plano que fuera tan esotérico que no le diera idea de la forma que tendría la casa en su terreno. El lema de un diseñador es: hacer un mapa de la técnica hacia el destino. Si el sistema va a operar con una base datos relacional se deben escoger tecnicas que sean particularmente adecuadas para el diseño de bases de datos relacionales. Si el sistema empleara un lenguaje orientado a objetos, entonces se deberán usar técnicas de diseño orientado a objetos para las partes del sistema que requieren objetos para lograr sus tareas. Si el sistema incluirá componentes más tradicionales, tales como funciones estructuradas en las rutinas cliente o por lotes en el servidor, entonces son adecuadas técnicas de diseño estructurado más tradicionales para esas partes del sistema.

ACTIVIDAD 11 (sugeridas)

o ¿Se diseña software cuando se escribe un programa?

El diseño consiste en decidir la manera en que debe construirse el sistema para satisfacer los requerimientos de los usuarios.


o El diseño necesita ser complejo ¿porque?

Esto causara que se tengan varios tipos diferentes de modelos en la documentación del diseño. Cada modelo está especializado para mostrar un aspecto particular del sistema. Encontrará que los modeladores son particularmente adeptos de la articulación de esos aspectos para los que está orientada la técnica de modelado, pero fallan miserablemente cuando se trata de estirar el modelo más allá de su propósito original. Ningún modelo puede mostrar todas las facetas del sistema funcional completo. Ese sería el sistema mismo.

ACTIVIDAD 11 (obligatorias)

o Describa con sus propias palabras que es el diseño.

Es la forma en la que se va a desarrollar el proyecto


o Diga con sus propias palabras cual es el objetivo del diseño.

Tener un buen metodo para desarrollar el sistema

o Describa brevemente las caracteristicas de las buenas metodologías

El buen diseño debe motivar la toma de decisiones ayudando a evaluar alternativas.
Todo el diseño es acerca de compromisos. Una técnica de diseño debe permitir que el diseñador evalúe su decisión contra otras posibilidades.

El diseño necesita ser completo
de tal forma que cubra cada uno de los aspectos principales del software que necesita construirse. Esto causara que se tengan varios tipos diferentes de modelos en la documentación del diseño

El diseño debe ser verificable antes de su construcción
Uno de los propósitos principales del diseño es revisar y discutir la solución antes de lanzarse a la carga y codificarla. Parte del proceso de verificación es su rastreabilidad.

Una buena metodología de diseño crea productos diferenciados que son mensurables
Una de las tareas más difíciles de cualquier proyecto es estimar cuando se terminará. Para hacer una estimación el gerente del proyecto debe tomar medidas, la cual involucra el conteo de cosas que necesitan hacerse y la aplicación de algún tipo de medida sobre ellas para estimar que tanto tiempo se llevara el hacerlas.

El diseño debe ser fácilmente aprovechado en el producto final.
Debe expresar el uso y la estructura del sistema en una forma muy cercana al resultado pretendido. Este punto puede parecer obvio, pero se ha visto proyectos que trataron de usar técnicas de diseño que fueron completamente inadecuadas para el lenguaje de destino en el que se codifico el sistema. Usted no querría que su arquitecto casero le presentara un plano que fuera tan esotérico que no le diera idea de la forma que tendría la casa en su terreno. El lema de un diseñador es: hacer un mapa de la técnica hacia el destino.

ACTIVIDAD 10

DIAGRAMA DE CASOS DE USO

Elementos


Actor:
Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.

Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.

Caso de Uso:
Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.

Relaciones:

Asociación
Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

Dependencia o Instanciación

Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.

Generalización

Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<>) o de Herencia (<>).
Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).
uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.

DIAGRAMA DE CLASES

Elementos
Clase
Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un rectángulo que posee tres divisiones

En donde:
Superior: Contiene el nombre de la Clase

Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public).

Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

DIAGRAMA DE ACTIVIDADES

DIAGRAMA DE INTERACCION (secuencia)

OBJETOS


Los diagramas de secuencia constan de objetos que se representan de modo usual: rectángulo con nombre, mensajes entre los objetos representados por líneas continuas con una punta de flecha y el tiempo representado como una progresión vertical. Los objetos se colocan cerca de la parte superior del diagrama de izquierda a derecha y se acomodan de manera que simplifiquen el diagrama.

La extensión que esta debajo (en forma descendente) de cada objeto será una línea discontinua conocida como la línea de vida de un objeto, junto con la línea de vida de un (objeto rectángulo) se le conoce como activación, el cual una operación que realiza el objeto la interpreta como la duración de la activación.

LINEA DE VIDA

Una línea de vida representa un participante individual en un diagrama de secuencia. Una línea de vida usualmente tiene un rectángulo que contiene el nombre del objeto. Si el nombre es self entonces eso indica que la línea de vida representa el clasificador que posee el diagrama de secuencia.

MENSAJE
Un mensaje que va de un objeto a otro pasa de la línea de vida de un objeto al de otro. Un objeto puede enviarse un objeto a si mismo es decir de su línea de vida así propia línea de vida.

Un mensaje puede ser simple, síncrono y asíncrono

•Mensaje simple: es la transferencia del control de un objeto a otro.

•Mensaje síncrono: es cuando el objeto espera la respuesta a ese mensaje antes de continuar con su trabajo.

•Mensaje asíncrono: es cuando el objeto no espera la respuesta a ese mensaje antes de continuar.

TIEMPO

El diagrama representa el tiempo en dirección vertical. El tiempo se inicia en la parte superior y avanza hacia la parte inferior. Un mensaje que este mas cerca de la parte superior ocurrirá antes que uno que esté cerca de la parte inferior.

Con ellos el diagrama de secuencia tiene 2 dimensiones: la dimensión horizontal (es la disposición de los objetos) y la dimensión vertical (muestra el paso del tiempo).

La siguiente figura muestra el conjunto basico de simbolos del diagrama desecuencia, junto con los simbolos de su funcionamiento.

 

RECURCIVIDAD

En ocasiones un objeto posee una operación que se invoca a si misma. A esto se le conoce como recursividad y es una característica fundamental de varios lenguajes de programación.

La siguiiente figura muestra este tipo de reprecentacion.

EJEMPLO

DIAGRAMA DE INTERACCION (colaboracion)

DIAGRAMA DE ESTADOS

Estado


Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el objeto está esperando alguna operación, tiene cierto estado característico o puede recibir cierto tipo de estímulos. Se representa mediante un rectángulo con los bordes redondeados, que puede tener tres compartimientos: uno para el nombre, otro para el valor característico de los atributos del objeto en ese estado y otro para las acciones que se realizan al entrar, salir o estar en un estado (entry, exit o do, respectivamente).
Eventos

Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta ocurrencia puede ser una de varias cosas:

· Condición que toma el valor de verdadero o falso

· Recepción de una señal de otro objeto en el modelo

· Recepción de un mensaje

· Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha particular

El nombre de un evento tiene alcance dentro del paquete en el cual está definido, no es local a la clase que lo nombre.
Envío de mensajes

Además de mostrar y transición de estados por medio de eventos, puede representarse el momento en el cual se envían mensajes a otros objetos. Esto se realiza mediante una línea punteada dirigida al diagrama de estados del objeto receptor del mensaje.
Transición simple

Una transición simple es una relación entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son satisfechas. Se representa como una línea sólida entre dos estados, que puede venir acompañada de un texto con el siguiente formato:
event-signature "[" guard-condition] "/" action-expression "^"send-clause

event-signature es la descripción del evento que da lugar la transición, guard-condition son las condiciones adicionales al evento necesarias para que la transición ocurra, action-expression es un mensaje al objeto o a otro objeto que se ejecuta como resultado de la transición y el cambio de estado y send-clause son acciones adicionales que se ejecutan con el cambio de estado, por ejemplo, el envío de eventos a otros paquetes o clases.

Transición interna

Es una transición que permanece en el mismo estado, en vez de involucrar dos estados distintos. Representa un evento que no causa cambio de estado. Se denota como una cadena adicional en el compartimiento de acciones del estado.
Acciones:

Podemos especificar la solicitud de un servicio a otro objeto como consecuencia de la transición. Se puede especificar el ejecutar una acción como consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un evento.


Generalización de Estados:

· Podemos reducir la complejidad de estos diagramas usando la generalización de estados.

· Distinguimos así entre superestado y subestados.

· Un estado puede contener varios subestados disjuntos.

· Los subestados heredan las variables de estado y las transiciones externas.

· La agregación de estados es la composición de un estado a partir de varios estados independientes.

La composición es concurrente por lo que el objeto estará en alguno de los estados de cada uno de los subestados concurrentes. La destrucción de un objeto es efectiva cuando el flujo de control del autómata alcanza un estado final no anidado. La llegada a un estado final anidado implica la subida al superestado asociado, no el fin del objeto.
Subestados

Un estado puede descomponerse en subestados, con transiciones entre ellos y conexiones al nivel superior. Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel inmediatamente superior.
Transacción Compleja

Una transición compleja relaciona tres o más estados en una transición de múltiples fuentes y/o múltiples destinos. Representa la subdivisión en threads del control del objeto o una sincronización. Se representa como una línea vertical de la cual salen o entran varias líneas de transición de estado.
Transición a estados anidados

Una transición de hacia un estado complejo (descrito mediante estados anidados) significa la entrada al estado inicial del subdiagrama. Las transiciones que salen del estado complejo se entienden como transiciones desde cada uno de los subestados hacia afuera (a cualquier nivel de profundidad).

DIAGRAMA DE IMPLEMENTACION (componentes)
 
 1


Componente

Elemento de funcionalidad del sistema reutilizable. Un componente proporciona y utiliza el comportamiento a través de las interfaces y puede hacer uso de otros componentes.
Los elementos internos de un componente se pueden mostrar u ocultar con el control de expandir y contraer (9).
Un componente es un tipo de clase.
Is Indirectly Instantiated. Si es true (valor predeterminado), el componente solo existe como artefacto de diseño. Solo existen sus elementos en tiempo de ejecución.

2

Puerto de interfaz proporcionada

Representa un grupo de mensajes o llamadas que un componente implementa y que otros componentes o sistemas externos pueden utilizar. Un puerto es una propiedad de un componente que tiene una interfaz como tipo.

3

Puerto de interfaz necesaria

Representa un grupo de mensajes o llamadas que el componente envía a otros componentes o sistemas externos. El componente está diseñado para que se acople a los componentes que proporcionan al menos estas operaciones. El puerto tiene una interfaz como tipo.

4

Dependencia

Se puede utilizar para indicar que una interfaz necesaria de un componente se puede satisfacer mediante una interfaz proporcionada de otro.

Las dependencias también se pueden utilizar con más frecuencia entre los elementos del modelo para mostrar que el diseño de uno depende del diseño del otro.
5

Parte

Atributo de un componente cuyo tipo normalmente es otro componente. Los elementos se utilizan en el diseño interno de su componente primario. Los elementos se muestran de forma gráfica, anidados dentro del componente primario.
Para crear un elemento de un tipo del componente existente, arrastre el componente del Explorador de modelos UML al componente propietario.
Para crear un elemento de un nuevo tipo, haga clic en la herramienta Componente y, a continuación, en el componente propietario.
Por ejemplo, un componente Car tiene los elementos engine:CarEngine, backLeft:Wheel, frontRight:Wheel, etc.
Varios elementos pueden tener el mismo tipo y varios componentes distintos pueden tener elementos del mismo tipo.
Tipo. Tipo del elemento, que se define en otra parte del modelo. Normalmente, el tipo es otro componente.

Multiplicity. El valor predeterminado es 1. Puede establecerse en 0..1 para indicar que el elemento puede tener el valor null, en * para indicar que el elemento es una colección de instancias del tipo especificado, o en cualquier expresión que se pueda evaluar como un intervalo de números.

6

Ensamblado de elementos

Conexión entre los puertos de la interfaz necesaria de un elemento y los puertos de la interfaz proporcionada de otro. La implementación de un ensamblado de elementos puede variar de un componente a otro. Los elementos conectados deben tener el mismo componente primario.

7

Delegación

Vincula un puerto a una interfaz de uno de los elementos del componente. Indica que los mensajes enviados al componente se administran en el elemento o que los mensajes enviados desde el elemento se envían fuera del componente primario.

8

Generalización

Indica que un componente hereda de otro componente. Los elementos y las interfaces se heredan.

9

Control de expandir y contraer

Utilice este control para mostrar u ocultar los elementos internos de un componente.

(no se muestra)

Comentario

Se utiliza para agregar notas adicionales. Puede vincular un comentario a cualquier número de elementos del diagrama mediante la herramienta Conector.

DIAGRAMA DE IMPLEMENTACION (despliege)

Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo. Este tipo de diagrama debemos también añadir que no van a existir actores para relacionarse con los nodos (no es un diagrama de casos de uso) si no que las relaciones que pueda haber siempre seran entre los nodos y por ejemplo con una base de datos.



Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o una base de datos construida o modificada en un proyecto. Estos artefactos implementan colecciones de componentes. Los nodos internos indican ambientes, un concepto más amplio que el hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje de programación, a un sistema operativo, un ordenador o un cluster de terminales.



La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificación hardware de propósito general, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema.

ACTIVIDAD 9

PRESENTACION DE POWERPOINT

UML

https://docs.google.com/presentation/d/14IjL9S4cpfjJyNViSm8vn2yOZN8ewe3nSwrWKTNpvec/edit

AUTOEVALUACION 8

1. ¿Cuáles son las cinco capas en las que está basado el diseño orientado a objetos?

1. Capa Clase/Objeto. Esta capa indica las clase y objetos.
2. Capa de Estructura. Esta capa captura diversas estructuras de clase y objetos, tales como las relaciones uno a muchos y la herencia.
3. Capa de Atributos. Esta capa detalla los atributos de las clases.
4. Capa de Servicios. Esta capa indica los mensajes y comportamientos del objeto (servicios y métodos).
5. Capa de Tema. Esta capa divide el diseño en unidades de implementación o asignaciones de equipos.


2. Nombra tres criterios para usados para determinar si se justifica una nueva clase

1. Hay una necesidad de recordar el objeto. Esto es, el objeto puede ser descrito en un sentido definido y sus atributos son relevantes para el problema.
2. Hay una necesidad de determinados comportamientos del objeto. Esto es, aunque un objeto no tenga atributos, hay servicios que debe proporcionar o estados de objeto que deben ser llamados.
3. Usualmente un objeto tendrá varios atributos. Los objetos que tienen solamente uno o dos atributos sugieren diseños sobreanalizados.


3. ¿Qué es una clase?

Clase. Es una categoría de objetos similares. Los objetos se agrupan en clases. Una clase define el conjunto de atributos y comportamientos compartidos que se encuentran a cada objeto de la clase.


4. ¿Qué es un objeto?

Objeto: es una abstracción de algo en un dominio de un problema que refleja las capacidades de un sistema para llevar información acerca de ello, interactuar con ello a ambas cosas.

ACTIVIDAD 8 (sugeridas)

1.-Explique los ocho criterios usados para determinar si se justifica una nueva clase

1. Hay una necesidad de recordar el objeto. Esto es, el objeto puede ser descrito en un sentido definido y sus atributos son relevantes para el problema.
2. Hay una necesidad de determinados comportamientos del objeto. Esto es, aunque un objeto no tenga atributos, hay servicios que debe proporcionar o estados de objeto que deben ser llamados.
3. Usualmente un objeto tendrá varios atributos. Los objetos que tienen solamente uno o dos atributos sugieren diseños sobreanalizados.
4. Usualmente una clase tendrá mas de una instancia de objeto, a menos de que sea una clase base.
5. Usualmente los atributos tendrán siempre un valor significativo para cada objeto de la clase. Los objetos que producen valor NULO para un atributo, o para los que no es aplicable un atributo, por lo general implican una estructura generalización-especificación.
6. Usualmente los servicios siempre se comportarán en la misma forma para todos los objetos de la clase. Los servicios que varían dramáticamente para algunos objetos de una clase o que regresan sin realizar acción para algunos objetos también sugieren una estructura generalización-especificación.
7. Los objetos deben implementar requerimientos que son derivados del problema y no de la tecnología de solución. La parte de análisis del proyecto orientado a objetos no debe llegar a ser dependiente de una tecnología de implementación particular, tal como un sistema de computadora especifico o un lenguaje de programación especifico. Los objetos que atienden tales detalles técnicos no deben aparecer sino hasta muy tarde en la etapa de diseño. Los objetos dependientes de la tecnología sugieren que el proceso de análisis tiene fallas.
8. Los objetos no deben duplicar atributos o servicios que pueden ser derivados de otros objetos del sistema. Por ejemplo, un objeto que guarda la edad de un empleado es superfluo cuando existe un objeto de empleado separado que conserva el atributo fecha de nacimiento. El objeto edad puede ser eliminado por un servicio edad que es componente del objeto empleado.


2.- Describa la diferencia entre una clase y un objeto

Las clases son representadas por cuadros rectangulares redondeados (bubtángulos) divididos en tres partes. El nombre de la clase se muestra en la división superior del cuadro. Las otras dos divisiones se usan para las capas de atributo y servicio. Cuando una clase aparece sin objetos, puede ser solamente una clase base, debido a que la única razón para tal clase "sin objetos" es que sea un medio para agrupar atributos y servicios que serán heredados por varias otras clases.

ACTIVIDAD 8 (obligatorias)

1.- Explique las cinco capas en las que esta basado el diseño orientado a objetos

1. Capa Clase/Objeto. Esta capa indica las clase y objetos.
2. Capa de Estructura. Esta capa captura diversas estructuras de clase y objetos, tales como las relaciones uno a muchos y la herencia.
3. Capa de Atributos. Esta capa detalla los atributos de las clases.
4. Capa de Servicios. Esta capa indica los mensajes y comportamientos del objeto (servicios y métodos).
5. Capa de Tema. Esta capa divide el diseño en unidades de implementación o asignaciones de equipos.


2.- ¿Cuáles son los cinco tipos generales de objetos?

Algunas veces los objetos representan papeles actuados por personas u organizaciones. Los objetos también pueden ser derivados de incidentes o eventos. Otros objetos pueden indicar interacciones tales como una venta o un matrimonio. Las interacciones tienen una cualidad de transacción o contrato. Los objetos también pueden detallar especificaciones. Las especificaciones tienen estándares o una cualidad de definición y, por lo general, implican que otros objetos representaran ocurrencias de cosas tangibles.


3.- ¿Cómo puede decidirse si una clase ha tenido ocurrencia de objetos?

Los objetos que tienen ocurrencia de una clase son representados por un cuadro sombreados rodeado por la clase. Debido a que los objetos tiene ocurrencias de una clase.

organigrama