Está en la página 1de 13

1.

DIRECCIÓN ACADÉMICA

Formato de entrega de evidencias


FO-205P11000-14

División: (1) Grupo: (2)

Asignatura: (3) Docente: (4)


Nombre y número de control: (5)
Fecha de entrega: (6)
Competencia No.: (7) Descripción: (8)
Indicador de alcance: (9)
Evidencia de aprendizaje: (10)

EL PROCESO DE DISEÑO
El diseño es la transformación de los requerimientos en una forma adecuada
para la fabricación o la utilización. El proceso de diseño puede abarcar la
investigación y el desarrollo, siendo actividades de carácter creativo. Este
proceso es iterativo, en cierto sentido nunca se termina. Los usuarios
alimentan nueva información y se descubren formas para mejorar los diseños
que reduzcan los costos y mejoren la calidad.

Responsabilidad del diseño

La función del proceso de diseño se encuentra relacionada con las funciones


de:

Su finalidad es recoger las necesidades del mercado y transformarlas de tal


forma que pueda satisfacerlas la unidad operativa.

Las decisiones tomadas durante el proceso de diseño pueden tener efectos


importantes a largo plazo en toda la organización.

El proceso de diseño en todos aspectos tiene efectos económicos, de desarrollo,


y de permanencia de las empresas e instituciones de ahí su importancia.
La primera consideración es crear algo que satisfaga funcionalmente los
requerimientos.

Etapas del proceso de diseño

En todo proyecto, el proceso de diseño debe pasar por las siguientes etapas

1. Concepción: ésta se puede subdividir en cuatro etapas, a las que


llamaremos causas:

Causa primera: Es el motivo, cualquiera que sea, en ella está la necesidad


humana, sin ella no existiría el diseño.

Causa Formal: Comienza cuando imaginamos cómo será el objeto a diseñar,


y es así como empieza a adquirir forma en la mente. Es probable que se agarre
lápiz y papel y con ello empecemos a bocetar. De esta manera vemos la forma
preliminar, tenemos una idea acerca de los materiales que hemos de emplear,
imaginamos maneras de fabricarlos, de ensamblarlos, de venderlos etc.

Causa Material: Lo que hemos imaginado, no es el producto simplemente


representa una idea que se realizara en madera, en metal, en plástico u otro
material cualquiera. No es factible imaginar una forma real si no es en algún
material, tal es la causa material.

Causa Técnica: Parte de la naturaleza de los materiales es la manera en que


podemos darles forma, tal es la causa técnica. Lo que se desea hacer y el
material elegido sugerirá herramientas y técnicas apropiadas

2
2. Aceptación: Es cuando se demuestra que las especificaciones son
alcanzadas por medio de cálculos matemáticos, bocetos, modelos
experimentales, maquetas o pruebas de laboratorio.

3. Ejecución: Cuando se preparan varios modelos a partir del trabajo de la etapa


de aceptación. Se construyen plantas piloto como continuación de los
experimentos o pruebas.

4. Adecuación: Etapa en la cual el proyecto adquiere una forma que permite


integrarlo a la organización y ajustarlo a las especificaciones definitivas.

MODELO ENTIDAD -RELACION


Es un método del que disponemos para diseñar estos esquemas que
posteriormente debemos de implementar en un gestor de BBDD (bases de datos).
Este modelo se representa a través de diagramas y está formado por varios
elementos.

Este modelo habitualmente, además de disponer de un diagrama que ayuda a


entender los datos y como se relacionan entre ellos, debe de ser completado con
un pequeño resumen con la lista de los atributos y las relaciones de cada
elemento.

Elementos del modelo entidad-relación

Entidad

Las entidades representan cosas u objetos (ya sean reales o abstractos), que se
diferencian claramente entre sí.

3
Para poder seguir un ejemplo durante el artículo añadiré ejemplos sobre un taller
mecánico, donde se podría crear las siguientes entidades:

 Coches (objeto físico): contiene la información de cada taller.

 Empleado (objeto físico): información de los trabajadores.

 Cargo del empleado (cosa abstracta): información de la función del empleado.

Estas entidades se representan en un diagrama con un rectángulo, como los


siguientes.

Atributos

Los atributos definen o identifican las características de entidad (es el contenido


de esta entidad). Cada entidad contiene distintos atributos, que dan información
sobre esta entidad. Estos atributos pueden ser de distintos tipos (numéricos, texto,
fecha...).

Siguiendo el ejemplo de antes podemos analizar los atributos de nuestra entidad


"Coches", que nos darán información sobre los coches de nuestro supuesto taller.

Unos posibles atributos serían los siguientes: número de chasis, matrícula, DNI del
propietario, marca, modelo y muchos otros que complementen la información de
cada coche.

