Juan Luis Estrada Muñoz U2.docs

TECNOLOGICO NACIONALE DE MEXICO
INSTITUTO TECNOLOGICO DE ZACATECAS
INGENIERIA DE SOFTWARE
INVESTIGACION DE TEORIA 2: DISEÑO
ALUMNO:
JUAN LUIS ESTRADA MUÑOZ 19450169
MAESTRA:
I.S.C CINTHYA YERANIA CASAS RAMIREZ
28/02/2023
JEAA Página 2 de 31
Proceso Código: 19450169
Ingeniería de software
Teoría 2: DISEÑO  Versión: 1
Fecha elaboración: 28-02-2023
INDICE.
2.1 DISEÑO DE PROCESOS PROPUESTOS…………………………….. 3-6
2.1.1 HERRAMIENTAS CASE PARA DISEÑO ………………………………7-14
2.2 DISEÑO ARQUITECTONICO ……………………………………………. 14-24
2.3 DISEÑO DE DATOS ………………………………………………………. 24-28
2.4 DISEÑO DE INTERFAZ DE USUARIO ………………………………….28-30

2.1 DISEÑO DE PROCESOS PROPUESTOS.
DIMENSION DEL PROCESO.
La dimensión del proceso indica la evolución del modelo del diseño conforme se
ejecutan las tareas de este como parte del proceso del software.
DISEÑO DE LA ABSTRACCION.
Representa el nivel de detalle a medida que cada elemento del modelo de análisis
se transforma en equivalente de diseño y luego se mejora en forma iterativa.
La línea punteada indica la frontera entre los modelos de análisis y de diseño.

Los elementos del modelo de diseño usan mucho de los diagramas UML que se
utilizaron en el modelo del análisis. La diferencia es que estos diagramas se
refinan y elaboran como parte del diseño.
EL PROCESO DEL DISEÑO.
El diseño del software es un proceso iterativo por medio del cual se traducen los
requerimientos en un “plano” para construir el software.
A medida que tiene lugar las iteraciones del diseño, las mejoras posteriores
conducen a niveles menores de abstracción.
IMPORTANCIA DEL SISEÑO DE SOFTWARE.
 Durante el diseño se toman decisiones que en ultima instancia afectaran el

éxito de la construcción y facilidad de mantenimiento del software.
 El diseño es el sitio en el que se introduce calidad en la ingeniería de
software.
 Da representaciones del software que pueden evaluarse en su calidad.
 Es la única manera de traducir con exactitud a un producto o sistema
terminando los requerimientos de los participantes.
FLUJO DURANTE EL DISEÑO DE SOFTWARE.
El trabajo de diseño es alimentado por el modelo de requerimientos,

manifestado por elementos basados en el escenario, en la clase, orientados al
flujo, y del comportamiento.
DISEÑO DE DATOS.
Transforma los modelos de clases en realizaciones de clases de diseño y en

las estructuras de datos que se requieren para implementar el software.
Los objetos y relaciones definidos en el diagrama CRC y el contenido detallado

de los datos ilustrado por los atributos de clase y otros tipos de notación dan la
base para el diseño de datos.
DISEÑO DE ARQUITECTURA.
Define la relación entre los elementos principales de la estructura del software,

los estilos y patrones de diseño de la arquitectura que pueden usarse para
alcanzar los requerimientos definidos por el sistema y las restricciones que
afectan la forma en la que se implementa la arquitectura.
DISEÑO DE INTERFAZ.
Describe la forma en la que el software se comunica con los sistemas que

interactúan con el y con los humanos que lo utilizan. Una interfaz implica un
flujo de información (por ejemplo, datos o control) y un tipo especifico de
comportamiento.
Los modelos de escenarios de uso y de comportamiento dan mucha de la

información requerida para diseñar la interfaz.
DISEÑO DE COMPONENTES.
Transforma los elementos estructurales de la arquitectura del software en una

descripción de sus componentes en cuanto a procedimiento. La información
obtenida a partir de los modelos basados en clase, flujo y comportamiento sirve
como la base para diseñar los componentes.
DISEÑO DE SOFTWARE.
EL diseño de software agrupa el conjunto de principios, conceptos y practicas

que llevan al desarrollo de un sistema o producto de alta calidad. Los principios
de diseño establecen una filosofía general que guía el trabajo de diseño que
debe ejecutarse.
El diseño de software se ubica en el área técnica de la ingeniería de software y

