Desarrollo de Software Orientado a Objetos.

Kom i gang. Det er Gratis
eller tilmeld med din email adresse
Desarrollo de Software Orientado a Objetos. af Mind Map: Desarrollo de Software Orientado a Objetos.

1. 3.) Modelo de Diseño

1.1. Es el complemento y formalización adicional al modelo de análisis, ya que por si mismo no es suficientemente formal para llegar al código fuente. Es resultado de este modelo son especificaciones detalladas de todos los objetos, operaciones y atributos

1.1.1. El ambiente es un factor importante para la creación del sistema, este cambian aspectos como los requisitos de rendimientos, concurrencias (ejecución simultanea), lenguaje de programación, etc.

1.2. Algo importante de este modelo de diseño es valor si los modelos anteriores (modelo de requisitos y análisis) son apropiados para la implementación del sistema.

1.2.1. tomado de: desktop-9415ab1a-09f7-4ee1-a6c0-b736fc5b2832

1.2.1.1. Si esto no funciona, se cambian los aspectos al finalizar el modelo de diseño ya que si se implementan los cambias en este modelo, seria una practica errónea.

1.3. Como se dijo anterior mente, este modelo es la formalización del espacio dimensional de análisis. Este imparte una nueva dimensión que corresponde al ambiente de implementación.

1.3.1. tomado de: desktop-9399d5f4-3a75-4b2f-9219-b11c0b9c651b

1.3.1.1. La nueva dimensión, Ambiente de implementación, tiene como función refinar el modelo hasta que sea fácil escribir el código fuente del sistema.

1.4. Los modelos de análisis y diseño deben realizarse por separado para tener aplicaciones particulares en el sistema

2. 4.) Modelo de Implementación.

2.1. Al tener el modelo de diseño definido, se genera el código final. Este código debe implementarse con un lenguaje de programación sencillo y adaptado junto con la base de datos que usara el sistema.

2.2. Lenguaje de Programación:

2.2.1. El lenguaje de programación se escoge dependiendo el diseño obtenido en el modelo anterior, pero este lenguaje no depende de detalles mínimos ya que el lenguaje puede cambiar a futuro

2.2.1.1. Se debe usar guías de programación para decidir aspectos claves como:

2.2.1.1.1. Asignación de variables

2.2.1.1.2. Documentación en lineal

2.2.1.1.3. Estilo de programación

2.2.1.1.4. Métodos de documentación

2.3. Herramientas que se usan para implementar le código:

2.3.1. Editor de texto plano para escribir el código fuente.

2.3.2. Interpretar que el código fuente se pueda procesar y se pueda ejecutar.

2.3.3. Deputar los errores corrigiendo el código fuente hasta que se pueda ejecutar sin errores.

3. 5.) Modelo de Pruebas.

3.1. En este caso, existen varios tipos de pruebas que se aplican durante el proceso de desarrollo. Estas pruebas realizadas al final, pueden aumentar considerablemente el costo total del producto final.

3.1.1. Las pruebas se hacen en el transcurso del desarrollo del sistema ya que este modelo debe centrarse en la certificación de calidad del sistema y no en la búsqueda de errores.

3.2. Hay dos tipos de pruebas :

3.2.1. Verificacion:

3.2.1.1. Este revisa si el resultado corresponde con las especificaciones del sistema

3.2.2. Vlaidación:

3.2.2.1. Este revisa si el resultado del sistema es lo que el cliente esperaba.

3.3. En este modelo también se realizan pruebas que pongan a prueba el sistema.

3.3.1. Algunas de esas pruebas son:

3.3.1.1. Prueba de regresión

3.3.1.2. Prueba de rendimiento a operaciones normales y extremas.

3.3.1.3. Prueba de ergonomía o de interfaces

3.3.1.4. prueba de documentación alojada en el sistema y en línea.

3.3.1.5. Prueba de estrés.

4. Referencias

4.1. Weitzenfeld, A. (2005). Desarrollo de Software Orientado a Objetos. In Ingeniería de Software Orientada a Objetos con UML, Java e Internet (p. [193]). Cengage Learning. https://link.gale.com/apps/doc/CX3004300050/GVRL?u=unad&sid=bookmark-GVRL&xid=8f31e145

5. 1.) Modelo de Requisitos

5.1. Es el primero en desarrollarse.

5.1.1. Tiene como objetivo limitar o precisar el sistema (programa). También, capturar la funcionalidad que ofrecerá desde el punto de vista o perspectiva del usuario.

5.1.1.1. Este modelo se desarrolla a través de la metodología ObjectOry. Este modelo de requisitos consta de tres modelos primordiales en esta metodología.

5.2. Metodología ObjectOry

5.2.1. Tomado de: slideplayer.es/slide/2352538/

5.2.1.1. Modelo de Comportamiento (Casos de Uso):

5.2.1.1.1. Se especifica el funcionamiento del sistema basándose en la perspectiva del usuario.

5.2.1.1.2. Conceptos usados del modelo:

5.2.1.1.3. Es decir, el actor es el usuario externo no necesariamente el usuario final, que accede al sistema para realizar acciones que identifique la funcionalidad del mismo.

5.2.1.2. Modelo de Presentación (Interfaces/borde):

5.2.1.2.1. Especifica cómo interactúa el sistema a la hora de ejecutar los casos de uso por medio de actores externos.

5.2.1.2.2. Especifica en detalle cómo se verán las interfaces del los casos de uso del sistema para saber la funcionalidad.

5.2.1.3. Modelo de Información (Dominio del Problema):

5.2.1.3.1. Se quiere especificar la estructura del sistema en términos de objetos. Esto se hace a través de diagramas para saber si hay objetos que deban se guardados en base de datos o no. También se especifica para organizarse como parámetro y ser llamado entre funciones en el sistema.

6. 2.) Modelo de Análisis

6.1. Al tener listo el modelo de requisitos, se realiza el modelo de análisis.

6.1.1. este modelo se desarrolla por medio del modelo de casos. tiene como objetivo comprender y generar una arquitectura de objetos para el sistema.

6.1.1.1. Este modelo es una representación conceptual, este corresponde al problema y al modelo de requisitos traducidos a términos de cases de objetos.

6.1.1.1.1. Las clases se forman para lograr la arquitectura del modelo

6.2. Arquitectura de Clases:

6.2.1. es una arquitectura de objetos que sirve como base para el diseño del sistema.

6.2.2. Las dimensiones son grupos de objetos que integran la arquitectura deseada.

6.2.2.1. es decir, si hay un grupo de objetos se le denomina una dimensión y así sucesivamente. Pero en términos generales, una arquitectura puede incluir una serie de dimensiones dependiendo el sistema a construir.

6.3. Modelo Vista, Control

6.3.1. Este modelo se usa mucho para la construcción de la arquitectura. Se divide en tres dimensiones:

6.3.1.1. Vista (Presentación): Son las interfaces que se le presentan al usuario para le manejo de la información. Esta información es el dominio del problema para ser almacenada en una base de datos

6.3.1.2. Control (Comportamiento): Es el comportamiento o manipulación de la información a través de diversas presentaciones independientes.

6.3.1.3. Modelo (Información): A pesar de ser un modelo de tres dimisiones dependientes, se muestra la información independiente de la propia información y también se muestra cómo se controla la información.

6.4. Clases de Estereotipos:

6.4.1. tomado de: player.slideplayer.es/7/1674729/data/images/img6.jpg

6.4.2. Es la razón de un objeto dentro de la arquitectura, esta se conoce como estereotipo. con la metodología casos de uso, se imparte tres dimensiones en estas clases.

6.4.2.1. Estereotipo Entidad:

6.4.2.1.1. Los objetos que guardan información sobre el estado interno del sistema a corto y a largo plazo corresponde al dominio del problema

6.4.2.2. Estereotipo Borde o Interface:

6.4.2.2.1. Objetos que implementan interfaces del sistema para todos los actores humanos y no humanos.

6.4.2.3. Estereotipo Control:

6.4.2.3.1. Objetos que tienen el comportamiento o control de la lógica de los casos de uso especificando el estado del sistema, si cambia y como lo hace. (cambio de estado del sistema por medio de casos de uso)

7. Entornos de Programación OO

7.1. Java

7.1.1. Lenguaje de programación de alto nivel orientado a objeto

7.1.1.1. Usa sintaxis C y C++

7.1.1.1.1. lenguaje sensible con las mayúsculas y minúsculas.

7.1.2. Reconocimiento de Interfaz:

7.1.2.1. Se puede compilar, ejecutar, depurar y documentar aplicaciones.

7.1.2.2. Crear interfaces gráficas de usuario.

7.1.2.3. Biblioteca de base de datos

7.1.3. Estructura:

7.1.3.1. Tomado de:https://i.imgur.com/eptnsL6.png

7.2. Python

7.2.1. Lenguaje de programación orientado a objetos, imperativa y funcional. Es Lenguaje multiplataforma

7.2.1.1. lenguaje sensible con las mayúsculas y minúsculas.

7.2.2. Reconocimiento de Interfaz:

7.2.2.1. Se puede compilar, ejecutar, depurar y documentar aplicaciones.

7.2.2.2. Crear interfaces gráficas de usuario.

7.2.2.3. Biblioteca de base de datos

7.2.3. Estructura:

7.2.3.1. Funciones-en-Python-Estructura-de-una-funci-n-768x576

7.3. C#

7.3.1. Lenguaje de programación orientado a objetos usando desde la plataforma Visual Studio para Windows.

7.3.2. Reconocimiento de Interfaz:

7.3.2.1. Se puede compilar, ejecutar, depurar y documentar aplicaciones.

7.3.2.2. tomaod de:https://parzibyte.me/blog/wp-content/uploads/2021/05/Cambiar-color-de-texto-en-consola-con-C.png

7.3.2.3. Crear interfaces gráficas de usuario.

7.3.2.4. Biblioteca de base de datos

7.3.3. Estrucura