Los atributos se representan como círculos que descienden de una entidad, y no


es necesario representarlos todos, sino los más significativos, como a
continuación.

En un modelo relacional (ya implementado en una base de datos) un ejemplo de


tabla dentro de una BBDD podría ser el siguiente.

4
Número de chasis Matrícula DNI del propietario

5tfem5f10ax007210 4817 BFK 45338600L

6hsen2j98as001982 8810 CLM 02405068K

5rgsb7a19js001982 0019 GGL 40588860J

Este ejemplo es con tres atributos, pero un coche podría tener cientos (si fuese
necesario) y seguirían la misma estructura de columnas, tras implementarlo en
una BBDD.

Relación

Es un vínculo que nos permite definir una dependencia entre varias entidades, es
decir, nos permite exigir que varias entidades compartan ciertos atributos de forma
indispensable.

Por ejemplo, los empleados del taller (de la entidad "Empleados") tienen un cargo
(según la entidad "Cargo del empleado"). Es decir, un atributo de la entidad
"Empleados" especificará que cargo tiene en el taller, y tiene que ser idéntico al
que ya existe en la entidad "Cargo del empleado".

Las relaciones se muestran en los diagramas como rombos, que se unen a las
entidades mediante líneas.

Yo, bajo mi punto de vista, entiendo mejor esto en una tabla (de una
implementación en una BBDD), por lo que voy a poner el ejemplo de cómo se
representaría (resaltada la relación, que posteriormente veremos cómo se haría).

5
Empleados

Nombre DNI Cargo

Carlos Sánchez 45338600L 001

Pepe Sánchez 02405068K 002

Juan Sánchez 40588860J 002

Cargo del empleado

ID del cargo Descripción

001 Jefe de taller

002 Mecánico

Relaciones de cardinalidad

Podemos encontrar distintos tipos de relaciones según como participen en ellas


las entidades. Es decir, en el caso anterior cada empleado puede tener un cargo,
pero un mismo cargo lo pueden compartir varios empleados.

Esto complementa a las representaciones de las relaciones, mediante un intervalo


en cada extremo de la relación que especifica cuantos objetos o cosas (de cada
entidad) pueden intervenir en esa relación.

6
Uno a uno: Una entidad se relaciona únicamente con otra y viceversa. Por
ejemplo, si tuviésemos una entidad con distintos chasis y otra con matrículas
deberíamos de determinar que cada chasis solo puede tener una matrícula (y
cada matrícula un chasis, ni más en ningún caso).

Uno a varios o varios a uno: determina que un registro de una entidad puede
estar relacionado con varios de otra entidad, pero en esta entidad existir solo una
vez. Como ha sido en el caso anterior del trabajador del taller.

Varios a varios: determina que una entidad puede relacionarse con otra con
ninguno o varios registros y viceversa. Por ejemplo, en el taller un coche puede
ser reparado por varios mecánicos distintos y esos mecánicos pueden reparar

varios coches distintos.

Los indicadores numéricos indican el primero el número mínimo de registros en


una relación y posteriormente el máximo (si no hay límite se representa con una
"n").

Claves

Es el atributo de una entidad, al que le aplicamos una restricción que lo distingue


de los demás registros (no permitiendo que el atributo específico se repita en la
entidad) o le aplica un vínculo (exactamente como comentábamos en las
relaciones). Estos son los distintos tipos:

Superclase: aplica una clave o restricción a varios atributos de la entidad, para así
asegurarse que en su conjunto no se repitan varias veces y así no poder entrar en
dudas al querer identificar un registro.

7
Clave primaria: identifica inequívocamente un solo atributo no permitiendo que se
repita en la misma entidad. Como sería la matrícula o el número de chasis de un
coche (no puede existir dos veces el mismo).

Clave externa o clave foránea: este campo tiene que estar estrictamente
relacionado con la clave primaria de otra entidad, para así exigir que exista
previamente ese clave. Anteriormente hemos hablado de ello cuando
comentábamos que un empleado indispensablemente tiene que tener un cargo
(que lo hemos representado numéricamente), por lo cual si intentásemos darle un
cargo inexistente el gestor de bases de datos nos devolvería un error.

DISEÑO CON DIAGRAMAS E-R


El modelo de datos E-R da una flexibilidad sustancial en el diseño de un
esquema de bases de datos para modelar una empresa dada. En este
apartado se considera cómo un diseñador de bases de datos puede
seleccionar entre el amplio rango de alternativas.

Un modelo de datos de alto nivel sirve al diseñador de la base de datos para