se aplica sin importar el modelo del proceso que se utilice.
El diseño del software comienza una vez que se han analizado y modelado los
requerimientos.
2.1.1 HERRAMIENTAS CASE PARA DISEÑO.
Las siglas 'CASE' se refieren a Computer Aided Software Engineering

(Ingeniería de Software Asistida por Computadora). Por tanto se refiere al
desarrollo y mantenimiento de proyectos de Software con la ayuda de varias
herramientas automatizadas.
Herramienta CASE
Las herramientas CASE son un conjunto de aplicaciones informáticas, usadas

para automatizar actividades de el ciclo de vida de desarrollo de sistemas
(SDLC). Las herramientas CASE son usadas por los Directores de proyectos
de software, analistas e Ingenieros para desarrollar sistemas de software.
Hay un gran número de Herramientas CASE disponibles para simplificar varias

etapas en el desarrollo del ciclo vital del Software, como por ejemplo
herramientas de análisis, diseño de herramientas, Gestión de proyectos de
herramientas, Proyectos de gestión de herramientas de Bases de datos,
gestión de herramientas de Bases de datos, deben nombrarse también algunas
Herramientas de Documentación.
El uso de Herramientas CASE acelera el desarrollo del proyecto con tal de

producir los resultados deseados y ayuda a encontrar imperfecciones antes de
proseguir con la siguiente etapa del desarrollo de Software.
Componentes de las Herramientas CASE

Las herramientas CASE se pueden dividir en las siguientes partes en base a a

su uso en una etapa concreta del SDLC:
Depósito central - Las herramientas CASE requieren un Depósito central, el

cual nos puede servir como fuente de común, consistente e integrada
información. El depósito central, es un lugar central de almacenamiento, donde
los requisitos del producto, los documentos requeridos, los informes y
diagramas relacionados, y otra información útil sobre la gestión se almacena.
El Depósito central también sirve como Diccionario de datos.
Herramientas Upper CASE - Las Herramientas Upper CASE se usan en las

etapas de planificación, análisis y diseño del SDLC.
Herramientas Lower CASE - Las Herramientas Lower CASE se usan en la

implementación, las pruebas y en el mantenimiento.
Herramientas Integrated CASE - Las Herramientas Integrated CASE son de

utilidad en todas las fases del SDLC, des de la educción de requisitos y las
pruebas hasta la documentación.
La Herramientas CASE se pueden agrupar todas juntas si tienen una

funcionalidad similar, y procesa actividades y la capacidad de integrarse con
otras Herramientas.
Alcance de las herramientas CASE
Alcance de las herramientas CASE recorre el SDLC.
Tipos de Herramientas CASE
Ahora veremos de manera breve varios casos de herramientas CASE
Herramienta CASE Diagrama

Estas herramientas se usan para representar componentes del sistema, datos,

y a controlar la fluidez de varios componentes y estructura del software de
manera gráfica. Por ejemplo, la herranmienta 'Flow Chart Maker' para crear los
más novedosos Diagramas de flujos.
Herramientas para modelado de procesos
El modelado de procesos es un método para crear modelos de proceso de

software y se usa para desarrollar el software. Las herramientas para el
modelado de procesos ayudan a los Directores a escoger un modelo de
proceso o para modificarlo según los requerimientos del producto software. Por
ejemplo, el 'EPF Composer'
Herramientas de administración de procesos
Estas herramientas se usan para la planificación del proyecto, el coste y

esfuerzo estimados, la temporalización y la organización de los recursos. Los
Directivos deben coordinar de manera muy estricta la ejecución del proyecto
con cada uno de los pasos mencionados con anterioridad para la buena
gestión del proyecto software. Herramientas de administración de procesos
ayudan a almacenar y a compartir información sobre el proyecto en tiempo real
durante su organización. Ejemplos de este tipo de herramienta son 'Creative
Pro Office', 'Trac Project', o 'Basecamp'.
Herramientas de documentación
La documentación de un proyecto de software empieza antes que el proceso

de software, pasa por todas las fases del SDLC y se concluye con la
terminación del proyecto.
Las Herramientas de documentación generan documentos tanto para el

consumidor final como para consumidores de soporte técnico. Estos últimos
son en su mayoría profesionales internos del equipo de desarrollo que
consultan manuales de sistemas, manuales de referencia, manuales de
formación, de instalación, etc. El consumidor final describe el funcionamiento e
instrucciones del sistema como por ejemplo el manual para el usuario.
Ejemplos de este tipo de herramientas son: Doxygen, DrExplain, Adobe
RoboHelp para documentación.
Herramientas de análisis
Estas herramientas ayudan a cumplir con los requisitos, de manera automática

