Wondershare EdrawMind
Galería de mapas mentales Análisis de sistemas de información y diseño de mapas mentales.
- 2
Análisis de sistemas de información y diseño de mapas mentales.
Este es un mapa mental sobre el análisis y diseño de sistemas de información, que incluye análisis del sistema y descripción general del diseño, encuesta de requisitos del sistema, casos de uso, modelo de dominio, etc.
Editado a las 2023-11-14 10:01:51,
- プロジェクト管理プロセステンプレート
プロジェクトマネジメントとは、専門的な知識、スキル、ツール、方法論をプロジェクト活動に適用し、限られたリソースの制約の中で、プロジェクトが設定された要件や期待を達成、またはそれ以上にできるようにするプロセスである。 この図は、プロジェクトマネジメントプロセスの8つの構成要素を包括的に示したものであり、一般的なテンプレートとして利用することができる。
- プロジェクト管理プロセステンプレート
プロジェクトマネジメントとは、専門的な知識、スキル、ツール、方法論をプロジェクト活動に適用し、限られたリソースの制約の中で、プロジェクトが設定された要件や期待を達成、またはそれ以上にできるようにするプロセスである。 この図は、プロジェクトマネジメントプロセスの8つの構成要素を包括的に示したものであり、一般的なテンプレートとして利用することができる。
- 科学者-銭雪仙
世界的に著名な科学者、航空力学者、中国有人宇宙飛行の創始者、中国科学院および中国工程院の院士、「二元一星勲章」受章者、「中国宇宙飛行の父」、「中国ミサイルの父」、「中国自動制御の父」、「ロケットの王」として知られる。 中国宇宙の父」、「中国ミサイルの父」、「中国自動制御の父」、「ロケット王」として知られる。
Análisis de sistemas de información y diseño de mapas mentales.
- プロジェクト管理プロセステンプレート
プロジェクトマネジメントとは、専門的な知識、スキル、ツール、方法論をプロジェクト活動に適用し、限られたリソースの制約の中で、プロジェクトが設定された要件や期待を達成、またはそれ以上にできるようにするプロセスである。 この図は、プロジェクトマネジメントプロセスの8つの構成要素を包括的に示したものであり、一般的なテンプレートとして利用することができる。
- プロジェクト管理プロセステンプレート
プロジェクトマネジメントとは、専門的な知識、スキル、ツール、方法論をプロジェクト活動に適用し、限られたリソースの制約の中で、プロジェクトが設定された要件や期待を達成、またはそれ以上にできるようにするプロセスである。 この図は、プロジェクトマネジメントプロセスの8つの構成要素を包括的に示したものであり、一般的なテンプレートとして利用することができる。
- 科学者-銭雪仙
世界的に著名な科学者、航空力学者、中国有人宇宙飛行の創始者、中国科学院および中国工程院の院士、「二元一星勲章」受章者、「中国宇宙飛行の父」、「中国ミサイルの父」、「中国自動制御の父」、「ロケットの王」として知られる。 中国宇宙の父」、「中国ミサイルの父」、「中国自動制御の父」、「ロケット王」として知られる。
- Recomendados
- Resumen
Diagrama de arquitectura funcional del sistema de información de recursos humanos.
- 1
Sistema de información Sistema de conocimiento del administrador de proyectos (Capítulo 3 Gestión del alcance del proyecto)
- 1
Sistema de información sistema de conocimiento del director de proyectos (Capítulo 10 Gestión de la comunicación del proyecto y gestión de las partes interesadas)
- 1
Sistema de información sistema de conocimiento del gerente de proyectos (Capítulo 12 Gestión de adquisiciones de proyectos)
- 1
Análisis y Diseño de Sistemas de Información
capítulo01 Descripción general del análisis y diseño del sistema
Introducción
Este es un conjunto de especificaciones, orientación para ayudar a desarrollar sistemas de información.
1.1 Desarrollo de software y análisis y diseño de sistemas.
aplicación de computadora
Un programa de software de computadora que realiza un conjunto específico de funciones en un dispositivo informático.
Rango medio de aplicación
También llamada "aplicación" (app)
Sistema de informacion
Un conjunto de componentes interrelacionados que recopilan, procesan, almacenan y proporcionan información necesaria para completar tareas comerciales.
Alcance más amplio que la "aplicación"
Incluye software, bases de datos y procesos manuales relacionados.
análisis del sistema
Aquellas actividades que permiten a las personas comprender y especificar lo que debe lograr un sistema de información.
diseño de sistemas
Aquellas actividades que permiten definir y describir en detalle el sistema que resuelve los requisitos.
El análisis del sistema equivale a dibujar un plano, mientras que el diseño del sistema es un plan detallado.
1.2 Ciclo de vida del desarrollo del sistema
proyecto
Una tarea planificada que tiene un principio y un final y produce un resultado determinado.
para desarrollar sistemas de información
Requiere conocimiento de herramientas y técnicas de análisis y diseño de sistemas.
SDLC (ciclo de vida de desarrollo del sistema), es decir, ciclo de vida de desarrollo del sistema
El ciclo de vida del desarrollo de sistemas identifica el proceso completo que incluye todas las actividades necesarias para construir, lanzar y mantener sistemas de información.
Todas las actividades incluyen: análisis del sistema, diseño del sistema, programación, pruebas, mantenimiento del sistema.
seis procesos centrales
Identificar problemas o necesidades y obtener aprobación
Planificar y monitorear proyectos.
Descubrir y comprender los detalles de un problema o necesidad.
Diseñar componentes del sistema que resuelvan un problema o satisfagan una necesidad.
Construya, pruebe e integre componentes del sistema
Complete las pruebas del sistema y luego implemente la solución.
proceso de desarrollo del sistema de información
Un enfoque práctico para desarrollar un sistema de información específico (también conocido como metodología) completando las pruebas del sistema y luego implementando la solución.
Por ejemplo
Proceso Unificado (UP)
Programación extrema (XP)
Proceso iterativo de desarrollo de software incremental Scrum
La mayoría de los procesos/métodos ahora utilizan un desarrollo ágil e iterativo.
Desarrollo ágilDesarrollo ágil
Un proceso de desarrollo de sistemas de información que enfatiza la flexibilidad para anticipar nuevos requisitos durante el desarrollo.
Rápido en pies; receptivo al cambio
Ni los usuarios ni los miembros del equipo comprenden completamente los problemas y las complejidades del nuevo sistema, por lo que la planificación y ejecución del proyecto deben tener en cuenta problemas imprevistos.
Desarrollo iterativoDesarrollo iterativo
Un enfoque para el desarrollo de sistemas en el que el sistema "crece" gradualmente a través de múltiples iteraciones.
Complete una pequeña parte del sistema (miniproyecto), luego repita el proceso para refinar y agregar más, luego repita el refinamiento y agregue más hasta completar
Ventaja
1. Partes del sistema se pueden implementar rápidamente
2. Saque una pequeña parte para desarrollarla primero, de modo que pueda encontrar problemas difíciles en el proyecto lo antes posible.
Seis procesos centrales para iterar en un proyecto
El área del círculo representa la carga de trabajo de la iteración correspondiente en este proceso.
Cada iteración llevará a cabo múltiples procesos con diferentes enfoques.
1.5 Tomar el sistema de comercio OMR como ejemplo para presentar el proceso de desarrollo
1.5.1 Preparación
Identificar el problema y documentar los objetivos del sistema (Proceso central 1)
Investigación preliminar
Traducir los resultados a un documento de visión del sistema (SVD)
Obtener aprobación para iniciar el proyecto (Proceso Central 1)
Reunirse con partes interesadas clave, incluida la dirección ejecutiva.
Reunirse con partes interesadas clave, incluida la dirección ejecutiva, para tomar decisiones y aprobar planes y presupuestos.
SVD (documento de visión del sistema)
Un documento de visión del sistema se utiliza para identificar las características que beneficiarán a la empresa y aquellas que se incluirán en el sistema.
Hazlo en dos pasos
Desarrollar una declaración de beneficios inicial.
Agregue estimaciones detalladas de ingresos y costos
Generalmente consta de tres partes.
Descripción del problema
Capacidades del sistema
beneficios de negocio
1.5.2 Actividades del primer día
Proceso Central 2: Planificación del Proyecto
Identificar los principales componentes (áreas funcionales) necesarios.
Dividir el sistema en subsistemas o componentes.
Un subsistema es parte del sistema general.
Definir iteraciones y asignar cada área funcional a las iteraciones.
Planificar una única iteración
Determinar las tareas requeridas para la iteración.
Las tareas identificadas se compilan y organizan en una lista llamada estructura de desglose del trabajo (WBS, por sus siglas en inglés).
Ejemplo
Contenido de WBS (estructura de pausa laboral)
Base de descomposición (nombre)
La base de la descomposición depende de los siguientes cuatro procesos centrales.
tiempo requerido
Orden de ejecución
Medir el tiempo requerido y la secuencia de ejecución puede ayudar con la construcción de la red de trabajo posterior y el cálculo de la ruta crítica (PERT).
La ruta crítica es la ruta más larga de toda la red. Los procesos por los que pasa deben ejecutarse estrictamente. Los procesos en otras rutas tienen un cierto grado de flexibilidad.
Organiza y mantén estas tareas organizadas por fecha
Convertir WBS en un cronograma
La ventaja de planificar iteraciones individuales es que el cronograma es informal y puede ajustarse para afrontar circunstancias inesperadas.
Desarrollar un borrador de secuencia de trabajo.
Beneficios del borrador de orden de trabajo
1. Ayudar a organizar el trabajo en equipo
2. Proporciona una medida de si la iteración va según lo planeado.
3. Si el proyecto tomará algún tiempo según este cronograma, el líder del proyecto puede ver que la programación puede requerir más tiempo y recursos y puede organizar los recursos con anticipación para ayudar con esta parte del proyecto.
Identificar los recursos necesarios (personas) y organizar el personal para realizar las tareas correspondientes.
Identificar los miembros del equipo y sus responsabilidades.
1.5.3 Actividades del segundo día
Realice tareas preliminares de investigación para comprender los requisitos. (Proceso central 3)
El capítulo 2 lo explicará en detalle.
Desarrolle una lista preliminar de casos de uso y un diagrama de casos de uso. (Proceso central 3)
Caso de uso
Un caso de uso registra un evento empresarial desencadenado por un único usuario y la respuesta del sistema a ese evento.
Un caso de uso se refiere a un ejemplo o situación de uso del sistema.
Por ejemplo: Los agentes de compras "utilizan" este sistema para "consultar a los proveedores"
Los casos de uso son generalmente verbos, correspondientes a requisitos/funciones.
Ejemplo de lista de casos de uso
Ejemplo de diagrama de caso de uso
Desarrollar una lista de clases preliminar y un diagrama de clases. (Proceso central 3)
Clase de objeto
Los sistemas de identificación de clases de objetos necesitan comprender y rastrear esas cosas en el mundo real.
Las clases de objetos necesitan guardar información en el sistema.
Ejemplo de lista de clases
Ejemplo de diagrama de clases
Este es un diagrama de clases preliminar, por lo que solo hay propiedades (características estáticas)
El diagrama de clases de diseño tendrá tipos de datos de atributos y métodos de clase, etc.
El diagrama anterior se desarrolló utilizando el lenguaje de modelado unificado UML.
1.5.4 Actividades del tercer día
Lleve a cabo una investigación en profundidad para conocer los detalles. (Proceso central 3)
Comprenda y documente el flujo de trabajo detallado para cada caso de uso. (Proceso central 3)
Desarrollar descripciones de casos de uso y diagramas de flujo de trabajo.
Aquí hay dos formas de documentar los detalles del caso de uso.
El desarrollo de diagramas de flujo de trabajo requiere el uso de diagramas de actividad, que son diagramas en UML.
Ejemplo de diagrama de flujo de trabajo
Los óvalos en la figura representan tareas, los diamantes representan puntos de decisión, las flechas representan el flujo de secuencia y las flechas que cruzan la línea central representan la interacción entre el usuario y el sistema.
Definir la experiencia del usuario con pantallas e informes. (Proceso central 3 y 4)
Definir diseño de pantalla
1.5.5 Actividades del cuarto día
Diseñar la estructura de la base de datos (esquema). (Proceso central 4)
diseño de mesa
Palabras clave e identificadores de índice
Tipo de propiedad
integridad referencial
Ejemplo de esquema de base de datos
Diseñar la estructura de alto nivel del sistema. (Proceso central 4)
Diseño arquitectónico general.
Definir el diagrama de clases de diseño preliminar.
Ejemplo de diagrama de clases de diseño preliminar
Las clases de diseño incluyen las variables de nivel de clase requeridas por la clase, que también muestran los nombres de los métodos importantes en cada clase. Los últimos elementos en un diagrama de clases de diseño son flechas, que muestran qué clases tienen acceso a métodos de qué otras clases.
Diseño de arquitectura de subsistema.
1.5.6 Actividades del quinto día
Continuar con el diseño detallado (CP4)
Realizar programación y pruebas individuales (CP5)
El diseño y la programación no se tratan de diseñar todo y luego programar, sino de diseñar una parte, programar, luego diseñar una parte y luego programar nuevamente.
1.5.7 Actividades del sexto día
Pruebas completas del sistema (CP6)
Pruebas funcionales generales del sistema.
Pruebas de aceptación del usuario
Posible despliegue de sistemas parciales (CP6)
1.5.8 Revisión de la primera iteración
1.6 Introducción al contenido posterior
1.6.1 Primera parte Introducción al desarrollo de sistemas
Capítulo uno
1.6.2 Actividades de análisis del sistema de la Parte 2
Capítulos 2, 3, 4 y 5
1.6.3 Actividades de diseño del sistema de la Parte 3
Capítulo seis y siete
1.6.4 Parte 4 Proyectos y Gestión de Proyectos
Capítulo 8 y 9
1.6.5 Parte 5 Conceptos avanzados y conceptos de implementación
Capítulo 10, 11, 12
cap02 Encuesta de requisitos del sistema
2.1 Introducción
En este capítulo, comenzamos a ampliar el alcance y los detalles del proceso SDLC para cubrir una gama más amplia de conceptos, herramientas y técnicas. Este capítulo se centra en las actividades de análisis de sistemas (el tercer proceso central enumerado), y los siguientes capítulos discutirán en detalle los modelos desarrollados durante estas actividades de análisis de sistemas. Los capítulos siguientes amplían la discusión de otros procesos centrales del SDLC.
2.2CSMS (Sistema Integral de Ventas y Marketing) para RMO
2.2.1 Arquitectura y sistema de información existente de la RMO
La arquitectura se divide en dos tipos.
arquitectura tecnológica arquitectura tecnológica
La arquitectura tecnológica describe el conjunto de hardware informático, hardware y topología de red y software de sistema utilizados por una organización (como sistemas operativos y sistemas de gestión de bases de datos).
arquitectura de aplicaciones arquitectura de aplicaciones
La arquitectura de aplicaciones describe cómo se organizan y estructuran los recursos de software para implementar los sistemas de información de una organización. Describe la organización del software en módulos y subsistemas, incluidas las tecnologías de soporte (como lenguajes de programación y entornos de desarrollo), enfoques arquitectónicos (como la arquitectura orientada a servicios) y tecnologías de interfaz de usuario (como pantallas informáticas móviles, pantallas táctiles). tecnología y reconocimiento de voz).
2.1.2 Nuevo CSMS
El nuevo sistema integrado de ventas y marketing tendrá cuatro subsistemas
Subsistema de ventas
Subsistema de implementación de órdenes
Subsistema de cuentas de clientes
Subsistema de marketing
2.3 Actividades de análisis del sistema
Hay cinco partes principales.
2.3.1 Recopilar información detallada
Entrevistas, cuestionarios, documentación, observación de procesos de negocio, búsqueda de proveedores, opiniones y sugerencias.
2.3.2 Definir requisitos
Modelado de requisitos funcionales y no funcionales.
2.3.3 Priorización de requisitos
2.3.4 Desarrollar cuadros de diálogo de interfaz de usuario
El proceso de interacción entre los usuarios y el sistema.
2.3.5 Evaluar necesidades con los usuarios
Participación del usuario, retroalimentación, adaptación a los cambios.
2.4 ¿Qué es la demanda?
Los requisitos del sistema son todas las actividades que el nuevo sistema debe realizar o soportar, y las restricciones que el nuevo sistema debe satisfacer.
Los requisitos del sistema se dividen en
requerimientos funcionales
Los requisitos funcionales son las actividades que el sistema debe realizar (por ejemplo, el negocio al que se aplicará el sistema).
Requiere que el usuario ejecute
requerimientos no funcionales
Los requisitos no funcionales son características más allá de las actividades que el sistema debe realizar o soportar.
Como indicadores de desempeño, restricciones (herramientas de desarrollo, formatos de datos, etc.)
Puede utilizar FURPS para dividir simplemente los requisitos
funcionalidad funcional
disponibilidad de usabilidad
Fiabilidad
Actuación
Seguridad
Otros, como condiciones restrictivas.
requerimientos no funcionales
2.5 Modelos y Modelado
Modelo
Un modelo es una representación de algún aspecto del sistema que se está construyendo.
Tipo de modelo
modelo de texto
informes, documentos
modelo grafico
Diagrama esquemático
modelo matemático
fórmula
lenguaje de modelado
El desarrollo de muchos modelos gráficos se implementa mediante UML (lenguaje de modelado indefinido)
UML es un conjunto de símbolos y construcciones de modelos estándar definidos por Object Management Group, una organización sin fines de lucro.
2.6 Partes interesadas
Las partes interesadas son todos aquellos que tienen interés en la implementación exitosa del sistema.
Clasificación de partes interesadas
Partes interesadas internas
Las partes interesadas internas son personas dentro de la organización que interactúan con el sistema o tienen un interés significativo en su funcionamiento o éxito.
interesados externos
Las partes interesadas externas son aquellas que están fuera del control e influencia de la organización,
partes interesadas operativas
Las partes interesadas operativas son personas que interactúan frecuentemente con el sistema en su trabajo o vida.
Por ejemplo: contables que interactúan con sistemas de contabilidad o facturación, trabajadores de fábricas que interactúan con sistemas de programación de producción, clientes que interactúan con escaparates de Internet y pacientes que interactúan con sitios web de atención médica, páginas de Facebook o canales de noticias de Twitter.
Gestionar las partes interesadas
Las partes interesadas en la gestión son aquellas que no interactúan directamente con el sistema, pero utilizan la información producida por el sistema o tienen un interés financiero o de otro tipo significativo en su operación y éxito.
Por ejemplo: la alta dirección y la junta directiva de una organización, los reguladores y las autoridades fiscales.
Dos tipos de partes interesadas importantes
Cliente: la persona que brinda apoyo financiero
Personal de soporte técnico del sistema.
2.7 Tecnología de recopilación de información
Las tecnologías de recopilación de información incluyen
2.7.1 Realizar entrevistas con usuarios y otras partes interesadas
Se necesitan analistas de sistemas
Prepare preguntas detalladas
tema de pregunta
¿Cuál debería ser el proceso de negocio?
Cómo funcionan los procesos de negocio
¿Qué información se necesita?
tipo de pregunta
preguntas abiertas
preguntas cerradas
Objeto de la pregunta: sistema antiguo o sistema nuevo
Conocer usuarios individuales o grupos de usuarios
Obtener y discutir respuestas a preguntas
grabar respuesta
Seguimiento de la información para utilizar en futuras entrevistas.
2.7.2 Distribuir y recopilar cuestionarios
Tres tipos de preguntas
preguntas cerradas
Mira los problemas de formato.
preguntas abiertas
2.7.3 Verificar entrada, salida y proceso
Hay dos fuentes de entrada, salida y procesos.
Registros comerciales y descripciones de procesos dentro de la organización.
Desde fuera de la organización: organizaciones profesionales y otras empresas de la industria.
Verificar la documentación de procesamiento existente
2.7.4 Observar y registrar los procesos comerciales
Esto le ayudará a comprender la función del negocio.
2.7.5 Soluciones de proveedores de investigación
Tres beneficios y un peligro
1. Estudiar estas soluciones puede ayudar a los usuarios a pensar mejor sobre cómo ejecutar mejor las funciones comerciales.
2. Algunas soluciones ya son de primera categoría y es difícil mantenerse al día con la tendencia sin realizar una investigación.
3. Comprar una solución es menos riesgoso y más barato que investigar una
Peligro: apresurarse a comprar una solución sin investigar todas las necesidades del sistema
2.7.6 Recopilar comentarios de usuarios activos
2.8 Utilice el diagrama de actividades para registrar el flujo de trabajo
Flujo de trabajo
Un flujo de trabajo es una serie de pasos de procesamiento que manejan por completo una transacción comercial o una solicitud de un cliente.
diagrama de actividad
Un diagrama de actividades describe varias actividades del usuario (o sistema), las personas que realizan cada actividad y el flujo secuencial de esas actividades.
Símbolos y explicaciones.
Las elipses representan diversas actividades en el flujo de trabajo. Las flechas de conexión indican la secuencia entre actividades. Los círculos negros indican el principio y el final del flujo de trabajo. El diamante es un punto de decisión en el que el proceso seguirá un camino u otro. La línea gruesa y continua es una barra de sincronización que puede dividir una ruta en varias rutas simultáneas o recombinar rutas simultáneas. El título del carril de natación representa el agente que realiza la actividad. Debido a que generalmente hay diferentes agentes (es decir, personas) en un flujo de trabajo que realizan diferentes pasos del proceso de flujo de trabajo, los símbolos de carriles de natación dividen las actividades del flujo de trabajo en grupos, mostrando qué agente realiza qué actividad.
caso de uso del capítulo 03
3.1 Introducción
Al igual que los Capítulos 4 y 5, este capítulo presenta técnicas para documentar requisitos funcionales mediante la creación de varios modelos.
Un caso de uso es una actividad que realiza un sistema, generalmente en respuesta a la solicitud de un usuario.
Los casos de uso definen los requisitos funcionales
Los analistas descomponen el sistema en un conjunto de casos de uso (descomposición funcional)
Los casos de uso suelen llevar el nombre de verbos o gerundios.
3.2 Casos de uso y objetivos del usuario
Una técnica para definir casos de uso es la técnica de objetivos de usuario, que les pide a los usuarios que describan sus objetivos al utilizar un sistema nuevo o actualizado.
Dividido en ocho pasos
Identificar a todos los usuarios potenciales del nuevo sistema.
Clasifique a los usuarios potenciales según sus roles funcionales (por ejemplo, transporte, marketing, ventas).
Clasifique aún más a los usuarios potenciales por nivel organizacional (por ejemplo, operaciones, administración, ejecutivo)
Para cada tipo de usuario, visítelos y encuentre una lista de objetivos específicos que tendrán al utilizar el nuevo sistema (objetivos actuales y características innovadoras que agregan valor)
Cree una lista preliminar de casos de uso organizados por tipo de usuario
Encuentre copias con nombres de casos de uso similares y resuelva inconsistencias
Determinar dónde diferentes tipos de usuarios requieren los mismos casos de uso
Revisar el listado completo con cada tipo de usuario y partes interesadas
Generalmente solo se consideran eventos con requisitos funcionales.
Las técnicas de orientación a usuarios son simples pero de uso común.
3.3 Casos de uso y descomposición de eventos
La tecnología de descomposición de eventos es la tecnología más completa para identificar casos de uso.
La tecnología de descomposición de eventos primero determina todos los eventos comerciales que harán que el sistema de información responda, y cada evento conducirá a un caso de uso. Comenzar con eventos comerciales ayuda a los analistas a definir cada caso de uso con el nivel de detalle adecuado.
Para determinar el nivel apropiado de detalle para un caso de uso se utiliza el Proceso de Negocio Esencial (EBP, por sus siglas en inglés).
EBP es una tarea realizada por una persona en un solo lugar para responder a eventos comerciales, agregar valor comercial mensurable y llevar el sistema y sus datos a un estado estable y consistente.
Cada EBP responde a un evento de negocios cuando ocurre.
3.3.1 Tecnología de descomposición de eventos
evento
Los eventos ocurren en un momento y lugar específicos, pueden describirse y el sistema debe recordarlos.
3.3.2 Tipos de eventos
eventos externos
Los eventos externos son eventos que ocurren fuera del sistema, generalmente iniciados por agentes o actores externos.
Los agentes (o actores) externos son individuos o unidades organizativas que proporcionan o reciben datos al sistema.
Por ejemplo
Varios procesos comerciales, como la realización de pedidos por parte del usuario, etc.
Los eventos externos se utilizan generalmente para responder a solicitudes de usuarios (actores) y ocurren en entornos de interacción persona-computadora.
Evento cronometrado/tiempo temporal
Un evento que ocurre como resultado de llegar a un cierto punto en el tiempo.
Por ejemplo
Enviar periódicamente informes estadísticos, etc.
Los eventos temporales ocurren dentro del sistema.
evento de estado
Los eventos de estado ocurren cuando ocurre un evento dentro del sistema que desencadena un requisito de procesamiento.
Causado cuando el estado cambia.
Generalmente, son requisitos no funcionales y no suelen considerarse.
3.3.3 Definir eventos
Evento/Condición previa/Respuesta
Los analistas deben considerar una secuencia de eventos y luego identificar los eventos que realmente afectan al sistema.
secuencia de eventos
Es útil para rastrear una serie de eventos que le ocurrieron a una entidad o actor externo específico.
Eventos de dependencia tecnológica y control del sistema.
A veces, los analistas se preocupan por eventos que son importantes para el sistema pero que no están directamente relacionados con los usuarios o las transacciones. Estos eventos generalmente involucran elecciones de diseño o controles del sistema. Los analistas deben ignorar temporalmente estos eventos durante el análisis.
Los controles del sistema son controles o procedimientos de seguridad diseñados para proteger la integridad de un sistema.
Copia de seguridad de datos, inicio de sesión, etc.
Durante la fase de análisis utilizaremos supuestos técnicos ideales.
La hipótesis de la tecnología perfecta establece que los eventos sólo ocurren cuando el sistema necesita responder en condiciones perfectas (por ejemplo, el dispositivo nunca falla, la potencia de procesamiento y almacenamiento es ilimitada y las personas que operan el sistema son completamente honestas y nunca cometen errores). incluidos en el proceso de análisis.
3.3.4 Utilizar tecnología de descomposición de eventos
1. Considere eventos externos en el entorno del sistema que requieran una respuesta del sistema.
2. Para cada evento externo, identifique y nombre el caso de uso requerido por el sistema.
3. Utilice una lista de verificación para considerar eventos temporales que requieren una respuesta del sistema.
4. Para cada evento temporal, identifique y nombre los casos de uso requeridos por el sistema y luego establezca el momento que desencadena el caso de uso.
5. Considere los eventos de estado a los que puede responder el sistema, especialmente si se trata de un sistema en tiempo real donde los cambios de estado interno o del dispositivo desencadenan casos de uso.
6. Para cada evento de estado, identifique y nombre el caso de uso requerido por el sistema y luego defina el cambio de estado.
7. Después de definir eventos y casos de uso, verifique si requieren supuestos técnicos perfectos. No incluya eventos que involucren controles del sistema, como inicio de sesión, cierre de sesión, cambio de contraseña y copia de seguridad o recuperación de la base de datos, ya que se colocan como controles del sistema.
3.4 Casos de uso y CRUD
Otra tecnología importante para validar y perfeccionar casos de uso es la tecnología CRUD.
CRUD significa
Crear
Leer leer
Actualizar, actualizar
Eliminar, eliminar
Estas son operaciones relacionadas con la gestión de bases de datos.
Las técnicas CRUD son más útiles cuando se usan junto con técnicas de orientación al usuario como verificación cruzada. En lugar de utilizarlo directamente como método para identificar casos de uso, puede provocar que los casos de uso no sigan muy bien el proceso empresarial.
Puede comprobar si falta algún tipo de caso de uso
Pasos de la tecnología CRUD
1. Identifique todas las entidades de datos o clases de dominio involucradas en el nuevo sistema.
2. Para cada tipo de datos (entidad de datos o clase de dominio), verifique que haya identificado casos de uso para crear nuevas instancias, actualizar instancias existentes, leer o informar valores de instancias y eliminar (archivar) instancias.
3. Si se ignora un caso de uso requerido, agregue un nuevo caso de uso e identifique a las partes interesadas.
4. Para aplicaciones integradas, asegúrese de que quede claro qué aplicación es responsable de agregar y mantener datos y qué sistema solo usa los datos.
3.6 Diagrama de casos de uso
Los diagramas de casos de uso son modelos UML que se utilizan para mostrar gráficamente los casos de uso y su relación con los usuarios.
3.6.1 Casos de uso, actores y símbolos
En la mayoría de los casos de uso están implícitas las personas que utilizan el sistema, a quienes hasta ahora nos hemos referido como usuarios. En UML, esta persona se llama actor. Los actores suelen estar fuera de los límites de la automatización.
En el diagrama de casos de uso, el símbolo humano representa al actor, el óvalo representa el caso de uso, el borde rectangular representa el límite de automatización y la conexión entre el caso de uso y el actor representa qué actor participa en qué caso de uso.
Ejemplo
No sólo existen relaciones entre casos de uso y actores, sino que también puede haber relaciones entre casos de uso.
Esta es una dependencia entre casos de uso y se presenta en dos formas. Utilice flechas discontinuas y << >> para indicar
<<incluir>>
Puede entenderse como una relación de uso, que se refiere al uso de un caso de uso en otro caso de uso. El caso de uso señalado por la flecha es el caso de uso utilizado (dependiente). Esta relación requiere que un caso de uso se utilice en otro caso de uso.
<<extendido>>
Esta relación indica que un caso de uso puede utilizar otro caso de uso. En esta relación, habrá algo llamado punto de extensión. Por ejemplo, en un sistema de gestión de biblioteca, el caso de uso de devolución de libros puede implicar multas (tiempos de espera, etc.). Esta es la relación extendida.
La conexión entre los dos es que ambos son relaciones entre casos de uso, y ambos significan usar otro caso de uso en un caso de uso. La diferencia entre los dos es que incluir significa que definitivamente se usará otra UC, mientras que extendido requiere juzgar la extensión; punto antes de decidir su uso o no
modelo de dominio chap04
4.1 Introducción
Conceptos básicos: cosas en el dominio de problemas del usuario del sistema
4.2 Cosas en el dominio del problema
El dominio del problema se refiere al área específica de negocio del usuario incluida en el nuevo sistema.
Las clases o entidades de dominio son con las que los usuarios finales necesitan trabajar en el estudio. A menudo se las denomina "cosas" en el dominio del problema del sistema.
productos, pedidos, clientes
4.2.2 Método 2 para definir cosas en el dominio del problema: sustantivo tecnología
paso
1. Identifique todos los sustantivos utilizando casos de uso, actores y otra información sobre el sistema (incluidas entradas y salidas).
2. Utilizando sistemas existentes, procedimientos actuales y otra información de informes o formularios actuales, agregue elementos o categorías de información requerida. Algunos de estos elementos pueden ser elementos adicionales y otros pueden ser información más específica (llamada atributos) sobre elementos que ya identifica. Refine la lista y luego registre las hipótesis o preguntas que desea explorar.
3. A medida que se construya esta lista de sustantivos, deberá perfeccionarla.
Haga las siguientes preguntas para cada sustantivo para ayudarle a decidir si debe incluirse:
¿Es algo único que el sistema necesita saber?
¿Está dentro del alcance del sistema que estoy desarrollando?
¿Necesita el sistema recordar más de uno de los elementos anteriores?
Haga las siguientes preguntas sobre cada sustantivo para decidir si debe excluirse:
¿Es realmente sinónimo de algo más que he identificado?
¿Es realmente solo una salida del sistema basada en otra información que identifiqué?
¿Es realmente sólo una entrada que da como resultado el registro de otra información que he identificado?
Haga las siguientes preguntas sobre cada sustantivo para decidir si debe estudiarse:
¿Es posible que sea información (propiedad) específica sobre otras cosas que he identificado?
Si las suposiciones cambian, ¿podría necesitarlo?
4. Cree una lista maestra de todos los sustantivos identificados y luego indique si cada sustantivo debe incluirse, excluirse o estudiarse más a fondo.
5. Revise la lista con los usuarios, las partes interesadas y los miembros del equipo, luego refine la lista de cosas en el dominio del problema.
Ejemplo
4.2.3 Propiedades de las cosas
La mayoría de los sistemas almacenan información específica sobre transacciones llamadas atributos.
Un atributo que identifica de forma única algo se llama identificador o palabra clave (clave/código).
Los atributos compuestos se componen de múltiples atributos relacionados, como dirección, nombre completo, etc.
4.2.4 Relaciones entre cosas
La asociación se refiere a la relación que ocurre naturalmente entre ciertas cosas.
En UML, existen aproximadamente cuatro tipos de relaciones entre cosas.
asociación
generalización generacional
dependenciadependencia
implementar
detalles asociados
tiene un nombre
Hay una dirección, y lo que apunta la flecha no puede ver al otro (es decir, el otro depende de lo que señala la flecha, y lo que apunta cambia a lo otro, pero viceversa no tiene ningún efecto)
Por ejemplo, A->B se llama A dependiente de B.
La asociación es multiplicidad, es decir, la relación cuantitativa entre una cosa y otra cosa.
ejemplo
Existen restricciones de cardinalidad entre asociaciones.
elemento asociado
Una asociación consta de varios tipos diferentes de cosas, y el número de estas cosas es la aridad de la asociación.
Cliente y pedido, relación binaria.
Asociación entre cosas similares, un elemento
Tres o más tipos diferentes de cosas están relacionadas, múltiples
4.3 Diagrama entidad-contacto
Este es un modelo para modelado de bases de datos.
Los rectángulos representan entidades y las líneas que conectan rectángulos representan conexiones entre entidades.
representación simbólica
Sólo las líneas verticales se truncan para representar que hay y sólo una
Las líneas verticales se cortan y se rodean con un círculo para representar 0 o 1.
Un círculo con una línea cruzada indica 0 o más
Las líneas verticales cortadas y las líneas bifurcadas representan una o más
La dirección correspondiente al número es de sin firmar a firmada.
En los atributos de la entidad, el código primario (identificador) se coloca en la primera línea y se marca PK para indicar que es el código primario.
Ejemplo
Un cliente corresponde a 0 para múltiples pedidos; un pedido corresponde a un solo cliente.
4.4 Diagrama de clases del modelo de dominio
La clase de cosas en cuestión se llama clase de dominio.
En UML, el diagrama de clases se utiliza para mostrar las clases de objetos del sistema.
Diagrama de clases del modelo de dominio
Se utiliza para mostrar cosas en el dominio problemático del usuario.
Diagrama de clases de diseño
para diseño
representación simbólica
En un diagrama de clases, los rectángulos representan clases y las líneas rectas que conectan los rectángulos representan relaciones entre clases.
El rectángulo tiene dos partes (diagrama de clases del modelo de dominio, diagrama de clases de diseño consta de tres partes: nombre de clase, atributos, métodos), la parte superior es el nombre de la clase y la parte inferior son los atributos de la clase.
Los nombres de clase y los nombres de atributos utilizan nombres en mayúsculas y minúsculas. La primera letra del nombre de la clase está en mayúscula y la primera letra del nombre del atributo está en minúscula.
4.4.1 Notación del diagrama de clases del modelo de dominio
símbolo de multiplicidad
Representa el número de relaciones entre instancias de clases, similar a la multiplicidad de diagramas de relaciones entre entidades.
Ejemplo
La multiplicidad aquí es similar a la cardinalidad de mapeo del diagrama entidad-relación.
Aplicación de diagrama de clases de dominio específico
Este es un diagrama de clases de modelo de dominio para la selección de cursos de estudiantes. Un curso puede tener de 0 a varias secciones, pero una sección solo puede pertenecer y debe pertenecer a un curso y las secciones tienen una relación de muchos a muchos y ambas pueden ser; cero Hay una clase de asociación entre estudiantes y cursos, marcada con una línea de puntos, con un atributo de calificación;
4.4.2 Cuestiones más complejas relativas a las clases de objetos
Hay tres tipos de relaciones en las clases de dominio.
asociación
Generación de generalización/especialización
La base de la relación de generalización/especialización es que las personas clasifican las cosas en función de similitudes y diferencias.
La relación de generalización/especialización se utiliza para estructurar u ordenar estas cosas de más generales a más específicas.
Cada clase en la jerarquía puede tener una clase más general por encima de ella, llamada superclase.
Una clase puede tener una clase más especializada debajo, llamada subclase.
La herencia permite que las subclases compartan características de su superclase.
Usa una flecha triangular para señalar la superclase.
Ejemplo
Utilice cursiva para etiquetar clases abstractas
No se pueden crear instancias de clases abstractas y solo se pueden heredar
También hay una clase concreta, que es una clase que puede tener objetos de instancia.
Las superclases son a veces concretas o abstractas.
Toda una parte
La relación global/parte se utiliza para expresar la relación entre una clase y otras clases contenidas en esta clase.
polimerización
En una relación de agregación, los componentes pueden existir de forma independiente.
Utilice diamantes huecos para representar
combinación
En una relación combinada, cada parte no puede existir de forma independiente una vez que está relacionada.
Utilice un diamante sólido para representar
Capítulo 05 Ampliación del modelo de requisitos.
5.2 Descripción del caso de uso
Las descripciones de casos de uso describen los detalles de cada caso de uso.
Descripción de caso de uso sencilla
Adecuado para escenarios únicos y menos excepciones
Ejemplo
Descripción del caso de uso completamente desarrollada
Para algunos casos de uso más complejos, se requiere una descripción del caso de uso completamente ampliada.
Plantilla estándar
Nombre del caso de uso
Escenarios de casos de uso
acontecimiento desencadenante
Descripción rápida
Participantes
Otros casos de uso asociados con él y cómo se asocia
Partes interesadas
Requisitos previos
Los requisitos previos determinan el estado del sistema cuando comienza un caso de uso, incluidos los objetos que ya deben existir, la información que debe estar disponible e incluso las condiciones para los actores antes de que comience el caso de uso.
Condiciones posteriores
Las poscondiciones determinan lo que debe ser cierto cuando se completa el caso de uso. Lo más importante es que indican qué objetos nuevos crea o actualiza el caso de uso y cómo deben relacionarse los objetos.
flujo de actividad
Flujo de actividad que incluye participantes (usuarios) y sistema.
situación anormal
El flujo de actividad para cada caso de uso puede ser muy diferente, dependiendo del actor que invoca el caso de uso. Los diferentes flujos de actividad se denominan escenarios, también conocidos como instancias de casos de uso;
5.3 Diagrama de actividad de casos de uso
Una forma de registrar casos de uso es usar diagramas de actividad. Hemos aprendido a usar diagramas de actividad para crear flujos de trabajo en el Capítulo 2. Usaremos diagramas de actividad aquí para registrar el flujo de actividad de los casos de uso.
Ejemplo
Este diagrama de actividad muestra el flujo de actividad del registro de casos de uso de registro de clientes.
5.4 Diagrama de secuencia del sistema SSD
El diagrama de secuencia del sistema se utiliza para describir el flujo de información dentro y fuera de un sistema de automatización.
Utilice símbolos humanos para representar actores de casos de uso y bordes rectangulares para representar límites de automatización.
El rectángulo está marcado: sistema (con dos puntos), que indica el sistema automatizado
Hay una línea de puntos debajo de los participantes y el sistema, llamada línea de vida, que representa el ciclo de vida de los participantes y el sistema, y el tiempo fluye de arriba hacia abajo.
Existe el envío y recepción de mensajes entre los participantes y la línea de vida del sistema.
El envío de mensajes está representado por una línea continua, con la dirección del participante al sistema
Los mensajes recibidos están representados por líneas discontinuas con dirección del sistema al participante.
Representación simbólica completa del mensaje.
(*)[Condición Verdadero/Falso]Valor de retorno:=Nombre del mensaje (lista de parámetros)
* indica bucle
[] representa las condiciones verdadera y falsa. Si el interior es verdadero, el mensaje se enviará; de lo contrario, no se enviará.
El nombre del mensaje es una descripción del mensaje enviado.
La lista de parámetros es la información que se pasará.
Además, existen algunos marcos alternativos.
alteración de bucle
Si se envían y reciben varios mensajes en un bucle, puede ser mejor utilizar un marco alternativo.
El marco alternativo es utilizar un marco rectangular para seleccionar la parte que se va a buclear y expresar el bucle para todos los elementos en la esquina superior izquierda.
seleccionar alterar
El marco alternativo de selección se usa junto con else. Utilice un marco rectangular para seleccionar el área de selección. Utilice líneas de puntos para distinguir los mensajes enviados en diferentes circunstancias y etiquételos respectivamente en la parte final del mensaje enviado.
5.4.2 Desarrollar SSD
1. Confirme el mensaje de entrada
2. Utilice símbolos de mensaje para describir la información pasada al sistema desde el exterior.
3. Agregue condiciones específicas en el mensaje de entrada, incluidos bucles y condiciones de verdadero/falso.
4. Confirmar y agregar mensaje de respuesta.
5.5 diagrama de máquina de estados diagrama de máquina de estados
El estado de un objeto es una condición que ocurre durante su vida cuando se cumplen ciertas condiciones, se realizan ciertas acciones o se espera algún evento.
La transición de estado es la actividad de un objeto que pasa de un estado a otro.
función de transición de estado
Nombre de la conversión (parámetro,...) [condición de evaluación]/descripción del comportamiento
Una expresión de acción representa algún proceso que debe ocurrir antes de que se complete la transición y el objeto alcance el estado objetivo.
Una condición es un calificador o prueba para una transición; es simplemente una condición verdadero/falso que debe cumplirse antes de que se pueda desencadenar la transición.
5.5.1 Estado compuesto y estado concurrente
Estar en varios estados al mismo tiempo se denomina concurrencia o estados concurrentes.
Representada mediante rutas concurrentes similares a los diagramas de actividad, una ruta es un conjunto ordenado de transiciones de estado interconectadas.
Anida estados dentro de otros estados de nivel superior. Estos estados de nivel superior se denominan estados compuestos.
El estado compuesto está representado por un estado de alto nivel anidado en un estado de nivel inferior.
Ejemplo
Cuando la impresora está encendida (estado compuesto), tiene dos rutas simultáneas, a saber, la parte de la bandeja de papel y la parte de impresión. Las dos partes son independientes cuando se presiona el botón de encendido, se enciende y cuando se presiona el botón de apagado. presionado, se apaga. No hay restricciones.
5.5.2 Reglas para desarrollar diagramas de máquinas de estados
Vea el diagrama de clases y seleccione las clases que pueden requerir estado
Para cada clase seleccionada en el grupo, enumere todas las condiciones de estado que puede determinar
Comienza a construir un fragmento de diagrama de máquina de estados identificando las transiciones que hacen que un objeto abandone el estado identificado.
Organice estas combinaciones de transición de estados en el orden correcto
Verifique estas rutas y busque rutas concurrentes independientes
Encuentra otras conversiones
Amplíe cada transición con eventos de mensajes, condiciones de protección y expresiones de acción apropiadas.
Verifique y pruebe el diagrama de cada máquina de estado.
5.6 Integración de modelos de demanda
La relación entre varios modelos de demanda.
use el diagrama del caso
Descripción del caso de uso
diagrama de actividad
SSD
Diagrama de clases del modelo de dominio
diagrama de máquina de estados
La relación se describe en la siguiente figura.
La flecha apunta en la dirección del elemento dependiente al elemento dependiente.
Las líneas continuas representan dependencias primarias, las líneas de puntos representan dependencias secundarias y algunas flechas son bidireccionales, lo que indica influencia mutua.
cap06 Puntos básicos del diseño y actividades de diseño.
6.1 Introducción
En la fase de análisis, discutiremos principalmente qué hace el sistema (como los requisitos), mientras que en la fase de diseño, discutiremos principalmente cómo el sistema logra estos requisitos.
La entrada y la salida del diseño del sistema no son la entrada y la salida del sistema: la entrada del diseño del sistema es el resultado del análisis del sistema, es decir, los requisitos y los modelos relacionados, mientras que la salida del diseño del sistema es una solución más detallada.
6.2 Elementos de diseño
6.2.1 ¿Qué es el diseño de un sistema?
El diseño del sistema es un proceso de unión entre el análisis y la implementación del sistema con el propósito de definir, organizar y construir los componentes de la solución final como modelo para la construcción.
6.2.2 Principales componentes y niveles de diseño
Componentes principales
Diseño ambiental
Describe las redes, hardware, etc. que conectan el sistema entre sí.
diseño de aplicaciones
Programa de computadora
Diseño de interfaz de usuario
Pantallas, informes y controles definidos para entrada y salida.
Diseño de base de datos
Estructura de la base de datos
Diseño de interfaz del sistema
Describe la comunicación con otros sistemas.
Diseño de Seguridad y Control
dos niveles
Diseño arquitectónico
Aclarar todo el marco y la forma de la solución, que es el diseño amplio de la estructura general del sistema.
También llamado diseño general o diseño conceptual.
diseño de detalle
Incluye detalles de programación específicos.
Ejemplo
Diseño por caso de uso
Diseño de base de datos
Diseño de interfaz de usuario e interfaz del sistema.
Diseño de Seguridad y Control
6.3 Entradas y salidas del diseño del sistema
Convertir información como modelos de análisis y documentos obtenidos del análisis del sistema en un modelo que represente el sistema de solución.
modelo analítico
Diagrama de clase
Diagrama de casos de uso UCD
Diagrama de secuencia del sistema SSD
Descripción del caso de uso
diagrama de máquina de estados
diagrama de actividad
modelo de diseño
Mapa del paquete
Gráfico de nodos y ubicaciones
Diagrama de clases de diseño
Diagrama de flujo
Esquema de base de datos
Interfaz de usuario y sistema
Control de seguridad del sistema
Diagrama de colaboración
6.4 Actividades de diseño
Las actividades de diseño son el diseño de los seis componentes anteriores. Cada actividad de diseño tiene sus correspondientes cuestiones clave.
Diseño ambiental
¿Hemos detallado el entorno en el que se ejecutará el software y todas las opciones?
Arquitectura de aplicaciones y diseño de software.
¿Hemos detallado todos los elementos del software y cómo se realiza cada caso de uso?
diseño de interfaz de usuario
¿Hemos detallado cómo se comunicará este sistema con todos los demás sistemas dentro y fuera de la organización?
Diseño de interfaz del sistema
¿Hemos detallado cómo los usuarios interactuarán con el sistema para realizar todas sus tareas [casos de uso]?
Diseño de base de datos
¿Hemos especificado todos los requisitos de almacenamiento de información, incluidos todos los elementos del esquema?
Diseño de Seguridad y Control
¿Hemos detallado todos los elementos necesarios para garantizar que los sistemas y los datos estén seguros y protegidos?
6.4.1 Entorno de diseño
El entorno es toda la tecnología necesaria para soportar una aplicación de software.
Servidor, computadora de escritorio
dispositivos móviles, sistemas operativos
Capacidad de comunicación, capacidad de entrada y salida.
Lo llamamos arquitectura técnica en el Capítulo 2.
6.4.2 Arquitectura y software de la aplicación de diseño
Dividir el sistema en subsistemas.
Definir la arquitectura del software (diseño arquitectónico)
Arquitectura MVC de tres niveles, etc.
Diseño detallado de cada caso de uso.
Diagrama de clases de diseño
Diagrama de flujo
diagrama de máquina de estados
6.4.3 Diseño de interfaz de usuario
El diseño del diálogo comienza con los requisitos.
El diseño agrega diseño de pantalla, apariencia, navegación y experiencia de usuario.
Diseñar diferentes interfaces para diferentes dispositivos.
6.4.4 Interfaz del sistema de diseño
Los sistemas de información interactúan con muchos otros sistemas internos y externos.
Las interfaces del sistema se conectan a otros sistemas de muchas maneras diferentes.
6.4.5 Base de datos de diseño
Comience con un diagrama de clases de modelo de dominio (o ERD)
Seleccionar estructura de base de datos
Arquitectura de diseño (distribuida, etc.)
Diseñar esquema de base de datos
Tabla, columna de atributos
Restricciones de integridad de referencia de diseño
6.4.6 Diseño de controles de seguridad y del sistema
El propósito es proteger los activos de una organización, críticos en Internet y el mundo inalámbrico.
Controles de la interfaz de usuario
control de aplicaciones
Control de base de datos
control de red
6.5 Cómo diseñar el entorno
Diseño local
Hay dos tipos de sistemas de software locales.
Sistema de software independiente
Ejecutar desde un dispositivo sin red
Sistema interno basado en web
Implementación de hardware: LAN
arquitectura cliente-servidor
Sistema de aplicación de escritorio (cliente-servidor)
Sistema de aplicación basado en navegador (navegador-servidor)
Utilice el lenguaje de marcado de hipertexto como página
Utilice el protocolo TCP/IP como protocolo de transporte
Arquitectura cliente/servidor de tres niveles
Una forma eficaz de diseñar software es separar la interfaz de usuario y las capas de lógica empresarial, y separar la capa de lógica empresarial y la capa de acceso a datos. Este método de diseño de programas se denomina arquitectura de tres niveles. La idea básica es dividir el software en tres capas.
Capa de vista: responsable de recibir la entrada del usuario y procesarla en una salida formateada.
Capa lógica/Capa de dominio Capa de dominio: Responsable de las reglas y procedimientos que implementan procesos comerciales o de procesamiento.
Capa de datos: Responsable de gestionar los datos almacenados, que generalmente existen en una o más bases de datos.
Se pueden ejecutar varios niveles en una sola computadora, o cada nivel puede ser operado por una computadora separada. Se pueden implementar niveles complejos en dos o tres niveles distribuyendo la funcionalidad del nivel o implementando el equilibrio de carga entre computadoras redundantes.
Otra idea de diseño es MVC, es decir, Model-View-Controller.
Diseñar implementación externa
Las preguntas importantes incluyen
Configuración para la implementación de Internet
La protección de datos se implementa mediante el protocolo de seguridad de transferencia de hipertexto (HTTPS). Las páginas web atendidas por el protocolo HTTPS se transmiten en forma cifrada, que es más segura que HTTP.
Utilice estructuras de servidores de varios niveles y redes de entrega de contenido (CDN) y equilibrio de carga para aumentar el rendimiento.
La estructura del servidor de varios niveles incluye un servidor de aplicaciones y un servidor de bases de datos.
Las solicitudes se envían a diferentes servidores del centro de datos a través de computadoras de equilibrio de carga.
Al acceder a algunas imágenes o videos estáticos, puede usar un CDN independiente para enviarlos
Opciones de alojamiento para implementaciones de Internet
alquiler de locales
Proporcionar un centro de datos seguro para que los clientes coloquen computadoras servidor. La ventaja es que no hay costos de centro de datos físicos, seguros y complejos.
Servicios gestionados
Proporciona servicios adicionales que incluyen administración de sistemas operativos, servidores de red, servidores de bases de datos, etc. La ventaja es que no es necesario contratar empleados para administrar los sistemas de servidores y el software del sistema.
servidor virtual
Los clientes pueden alquilar servidores virtuales, que son de un tamaño fijo.
computación en la nube
Los clientes solo necesitan comprar la capacidad informática que necesitan y utilizan, y cuando la capacidad informática crece, la nube proporcionará automáticamente más capacidad. Este acuerdo puede ahorrar costos porque no hay necesidad de comprar capacidad innecesaria;
Para todas las alternativas existe un Acuerdo de Nivel de Servicio (Service Level Agreement), que forma parte del contrato entre la empresa y la empresa de hosting para garantizar un nivel específico de disponibilidad del sistema.
Diversidad de dispositivos de clientes implementados para Internet
computadora
Dispositivo de tableta de tamaño mediano
pequeño dispositivo móvil
Diseño para entornos remotos y distribuidos.
Implementación remota a través de red privada virtual (VPN)
Una VPN es una red construida sobre una red pública como Internet. Proporciona una red segura y conectable para grupos privados.
cap07 Diseño de interfaz de usuario e interfaz del sistema.
7.2 Interfaz de usuario e interfaz del sistema
La interfaz de usuario contiene entradas y salidas que requieren la intervención directa del usuario.
La interfaz del sistema requiere una entrada y salida manual mínima
7.3 Comprensión de la interfaz de usuario
La interfaz de usuario tiene tres componentes.
Significado físico: escritorios y sillas de oficina, lámparas, teclados, ratones, pantallas táctiles.
Significado percibido: colores, formas, texturas, fuentes, ventanas, menús, botones.
Significado conceptual: cliente, participante, pedido, transporte, retroalimentación.
La perspectiva del diseño de la interfaz de usuario está centrada en el usuario y enfatiza la interacción entre humanos y computadoras (interacción persona-computadora)
La interacción persona-computadora es un campo que estudia la eficiencia y efectividad de la interacción del usuario con sistemas informáticos, técnicas de entrada y salida orientadas a humanos y los aspectos psicológicos de las interfaces de usuario.
Tres principios básicos del diseño centrado en el usuario
Centrarse desde el principio en los usuarios y su trabajo
Evaluar el sistema para asegurar su usabilidad.
Utilice desarrollo iterativo
Metáforas para la interacción persona-computadora
Las metáforas son analogías entre las características de la interfaz de usuario y entidades físicas que son familiares para los usuarios.
Las metáforas se utilizan ampliamente en el diseño de interfaces de usuario en las siguientes situaciones:
manipulación directa
Manipular objetos físicos directamente en la pantalla u objetos que los representen.
Ejemplo: el usuario arrastra una carpeta a la Papelera de reciclaje
metáfora de escritorio
Organice la pantalla visual en diferentes áreas, con un gran espacio de trabajo vacío en el medio rodeado por un conjunto de iconos de herramientas.
Ejemplo: escritorio de Windows
metáfora del documento
Mostrar datos como una página o tabla
Ejemplo: documento de instrucciones para el usuario, etc.
metáfora conversacional
Los usuarios y las computadoras completan tareas comunicándose o dialogando utilizando texto, voz u otras herramientas.
Ejemplo: ventana cmd
Los tres primeros enfatizan los objetos que interactúan con el usuario, y la metáfora conversacional enfatiza la comunicación que ocurre entre el usuario y la computadora.
7.4 Conceptos de diseño de interfaz de usuario
7.4.1 Rapidez y visibilidad
Indicativo se refiere a la apariencia de un control que refleja su desempeño.
Visibilidad significa que el control es visible.
7.4.2 Consistencia
7.4.3 Atajos
7.4.4 Comentarios
7.4.5 Diálogo completo
7.4.6 Manejo de errores
7.4.7 Deshacer acción
7.4.8 Reducir la carga sobre la memoria a corto plazo
7.5 Del análisis al diseño de la interfaz de usuario
7.5.1 Casos de uso y jerarquía de menús
Los menús son una forma de organizar una gran cantidad de casos de uso o conversaciones relacionadas en una interfaz de usuario.
El diseñador debe estimar la jerarquía del menú en función del número de casos de uso.
Un nivel de menú suele contener entre 5 y 10 opciones.
7.5.2 Diálogo y guiones gráficos
Necesidad de grabar las conversaciones que los usuarios necesitan.
Guión gráfico: muestra esta serie de bocetos en pantalla en la conversación.
7.6 Diseño de interfaz de usuario
7.6.1 Directrices para diseñar formularios y tablas
Diseño y formato de la interfaz.
Consistencia, etiquetas y títulos, distribución y orden, fuentes y colores.
Entrada de datos
Cuadro de texto, cuadro de lista, cuadro combinado, botón de opción, casilla de verificación
Control de orientación y apoyo.
Minimizar, maximizar, cerrar, barras de desplazamiento, cambiar el tamaño
7.6.2 Directrices adicionales para las interfaces del navegador
consistencia
Hojas de estilo en cascada (CSS): un estándar de codificación de páginas web que permite a los diseñadores de sitios web especificar partes de una página que siempre tienen el mismo aspecto y partes que varían según la tarea o la audiencia.
Consideraciones de rendimiento
Sensible a las conexiones de red, cantidad de información transferida, tipo de información transferida
Imágenes, vídeos y sonidos.
Habrá problemas de compatibilidad
Usuarios especiales (discapacidad)
Tecnología de asistencia: software que adapta las interfaces de usuario a las necesidades especiales de las personas con discapacidades (como herramientas de reconocimiento de voz y de texto a voz)
7.6.3 Directrices adicionales para interfaces de dispositivos móviles
Desafíos en el diseño de interfaces de usuario para dispositivos móviles
Pantallas pequeñas, teclados y pantallas táctiles, capacidad de red limitada, pautas de diseño de aplicaciones y kits de herramientas
7.7 Determinar la interfaz del sistema
Las interfaces del sistema se definen ampliamente como entradas y salidas que requieren poca o ninguna intervención del usuario.
Dividido en las siguientes categorías.
Entrada y salida de otros sistemas.
XML (lenguaje de marcado extensible) se puede utilizar para el intercambio electrónico de datos y la comunicación entre sistemas.
XML implementa una estructura de datos personalizada incrustada en comparación con HTML
Entrada y salida altamente automatizadas
Entrada y salida de bases de datos externas.
7.8 Entrada del sistema de diseño
7.8.1 Dispositivos de entrada automatizados
El objetivo principal de cualquier entrada de datos es proporcionar o actualizar datos libres de errores en el sistema. Lo más importante es evitar errores tanto como sea posible. Aquí hay varias formas de evitarlos de manera efectiva.
Utilice dispositivos de entrada automatizados
Evite la intervención humana tanto como sea posible.
Si la información de entrada se puede obtener de una hoja de cálculo, utilice la hoja de cálculo sin volver a ingresar los datos.
Verificar y corregir datos
7.8.2 Definir detalles de entrada del sistema
7.9 Salida del sistema de diseño
Diseñar informes, declaraciones y documentos de devolución.
Tipo de informe
Informe detallado: contiene información detallada sobre el proceso de negocio.
Informe resumido: este tipo de informe se utiliza para resumir las actividades por fases.
Informe anormal: generado cuando los resultados de una transacción u operación son anormales.
Informes ejecutivos: evaluar el estado general y las operaciones
La salida interna se genera para uso interno de la organización o unidad. Los informes discutidos anteriormente pertenecen a la salida interna y se generan para uso de miembros externos de la organización, como información de confirmación de pedidos, estados de cuenta mensuales, etc. Porque es un documento comercial oficial generado para personas externas y requiere una mayor calidad.
Existe un tipo de salida externa llamada documento de devolución. La salida proporcionada al usuario consiste en una parte que se puede arrancar y utilizar como entrada al sistema más adelante, como una factura que contiene un talón de pago que se devolverá con el documento. controlar.
estados de cuenta electronicos
Presentación gráfica y multimedia.
método de desarrollo del sistema capítulo08
8.2 Ciclo de vida del desarrollo del sistema
8.2.1 Métodos tradicionales de predicción del ciclo de vida del desarrollo de sistemas.
El método de previsión es un método que puede planificar proyectos de desarrollo organizacional con anticipación y desarrollar nuevos sistemas de información de acuerdo con el plan.
Requisitos: se supone que el proyecto se puede planificar con anticipación, el sistema de información se puede desarrollar de acuerdo con el plan, los requisitos se comprenden bien y el riesgo técnico es bajo.
modelo de cascada
En un proyecto, las seis fases del ciclo de vida avanzan de una fase a la siguiente y las fases son secuenciales.
En el modelo de cascada tradicional, no hay superposición ni iteración entre las distintas etapas del SDLC.
El modelo en el lado relativamente derecho de la escala es el modelo de cascada mejorado.
El modelo de cascada mejorado aún conserva la secuencia prevista de fases de desarrollo, pero estas fases se superponen, influyen y dependen unas de otras.
Mayor flexibilidad, pero aún asume planificación predictiva y fases secuenciales.
8.2.2 Enfoque adaptativo al ciclo de vida del desarrollo del sistema
Los modelos de adaptación se pueden utilizar para el desarrollo cuando los requisitos (requisitos) no están claros y, a menudo, implican varias iteraciones.
Los proyectos deben ser más flexibles y adaptarse a las necesidades cambiantes durante el proceso de desarrollo, la demanda es incierta y los riesgos técnicos son altos;
modelo espiral
Relativamente lejos del extremo derecho de la escala
Utilice una espiral para describir SDLC, comenzando desde el centro y expandiéndose hacia afuera una y otra vez hasta que se complete el proyecto.
Más de una vez por etapa
modelo iterativo
De manera similar al método de desarrollo del Capítulo 1, las filas de la tabla son actividades de desarrollo y las columnas son iteraciones.
Cada iteración contiene varias etapas, y cada etapa no se completará de una vez, sino que se mejorará continuamente en iteraciones posteriores.
Conceptos adicionales sobre enfoques adaptativos
desarrollo incremental
El concepto básico es que los sistemas se construyen en pequeños incrementos, creciendo orgánicamente.
Durante el proyecto, el sistema se implementa en pasos y se implementa parcialmente.
La ventaja es que los usuarios pueden obtener rápidamente parte del sistema para que el negocio pueda iniciarse lo más rápido posible.
esqueleto andante
Un enfoque temprano para construir una estructura de sistema completa pero que solo proporciona funciones básicas
Primero, proporcione un "esqueleto" del proceso de implementación completo del nuevo sistema de adelante hacia atrás, y luego use iteraciones posteriores para completar el esqueleto.
En proyectos, a menudo no es una elección extrema.
8.3 Fase de soporte
El enfoque predictivo SDLC incluye dicha fase de soporte.
El enfoque adaptativo trata la fase de soporte como un proyecto completo e independiente.
Tres actividades principales ocurren durante la fase de soporte.
Sistema de mantenimiento
Fortalecer el sistema
Usuarios de soporte
8.4 Métodos, modelos, herramientas y técnicas
métodos de desarrollo de sistemas
El alcance del método es el mayor.
Una metodología incluye un conjunto de técnicas para completar actividades y tareas, incluido el modelado de cada aspecto de un proyecto.
Modelo
Un modelo es una representación abstracta de algún aspecto específico del mundo real que permite comprender un concepto complejo centrándose sólo en las partes relevantes.
Cada modelo enfatiza información diferente.
Ya hemos entrado en contacto con algunos de estos modelos: diagrama ER, diagrama de casos de uso, diagrama de clases, diagrama de secuencia.
herramienta
soporte de software
tecnología
adquirido a través del aprendizaje
8.5 Dos métodos de construcción y modelado de software
8.5.1 Enfoque estructurado
El método estructurado se centra en el proceso y se centra en el flujo de datos. Asume que el sistema es una colección de procesos que interactúan con el flujo de datos.
El método estructurado es el mismo método tradicional que el método de predicción SDLC.
Análisis estructurado
Modelado utilizando el diagrama de flujo de datos
También se utilizarán diagramas ER.
diseño estructurado
Diseñar programas utilizando diagramas de estructura.
Requiere bajo acoplamiento y alta cohesión.
Un acoplamiento bajo significa que diferentes módulos son lo más independientes posible de otros módulos, de modo que modificar un módulo no afectará el funcionamiento de otros módulos.
Alta cohesión significa que cada módulo implementa una tarea clara
programación estructurada
Incluye un principio, un final y tres estructuras: secuencia, selección, ciclo.
Programación de arriba hacia abajo/diseño modular
8.5.2 Enfoque orientado a objetos
El enfoque orientado a objetos ve un sistema como una colección de objetos que trabajan juntos para lograr una determinada interacción.
Los objetos son cosas en el sistema que responden a mensajes.
análisis orientado a objetos
El proceso de identificar y definir casos de uso y conjuntos de objetos (clases) en un nuevo sistema.
diseño orientado a objetos
Defina todo tipo de objetos necesarios para comunicarse con personas y dispositivos y muestre cómo interactúan para completar tareas.
Utilice modelos como diagramas de clases y diagramas de casos de uso.
Programación orientada a objetos
Escriba declaraciones para definir la clase real y el rol de cada objeto de la clase.
Utilice modelos como diagramas de secuencia y diagramas de clases de diseño.
8.6 Desarrollo ágil
Actividades de desarrollo realizadas en un entorno desconocido y que cambia rápidamente.
8.6.1 Teoría y valor del desarrollo ágil
teoría central
Centrarse en responder al cambio en lugar de seguir un plan.
Valorar a las personas y las interacciones en lugar de los procesos y herramientas.
Valore el software funcional sobre la documentación completa
Centrarse en la colaboración con el cliente en lugar de negociaciones contractuales.
Describir el concepto de proyectos ágiles: caos
Eso es caos y orden: las dos primeras teorías centrales (el predominio de los valores individuales sobre los valores grupales) son la causa del caos, y este caos puede manejarse con una flexibilidad cada vez mayor. El caos es inevitable durante el proceso de desarrollo impredecible. Los desarrolladores deben aceptar el caos, pero a veces es necesario utilizar otros métodos y técnicas que son beneficiosos para agregar orden y estructura al proyecto.
En pocas palabras, significa permitir que se produzca cierto caos y al mismo tiempo garantizar el orden general.
cap09 Planificación y gestión de proyectos
Estas son las dos primeras de las seis secciones principales: Identificar el problema y obtener aprobación, Planificar y monitorear el proyecto.
9.2 Principios de gestión de proyectos
9.2.1 Requisitos para la gestión de proyectos
Según las estadísticas, menos de un tercio de los proyectos exitosos
Razones por las que algunos proyectos fracasan
Razón principal: Falta de participación de la alta dirección y de habilidades de gestión.
Falta de participación del grupo de usuarios.
9.2.2 El papel del director del proyecto
La gestión de proyectos es el proceso de organizar y dirigir a otros para lograr los resultados planificados de acuerdo con un cronograma y presupuesto previamente determinados. También se puede definir como el proceso de planificar un proyecto y luego monitorearlo y controlarlo.
Responsabilidades Internas del Gerente de Proyecto
Desarrollar el cronograma del proyecto.
Reclutar y capacitar a los miembros del equipo.
Coordinar el trabajo entre los miembros del equipo.
Evaluar los riesgos del proyecto
Monitorear y controlar los hitos del proyecto.
Gestionar personas y recursos
Responsabilidades externas del director del proyecto.
Informar del estado y progreso del proyecto.
Trabajar directamente con los clientes y otras partes interesadas.
Determinar las necesidades de recursos y obtener recursos.
Coordinar relaciones públicas.
Los gerentes de proyectos trabajan con diversos grupos de personas.
Cliente: La persona que financia el sistema.
Comité de Supervisión: compuesto por el cliente y otros altos directivos para supervisar el proyecto.
Usuario: Persona que utiliza directamente el sistema para completar tareas.
Los directores de proyectos tienen funciones duales internas y externas.
9.2.3 Gestión del proyecto y ceremonia (ceremonia)
El grado de formalidad de un proyecto, o ritual, también tiene un impacto en la gestión del proyecto.
Los proyectos más pequeños suelen realizar rituales de bajo nivel
Los proyectos más grandes y complejos suelen realizar ceremonias de alta calidad.
Los rituales del proyecto difieren cuando se utilizan métodos predictivos tradicionales versus métodos adaptativos
Los proyectos adaptativos a menudo pueden ser más formales o informales en sus métodos de gestión: UP (Proceso Unificado) es bastante formal y tiene rituales estrictos, mientras que los métodos iterativos son más informales.
9.2.4 Sistema de conocimiento de gestión de proyectos
PMBOK, consta de nueve módulos
Gestión de escala de proyecto
Gestión del tiempo del proyecto.
gestión de costos del proyecto
Gestión de la calidad del proyecto.
Gestión de Recursos Humanos del Proyecto
Gestión de la comunicación del proyecto.
gestión de riesgos del proyecto
Gestión de Adquisiciones de Proyectos
Manejo del proyecto de integración
9.2.5 Gestión ágil de proyectos
Gestión de proyectos ágiles
El alcance no se comprende bien pero es necesario controlarlo.
Utilice varias pautas para determinar las prioridades comerciales.
Gestión ágil del tiempo
El horario debe ser flexible para adaptarse a los cambios.
Gestión ágil de costes
Los costos son más difíciles de estimar, por lo que el control de costos no es tan importante como lo es en un enfoque predictivo.
Gestión ágil de riesgos
Los aspectos de alto riesgo del proyecto se completan primero.
Gestión ágil de la calidad
Realizar una evaluación de calidad después de cada iteración.
9.3 Proceso central 1: identificar el problema y obtener la aprobación
9.3.1 Identificar el problema
Tres propósitos principales para el desarrollo de nuevos sistemas
Responder a nuevas oportunidades de desarrollo
ocupar cuota de mercado
Resolver problemas comerciales existentes
Responder a comandos externos
Legales, fiscales, etc.
Una forma eficaz de definir el problema es crear un Documento de visión del sistema (SVD)
Incluye tres partes
Descripción del problema
¿Cuáles son los problemas y las soluciones?
Capacidades del sistema
¿Qué características tendrá el nuevo sistema?
beneficios de negocio
Beneficios para la organización (tangibles o intangibles)
9.3.2 Cuantificar los factores de aprobación del proyecto
Necesito ser claro
Tiempo estimado de finalización
Costos de desarrollo estimados
Costos de funcionamiento estimados
Pre-ganancias
análisis coste-beneficio
algunos conceptos
VAN (valor actual neto) valor actual neto
El valor presente de los beneficios y costos de una inversión particular.
Calculado restando los costos usando "ganancias actuales" (usando un factor de descuento)
punto de recuperación de costos
Durante este período, las ganancias en dólares compensaron los costos en dólares.
beneficios tangibles
La parte del beneficio que se puede medir en términos de dinero.
beneficios intangibles
Beneficios para la organización pero que no pueden medirse cuantitativamente ni estimarse con precisión.
Mejoras en los niveles de servicio (en formas que no se pueden medir en dólares)
Mejora de la satisfacción del cliente (no medible en dólares)
Supervivencia: es necesario competir así.
Necesidad de desarrollar experiencia interna (por ejemplo, proyectos piloto para nuevas tecnologías)
método de análisis costo/beneficio
Utilice el valor actual como valor estimado
Calcular la vida del sistema.
Calcule el período de recuperación y los ingresos finales acumulando el valor actual neto cada año.
Ejemplo
El período de recuperación utiliza los puntos de inflexión positivos y negativos del valor presente neto acumulado como parte entera, y la parte decimal se calcula usando (último valor negativo/diferencia total)
9.3.3 Evaluación de riesgos y análisis de viabilidad
Determinar el riesgo y la viabilidad de la organización.
Evaluar los riesgos técnicos y la viabilidad.
Evaluar el riesgo y la viabilidad de los recursos.
Determinar los riesgos y la viabilidad del cronograma.
9.3.4 Trabajar con los clientes tras la aprobación
Revisión y aprobación del Comité Ejecutivo
Las juntas directivas deben revisar y aprobar proyectos muy grandes
Las partes interesadas involucradas deben comprender qué se espera de ellas.
Los departamentos de SI necesitan saber qué hacer en términos de personal y soporte.
Toda la organización debe ser consciente de este proyecto y su importancia.
9.4 Proceso central 2: Planificar y monitorear proyectos
9.4.1 Establecer el entorno del proyecto
A diferencia del diseño del entorno mencionado anteriormente, el entorno del proyecto aquí se refiere al entorno de trabajo y la comunicación dentro y fuera del equipo, en lugar de la tecnología requerida por el sistema, etc.
Registros y Comunicaciones - Internas/Externas
Ambiente de Trabajo – Soporte/Equipo/Herramientas
PC o estación de trabajo
Software y herramientas de desarrollo personal.
Servidor con biblioteca de recursos, herramientas de comunicación.
Oficinas, salas de conferencias, impresoras y otros equipos.
Empleados de apoyo (fuera del equipo)
Procesos y procedimientos
Informes y Documentación
programación
prueba
Entregables
Control de código y versión.
9.4.2 Organizar el progreso del trabajo
Utilice el cronograma de iteración del proyecto para asignar casos de uso a las iteraciones.
Programe un cronograma detallado de tareas y trabajo que deben completarse en cada iteración: utilice un cronograma de trabajo detallado
Tres pasos para crear un cronograma de trabajo detallado iterativo
Crear estructura de desglose del trabajo WBS
Estimar el esfuerzo e identificar dependencias.
Crear un horario usando un diagrama de Gatt
La estructura de desglose del trabajo contiene
Base de descomposición
tiempo requerido
Orden de ejecución
Evaluar el tiempo basándose en información relevante de WBS y descubrir dependencias, posiblemente utilizando la ruta crítica
Un diagrama de Gantt es un gráfico de barras con actividades en barras y que se muestra en una línea de tiempo horizontal.
Excepto la primera tarea, cada tarea tiene una tarea predecesora.
La parte de color claro es el camino crítico, que afecta todo el progreso y debe ser monitoreado de cerca.
9.4.3 Asignación de personal y recursos
cinco tareas
Crear un plan de recursos en el proyecto.
Identificar y solicitar empleados técnicos específicos.
Identificar y solicitar empleados usuarios específicos
Organizar equipos en grupos de trabajo.
Establecer ejercicios iniciales de formación y team building.
9.4.4 Proceso de trabajo de evaluación
exposición retrospectiva
9.4.5 Proceso de seguimiento y corrección
Asignar trabajo a individuos o equipos.
estado de cobro
¿Se completó la tarea y se logró el objetivo?
Analizar anomalías
¿Importan las excepciones?
tomar la acción correcta
cap10 Diseño orientado a objetos: principios de diseño
10.2 Diseño orientado a objetos: el puente entre el análisis y la implementación
10.3 Diseño de arquitectura orientada a objetos (diseño de alto nivel)
Los sistemas de software generalmente se dividen en dos tipos
Sistema de usuario único: ejecutado en el escritorio del usuario o en un servidor sin compartir recursos
Sistemas de nivel empresarial: los componentes se pueden compartir entre varias personas u organizaciones.
Sistema servidor/cliente
Sistema de Internet (navegador/servidor)
Tres diferencias básicas que afectan el diseño de la arquitectura del sistema.
estado
Cliente/servidor es un sistema basado en estados y las conexiones cliente/servidor son de larga duración.
Los sistemas de Internet son sistemas sin estado y las conexiones no son a largo plazo.
Implementación de cliente
Visualización directa de pantallas y tablas.
Las pantallas y tablas se muestran a través del navegador.
Implementación del servidor
La aplicación o el cliente se conecta directamente al servidor.
El cliente se conecta indirectamente al servidor de aplicaciones a través del navegador.
Diagrama de componentes y diseño de arquitectura.
Un tipo de diagrama de diseño que muestra la arquitectura general del sistema y los componentes lógicos dentro de ella, ilustrando cómo se implementará el sistema.
El diagrama de componentes identifica los componentes del sistema para su lógica, reutilización y portabilidad.
Los elementos básicos de un diagrama de componentes son elementos componentes con API.
Las API son métodos públicos a los que puede acceder el mundo exterior.
Hay dos tipos de API en los diagramas de componentes.
Toma de entrada (Socket)
Puerto de salida (Puerto)
Ejemplo
Caso: Diseño de arquitectura de Internet de dos capas (en realidad también puede ser de tres capas)
Capa de interfaz de usuario (capa de vista)
Capa de dominio (capa lógica)
Capa de acceso a la base de datos (capa de datos)
Representar usando diagramas de componentes.
10.4 Principios básicos del diseño detallado orientado a objetos
Pasos de diseño detallado orientado a objetos
Desarrollar diagramas de clases de diseño preliminares.
Utilice tarjetas CRC para determinar las responsabilidades de clase y la cooperación para casos de uso.
Desarrolle diagramas de secuencia detallados para cada caso de uso: desarrolle primero diagramas de secuencia preliminares, luego diagramas de secuencia de múltiples capas
Agregar características del método e información de navegación.
Divida la solución en paquetes (diagrama de paquete)
10.5 Clase de diseño y diagrama de clases de diseño
10.5.1 Símbolos de diseño
Un prototipo es una forma de clasificar elementos en función de sus características, representado por <<>>
Hay cuatro tipos de prototipos de diseño.
clase de entidad
El identificador de diseño de la clase de dominio del problema, generalmente persistente, representado por <<entidad>>
Las clases persistentes se refieren a clases que todavía tienen datos después de que se apaga el sistema. Al implementar métodos, sus datos se escriben en la base de datos o en el archivo.
Ejemplo
Estudiantes y docentes en el sistema de gestión educativa.
Clase de control
Es una clase que desempeña un papel de coordinación entre clases de vista y clases de entidad, similar a enrutadores o conmutadores, representados por <<controlador>>
Ver clase
Las clases de vista, o clases de límite, están en el límite de automatización del sistema, similares a cuadros de entrada o páginas web, frente a los usuarios, y están representadas por <<límite>>
Clase de acceso a la base de datos
Es una clase que obtiene datos de la base de datos y los devuelve, representado por <<dataAccess>>
Cada clase de prototipo tiene un símbolo diferente.
10.5.2 Representación de clase de diseño
Definir el formato de los atributos en una clase de diseño.
visibilidad
Indica (o -) si otro objeto puede acceder directamente a la propiedad. Generalmente privado(-) en lugar de público()
Nombre de la propiedad
minúsculas camello
tipo de expresión
clase, cadena, número entero, doble, fecha
valor inicial
propiedad
Entre llaves, como {key}
Definir el formato del método (características del método)
visibilidad del método
nombre del método
Tipo de valor de retorno del método
lista de parámetros
Ejemplo
Hay dos puntos entre el nombre y el tipo de la propiedad, y lo mismo entre la lista de parámetros y el tipo de valor de retorno del método hay un signo igual antes del valor inicial;
Utilice nombres de clases en cursiva para indicar clases abstractas
Las clases que solo permiten la herencia pero no la creación de instancias generalmente representan conceptos abstractos de nivel superior.
10.5.3 Desarrollar diagramas de clases de diseño preliminares.
Refinamiento de atributos
Los diseñadores determinan los tipos de atributos según la experiencia. En la mayoría de los casos, los atributos son invisibles (privados).
Visibilidad de navegación
La visibilidad de navegación se refiere a si una clase es visible o invisible para otra clase, lo que indica la capacidad de un objeto para ver e interactuar con otro objeto.
Utilice una flecha para indicar que la dirección apuntada es el lado visible
En este ejemplo, cliente se refiere a la clase de venta, por lo que la venta es visible para el cliente, pero el cliente no es visible para la venta.
Tipo de visibilidad de navegación
Representa una relación de uno a muchos entre superiores y subordinados, que generalmente apunta de superiores a subordinados.
Asociación forzada, donde un objeto de una clase no puede existir sin un objeto de otra clase, normalmente navegando de una clase más independiente a una clase dependiente
Por ejemplo, en el caso de cliente y venta anterior, la venta no tiene sentido cuando no hay clientes.
Cuando un objeto requiere información de otro objeto, es posible que se necesite una flecha de navegación
La visibilidad de la navegación puede ser bidireccional.
Pasos para desarrollar diagramas de casos de uso preliminares
Caso de uso tras caso de uso, agregado al diagrama
Seleccione las clases de dominio involucradas en el caso de uso (consulte la idea de requisitos previos y condiciones posteriores)
Las condiciones previas y posteriores deben estar en la descripción del caso de uso en el Capítulo 5.
Agregue una clase de controlador para encargarse del caso de uso
Utilice pautas para determinar las necesidades iniciales de visibilidad de navegación y agréguelas al diagrama.
Describe las propiedades de cada clase en detalle con visibilidad y tipo.
Tenga en cuenta que las asociaciones y la multiplicidad a menudo se eliminan de los diagramas de clases de diseño, al igual que se enfatiza la navegación en el texto, pero a menudo se conservan.
Del diagrama de clases de dominio al diagrama de clases de diseño preliminar
10.6 Uso de tarjetas CRC para diseño detallado
Tarjeta CRC significa Clase, Responsabilidad, Colaboración
El diseño orientado a objetos consiste en asignar responsabilidades a las clases y cómo trabajan juntas para completar un caso de uso.
La tarjeta CRC se divide en tres áreas: nombre de clase, nombre de responsabilidad y clase de cooperación.
Pasos para usar la tarjeta CRC
Comience con un conjunto de tarjetas CRC sin usar y avance a través de un caso de uso tras otro.
Seleccione un caso de uso y seleccione una tarjeta como su controlador
Determine la clase de dominio que es principalmente responsable de este caso de uso. Los objetos de esta clase recibirán mensajes del controlador, determine las responsabilidades y escríbalas en el lado izquierdo de la tarjeta.
Identifique otras clases que cooperen con la clase de objeto principal para completar el caso de uso y escríbalas en el lado derecho de la tarjeta CRC.
Después de determinar las categorías de cooperación, realice las operaciones anteriores para cada categoría de cooperación (determinar responsabilidades/buscar categorías de cooperación)
Las clases de interfaz de usuario y las clases de acceso a la base de datos se pueden agregar adecuadamente
Utilice los resultados de la tarjeta CRC para actualizar el diagrama de clases de diseño preliminar.
Actualice el método: la responsabilidad en la tarjeta CRC se convierte en un método (pero no hay visibilidad ni expresión de tipo de retorno, es decir, no se agregan características del método)
Actualizar la visibilidad de la navegación
Ejemplo
Diagrama de clases de diseño preliminar.
Diagrama de clases de diseño actualizado
10.7 Algunos principios del diseño detallado
acoplamiento bajo
Alta cohesión
Protección variable
indirecto
Responsabilidades del objeto
cap11 Diseño orientado a objetos: implementación del diseño
11.2 Diseño detallado de sistemas multicapa.
Patrones de diseño
Patrones de diseño: técnicas y plantillas de diseño estándar ampliamente reconocidas como buenas prácticas.
Para problemas comunes de diseño/codificación, los patrones de diseño sugieren la mejor manera de manejar el problema.
elementos de patrones de diseño
Nombre del esquema
Problemas que requieren soluciones
modelo de resolución de problemas
Caso patrón
Beneficios y consecuencias de los patrones
El primer ejemplo de un patrón de diseño de programación es el patrón Controlador.
Los controladores de casos de uso se crean artificialmente para pasar mensajes desde la capa de vista a la capa de dominio para reducir el acoplamiento.
Ventajas y consecuencias
Reduce el acoplamiento entre la capa de dominio y la capa de vista.
proporciona una capa de indirección
Los controladores y las clases de dominio están estrechamente acoplados
Si no tiene cuidado, el controlador contendrá mucha lógica irrelevante, especialmente lógica empresarial.
11.3 Implementación de casos de uso y diagrama de secuencia SSD
Implementación de casos de uso: el proceso de diseñar casos de uso en detalle utilizando diagramas de interacción.
Hay dos tipos de diagramas de interacción.
Diagrama de flujo
Los diagramas de secuencia se muestran ampliando el diagrama de secuencia del sistema.
ver objeto de capa
Objetos de capa de dominio (generalmente se hacen primero)
objeto de capa de acceso a datos
Diagrama de colaboración
11.3.1 Comprensión de los diagramas de secuencia
La diferencia entre el diagrama de secuencia del sistema y el diagrama de secuencia.
El diagrama de secuencia del sistema tiene un solo objeto, que representa el sistema: sistema, mientras que el diagrama de secuencia extiende el objeto hacia el interior del sistema.
El diagrama de secuencia del sistema tiene solo dos líneas de vida, que representan a los actores y al sistema, y cada objeto en el diagrama de secuencia tiene una línea de vida, aunque la longitud puede ser diferente (el tiempo comienza cuando se crea el objeto);
En el mismo caso de uso, la parte del límite de automatización del diagrama de secuencia del sistema y el diagrama de secuencia son los mismos (el conjunto permanece sin cambios), es decir, la entrada al sistema y la salida del sistema al exterior son las mismo.
Los diagramas de secuencia tienen una sección de línea de vida especial llamada línea de vida de actividad.
La línea de vida de actividad representa el tiempo que un objeto está en el estado de ejecución activo. El estado activo dura hasta que se guardan todos los datos o se llaman otros métodos.
En este diagrama de secuencia de creación de un caso de uso de usuario: se crearon Customform y CustomHandler, y el objeto personalizado se crea después del método createCustom, por lo que la hora de inicio de la línea de vida es diferente y la barra rectangular es la línea de vida activa;
11.3.2 Proceso de diseño de implementación de casos de uso
pasos de diseño
Desarrollar un diagrama de clases de diseño preliminar que muestre la visibilidad de la navegación.
Utilice tarjetas CRC para asignar funciones a clases en casos de uso
Desarrollar diagramas de secuencia detallados para cada caso de uso.
Diagrama de secuencia preliminar
Diagrama de secuencia multinivel
Utilice tarjetas CRC y diagramas de secuencia detallados para actualizar los diagramas de clases de diseño y agregar funciones de método.
Diagramas de clases de diseño de paquetes.
11.3.3 Caso: Diagrama de clases de diseño preliminar para la creación de una cuenta de usuario
Desarrollar un diagrama de secuencia preliminar basado en el diagrama de clases de diseño preliminar desarrollado previamente.
Expanda el diagrama de secuencia del sistema y marque los objetos de clase que deben usarse en el sistema original:, y todavía hay dos puntos delante.
Determine mensajes internos entre objetos, agregue mensajes y activaciones para completar la colaboración
El formato del mensaje es coherente con el diagrama de secuencia del sistema: *[codición] valor_retorno:=nombre_función(lista_parámetros) También puede utilizar una flecha invertida discontinua como valor de retorno.
subtema
11.3.5 Directrices y supuestos para desarrollar diagramas de secuencia preliminares
guía
Aceptar cada mensaje e identificar otros mensajes internos resultantes de este mensaje de entrada.
Al procesar cada mensaje, especifique el conjunto de clases afectadas.
Enriquezca la estructura del mensaje, agregue condiciones verdaderas y falsas, bucles, valores de retorno, transferencia de parámetros, etc.
hipótesis
Hipótesis de la perfección técnica
hipótesis de la perfección de la memoria
ninguna suposición de anomalía
11.3.6 Desarrollo de diagramas de secuencia multicapa
Lo anterior es solo un diagrama de secuencia preliminar para la capa de dominio (capa lógica). Para describir los casos de uso con más detalle, es necesario desarrollar diagramas de secuencia para la capa de acceso a datos y la capa de visualización.
11.4 Utilice el diagrama de comunicación del diagrama de colaboración
11.5 Diagrama de clases de diseño de paquetes y actualización
Actualizar diagrama de clases de diseño
Según la información del diagrama de secuencia, agregue características del método para actualizar el DCD
Tres tipos de métodos
Método constructor: crear una nueva instancia de objeto
Métodos de lectura y escritura de datos: obtener o actualizar valores de atributos
Métodos específicos de casos de uso: incluidos en el diagrama de clases de diseño
Mapa del paquete
Un diagrama de paquete es un diagrama de alto nivel que asocia grupos de clases relacionados.
Utilice iconos similares a carpetas para representar paquetes y las clases se colocan en los paquetes correspondientes según las capas a las que pertenecen.
Utilice flechas de puntos para indicar dependencias, incluidas las dependencias entre clases y las dependencias entre paquetes.
Ejemplo
Diagrama de paquete parcial con un solo caso de uso
Diagrama de paquete del subsistema
11.6 Otros patrones de diseño comunes
adaptador
Cuando es necesario conectar dos sistemas pero las interfaces entre ellos no coinciden, se necesita un adaptador.
Conecte interfaces no coincidentes reescribiendo datos
Por ejemplo: cuando se enfrenta a diferentes proveedores (impuestos, gastos de envío), solo necesita reescribir el adaptador
fábrica
Las clases de fábrica se utilizan para crear muchos tipos diferentes de instancias de clases de utilidad.
Generalmente, una clase de herramienta solo necesita una instancia, y la fábrica debe garantizar que solo haya una instancia.
único
Un singleton tiene una variable estática que apunta a una instancia de sí mismo. Verifique esta variable a través de algún método. Si está vacío, puede crear una instancia y asignarla a la variable; si no está vacío, puede devolver directamente la instancia de la variable.
Conexión de clase{ conexión estática privada = nulo; getConnection estática pública sincronizada(){ si conexión == nulo { conexión=nueva conexión(); } conexión de retorno; } }
Fábrica y singleton
La lógica básica de las fábricas y los singleton es la misma: ambos deben garantizar que solo haya una instancia del objeto y ahorrar memoria.
Pero la fábrica debe ser responsable de múltiples clases; el singleton solo verifica las variables de instancia estáticas dentro de la clase.