proporcionar un marco conceptual en el que especificar de forma sistemática
los requisitos de datos de los usuarios de la base de datos que existen, y cómo
se estructurará la base de datos para completar estos requisitos. La fase inicial
del diseño de bases de datos, por tanto, es caracterizar completamente las
necesidades de datos esperadas por los usuarios de la base de datos. El
resultado de esta fase es una especificación de requisitos del usuario. Esta
estructura general se puede expresar gráficamente mediante un diagrama E-R.

A continuación, el diseñador elige un modelo de datos y, aplicando los


conceptos del modelo de datos elegido, traduce estos requisitos a un esquema
conceptual de la base de datos. El esquema desarrollado en esta fase
de diseño conceptual proporciona una visión detallada del desarrollo. Debido
a que sólo se ha estudiado el modelo E-R hasta ahora, se usará éste para
desarrollar el esquema conceptual. En términos del modelo E-R, el esquema

8
especifica todos los conjuntos de entidades, conjuntos de relaciones, atributos
y restricciones de correspondencia.
El diseñador revisa el esquema para confirmar que todos los requisitos de
datos se satisfacen realmente y no hay conflictos entre sí. También se examina
el diseño para eliminar características redundantes. Lo importante en este
punto es describir los datos y las relaciones, más que especificar detalles del
almacenamiento físico.

Un esquema conceptual completamente desarrollado indicará también los


requisitos funcionales de la empresa. En una especificación de requisitos
funcionales los usuarios describen los tipos de operaciones (o transacciones)
que se realizarán sobre los datos. Algunos ejemplos de operaciones son la
modificación o actualización de datos, la búsqueda y recuperación de datos
específicos y el borrado de datos. En esta fase de diseño conceptual se puede
hacer una revisión del esquema para encontrar los requisitos funcionales.

MODELO E-R EXTENDIDO


El Modelo Entidad-Relación Extendido incluye todos los conceptos del Entidad-
Relación e incorpora los conceptos de Subclase y superclase con los conceptos
asociados de Especialización y Generalización.

Subclases, Superclases y Especialización:

En el modelo Entidad-Relación, una entidad agrupa un conjunto de ocurrencias de


entidad del mismo tipo. En muchos casos, estas ocurrencias se pueden agrupar a
su vez en otros subconjuntos que tienen un significado propio para los propósitos
de la Base de Datos y, por tanto, deberían representarse de forma explícita.

Una generalización se define como una entidad llamada superclase la cual


contiene los aspectos más generales de una aplicación y pueden existir tantas

9
superclases como se requiera. Si esas existen se les conoce también con el
nombre de entidades fuertes.

La especialización se define como el conjunto de entidades que tienen


características más particulares de la aplicación y para estas existan deberá de
ocurrir una instancia de la superclase, pero no necesariamente ocurrirá
ocurrencias de las subclases (entidades débiles).

En el modelo entidad-relación extendido, una entidad agrupa un conjunto de


ocurrencias de entidad del mismo tipo, en muchos casos esas ocurrencias tienen
un significado propio para la base de datos y se deberán de representar de otra
manera. Por ejemplo, la entidad empleada puede a su vez subdividirse en docente
y no docente y cada una de estas subdivisiones se le llamaran subclase.

Las subclases deberán de pertenecer a una superclase y podremos tener las


relaciones clase/subclase que en el ejemplo anterior las relacionemos con
empleado/docente y empleado/no docente.

Debido a que una subclase es a su vez parte de una superclase, la superclase


tendrá sus atributos específicos, así como los atributos correspondientes a la
superclase a la cual pertenece. Si esto existe en un diagrama se dice entonces
que existe una herencia. De la misma manera en que se heredan los atributos, las
subclases heredarán las relaciones que contenga la superclase.

El proceso por el cual se definen las diferentes subclases de una superclase se le


conoce con el nombre de especialización, y la forma de denotar será la siguiente:
se pondrá un circulo y dentro del circulo la letra "d", y el circulo deberá de estar
entre la superclase y la subclase. Este círculo podrá unir a más de dos subclases
y la letra "d" significa desunión.

10
La desunión significa que cada subclase es completamente independiente de las
otras y que una instancia de la superclase podrá tener solamente una ocurrencia
de una subclase.

Generalización:
Se da cuando se tienen varias entidades con características comunes y pueden
crearse una entidad superior que tenga la información general de la aplicación. En
otras palabras, la generalización es el proceso inverso de la especialización.

Restricción de desunión:
Las restricciones de desunión especifican que las subclases de las
especializaciones deben de estar separadas. Esto significa que una ocurrencia de
la subclase puede ser miembro de como máximo una de las subclases de la
especialización si esta ocurre se denota la desunión con una letra "d", si la
desunión esta desunida por el usuario, entonces el predicado deberá estar entre el
circulo y la entidad.