examinan si hay alguna inconsistencia, o informaciones no acuradas en los
diagramas, buscan posibles redundancias o omisiones erróneas. Ejemplos de
este tipo de herramienta son Accept 360, Accompa, CaseComplete para
análisis de requisitos, y Visible Analysts para análisis total.
Herramientas de diseño
Estas herramientas ayudan a los diseñadores de software a crear la estructura

de los programas, la cual se puede más adelante desglosar en pequeños
módulos usando técnicas de perfeccionamiento. Estas herramientas aportan
los detalles de cada módulo y la interconexión presente entre estos. Un

ejemplo de herramienta puede ser el diseño animado de software
Herramientas para la gestión de la Configuración
Un ejemplo de software se lanza al mercado en una versión. Las Herramientas

para la gestión de la Configuración se ocupa de ello –
Control de versiones
Línea base
Gestión del control de cambios
Las herramientas CASE ayudan en esto usando un rastreo automático, control

de versiones y gestión de versiones. Por ejemplo, Fossil, Git, Accu REV.
Herramientas de control de cambios
Estas herramientas son consideradas como una parte de la configuración en la

gestión de herramientas. Se ocupan de los cambios hechos en el software
después de que se haya fijado su línea de base, o cuando el software se lanza
por primera vez al mercado. Las herramientas CASE automatizan la opción
'resaltar cambios', la gestión de archivos, la gestión del código, entre otros.
También ayuda a ejecutar el cambio de principios en que se basa la
organización.
Programming Tools
These tools consist of programming environments like IDE (Integrated

Development Environment), in-built modules library and simulation tools. These
tools provide comprehensive aid in building software product and include
features for simulation and testing. For example, Cscope to search code in C,
Eclipse.
Herramientas de desarrollo de software
El modelo de prototipo en Ingeniería de software, es una versión silmulada del

producto software que se intenta conseguir. Este prototipo da una idea inicial
del producto y simula algunos aspectos del producto real.
Las Herramientas de modelos de prototipo CASEP, esencialmente vienen con

bibliotecas gráficas. Pueden crear interfaces de usuario independientes del
hardware y diseño. Estas herramientas nos ayudan a construir prototipos
rápidos basados en información ya existente. Además producen prototipos de
simulación de software. Por ejemplo, Serena prototype composer, Mockup
Builder.
Herramientas de desarrollo Web
Estas herramientas ayudan en el diseño de páginas Web con todos los

elementos relacionados como impresos, textos, secuencias de comando,
gráficos y demás. Las herramientas Web también producen una vista
preliminar en directo de lo que se está desarrollando y cómo será una vez
terminado. Por ejemplo Fontello, Adobe Edge Inspect, Foundation 3, Brackets.
Herramientas de Aseguramiento de la calidad
El aseguramiento de la calidad de una organización de Software es la

supervisión del proceso de Ingeniería y de los métodos adoptados para
desarrollar el producto software con tal de asegurar conformidad con la calidad
según los estándares organizativos. Las herramientas de Aseguramiento de la
calidad, constan de herramientas de control de cambios y configuración y de
herramientas para pruebas de software. Por ejemplo, SoapTest, AppsWatch,
JMeter.
Herramientas de mantenimiento
El mantenimiento del Software incluye modificaciones en el producto software

después de ser distribuido. Algunas de las herramientas CASE que ayudan en
la organización y la fase de mantenimiento del software del SDLC son las
técnicas de inicio automático y de reporte de error, producción automática de
etiqueta de error y de Análisis de Causa Raíz (ACR o RCA en sus siglas en
inglés). Por ejemplo, Bugzilla para seguimiento de defectos, HP Quality Center.
2.2 DISEÑO ARQUITECTONICO.
No sería adecuado iniciar un proyecto sin un plan sólido; lo mismo ocurre con
el diseño de arquitectura de software. Al hacer que este proceso sea más
eficaz, puedes justificar todos tus requisitos de manera adecuada y brindar a
las partes interesadas la oportunidad de presentar sus aportaciones.
Mediante el uso de las imágenes técnicas y un cuidadoso proceso de

planeación, puedes hacer un esbozo de la arquitectura y el diseño de tu
software antes de empezar a crear un prototipo.
¿Para qué sirve la arquitectura de software?
El diseño de una arquitectura de software utiliza los conocimientos de

programación para planear el diseño general del software de modo que puedan
agregarse detalles más adelante, lo cual permite a los equipos de software
delimitar el panorama general y comenzar a elaborar un prototipo.
Si los desarrolladores de software siguen los consejos de diseño y las prácticas

