domingo, 20 de octubre de 2019

Unidad 4: Modelo de Análisis

El modelo de análisis proporciona una comprensión detallada de los  requisitos e impone una estructura del sistema a  mantener cuando se le dé forma.


4.1-Clases:
Una clase de objetos es una abstracción sobre un conjunto de objetos que identifica atributos comunes ( como en modelo semántico de datos) y los servicios u operaciones que son proporcionados por cada objeto.

  • Clases Entidad: Se refieren a información que se manipula en la realización del caso de uso.
  • Clases Interfaz (boundary): 
  1. Identificar una clase interfaz por cada actor humano, y que sea esa clase la que representa a la ventana o lo que sea su interfaz. Si dicho actor tiene ya una clase interfaz habría que estudiar la posibilidad de reutilizarla para minimizar el número de ventana con las que interactúa el actor.
  2. Identificar una clase interfaz por cada clase entidad encontrada que represente información con la que que el usuario humano va a interactúar. Son clases interfaz primitivas, en el sentido de que hay que refinarlas hasta conseguir una única y buena interfaz para el usuario.
  3. Identificar una clase interfaz por cada actor que sea en un sistema externo, y que hacer que esa clase interfaz  sea el canal de comunicación con él.Un sistema externo puede ser cualquier unidad de software o hardware que interactúa con el sistema. 
  • Clases Control: Identificar una clase de control responsable de llevar el control y la coordinación de la realización del caso de uso. Una clase de control puede actuar para varios casos de uso y puede ocurrir que el control se encapsule en una clase interfaz. 
"Las clases de análisis y las realizaciones de caso de uso forman el objetivo final del
flujo que es el llamado modelo de análisis. Para analizar los casos de uso se procede a identificar
clases de análisis y a definir, para cada caso de uso, las interacciones entre objetos de análisis" (Alonso, 2005, P.362).   

4.2-Objetos:
Los modelos de objetos que se desarrollan durante el análisis de requerimientos pueden utilizarse para representar tanto los datos del sistema como  su procesamiento, los modelos de objetos también son útiles para mostrar como se clasifican las entidades en el sistema y se componen de otras entidades.Los objetos son entidades ejecutables que tienen atributos y servicios de la clase objetos. Los objetos son instanciaciones de la clase de objetos, y pueden crearse muchos objetos a partir de una clase. Para algunas clases del sistema, los modelos de objetos son formas naturales de reflejar las entidades del mundo real que son manipuladas por el sistema. 
El desarrollo de modelos de objetos durante al análisis de requerimientos normalmente simplifica la transición entre el diseño orientado a objetos y la programación.

"El proceso de análisis para identificar los objetos y las clases de objetos se reconoce como una de las áreas más difíciles del desarrollo orientado a objetos. La identificación de objetos es básicamente la misma para el análisis y para el diseño"( Sommerville,2005,P. 154).

4.3-Modelo de requisitos:
El modelado de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente desea según la percepción del desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este modelo.
El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la formación de todos los demás modelos en el desarrollo de software. En general, el cualquier cambio en la funcionalidad del sistema es más fácil de hacer, y con menores consecuencias, a este nivel que posteriormente.   

"El enfoque consiste en usar modelos de requisitos estándar en los cuales
está inmersa la especificación de la variabilidad" (Piattini, 2015, P.2015).

4.4-Modelo de casos de uso:
El lenguaje de modelado unificado (UML), proporciona un conjunto estandarizado de herramientas para documentar el análisis y diseño de un sistema de software.El UML se basa esencialmente en una técnica orientada a objetos conocida como modelado de casos de uso.
Un modelo de caso de uso describe lo que hace un sistema sin describir como lo hace.Un modelo de caso de uso divide la funcionalidad de un sistema en comportamientos (conocidos como caso de uso) significativos para los usuarios del sistema (llamados actores).Se crean diferentes escenarios para cada conjunto diferente de condiciones de un caso de uso.
Los principales componentes de UML, son cosas, relaciones y diagramas. Los diagramas se relacionan entre sí.     
Al usar el UML de manera iterativa en el análisis y el diseño, usted puede lograr que los equipos de negocios y de tecnología de la información comprendan mucho mejor los requerimientos del sistema y los procesos que se tienen que realizar en este último para satisfacer los requerimientos. 


"El conjunto de herramientas de UML, está compuesto de diagramas de UML. Entre estos se incluyen diagramas de caso de uso, de actividades, de secuencias, de colaboración, de clases y de estado. Además de los diagramas , los analistas pueden describir un caso de uso mediante un escenario de caso de uso" (Kendall, 2005, P.695).   

4.5-Modelo de dominio:
Un modelo de dominio establece  los fundamentos para el modelo de objetos con el que se representarán los objetos del sistema, posteriormente, durante el proceso. El modelo de dominio  describe  cualquier modelo cuyo sujeto primario sea el mundo al que da apoyo al sistema de cómputo y cualquiera que sea la etapa del proceso de desarrollo en que se encuentre. Los modelos de dominio y los casos de uso capturan los requerimientos funcionales.
Hay 2 técnicas de UML para la construcción de modelos de dominio:

  • Los diagramas de clases, cuando se dibujan desde una perspectiva conceptual son excelentes para capturar el lenguaje del negocio. Estos diagramas sirven para establecer los conceptos de que se valen los expertos del negocio al pensar en él.
  • Los diagramas de actividades complementan los diagramas de clase describiendo el flujo de trabajo del negocio; es decir, los pasos que siguen los empleados para llevar a cabo sus labores.
"El modelo de dominio de Objetory casi se termina de construir antes de que usted encuentre casos de uso: su propósito es explorar el vocabulario del dominio en términos comprensibles para los expertos del dominio"(Fowler,1999, P. 23).

Referencias:

Publicado por en

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)