Si las subclases no son desunidas, entonces se dice que cada superclase puede
pertenecer a más de una subclase y si esto existe se representa mediante la Letra
"o" en el circulo y se llamara restricción de totalidad la cual puede ser parcial y
total.

Existen a su vez cuatro tipos de especializaciones que son las siguientes:

Desunión total o especialización total: que significa que cada superclase debe de
pertenecer a una sola subclase. Si eso existe se denota con línea doble antes del
circulo.

Desunión parcial o especialización parcial: Significa que una superclase no


pertenece a una subclase. Si esto existe se denota con línea sencilla antes del
circulo.

11
Unión o solapamiento total: Significa que las superclases pertenecen a todas las
subclases y se denota con doble línea antes del circulo.

Solapamiento parcial: Significa que la superclase no va a pertenecer a todas las


subclases en un momento dado y se denota con una línea antes del circulo.

LA NOTACION E-R CON UML


Los diagramas entidad-relación ayudan a modelar el componente de
representación de datos de un sistema software. La representación de datos, sin
embargo, sólo forma parte de un diseño completo de un sistema.

Otros componentes son modelos de interacción del usuario con el sistema,


especificación de módulos funcionales del sistema y su interacción, etc. El
lenguaje de modelado unificado (UML, Iniciad Madelin Lenguaje) es un estándar
propuesto para la creación de especificaciones de varios componentes de un
sistema software. Algunas de las partes de UML son:

 Diagrama de clase. Un diagrama de clase es similar a un diagrama E-R.


 Diagrama de caso de uso. Los diagramas de caso de uso muestran la
interacción entre los usuarios y el sistema, en particular los pasos de las
tareas que realiza el usuario.
 Diagrama de actividad. Los diagramas de actividad describen el flujo de
tareas entre varios componentes de un sistema.
 Diagrama de implementación. Los diagramas de implementación
muestran los componentes del sistema y sus interconexiones tanto en el
nivel del componente software como el hardware.

INSTRUCTIVO PARA LLENAR EL FORMATO: ENTREGA DE EVIDENCIAS (FO205P11000-14)

12
OBJETIVO: ESTANDARIZAR LA PRESENTACIÓN DE LAS EVIDENCIAS GENERADAS POR EL
ESTUDIANTADO EN EL TESCI.
DISTRIBUCIÓN Y DESTINATARIO: EL ESTUDIANTADO REQUISITA EL FORMATO Y ENTREGA AL
PERSONAL DOCENTE PARA SU EVALUACIÓN.
NO. CONCEPTO DESCRIPCIÓN
ANOTAR EL NOMBRE DE LA DIVISIÓN EN LA QUE EL PERSONAL
1 DIVISIÓN
DOCENTE IMPARTE LA ASIGNATURA
INDICAR EL GRUPO EN EL QUE EL ESTUDIANTADO CURSA LA
2 GRUPO
ASIGNATURA
3 ASIGNATURA REGISTRAR EL NOMBRE DE LA ASIGNATURA
ESCRIBIR EL NOMBRE COMPLETO DEL PERSONAL DOCENTE QUE
4 DOCENTE
IMPARTE LA ASIGNATURA
NOMBRE Y NÚMERO DE INDICAR EL NOMBRE Y NÚMERO DE CONTROL DEL ESTUDIANTADO
5
CONTROL QUE ENTREGA LA EVIDENCIA
ASENTAR DÍA, MES Y AÑO EN LOS QUE EL ESTUDIANTADO
6 FECHA DE ENTREGA ENTREGA LA EVIDENCIA DE APRENDIZAJE. EJEMPLO: 29 DE
SEPTIEMBRE DE 2018
PLASMAR EL NÚMERO CONSECUTIVO QUE LE CORRESPONDE A
7 COMPETENCIA NO. LA COMPETENCIA ESPECÍFICA QUE EL ESTUDIANTADO ESTÁ
DESARROLLANDO
ASENTAR LA COMPETENCIA ESPECÍFICA QUE EL ESTUDIANTADO
8 DESCRIPCIÓN ESTÁ DESARROLLANDO A TRAVÉS DE LA EVIDENCIA DE
APRENDIZAJE
DESCRIBIR EL INDICADOR DE ALCANCE QUE SE ESTÁ
9 INDICADOR DE ALCANCE
DESARROLLANDO A TRAVÉS DE LA EVIDENCIA DE APRENDIZAJE
EVIDENCIA DE ANOTAR EL NOMBRE DETALLADO DE LA EVIDENCIA DE
10
APRENDIZAJE APRENDIZAJE SOLICITADA POR EL PERSONAL DOCENTE

13