recomendadas de arquitectura de software, pueden analizar detalladamente
las características de su software y decidir cómo diseñar la arquitectura de
este.
Cómo diseñar una arquitectura de software en 5 pasos:
1. Comprende claramente cuáles son tus requisitos
Todo diseño que comiences tendrá requisitos funcionales y no funcionales.

Estos requisitos guían tu arquitectura de software y te permiten concluir el
proyecto con la presentación de un producto final que deje satisfechas a las
partes interesadas.
Si no tienes una comprensión clara de estos requisitos desde el principio, tu

equipo corre el riesgo de perderse, dar prioridad a requisitos equivocados en
detrimento de otros o utilizar una cantidad ineficaz de recursos internos.
Obtén una mejor comprensión a través de imágenes. Sigue estos pasos para
trazar tus requisitos en una plataforma de creación de diagramas inteligente
como Lucidchart:
Comienza con una visión general: primero, haz un resumen breve de tus
requisitos con una “vista aérea”. Los mapas mentales son una forma eficaz de
hacer esto.
Haz un mapa de tus requisitos funcionales: puedes usar verbos para agrupar
sustantivos. Por ejemplo, verbos como “ver” y “editar” pueden vincular “cuenta”
o “perfil” entre sí en un mapa mental de áreas funcionales.
Ten en consideración los requisitos no funcionales: mientras trabajas en tu

mapa mental, puedes anotar tus requisitos no funcionales para utilizarlos más
adelante. Un requisito como “desempeño” es clave, pero probablemente sea
demasiado abstracto para colocarlo en el mapa mental.
Tus requisitos deben utilizarse para definir el alcance del trabajo y planear el
proyecto.
2. Comienza a pensar en cada componente
Seamos sinceros: con la poderosa influencia que tienen los requisitos

funcionales en tu proyecto, es posible que tus opciones de diseño y tecnología
ya estén decididas una vez que hayas definido tus requisitos.
Es necesario que averigües qué requisitos plantearán desafíos importantes

para tu diseño o plan de proyecto, sin adelantarte demasiado al pensar en la
implementación. Algunos requisitos pueden ser imposibles de cumplir bajo
ciertos supuestos u opciones.
Empieza con el “escenario perfecto”: ¿Cómo sería tu diseño si pudieras crearlo

de manera perfecta?
Considera y documenta qué implicaciones tienen tus requisitos: comienza a

elaborar un borrador de trabajo con tu equipo y desarróllalo gradualmente. En
primer lugar, debes observar lo que implican los requisitos en tu diseño; por
ejemplo, en qué aspectos los elementos individuales de la lista de deseos de
las partes interesadas pueden contradecirse entre sí o estar en conflicto con
otros requisitos funcionales y no funcionales.
Espera y realiza el diseño de la arquitectura final más adelante: lo más

probable es que hagas cambios en tu planeación a lo largo de este proceso,
así que no esperes que el primer borrador se parezca mucho al resultado final.
3. Divide tu arquitectura en “rebanadas”
Tu diseño de arquitectura, por supuesto, pasa a una fase de planeación a

medida que decides cómo vas a entregar tu diseño. Al dividir tu arquitectura en
rebanadas, puede resultar más fácil la elaboración de este plan, de tal manera
que proporcione beneficios a los usuarios y sirva para planear adecuadamente

tu uso de los recursos de desarrollo.
Para esto, es útil pensar en cómo se rebana un pastel. La mayoría de la gente

lo hace pasando el cuchillo por cada una de las capas. Digamos que una
rebanada completa tiene glaseado, relleno y dos o tres capas de bizcocho en
su interior. Esta rebanada vertical tiene un poco de todos los ingredientes. Un
pastel también puede rebanarse horizontalmente, separando cada una de las
capas.
De manera similar, si cada rebanada es un piso que se utiliza para planear la

arquitectura de tu software, entonces hay capas. Si rebanas el pastel
verticalmente, creas pisos enfocados en características individuales, mientras
que, si lo rebanas horizontalmente, se muestran los componentes individuales.
Necesitas tener una mentalidad tanto horizontal como vertical para tu proyecto.
Agile se enfoca en las rebanadas verticales, lo que permite a tu equipo ofrecer

beneficios rápidamente. Este enfoque permite a los clientes conocer con
rapidez el progreso del producto y al equipo de desarrollo recibir información
sobre cada una de las capas de una función. Una rebanada vertical de la
arquitectura de tu software para un sitio web de comercio electrónico podría ser
el proceso de pago.
En tu rebanada de pastel vertical de “proceso de pago”, puedes ver la capa de

