4.5. Modelo de dominio

Un Modelo de Dominio es un artefacto de la disciplina de análisis, construido con las reglas de UML durante la fase de concepción, en la tarea construcción del modelo de dominio, presentado como uno o más diagramas de clases y que contiene, no conceptos propios de un sistema de software sino de la propia realidad física.

Un modelo de dominio puede incluir: 
- Una jerarquía de los objetos que existen en la aplicación. 
- Las propiedades de dichos objetos. 
- Las acciones que pueden llevar a cabo los objetos. 
- Los parámetros requeridos por las acciones, y 
- Las pre-condiciones y post-condiciones de las acciones.

Los modelos de dominio puede utilizarse para capturar y expresar el entendimiento ganado en un área bajo análisis como paso previo al diseño de un sistema, ya sea de software o de otro tipo. Similares a los mapas mentales utilizados en el aprendizaje, el modelo de dominio es utilizado por el analista como un medio para comprender el sector industrial o de negocios al cual el sistema va a servir. 

Bibliografía: 

Lozano Pérez, M. (2000). Ingeniería del software y bases de datos: tendencias actuales (1st ed., pp. 41-42). Ciudad Real, España: Univ de Castilla La Mancha.

4.4. Modelo de casos de uso

El objetivo final de este flujo de trabajo es descubrir y averiguar lo que se desea que el sistema informático haga a través de casos de usos.

Un caso de uso especifica una secuencia de acciones, incluyendo variantes, que el sistema puede realizar y que ofrece un resultado observable o tangible para un determinado usuario.

La idea detrás de los casos de usos es especificar lo que debe hacer el sistema viendo como y para que lo utilizaran los usuarios. Cada manera en que los usuarios emplean el sistema representa un caso de uso, y uniendo todos los caso de uso tendremos la especificación total del sistema, lo que queremos que haga el sistema.

Los caso de uso recogen los requisitos funcionales( que queremos que haga) y no funcionales (restricciones de tiempo, de sistema operativo, etc) del sistema. Adicionalmente los casos de uso contemplan también la interfaz de usuario para que este realice cada caso de uso.

Bibliografía: 

Loïc Martínez, F., & Segovia, F. (2005). Introducción a la Ingeniería del software Finanzas para la nueva economía (1st ed., p. 348). Madrid España: Delta Publicaciones.

4.3. Modelo de requisitos

Tipos de Requisitos 

Estos requisitos se pueden clasificar en: funcionales y no funcionales. Requisitos Funcionales: “Describen  las  funciones  que  el  software  debe  ejecutar,  a veces se  conocen  como capacidades”. SEWBOK, 2004: 2-2. 

A los requisitos funcionales se los puede dividir en: 

• De usuario: Los requerimientos de usuario, según Sommeville, 2005: 116; “Son declaraciones, en lenguaje natural y en diagramas, de los servicios que se espera que el sistema provea y de las restricciones bajos las cuales se debe operar. 

• Del sistema: “Establecen con detalle los servicios y restricciones del sistema. El documento de requerimientos del sistema, algunas veces denominado especificación funcional, debe ser preciso”. Sommerville, 2005: 118


Bibliografia:

Sommerville, I. (2005). Ingeniería del Software. Madrid: Pearson Education. Libro que enfoca todos los procesos de la Ingeniería de Software.

4.2. Objetos

Kendall (2005) afirma que "Los objetos son personas, lugares o cosas que son relevantes para el sistema bajo análisis. Los objetos podrían ser clientes, artículos, pedidos, etc. Los objetos también podrían ser pantallas GUI o áreas de texto en la pantallas".

El objeto es una instancia de una clase. Un objeto es capaz de almacenar estados a través de sus atributos y responder a las llamadas enviadas a el, a fin de relaciones y enviar llamadas a otros objetos.

Ejemplo de objetos de la clase Humanos:

JOHN es un objeto de la clase HUMANO, con todos los atributos de esta clase, pero su individualidad.

  Por lo tanto, el objeto es una discriminación de la clase, la clase deber ser una generalización de un conjuntos de objetos idénticos o con la misma base.

