El proceso de desarrollo de software incluye la asignación disciplinada de tareas y responsabilidades para asegurar la producción de software de calidad dentro de plazos y presupuestos predecibles. Esto implica definir quién realiza qué tareas, cuándo y cómo. El objetivo es desarrollar software que cumpla con los requisitos del usuario de manera eficiente.
Este documento describe los conceptos fundamentales del análisis y diseño orientado a objetos de un sistema de software. Explica brevemente el proceso de desarrollo de software, los casos de uso, el modelo conceptual y otros temas clave del análisis orientado a objetos. Además, utiliza un sistema de punto de venta como caso de estudio para ilustrar estos conceptos.
Este documento presenta los conceptos básicos de análisis y diseño orientado a objetos. Explica el proceso de desarrollo de software, incluyendo la definición de requisitos, casos de uso, modelo conceptual, diagramas de secuencia y colaboración. El objetivo es asegurar la producción de software de calidad dentro de plazos y presupuestos predecibles mediante un enfoque disciplinado.
Este documento presenta los contenidos de una unidad sobre diseño de sistemas. Incluye introducciones a temas como el proceso de diseño, principios de diseño, documentación de diseño, análisis y diseño orientados a objetos, modelos de dominio y casos de uso, y el lenguaje UML. También presenta un caso de estudio de ejemplo sobre un videoclub y los primeros artefactos de análisis requeridos como la presentación general del sistema, descripción de clientes, metas, funciones y atributos.
El documento describe los conceptos de modelado de procesos de negocios. Explica que un proceso de negocios es un conjunto estructurado de actividades diseñadas para producir un producto o servicio específico. Luego, detalla algunas características de los procesos como que pueden ser medidos y orientados al rendimiento. Finalmente, cubre temas como la reingeniería, administración y modelado de procesos de negocios, así como notaciones y objetivos del modelado.
10 Clase Captura De Los Requisitos Cap.6Julio Pari
Este documento describe los pasos para capturar los requisitos de un sistema de manera efectiva. Se necesitan modelos del dominio y del negocio para comprender el contexto del sistema. Los requisitos funcionales se capturan a través de casos de uso, mientras que los no funcionales se especifican por separado. El proceso iterativo permite actualizar los requisitos a lo largo del desarrollo del proyecto.
10 Clase Captura De Los Requisitos Cap[1].6Julio Pari
Este documento describe los pasos para capturar los requisitos de un sistema de manera efectiva. Se necesitan artefactos como un modelo de casos de uso, requisitos adicionales, modelos de dominio y de negocio. Los modelos de dominio y negocio ayudan a comprender el contexto mediante la identificación de objetos, procesos y actores. La captura de requisitos funcionales se basa en casos de uso, mientras que los no funcionales especifican propiedades como rendimiento y seguridad. El proceso iterativo permite actualizar los
Este documento presenta una introducción al análisis y diseño orientado a objetos. Explica brevemente los modelos de ciclo de vida, el análisis orientado a objetos, el diseño orientado a objetos y las notaciones utilizadas. Describe los modelos de ciclo de vida en cascada e iterativo-incremental, y explica conceptos clave del análisis como casos de uso, diagramas de clases y modelos basados en objetos y comportamiento. También cubre temas del diseño orientado a objetos como la separación entre el problema y la
Este documento presenta una introducción al análisis y diseño orientado a objetos. Explica brevemente los modelos de ciclo de vida, con énfasis en los ciclos iterativos e incrementales. Luego, describe las diferencias entre el análisis, que se centra en identificar los requisitos del problema, y el diseño, que se enfoca en cómo resolverlo. Finalmente, resume algunas técnicas clave de análisis orientado a objetos como casos de uso, diagramas de clases y secuencias.
Este documento describe los conceptos fundamentales del análisis y diseño orientado a objetos de un sistema de software. Explica brevemente el proceso de desarrollo de software, los casos de uso, el modelo conceptual y otros temas clave del análisis orientado a objetos. Además, utiliza un sistema de punto de venta como caso de estudio para ilustrar estos conceptos.
Este documento presenta los conceptos básicos de análisis y diseño orientado a objetos. Explica el proceso de desarrollo de software, incluyendo la definición de requisitos, casos de uso, modelo conceptual, diagramas de secuencia y colaboración. El objetivo es asegurar la producción de software de calidad dentro de plazos y presupuestos predecibles mediante un enfoque disciplinado.
Este documento presenta los contenidos de una unidad sobre diseño de sistemas. Incluye introducciones a temas como el proceso de diseño, principios de diseño, documentación de diseño, análisis y diseño orientados a objetos, modelos de dominio y casos de uso, y el lenguaje UML. También presenta un caso de estudio de ejemplo sobre un videoclub y los primeros artefactos de análisis requeridos como la presentación general del sistema, descripción de clientes, metas, funciones y atributos.
El documento describe los conceptos de modelado de procesos de negocios. Explica que un proceso de negocios es un conjunto estructurado de actividades diseñadas para producir un producto o servicio específico. Luego, detalla algunas características de los procesos como que pueden ser medidos y orientados al rendimiento. Finalmente, cubre temas como la reingeniería, administración y modelado de procesos de negocios, así como notaciones y objetivos del modelado.
10 Clase Captura De Los Requisitos Cap.6Julio Pari
Este documento describe los pasos para capturar los requisitos de un sistema de manera efectiva. Se necesitan modelos del dominio y del negocio para comprender el contexto del sistema. Los requisitos funcionales se capturan a través de casos de uso, mientras que los no funcionales se especifican por separado. El proceso iterativo permite actualizar los requisitos a lo largo del desarrollo del proyecto.
10 Clase Captura De Los Requisitos Cap[1].6Julio Pari
Este documento describe los pasos para capturar los requisitos de un sistema de manera efectiva. Se necesitan artefactos como un modelo de casos de uso, requisitos adicionales, modelos de dominio y de negocio. Los modelos de dominio y negocio ayudan a comprender el contexto mediante la identificación de objetos, procesos y actores. La captura de requisitos funcionales se basa en casos de uso, mientras que los no funcionales especifican propiedades como rendimiento y seguridad. El proceso iterativo permite actualizar los
Este documento presenta una introducción al análisis y diseño orientado a objetos. Explica brevemente los modelos de ciclo de vida, el análisis orientado a objetos, el diseño orientado a objetos y las notaciones utilizadas. Describe los modelos de ciclo de vida en cascada e iterativo-incremental, y explica conceptos clave del análisis como casos de uso, diagramas de clases y modelos basados en objetos y comportamiento. También cubre temas del diseño orientado a objetos como la separación entre el problema y la
Este documento presenta una introducción al análisis y diseño orientado a objetos. Explica brevemente los modelos de ciclo de vida, con énfasis en los ciclos iterativos e incrementales. Luego, describe las diferencias entre el análisis, que se centra en identificar los requisitos del problema, y el diseño, que se enfoca en cómo resolverlo. Finalmente, resume algunas técnicas clave de análisis orientado a objetos como casos de uso, diagramas de clases y secuencias.
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso RealesSergio Sanchez
El documento describe los contratos de operaciones en UML, incluyendo sus secciones, propósito y ejemplos. Explica que los contratos describen el comportamiento del sistema después de la ejecución de una operación y cómo las postcondiciones detallan los cambios en el estado de los objetos, como la creación, modificación de atributos y formación de asociaciones. También proporciona un ejemplo de contrato para la operación "IntroducirArticulo".
Este documento presenta información sobre modelado de procesos de negocios. Explica conceptos como procesos de negocios, características, reingeniería, administración de procesos de negocios y modelado. Detalla los objetivos, elementos, notaciones y beneficios del modelado de procesos. También describe diagramas de casos de uso, relaciones, documentación y diagramas de actividades como herramientas para el modelado.
Este documento presenta varios ejercicios relacionados con diagramas de casos de uso. El primer ejercicio consiste en indicar si varias afirmaciones sobre casos de uso son verdaderas o falsas. El segundo ejercicio analiza un diagrama de casos de uso existente. El tercer ejercicio pide corregir errores en otros diagramas. Los ejercicios 4 y 5 analizan la identificación de actores y casos de uso en diagramas específicos de sistemas de ventas. En general, el documento proporciona ejemplos y preguntas para practicar
1.Definir el problema-> Describir el problema de forma precisa y exacta.
2. Realizar un análisis de Requisitos-> En este paso se describen los requisitos que el sistema debe cumplir para satisfacer las necesidades del cliente o usuario. “La captura de requisitos es el proceso de averiguar, normalmente en circunstancias difíciles, lo que se debe construir, en otras palabras, lo que hará el sistema”.
3. Crear el modelo conceptual del dominio del problema-> En este paso se van a representar los conceptos más relevantes de las entrevistas, cuestionarios, observaciones, revisión documental, otros., realizadas para desarrollar el sistema.
4. Realizar Diseño de Sistema (Crear Arquitectura) -> en este paso se tiene el conjunto de diagramas UML que permiten modelar el problema y su solución. A continuación se mencionan los siguientes:
4.1 Diseño de Interfaces (E/S)
4.2 Diseño de Procesos:
Diagramas de Clases.
Diagramas de Secuencia.
Diagramas de Colaboración.
Diagramas de Actividad.
Diagramas de Estado.
4.3 Diseño de la Base de Datos
5. Evolución (Implantación)
Codificación
Documentación
Pruebas
Migración de Datos
Entretenimiento/Capacitacion
Costo del Sistema
6. Mantenimiento -> adaptación a nuevos requerimientos.
Este documento presenta el diseño de un sistema de facturación para una empresa de mantenimiento y repuestos de autos llamada REDICA DEL CENTRO C.A. El equipo de analistas describe el análisis de requisitos, el diseño de la interfaz, la arquitectura del sistema, el diseño de la base de datos y las pruebas del sistema. El objetivo del nuevo sistema es automatizar los procesos de facturación, registro de clientes y repuestos para mejorar la eficiencia y confiabilidad de la empresa.
Este documento presenta una introducción al desarrollo de casos de uso para sistemas de software orientados a objetos. Explica conceptos clave como actores, casos de uso, niveles de especificación de casos de uso, flujos normales y alternativos, y precondiciones y poscondiciones. Además, describe métodos para identificar casos de uso, priorizarlos y organizar el modelo general de casos de uso.
Gestion de administracion, planeacion y ciclo del desarrollo de sistemas de i...Maestros Online
Este documento ofrece servicios de asesoría y resolución de ejercicios en ciencias a través del correo electrónico ciencias_help@hotmail.com. Proporciona apoyo en diversas áreas como gestión de administración, planeación de sistemas de información, ejercicios de ciencias y servicio de asesoría. Los interesados pueden solicitar una cotización enviando un correo electrónico.
El documento explica por qué es importante modelar el negocio antes de modelar el sistema. Modelar el negocio permite entender claramente los procesos del negocio que se pretenden automatizar con el sistema. Se describen las principales actividades para modelar el negocio, como identificar los procesos clave, flujos de información, y volumen de datos. También se explican las herramientas clave para el modelado de negocio, como diagramas de casos de uso, diagramas de actividades, y diagramas de objetos de negocio. Modelar adecuadamente el neg
Este documento presenta una introducción a la modelación de casos de uso en UML. Explica que un caso de uso describe un comportamiento deseado del sistema desde la perspectiva de un actor y que incluye un flujo principal y variantes. También describe los componentes clave de un caso de uso como actores, pre y poscondiciones, y escenarios.
El documento presenta una introducción a la modelación de casos de uso en UML. Describe cómo los casos de uso especifican los requisitos funcionales del sistema desde la perspectiva de los actores, representando sus objetivos y las interacciones necesarias para alcanzarlos. Incluye ejemplos de elementos clave como actores, flujos principales y alternativos, y las relaciones entre casos de uso.
Este documento presenta una introducción a la modelación de casos de uso en UML. Explica que un caso de uso describe un comportamiento deseado del sistema desde la perspectiva de un actor. Incluye ejemplos de partes de un caso de uso como actores, flujos principales y alternativos. También cubre temas como relaciones entre casos de uso, escenarios y colaboraciones.
Este documento presenta una guía sobre la fase de planificación y elaboración de requerimientos en el desarrollo de software. Incluye temas como la especificación de requerimientos, casos de uso, análisis orientado a objetos, y ejemplos de cómo documentar un sistema de punto de venta. El objetivo principal es crear artefactos como especificaciones funcionales para identificar y clasificar las funciones del sistema y sus atributos.
Este documento presenta una aplicación de subastas en línea como ejemplo para ilustrar técnicas avanzadas de desarrollo de aplicaciones Java. Primero, describe el proceso de determinar los requisitos del proyecto a través de entrevistas con usuarios y la creación de un modelo. Luego, explica los componentes clave de la aplicación de subastas, incluido el registro de compradores y vendedores, la publicación y puja de artículos, y la notificación de resultados de subastas. Finalmente, proporciona un diagrama de
modelado casos de uso analisis y diseñooBereGarita
Este documento presenta el modelado de casos de uso con UML. Explica que los casos de uso especifican el comportamiento deseado del sistema desde la perspectiva de los actores y que representan los requisitos funcionales. Describe los componentes de un caso de uso como las secuencias de acciones, actores, variantes y objetivos tangibles. También cubre temas como la descripción textual y gráfica de casos de uso, las relaciones entre ellos, y cómo se obtienen y organizan los requisitos funcionales del sistema a través de este enfoque.
Este documento presenta el Lenguaje Unificado de Modelado (UML) y cómo se pueden usar los diagramas de casos de uso y clases para modelar los requisitos funcionales de un sistema. Explica qué son los casos de uso, cómo se describen y relacionan, e incluye ejemplos de diagramas y descripciones de casos de uso.
Este documento presenta el Lenguaje Unificado de Modelado (UML) y cómo se pueden usar los diagramas de casos de uso y clases para modelar los requisitos funcionales de un sistema. Explica cómo los casos de uso describen el comportamiento deseado del sistema desde la perspectiva de los actores y cómo los diagramas de clases modelan la estructura del sistema.
Este documento define y explica conceptos fundamentales relacionados con algoritmos, incluyendo: qué es un algoritmo, sus partes y características; tipos de algoritmos; pseudocódigo y cómo crearlo; y diagramas de flujo. Define un algoritmo como una serie de pasos secuenciales para resolver un problema. Explica que los algoritmos tienen entrada, proceso y salida, y provee ejemplos de cada concepto.
El documento describe el ciclo de vida tradicional del sistema conocido como modelo cascada. Este modelo sigue un enfoque secuencial de desarrollo que comienza con la ingeniería del sistema y progresa a través de requisitos, análisis, diseño, construcción, implementación y mantenimiento. En cada fase se especifican conceptos, diagramas UML, herramientas y procesos principales.
El documento presenta las distintas etapas del desarrollo de programas, incluyendo el análisis y especificación del problema, el diseño del algoritmo, la codificación, la verificación y validación, y el mantenimiento. Explica cada etapa en detalle con ejemplos. También incluye actividades para practicar los conceptos aprendidos.
El documento presenta las distintas etapas del desarrollo de programas, incluyendo el análisis y especificación del problema, el diseño del algoritmo, la codificación, la verificación y validación, y el mantenimiento. Explica cada etapa en detalle con ejemplos. También incluye actividades para aplicar los conceptos aprendidos.
Los puentes son estructuras esenciales en la infraestructura de transporte, permitiendo la conexión entre diferentes
puntos geográficos y facilitando el flujo de bienes y personas.
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso RealesSergio Sanchez
El documento describe los contratos de operaciones en UML, incluyendo sus secciones, propósito y ejemplos. Explica que los contratos describen el comportamiento del sistema después de la ejecución de una operación y cómo las postcondiciones detallan los cambios en el estado de los objetos, como la creación, modificación de atributos y formación de asociaciones. También proporciona un ejemplo de contrato para la operación "IntroducirArticulo".
Este documento presenta información sobre modelado de procesos de negocios. Explica conceptos como procesos de negocios, características, reingeniería, administración de procesos de negocios y modelado. Detalla los objetivos, elementos, notaciones y beneficios del modelado de procesos. También describe diagramas de casos de uso, relaciones, documentación y diagramas de actividades como herramientas para el modelado.
Este documento presenta varios ejercicios relacionados con diagramas de casos de uso. El primer ejercicio consiste en indicar si varias afirmaciones sobre casos de uso son verdaderas o falsas. El segundo ejercicio analiza un diagrama de casos de uso existente. El tercer ejercicio pide corregir errores en otros diagramas. Los ejercicios 4 y 5 analizan la identificación de actores y casos de uso en diagramas específicos de sistemas de ventas. En general, el documento proporciona ejemplos y preguntas para practicar
1.Definir el problema-> Describir el problema de forma precisa y exacta.
2. Realizar un análisis de Requisitos-> En este paso se describen los requisitos que el sistema debe cumplir para satisfacer las necesidades del cliente o usuario. “La captura de requisitos es el proceso de averiguar, normalmente en circunstancias difíciles, lo que se debe construir, en otras palabras, lo que hará el sistema”.
3. Crear el modelo conceptual del dominio del problema-> En este paso se van a representar los conceptos más relevantes de las entrevistas, cuestionarios, observaciones, revisión documental, otros., realizadas para desarrollar el sistema.
4. Realizar Diseño de Sistema (Crear Arquitectura) -> en este paso se tiene el conjunto de diagramas UML que permiten modelar el problema y su solución. A continuación se mencionan los siguientes:
4.1 Diseño de Interfaces (E/S)
4.2 Diseño de Procesos:
Diagramas de Clases.
Diagramas de Secuencia.
Diagramas de Colaboración.
Diagramas de Actividad.
Diagramas de Estado.
4.3 Diseño de la Base de Datos
5. Evolución (Implantación)
Codificación
Documentación
Pruebas
Migración de Datos
Entretenimiento/Capacitacion
Costo del Sistema
6. Mantenimiento -> adaptación a nuevos requerimientos.
Este documento presenta el diseño de un sistema de facturación para una empresa de mantenimiento y repuestos de autos llamada REDICA DEL CENTRO C.A. El equipo de analistas describe el análisis de requisitos, el diseño de la interfaz, la arquitectura del sistema, el diseño de la base de datos y las pruebas del sistema. El objetivo del nuevo sistema es automatizar los procesos de facturación, registro de clientes y repuestos para mejorar la eficiencia y confiabilidad de la empresa.
Este documento presenta una introducción al desarrollo de casos de uso para sistemas de software orientados a objetos. Explica conceptos clave como actores, casos de uso, niveles de especificación de casos de uso, flujos normales y alternativos, y precondiciones y poscondiciones. Además, describe métodos para identificar casos de uso, priorizarlos y organizar el modelo general de casos de uso.
Gestion de administracion, planeacion y ciclo del desarrollo de sistemas de i...Maestros Online
Este documento ofrece servicios de asesoría y resolución de ejercicios en ciencias a través del correo electrónico ciencias_help@hotmail.com. Proporciona apoyo en diversas áreas como gestión de administración, planeación de sistemas de información, ejercicios de ciencias y servicio de asesoría. Los interesados pueden solicitar una cotización enviando un correo electrónico.
El documento explica por qué es importante modelar el negocio antes de modelar el sistema. Modelar el negocio permite entender claramente los procesos del negocio que se pretenden automatizar con el sistema. Se describen las principales actividades para modelar el negocio, como identificar los procesos clave, flujos de información, y volumen de datos. También se explican las herramientas clave para el modelado de negocio, como diagramas de casos de uso, diagramas de actividades, y diagramas de objetos de negocio. Modelar adecuadamente el neg
Este documento presenta una introducción a la modelación de casos de uso en UML. Explica que un caso de uso describe un comportamiento deseado del sistema desde la perspectiva de un actor y que incluye un flujo principal y variantes. También describe los componentes clave de un caso de uso como actores, pre y poscondiciones, y escenarios.
El documento presenta una introducción a la modelación de casos de uso en UML. Describe cómo los casos de uso especifican los requisitos funcionales del sistema desde la perspectiva de los actores, representando sus objetivos y las interacciones necesarias para alcanzarlos. Incluye ejemplos de elementos clave como actores, flujos principales y alternativos, y las relaciones entre casos de uso.
Este documento presenta una introducción a la modelación de casos de uso en UML. Explica que un caso de uso describe un comportamiento deseado del sistema desde la perspectiva de un actor. Incluye ejemplos de partes de un caso de uso como actores, flujos principales y alternativos. También cubre temas como relaciones entre casos de uso, escenarios y colaboraciones.
Este documento presenta una guía sobre la fase de planificación y elaboración de requerimientos en el desarrollo de software. Incluye temas como la especificación de requerimientos, casos de uso, análisis orientado a objetos, y ejemplos de cómo documentar un sistema de punto de venta. El objetivo principal es crear artefactos como especificaciones funcionales para identificar y clasificar las funciones del sistema y sus atributos.
Este documento presenta una aplicación de subastas en línea como ejemplo para ilustrar técnicas avanzadas de desarrollo de aplicaciones Java. Primero, describe el proceso de determinar los requisitos del proyecto a través de entrevistas con usuarios y la creación de un modelo. Luego, explica los componentes clave de la aplicación de subastas, incluido el registro de compradores y vendedores, la publicación y puja de artículos, y la notificación de resultados de subastas. Finalmente, proporciona un diagrama de
modelado casos de uso analisis y diseñooBereGarita
Este documento presenta el modelado de casos de uso con UML. Explica que los casos de uso especifican el comportamiento deseado del sistema desde la perspectiva de los actores y que representan los requisitos funcionales. Describe los componentes de un caso de uso como las secuencias de acciones, actores, variantes y objetivos tangibles. También cubre temas como la descripción textual y gráfica de casos de uso, las relaciones entre ellos, y cómo se obtienen y organizan los requisitos funcionales del sistema a través de este enfoque.
Este documento presenta el Lenguaje Unificado de Modelado (UML) y cómo se pueden usar los diagramas de casos de uso y clases para modelar los requisitos funcionales de un sistema. Explica qué son los casos de uso, cómo se describen y relacionan, e incluye ejemplos de diagramas y descripciones de casos de uso.
Este documento presenta el Lenguaje Unificado de Modelado (UML) y cómo se pueden usar los diagramas de casos de uso y clases para modelar los requisitos funcionales de un sistema. Explica cómo los casos de uso describen el comportamiento deseado del sistema desde la perspectiva de los actores y cómo los diagramas de clases modelan la estructura del sistema.
Este documento define y explica conceptos fundamentales relacionados con algoritmos, incluyendo: qué es un algoritmo, sus partes y características; tipos de algoritmos; pseudocódigo y cómo crearlo; y diagramas de flujo. Define un algoritmo como una serie de pasos secuenciales para resolver un problema. Explica que los algoritmos tienen entrada, proceso y salida, y provee ejemplos de cada concepto.
El documento describe el ciclo de vida tradicional del sistema conocido como modelo cascada. Este modelo sigue un enfoque secuencial de desarrollo que comienza con la ingeniería del sistema y progresa a través de requisitos, análisis, diseño, construcción, implementación y mantenimiento. En cada fase se especifican conceptos, diagramas UML, herramientas y procesos principales.
El documento presenta las distintas etapas del desarrollo de programas, incluyendo el análisis y especificación del problema, el diseño del algoritmo, la codificación, la verificación y validación, y el mantenimiento. Explica cada etapa en detalle con ejemplos. También incluye actividades para practicar los conceptos aprendidos.
El documento presenta las distintas etapas del desarrollo de programas, incluyendo el análisis y especificación del problema, el diseño del algoritmo, la codificación, la verificación y validación, y el mantenimiento. Explica cada etapa en detalle con ejemplos. También incluye actividades para aplicar los conceptos aprendidos.
Los puentes son estructuras esenciales en la infraestructura de transporte, permitiendo la conexión entre diferentes
puntos geográficos y facilitando el flujo de bienes y personas.
Equipo 4. Mezclado de Polímeros quimica de polimeros.pptxangiepalacios6170
Presentacion de mezclado de polimeros, de la materia de Quimica de Polímeros ultima unidad. Se describe la definición y los tipos de mezclado asi como los aditivos usados para mejorar las propiedades de las mezclas de polimeros
La energía radiante es una forma de energía que
se transmite en forma de ondas
electromagnéticas esta energía se propaga a
través del vacío y de ciertos medios materiales y
es fundamental en una variedad naturales y
tecnológicos
ESPERAMOS QUE ESTA INFOGRAFÍA SEA UNA HERRAMIENTA ÚTIL Y EDUCATIVA QUE INSPIRE A MÁS PERSONAS A ADENTRARSE EN EL APASIONANTE CAMPO DE LA INGENIERÍA CIVIŁ. ¡ACOMPAÑANOS EN ESTE VIAJE DE APRENDIZAJE Y DESCUBRIMIENTO
1. • Proceso de desarrollo de software:
– Forma disciplinada de asignar tareas y responsabilidades en una
empresa de desarrollo (quién hace qué, cuándo y cómo).
• Objetivos:
– Asegurar la producción de software de calidad dentro de plazos
y presupuestos predecibles.
Requisitos del usuario Sistema de software
Proceso de desarrollo
de software
Introducción
2. Introducción
Ejemplo: Un juego de dados.
Se tiene un juego de dados en que un jugador lanza dos dados. Si el total
obtenido es siete, el jugador gana, en caso contrario pierde.
3. Introducción
1. Definición de casos de uso
Los casos de uso son descripciones narrativas en lenguaje natural de los procesos del
dominio en un formato estructurado de prosa. Describen una secuencia de acciones.
Caso de uso: Jugar un juego.
Participantes: Jugador.
Descripción: Este caso de uso comienza
cuando el jugador recoge y lanza los dados.
Si los puntos suman siete, gana y pierde si
suman cualquier otro número.
4. Introducción
2. Definición de un modelo conceptual
Un modelo conceptual muestra gráficamente los conceptos (clases de objetos),
los atributos y las asociaciones más importantes del dominio del problema.
Supongamos que queremos hacer una simulación del juego de dados:
5. Introducción
3. Definición de los diagramas de colaboración
Los diagramas de colaboración representan el flujo de mensajes entre las
instancias y la invocación de métodos.
6. Introducción
4. Definición del diagrama de diseño de clases
¿Cómo se relacionan unos objetos con otros?, ¿cuáles son las características
(métodos y atributos) de cada clase?
7. Introducción
5. Codificación
Escritura del código en un lenguaje orientado a objetos.
class JuegodeDados {
String Nombre;
class Jugador {
String nombre;
public Jugador(String nombre) {
this.nombre = nombre;
}
public jugar(Dado d1,d2);
int dado1 = d1.lanzar();
int dado2 = d2.lanzar();
}
}
public void Dado(){
int ValorMostrado;
public Dado {
this.ValorMostrado = 0;
}
public lanzar();
this.ValorMostrado = Math.random(1,6);
}
} ...
8. Introducción
Proceso de desarrollo de software
Planificación Construcción Aplicación
Ciclo de Ciclo de . . .
desarrollo 1 desarrollo 2
Perfeccionar
plan
Análisis Diseño Construcción Pruebas
De dos semanas a dos meses
9. Introducción
Proceso de desarrollo de software
Ciclo de Ciclo de Ciclo de . . .
desarrollo 1 desarrollo 2 desarrollo 3
Caso de uso A:
Versión
simplificada
-------
-------
Caso de uso A:
Versión
completa
-------
-------
Caso de uso B
-------
-------
-------
-------
Caso de uso C
-------
-------
-------
-------
10. Introducción
Proceso de desarrollo de software
Planificación Construcción Aplicación
Ciclo de Ciclo de . . .
desarrollo 1 desarrollo 2
Perfeccionar
plan
Análisis Diseño Construcción Pruebas
De dos semanas a dos meses
11. Análisis y Diseño OO
Perfeccionar
plan
Análisis Diseño Construcción Pruebas
Definir los
requisitos
Definir los casos
esenciales de uso
Crear diagramas
de casos de uso
Crear modelo
conceptual
Crear el
glosario
Definir diag.
de secuencia
Definir los
contratos
Algunas de las tareas a realizarse en la etapa de análisis
(dominio del problema) son las siguientes:
12. Análisis y Diseño OO
Perfeccionar
plan
Análisis Diseño Construcción Pruebas
Definir casos
reales de uso
Definir reportes,
interfaz de usuario,
secuencia de pantallas
Perfeccionar la
arquitectura
Definir diag.
de interacción
Definir diagramas
diseño de clases
Definir esquema
base de datos
Algunas de las tareas a realizarse en la etapa de diseño
(dominio de la solución) son las siguientes:
13. Caso de estudio
Caso de estudio: punto de venta
Supongamos como caso de estudio el sistema de una terminal
de punto de venta. Esta terminal es un sistema automatizado
con el que se registran las ventas y se realizan los pagos.
Por lo general este tipo de sistemas comprenden hardware (un
computador y un lector de código barras) y software (el sistema
que se ejecuta en la terminal).
14. Requisitos
Los requisitos
Los requisitos son una descripción de las necesidades
o deseos de un producto.
Se recomienda aquí definir al menos los siguientes puntos:
· Panorama general
· Metas
· Funciones del sistema
15. a) Panorama general
Este proyecto tiene por objeto crear un sistema de terminal para
el punto de venta que se utilizará en las ventas de un supermercado.
b) Metas
En términos generales, la meta es una mayor automatización del
pago en las cajas registradoras, y dar soporte a servicios más
rápidos, más baratos y mejores. Concretamente, la meta incluye:
· Pago rápido de los clientes.
· Análisis rápido y exacto de las ventas.
· Control automático del inventario.
Requisitos
16. c) Funciones del sistema
Las funciones del sistema son lo que éste deberá de hacer.
Las funciones pueden clasificarse en tres categorías: evidentes,
ocultas y superfluas. Las evidentes deben realizarse, y el usuario
debe saber que se han realizado. Las ocultas también deben
realizarse, y puede que no sean visibles para el usuario. Las
superfluas son opcionales, y su inclusión no repercute significati-
vamente en el costo ni en otras funciones.
Requisitos
17. Estas son algunas de las funciones del sistema de punto de venta:
Ref. Función Categoría
R1.1 Registra la venta en proceso (actual): los productos comprados. evidente
R1.2 Calcula el total de la venta actual; se incluye el impuesto. evidente
R1.3 Captura la información sobre el objeto comprado usando su código
de barras, o usando una captura manual del código de producto. evidente
R1.4 Reduce las cantidades del inventario cuando se realiza una venta. oculta
R1.5 Se registran las ventas efectuadas. oculta
R1.6 El cajero debe introducir una identificación y una contraseña para
poder utilizar el sistema. evidente
R1.7 Ofrece un mecanismo de almacenamiento persistente. oculta
R1.8 Ofrece mecanismos de comunicación entre los procesos y entre
los sistemas. oculta
R1.9 Muestra la descripción y el precio del producto registrado. evidente
Requisitos
18. Casos de uso
Los casos de uso requieren tener al menos un conocimiento parcial
de los requerimientos del sistema. Un caso de uso es un documento
narrativo que describe la secuencia de eventos de un actor (agente
externo) que utiliza un sistema para completar un proceso.
Casos de uso
19. El formato para la descripción de los casos de uso es el siguiente:
Caso de uso: Nombre
Actores: Lista de actores (agentes externos)
Propósito: Intención del caso de uso
Resumen: Repetición del caso de uso de alto nivel o alguna síntesis.
Tipo: Primario, secundario u opcional. Esencial o real.
Referencias
cruzadas: Casos de uso relacionados y funciones relacionadas del sistema.
Descripción: Descripción del caso de uso.
Casos de uso
20. Ejemplo: el siguiente caso de uso describe el proceso de comprar
artículos en una tienda, a través de un terminal de punto de venta.
Caso de uso: Comprar productos
Actores: Cliente, cajero
Tipo: Primario
Descripción: Un Cliente llega a la caja registradora con los artículos
que va a comprar. El Cajero registra los artículos y cobra
el importe. Al terminar la operación, el Cliente se marcha
con los productos.
Es conveniente comenzar con los casos de uso de más alto nivel para
lograr comprender mejor los principales procesos globales.
Casos de uso
21. Diagrama UML de casos de uso para el sistema de punto de venta:
Este esquema tiene por objeto ofrecer un diagrama contextual que nos
permita conocer rápidamente los actores externos de un sistema y las formas
básicas en que éstos lo utilizan.
Casos de uso
22. Un diagrama de casos
de uso más refinado
seria el siguiente:
Casos de uso
23. Modelo conceptual
Un modelo conceptual explica los conceptos significativos en un
dominio del problema, identificando los atributos y las asociaciones,
y es la herramienta más importante del análisis orientado a objetos.
Los casos de uso son una importante herramienta para el análisis de
requerimientos, pero realmente no están orientados a objetos. Un
modelo conceptual representa cosas del mundo real, no componentes
del software. En los diagramas UML se muestran conceptos (objetos),
asociaciones entre conceptos (relaciones) y atributos de conceptos
(atributos).
Modelo conceptual
24. La siguiente figura muestra un modelo conceptual parcial del
dominio de la tienda y las ventas.
Modelo conceptual
25. Modelo conceptual
La siguiente lista muestra un conjunto de conceptos idóneos para ser
incluidos en el modelo conceptual.
Objetos físicos o tangibles
Especificaciones, diseño o descripciones de cosas
Lugares
Transacciones
Línea o renglón de un elemento de transacciones
Rol de las personas
Contenedores de otras cosas
Cosas dentro de un contenedor
Otros sistemas de cómputo o electromecánicos externos al sistema
Organizaciones
Eventos
Procesos
Reglas y políticas
Catálogos
Registros de finanzas, de trabajo, de contratos, de asuntos legales
Instrumentos y servicios financieros
Manuales y libros
26. A partir de esta lista de categorías de conceptos podemos generar
un conjunto de conceptos para nuestro problema del punto de venta:
TDPV EspecificaciondeProducto
Producto VentasLineadeProductos
Tienda Cajero
Venta Cliente
Pago Gerente
CatalogodeProductos
Modelo conceptual
27. Por tanto, el modelo conceptual inicial del sistema de punto
de venta (sin incluir atributos ni asociaciones) sería:
Modelo conceptual
28. Asociaciones
Una asociación es una relación entre dos conceptos que indica
alguna conexión significativa entre ellos. Las asociaciones útiles
a determinar, suelen incluir el conocimiento de una relación que
ha de preservarse por algún tiempo: puede tratarse de milisegundos
o de años (según el contexto). Por ejemplo, ¿debemos recordar
cuales instancias de VentasLineadeProducto están asociadas a
Venta? Si, porque de lo contrario no sería posible reconstruir la venta,
imprimir la boleta ni calcular el total de la venta.
Modelo conceptual
29. Para identificar las asociaciones más comunes, la siguiente lista
es de gran ayuda.
A es una parte física o lógica de B
A está lógica o físicamente contenido en B
A es una descripción de B
A es un elemento de línea (o renglón) en una transacción o reporte B
A se conoce/introduce/registra/presenta/captura en B
A es miembro de B
A es una unidad organizacional de B
A usa o dirige a B
A se comunica con B
A se relaciona con una transacción B
A es una transacción relacionada con otra transacción B
A es propiedad de B
Modelo conceptual
30. La multiplicidad define cuántas instancias de un tipo A pueden asociarse
a una instancia del tipo B en determinado momento. Las expresiones de
multiplicidad son las siguientes:
* cero o más, muchos
1..* uno o más
1..40 de uno a cuarenta
5 exactamente cinco
2,4,6 exactamente dos, cuatro o seis
Por ejemplo:
Modelo conceptual
31. Los nombres de las asociaciones deben ser lo más claros posibles, y deben
permitir leer y entender fácilmente las relaciones entre conceptos. Por ej.:
Modelo conceptual
33. Diagramas de secuencia
El diagrama de secuencia de un sistema muestra gráficamente los
eventos que originan los actores y que impactan al sistema.
La creación de los diagramas de secuencia depende de la formulación
de los casos de uso.
Durante la operación del sistema, los actores generan eventos,
solicitando alguna operación a cambio. Ejemplo: cuando un cajero
ingresa un código de barras de un artículo, está pidiendo al sistema de
TPV que registre esa compra. Con este evento se inicia una operación
en el sistema.
34. Antes de hacer el diseño lógico de la aplicación de software,
es conveniente investigar y definir su comportamiento como
una "caja negra".
Se estudia el comportamiento del sistema, desde la
perspectiva de qué es lo que hace, y no de cómo lo hace.
Diagramas de secuencia
Definición: El diagrama de secuencia de un sistema es una
representación que muestra, en determinado escenario de un
caso de uso, los eventos generados por actores externos, su
orden y los eventos internos del sistema. En esta fase del
proyecto, el sistema mismo es una caja negra.
35. Recordemos el caso de uso Comprar productos:
Caso de uso: Comprar productos
Actores: Cliente, cajero
Tipo: Primario
Descripción: Un Cliente llega a la caja registradora con los artículos que va a
comprar. El Cajero registra los artículos y cobra el importe. Al
terminar la operación, el Cliente se marcha con los productos.
Diagramas de secuencia
36. El diagrama de secuencia del caso de uso ComprarProductos
podría ser el siguiente:
Diagramas de secuencia
37. Análisis y Diseño OO
Las herramientas usadas en la etapa de análisis (investigación
del problema) se pueden resumir en la siguiente tabla.
Herramienta de análisis Preguntas que contesta
Casos de uso ¿Cuáles son los procesos del dominio?
Modelo conceptual ¿Cuáles son los conceptos, los términos?
Diagramas de secuencia ¿Cuáles son los eventos y las operac. del sistema?
38. Diagramas de colaboración
Diagramas de colaboración
Los diagramas de interacción (diagramas de secuencia y diagramas
de colaboración) explican gráficamente cómo los objetos interactúan
a través de mensajes para realizar las tareas.
Antes de definir estos diagramas, hay que generar el modelo
conceptual y los casos de uso reales (estos últimos se generan a
partir de los casos de uso definidos en el análisis).
39. Diagramas de colaboración
Los diagramas de colaboración explican gráficamente las interacciones
entre las instancias del modelo (objetos). Por ejemplo:
40. Diseño de la solución
Para cada evento del sistema se debe construir un diagrama
de colaboración cuyo mensaje inicial sea el de sus eventos.
En el caso del punto de venta, tendremos tres diagramas,
uno para cada evento: pasarProducto, terminarVenta, y
efectuarPago.
Diagramas de colaboración
41. El diagrama de colaboración del caso de uso pasarProducto sería
el siguiente:
Diagramas de colaboración
44. Nombre: Modelo-Vista-Controlador (MVC) [Buschmann 96].
Problema: Las interfaces de usuario son especialmente propensas a
cambios de requerimientos. Cuando se extiende la funcionalidad de una
aplicación, se deben modificar cosas, por ejemplo: menús, botones,
ventanas, etc.
Solución: MVC divide una aplicación en tres áreas: procesamiento, entrada
y salida. El componente modelo encapsula los datos y la funcionalidad
principales de la aplicación. El componente Vista despliega la información al
usuario, a partir de los datos del Modelo. Cada Vista tiene un componente
Controlador asociado, que se encarga de recibir las entradas del usuario
(movimiento del mouse, activación de los botones o entradas de teclado).
Esta separación de componentes, permite, entre otras cosas, tener distintas
vistas del mismo modelo.
Análisis y Diseño OO
45. Ejemplo: La mayoría de aplicaciones con interfaz gráfica utilizan este
esquema. La programación con herramientas visuales como Visual Basic,
JBuilder, Delphi, etc. sigue este esquema.
Beneficios: Es posible tener múltiples vistas de un mismo modelo. Es
posible sincronizar las vistas cuando varios usuarios usan la misma
aplicación (juegos multiusuario, sistemas colaborativos, etc). La separación
conceptual permite intercambiar la vista y el controlador de un determinado
modelo (plug and play).
Análisis y Diseño OO
46. Análisis y Diseño OO
El patrón MVC separa dos conceptos fundamentales en toda
aplicación: la interfaz (vista y controlador) y el modelo (datos y
funcionalidad).
Usando este patrón podríamos implementar la interfaz de nuestra
aplicación de punto de venta como un applet Java, como un programa
Java stand-alone, y de otras formas (no necesariamente en Java).