datos que almacena la información del pago, la API de la capa intermedia y la
interfaz de usuario de la capa superior que ven los compradores. Con las
rebanadas verticales, puedes decidir qué funciones entregar y elegir piezas
iterativas.
Al hacer diagramas de las capas involucradas en tu proyecto de arquitectura

de software, puedes visualizar toda la pieza y cómo influye cada capa en otras
capas. A medida que elaboras tu plan, toma cada rebanada de pastel de Agile
y haz un diagrama de cómo se conectan las rebanadas entre sí.
4. Hacer un prototipo
Siempre crea un prototipo. Los prototipos te permiten descubrir fallas de forma

rápida y temprana, por lo que obtendrás retroalimentación con rapidez y podrás
descubrir tu prueba de concepto. Esta es una parte importante de la validación
de tu trabajo y de la comprobación de tus supuestos para asegurarte de que
sean válidos y minuciosos.
Al crear tu prototipo, recuerda que las primeras iteraciones nunca serán

perfectas y ninguna iteración final será completamente perfecta. Una de las
ventajas de la creación de prototipos es que no se presenta como un producto
acabado, y la mayoría de las personas inicia por instinto un proceso de
elaboración de prototipo esperando al menos encontrar algunas fallas.
Aprovecha la fase de elaboración del prototipo. Esto no sustituye a las

pruebas, pero es una parte crucial de las pruebas que deberás realizar.
Mantén un historial de cambios riguroso: por supuesto, si no documentas lo

que vas descubriendo en la creación de los prototipos, corres el riesgo de
repetir tus errores. Anota todo: documenta minuciosamente tus decisiones de
diseño y los cambios que realices sobre la marcha.
Ten una sola fuente de información: no será conveniente que tengas múltiples
cambios y diferentes versiones que frenen tu progreso, así que establece un
sólido control de versiones basadas en una única fuente de información para tu
documentación.
Haz diagramas de tus prototipos: puedes usar diagramas para ayudarte a

administrar los cambios de prototipos y visualizar las diferencias entre cada
versión.
5. Identifica y cuantifica los requisitos no funcionales
Además de los requisitos funcionales, deberás tener en cuenta los requisitos

no funcionales. Estos requisitos son tan importantes como tus requisitos
funcionales para el diseño porque definen las características del sistema.
Los requisitos no funcionales normalmente son los requisitos de calidad

general para todo el proyecto, pero no siempre. Es posible que tu sistema
tenga requisitos no funcionales específicos solo para una parte de tu
arquitectura de software. Por lo tanto, hay que estar preparados para incluir a
las partes interesadas en los requisitos locales no funcionales. Por ejemplo,

una rebanada vertical particular del proyecto puede interesar al equipo de
atención al cliente en especial, y ese equipo puede tener sus propias
expectativas sobre esos requisitos no funcionales.
Sin embargo, no es suficiente decir que deseas tener desempeño, portabilidad

o escalabilidad. Los requisitos no funcionales también deben cuantificarse.
Ningún proyecto puede tener un desempeño absolutamente perfecto: el
“desempeño” debe especificarse y delimitarse para cumplir con otros
requisitos.
Dado que tus requisitos no funcionales ocupan un lugar en la configuración de

tu diseño, no puedes evitar definirlos. A continuación, se detallan otros
requisitos que puedes tener en cuenta:
Desempeño: qué tan bien funciona todo tu sistema, así como las rebanadas o
capas individuales.
Escalabilidad: el potencial actual y futuro para escalar tu sistema junto con tus
necesidades.
Portabilidad: la portabilidad de tus datos, así como la posible portabilidad de los

componentes de tu sistema si procede o es necesario.
Extensibilidad: explica el crecimiento futuro de tu sistema y de tu empresa, la

capacidad de adaptación de tu sistema y el esfuerzo que conlleva la
adaptación.
Cumplimiento normativo: es otro factor esencial y que tiene un impacto

importante en el diseño general de tu proyecto.
Elaborar un diagrama de tus requisitos no funcionales puede ayudar a tu

equipo a ver cómo los cuantificas y, a la vez, coloca los requisitos específicos
en contextos relevantes. Aunque no tienes que preocuparte por optimizar todo
en este punto, también hay que considerar el esfuerzo y los recursos que
pueden ser necesarios para optimizar estos requisitos no funcionales más
adelante.
Prácticas recomendadas para el diseño de arquitectura de software
A medida que emprendes tu proyecto de diseño, estas prácticas