• Llama o mensaje es una llamada a un objeto para invocar uno de sus métodos, activando un comportamiento descrito por su clase
• La herencia es el mecanismo por el cual una clase (subclase) puede extender de otra clase (superclase), aprovechando sus comportamiento (métodos) y los posibles estados (atributos). Hay herencia múltiple cuando una subclase tiene mas de una superclase.
• La asociación es el mecanismo por el que un objeto utiliza los recurso de otro. Puede ser una simple asociación "utiliza un" o una " parte de". Por ejemplo: Una persona usa un teléfono. La tecla "1" es parte de un teléfono.
• La encapsulación es la separación de los aspectos internos y externos de un objeto. Este mecanismo se utiliza amplia mente para evitar el acceso directo al estado de un objetos (sus atributos), apenas siendo accesible los métodos que alteran estos estados.
• La abstracción es la capacidad de centrase en los aspectos esenciales de un contexto haciendo caso omiso de las características de menor importancia o accidentales. En el modelo orientado a objetos, una clase es una abstracción de entidades existentes en el dominio del sistema de software.
• El polimorfismo permite que una referencia a un tipo de una superclase tenga comportamiento cambiado de acuerdo a las instancia de la clase hija asociada con ella. El polimorfismo permite la creación de superclases abstractas, es decir, con los métodos definidos ( declarados) y no implementados, donde la implementación se produce solo en subclases no abstractas.

Bibliografía: 

Durango, A., & Arias, Á. (2014). Ingeniería y Arquitectura del Software (1st ed.). United States: IT Campus Academy.

4.1. Clases

Los objetos se representan y agrupan en clases que son optimas para reutilizarse y darles mantenimiento. UN a clase define el conjunto de atributos y comportamientos compartidos por cada objeto de la clase. Por ejemplo, los registros de los estudiantes en la sección de un curso almacenan información similar para cada estudiante. Se podría decir que los estudiantes constituyes una clase. Los valores podrían ser diferentes para cada estudiante, pero el tipo de información es el mismo. Los programadores deben definir las diversas clases en el programa que escriben. Cuando el programa corre, los objetos se pueden crear a partir de la clase establecida. El termino instanciar se usa cuando un objeto se crea a partir de una clase. Por ejemplo un programa podría instanciar a un estudiante llamado Peter Franco-manco como un objeto de la clase denominada estudiante.

Lo que hace a la programación orientada a objetos, y por consiguiente al análisis y diseño orientado a objetos, diferente de la programación clásica, es la técnica de poner todos los atributos y métodos  de un objeto en una estructura independiente, la propia clase. Esta es una situación común en el mundo física,. Por ejemplo, un paquete de haría para pastel empacado es similar a una clase ya que contiene los ingredientes y las instrucciones para mezclar y hornear el pastel. Un suéter de lana es similar a una clase por que incluye una etiqueta con instrucción del cuidado que advierten que se debe lavarlo a mano y ponerle a secar extendido.

Cada clase debe tener un nombre que la distinga de todos las demás. Los nombres de clase normalmente son sustantivos o frases cortar y empiezan con una letra mayúscula.
Un atributo describe alguna propiedad de todos los objetos de la clase, un ejemplo podría ser los atributos tamaño, color, marca y modelo para un carro.
Por ultimo, un método es una acción que se puede solicitar a cualquier objeto de la clase. Los métodos son los procesos que una clase sabe como realizar. Los métodos también se llaman operaciones. Por ejemplo para la clase RentaAuto podría tener los siguiente métodos: inicioRenta(), entregaAuto(), y servicio(). Al especificar métodos. normalmente la primera letra es minúscula


Un ejemplo de las clases con su respectivo modelo UML.

Bibliografía: 

Kendall, K., & Kendall, J. (2005). Análisis y diseño de sistemas (6th ed., pp. 658-659). Simón Bolivar, Venezuela: Pearson Educación.