recomendadas te ayudarán a mantenerte fundamentado en buenos principios
de diseño.
Visualiza tu diseño
El uso de elementos visuales en todo tu trabajo conceptual de diseño, así

como en tu implementación, permite a tu equipo ver la perspectiva general en
la que se basa tu diseño. Los diagramas son una excelente forma de visualizar
procesos y diferentes aspectos de tus opciones de diseño.
No elijas patrones
Mantén tu proceso de diseño enfocado en el panorama general sin recurrir a

los patrones como punto de partida. En lugar de usar patrones, mantén un
nivel muy general con una visión de los componentes principales para reducir
el riesgo de tener una sobreingeniería de tus sistemas.
Recuerda que el primer diseño es solo la primera iteración.
Con tu primer diseño, tendrás una mejor idea de los desafíos y obstáculos
técnicos que enfrentarás en el desarrollo de tu arquitectura. No esperes que el
primer diseño sea algo más que un prototipo.
No te preocupes: tu diseño de arquitectura crecerá y se desarrollará, lo que te

permitirá descubrir más detalles con el tiempo.
Ten cuidado con el crecimiento excesivo del alcance
Si bien puede ser tentador permitir que se amplíe tu alcance, el crecimiento

excesivo sacrificaría tus otros requisitos y podría acabarse los recursos
necesarios. Para detener el crecimiento excesivo del alcance del proyecto,
establece un borrador del plan de proyecto de trabajo que justifique tus
requisitos y ten una conversación con las partes interesadas acerca de los
límites de los requisitos no funcionales. No sería conveniente que alguna
expectativa no cubierta afecte de forma negativa tu proyecto.
Ten presente los límites y las interfaces
Mientras planeas tu diseño, ten en cuenta las interfaces entre componentes e

identifica los límites de tu sistema. Comienza a asignar responsabilidades para
que, cuando trabajes en tus prototipos y en las próximas iteraciones, tengas
esta información a la mano a fin de facilitar su consulta.
Mejora el diseño de tu arquitectura de software ahora
El diseño de una arquitectura de software es más eficaz cuando existe un plan,

la aportación de las partes interesadas y el enfoque adecuado para esbozar los
requisitos del proyecto. No escatimes en esta planificación inicial y tus
esfuerzos se verán recompensados con una experiencia de proyecto más
fluida.
2.3 DISEÑO DE DATOS.
El diseño de datos consiste en descubrir y definir completamente los proceso y

características de los datos de la aplicación. Es un proceso de
perfeccionamiento gradual que abarca las situaciones más simples como por
ejemplo ¿Qué datos requieren la aplicación? ¿Cómo se accederán a esos
datos? ¿Cómo se almacenarán los datos? Si se logra un diseño de datos
bueno el acceso a los datos de la aplicación será rápido y fácil de mantener y
podrá aceptar sin problemas las futuras mejoras de los datos.
El diseño de datos se centra más que todo en el diseño de la estructura de la

base de datos y los archivos que van a ser usados por el sistema de
información en construcción.
Aunque en el diseñado de datos trataremos de cubrir todos los aspectos

fundamentales y necesarios para el diseño adecuado para almacenar,
mantener y recuperar datos es imposible precisar al inicio de un diseño cómo,
cuándo y dónde se van almacenar los datos, generalmente solo se puede
prever el uso de un motor de base de datos relacional.
Para un diseño de datos adecuado se debe incluir la identificación de datos, la

definición de datos, la integridad de datos, precauciones que se deben adoptar
al diseñar datos.
IDENTIFICACION DE DATOS.
Los datos nos permiten describir cosas, personas, productos, elementos,

clientes entre otras muchas cosas más que nos permiten realizar tareas de
clasificación por categorías, organización y mantenimiento.
La identificación de datos es un proceso iterativo que a medida que va iterando va

siendo más preciso y de alto nivel, esto permite adquirir más conocimiento sobre
los procesos previstos de la aplicación y hacerlos más fiables. Cuando
identificamos un dato generalmente se debe documentar la siguiente información:
nombre, descripción general (qué es), propiedad (quién es el responsable),
características (como se mide, que magnitud puede tener), relaciones, procesos y
eventos lógicos ( cómo y cuándo se crea, modifica y utiliza).
Es importante resaltar, los datos tienen muchas características diferentes y es

importante cuantificar cada uno de los datos con atributos medibles. Algunas
características típicas de los datos son las siguientes:
 Atributos de ubicación (dirección, país, lugar de almacenamiento).

 Atributos físicos (peso, dimensiones, volumen, color, material, textura).
 Atributos conceptuales (nombre, categoría, número de serie).

 Atributos relacionales (conjuntos formados por subconjuntos, escritores de
varios libros).
 Atributos de valor (moneda, disposición, consideración).
Es importante resaltar que no todos los datos deben ser incluidos en el

desarrollo web y está en nuestra habilidad como desarrolladores saber qué
vamos a documentar y qué características van a tener estos datos.
DEFINICION DE DATOS.
A medida que vamos identificando los datos y su estructura general a
través de las características de los datos podemos crear relaciones entre
ellos y diseñar un poco más nuestra base de datos aplicando lo que hemos
visto en cursos anteriores. Para definir los datos se debe realizar las
siguientes acciones:
DEFINIR TABLAS, FILAS Y COLUMNAS.
Independientemente de la forma en que se almacenan los datos en la
aplicación estos generalmente deben estar establecidos en tablas donde
por medio de conjuntos de atributos identificaremos al objeto o dato que
hacemos relación.
Por ejemplo un dato persona, contendrá los campos Nombre, Dirección y

Teléfono y un ID numérico.
INSERTAR CLAVES DE INDICE (LLAVES PRIMARIAS).
Para el ejemplo anterior la llave primaria o clave de índice sería el atributoHace

referencia a una característica especifica de un objeto, cosa o persona. o
campo Id el cual nos permite crear una relación con el objeto único persona, ya
sea Bernardo Ramírez o Isabel Díaz.
Una clave es un campo especial que proporciona un índice para la

recuperación de datos de forma rápida.
INSERTAR RELACIONES ENTRE TABLAS.
Atributos de un mismo dato se relaciona en una tabla y a su vez atributoHace

referencia a una característica especifica de un objeto, cosa o persona.s de
otras tablas se pueden relacionar con un atributo que sea único de una tabla,
por ejemplo, para la tabla personas, la clave de indice o llave primaría es Id,
esto nos permitirá relacionar por ejemplo, con otra tabla que fuera notas de la
persona. Tal cual como vimos en el curso de base de datos.
ASIGNAR TIPOS DE DATOS.
Por último nos queda solo asignar de forma adecuada los tipos de datos para
cada atributoHace referencia a una característica especifica de un objeto, cosa
o persona. del dato, por ejemplo, el atributo nombre de la tabla persona debe
ser de tipo texto ya que nadie se llama 1418523578. Estos tipos de datos
generalmente van muy relacionado al tipo de base de datos que usemos y
pueden cambiar sus características de un motor de base de datos a otro. Lo
importante a resaltar en esta etapa de diseño es recordar que el espacio de
almacenamiento es un recurso finito y que asignar el tipo de dato adecuada en
la fase de diseño nos permitirá optimizar y mantener de una forma más
adecuada nuestro software.
2.4 DISEÑO DE INTERFAZ DE USUARIO.
¿Qué es una interfaz de usuario?
Una interfaz de usuario es la presentación visual de la interacción entre un

dispositivo con software, producto o servicio, y un usuario. También llamado UI
(User Interface) transforma ciertas señales, imágenes, símbolos o acciones de
un sistema para hacerlas comprensibles al ser humano.
El objetivo de una buena interfaz es proporcionar una experiencia mas

eficiente, intuitiva, coordinada, simple y fácil de recordar.
Diseño de la interfaz de usuario UI.
Hay libros enteros hablando del diseño tecnológico adaptado al cliente,

imposible remarcarlo en un artículo, pero lo que sí vamos a ver y comprender,
son las bases. Primero, unas preguntas rápidas:
 ¿Quién es el diseñador UI? EL UI Designer como lo llaman en inglés, es

el encargado de crear un medio de comunicación eficaz entre el
software y el ser humano ¿cómo? por medio de unas reglas de diseño
de la interfaz.
 ¿Quién lo hace? El encargado de diseñar la interfaz de usuario es el
ingeniero del software que aplica a una serie de procesos y principios
predefinidos según un diseño UI.
 ¿Por qué es tan importante? Si estamos ante una herramienta difícil de
utilizar, forzamos al cliente a cometer errores para alcanzar una meta
determinada, entonces, no le gustará.
 ¿Cuál es el proceso del diseño de la interfaz de usuario? El método se
sustenta en base una correlación de diferentes elementos que se
necesitan mutuamente…
 ¿Cuál es el producto final? Se crea la coordinación visual por

medio de herramientas para hacer mockup, organigramas,
diagramas, etc. Aparece el prototipo de la interfaz que está
interactivo y activo.
REFERNCIAS.
https://prezi.com/p/3sfzfyx0fvwr/21-diseno-de-procesos-propuestos/
https://www.tutorialspoint.com/es/software_engineering/
case_tools_overview.htm
https://www.lucidchart.com/blog/es/como-disenar-una-arquitectura-de-
software#:~:text=El%20dise%C3%B1o%20de%20una
%20arquitectura,comenzar%20a%20elaborar%20un%20prototipo.
http://contenidos.sucerman.com/nivel4/desarrollo/unidad2/leccion2.html
https://ovacen.com/diseno-interfaz-usuario-ui/

Juan Luis Estrada Muñoz U2.docs

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Juan Luis Estrada Muñoz U2.docs

Cargado por

Copyright:

Formatos disponibles

TECNOLOGICO NACIONALE DE MEXICO

INSTITUTO TECNOLOGICO DE ZACATECAS

INVESTIGACION DE TEORIA 2: DISEÑO

JUAN LUIS ESTRADA MUÑOZ 19450169

I.S.C CINTHYA YERANIA CASAS RAMIREZ

Fecha elaboración: 28-02-2023

2.1.1 HERRAMIENTAS CASE PARA DISEÑO ………………………………7-14

2.2 DISEÑO ARQUITECTONICO ……………………………………………. 14-24

2.3 DISEÑO DE DATOS ………………………………………………………. 24-28

2.4 DISEÑO DE INTERFAZ DE USUARIO ………………………………….28-30

Fecha elaboración: 28-02-2023

2.1 DISEÑO DE PROCESOS PROPUESTOS.

DIMENSION DEL PROCESO.

La línea punteada indica la frontera entre los modelos de análisis y de diseño.

Fecha elaboración: 28-02-2023

EL PROCESO DEL DISEÑO.

IMPORTANCIA DEL SISEÑO DE SOFTWARE.

 Durante el diseño se toman decisiones que en ultima instancia afectaran el

FLUJO DURANTE EL DISEÑO DE SOFTWARE.

El trabajo de diseño es alimentado por el modelo de requerimientos,

Fecha elaboración: 28-02-2023

Transforma los modelos de clases en realizaciones de clases de diseño y en

Los objetos y relaciones definidos en el diagrama CRC y el contenido detallado

Define la relación entre los elementos principales de la estructura del software,

Fecha elaboración: 28-02-2023

Describe la forma en la que el software se comunica con los sistemas que

Los modelos de escenarios de uso y de comportamiento dan mucha de la

Transforma los elementos estructurales de la arquitectura del software en una

EL diseño de software agrupa el conjunto de principios, conceptos y practicas

El diseño de software se ubica en el área técnica de la ingeniería de software y

Fecha elaboración: 28-02-2023

2.1.1 HERRAMIENTAS CASE PARA DISEÑO.

Las siglas 'CASE' se refieren a Computer Aided Software Engineering

Las herramientas CASE son un conjunto de aplicaciones informáticas, usadas

Hay un gran número de Herramientas CASE disponibles para simplificar varias

El uso de Herramientas CASE acelera el desarrollo del proyecto con tal de

Componentes de las Herramientas CASE

Fecha elaboración: 28-02-2023

Las herramientas CASE se pueden dividir en las siguientes partes en base a a

Depósito central - Las herramientas CASE requieren un Depósito central, el

Fecha elaboración: 28-02-2023

Herramientas Upper CASE - Las Herramientas Upper CASE se usan en las

Herramientas Lower CASE - Las Herramientas Lower CASE se usan en la

Herramientas Integrated CASE - Las Herramientas Integrated CASE son de

La Herramientas CASE se pueden agrupar todas juntas si tienen una

Alcance de las herramientas CASE

Alcance de las herramientas CASE recorre el SDLC.

Tipos de Herramientas CASE

Ahora veremos de manera breve varios casos de herramientas CASE

Herramienta CASE Diagrama

Fecha elaboración: 28-02-2023

Estas herramientas se usan para representar componentes del sistema, datos,

Herramientas para modelado de procesos

El modelado de procesos es un método para crear modelos de proceso de

Herramientas de administración de procesos

Estas herramientas se usan para la planificación del proyecto, el coste y

Fecha elaboración: 28-02-2023

La documentación de un proyecto de software empieza antes que el proceso

Las Herramientas de documentación generan documentos tanto para el

Estas herramientas ayudan a cumplir con los requisitos, de manera automática

Estas herramientas ayudan a los diseñadores de software a crear la estructura

Fecha elaboración: 28-02-2023

los detalles de cada módulo y la interconexión presente entre estos. Un