EL modelo de analisis es una serie de modelos los cuales son la primera representacion tecnica del sistema
1. Los productos del analisis deben tener una elevada facilidad de mantenimiento
2. Los problemas de gran tamaño deben tratarse con metodo efectivo de particion.
3. Deben utilizarse graficas cuanto sea posible
4. Debe diferenciarse entre consideraciones logicas y fisicas.
CONCEPTOS DEL MODELADO DE DATOS
El modelado de analisis usualmente inicia con el modelado de datos, en el que se define todos los objetos de datos que se procesan dentro del sistema y las relaciones entre los objetos de datos ademas la informacion pertinente para las relaciones.
un objeto de datos es casi cualquier informacion compuesta que el software debe entender, la informacion compuesta se refiere a algo que tiene muchas propiedades o atributos diferentes. Un objeto de datos encapsula solo datos.
los atributos definen las propiedades de un objeto de datos
un objeto de datos no es lo mismo que una clase Orientada a objetos.
El modelo de analisis utiliza una combinacion de formatos de texto y diagramas para representar los requisitos de los datos
ANALISIS DE REQUISITOS
El analisis de requisitos genera la especificacion de caracteristicas operacionales del software, indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe tener el software.
por medio del modelado de analisis el ingeniero de software se centra en el que y no tanto en el como, el modelo de analisis y la especificacion de requisitos proporciona un medio para evaluar la calidad del software una ves este este construido.
El modelado es un puente entre la descripcion del sistema y el diseño como se muestra en la figura
el modelo del analisis debe cubrir tres objetivos principales
1. describir lo que quiere el cliente
2. estableceer una base para la creacion de un diseño de software.
3. definir una serie de requisitos que puedan validarse una ves construido el software.
no siempre es posible crear una division clara entre analisis y diseño puesto que como parte invariable en las actividades de analisis se realiza un diseño y algun analisis se realizara durante el diseño.
REGLAS PRACTICAS PARA EL ANALISIS
1. El modelo debe centrarse en los requisitos visibles dentro del problema o dominio del negocio.
2. cada elemento del analisis debe agregarse a un acuerdo general de los requisitos de software y proporcionar una vision interna del dominio de informacion, funcion y comportamiento del sistema.
3. debe retrasarse la consideracion de la infraestructura y otros modelos no funcionales hasta la fase de diseño.
4. debe minimizarse el acoplamiento del sistema.
5. se debe tener la seguridad que el anallisis proporciona valor a todos los interesados.
6. el modelo debe mantenerse tan simple como sea posible.
ANALISIS DEL DOMINIO
Entradas y salidas del analisis del dominio
el analisis de dominio es la identificacion,analisis y especificacion de requisitos comunes de un dominio especifico de aplicacion para, de manera tipica reutilizarlos en multiples proyectos dentro de ese dominio de aplicacion.
la meta del analisis de domini es encontrar cosas comunes entre proyectos para poder reutilizase.
analisis estructurado. considera que los datos y procesos que transforman los datos son entidades separadas
analisis orientado a objetos. se centra en la definicion de clases y en la manera en que estas colaboran entre ellas para efectuar los requisitos del cliente.
las relaciones nos indican como estan conectados dos objetos distintos de datos por ejemplo
la cardinalidad nos indica el numero de ocurrencias de los objetos en una relacion dada. de modo que un objeto puede relacionarse con solo un objeto (1:1) o un objeto puede relacionarse con muchos (1:N) o muchas ocurrencias pueden relacionarse con otras ocurrencias (M:N)
ANALISIS ORIENTADO A OBJETOS
El objetivo del analisis OO es definir todas las clases ademas de las relaciones y comportamientos asociados a ellas relevantes para el problema y que deben resolverse
1. deben de comunicarse los requisitos basicos entre cliente y el ingeniero de software.
2. deben identificarse las clases atributos y metodos.
3. se define una jerarquia de clases
4. deben representarse las relaciones de objeto a objeto
5. debe modelarse el comportamiento del objeto.
6. los pasos del 1-6 son iterativos hasta que el modelo este completo.
MODELADO BASADO EN ESCENARIOS
El modelado del analisis con UML inicia con la construccion de esenarios basados en casos de uso, diagramas de actividad y diagramas de carril
MODELADO ORIENTADO AL FLUJO
Aunque el diagrama de flujo de datos DFD y relacionados no son parte de UML pueden utilizarse par acomprender mejor los requisitos del sistema.
algunas personas piensan que el DFD es de la vieja escuela y no tiene sitio en la practica moderna esta es una vision que excluye una herramienta potencialmente util a nivel de analisis si es de ayuda se recomienda usar DFD
MODELADO DE CLASE-RESPONSABILIDAD-COLABORADOR CRC
proporciona un medio simple para identificar clases y organizar clases relevantes para los requisitos del sitemao producto.
CRC son una coleccion de tarjetas indice estandar que representan clases, estas se dividen entres secciones alo largo del borde superior se escribe el nombre de la clase en el cuerpo se listan las responsabilidades de la clase izquierda y los colaboradores a la derecha, la responsabilidad es cualquier cosa que sabe o hace
una colaboracion implica una solicitud de informacion o de alguna accion
1. Los productos del analisis deben tener una elevada facilidad de mantenimiento
2. Los problemas de gran tamaño deben tratarse con metodo efectivo de particion.
3. Deben utilizarse graficas cuanto sea posible
4. Debe diferenciarse entre consideraciones logicas y fisicas.
CONCEPTOS DEL MODELADO DE DATOS
El modelado de analisis usualmente inicia con el modelado de datos, en el que se define todos los objetos de datos que se procesan dentro del sistema y las relaciones entre los objetos de datos ademas la informacion pertinente para las relaciones.
un objeto de datos es casi cualquier informacion compuesta que el software debe entender, la informacion compuesta se refiere a algo que tiene muchas propiedades o atributos diferentes. Un objeto de datos encapsula solo datos.
los atributos definen las propiedades de un objeto de datos
un objeto de datos no es lo mismo que una clase Orientada a objetos.
El modelo de analisis utiliza una combinacion de formatos de texto y diagramas para representar los requisitos de los datos
ANALISIS DE REQUISITOS
El analisis de requisitos genera la especificacion de caracteristicas operacionales del software, indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe tener el software.
por medio del modelado de analisis el ingeniero de software se centra en el que y no tanto en el como, el modelo de analisis y la especificacion de requisitos proporciona un medio para evaluar la calidad del software una ves este este construido.
El modelado es un puente entre la descripcion del sistema y el diseño como se muestra en la figura
el modelo del analisis debe cubrir tres objetivos principales
1. describir lo que quiere el cliente
2. estableceer una base para la creacion de un diseño de software.
3. definir una serie de requisitos que puedan validarse una ves construido el software.
no siempre es posible crear una division clara entre analisis y diseño puesto que como parte invariable en las actividades de analisis se realiza un diseño y algun analisis se realizara durante el diseño.
REGLAS PRACTICAS PARA EL ANALISIS
1. El modelo debe centrarse en los requisitos visibles dentro del problema o dominio del negocio.
2. cada elemento del analisis debe agregarse a un acuerdo general de los requisitos de software y proporcionar una vision interna del dominio de informacion, funcion y comportamiento del sistema.
3. debe retrasarse la consideracion de la infraestructura y otros modelos no funcionales hasta la fase de diseño.
4. debe minimizarse el acoplamiento del sistema.
5. se debe tener la seguridad que el anallisis proporciona valor a todos los interesados.
6. el modelo debe mantenerse tan simple como sea posible.
ANALISIS DEL DOMINIO
Entradas y salidas del analisis del dominio
el analisis de dominio es la identificacion,analisis y especificacion de requisitos comunes de un dominio especifico de aplicacion para, de manera tipica reutilizarlos en multiples proyectos dentro de ese dominio de aplicacion.
la meta del analisis de domini es encontrar cosas comunes entre proyectos para poder reutilizase.
analisis estructurado. considera que los datos y procesos que transforman los datos son entidades separadas
analisis orientado a objetos. se centra en la definicion de clases y en la manera en que estas colaboran entre ellas para efectuar los requisitos del cliente.
las relaciones nos indican como estan conectados dos objetos distintos de datos por ejemplo
la cardinalidad nos indica el numero de ocurrencias de los objetos en una relacion dada. de modo que un objeto puede relacionarse con solo un objeto (1:1) o un objeto puede relacionarse con muchos (1:N) o muchas ocurrencias pueden relacionarse con otras ocurrencias (M:N)
ANALISIS ORIENTADO A OBJETOS
El objetivo del analisis OO es definir todas las clases ademas de las relaciones y comportamientos asociados a ellas relevantes para el problema y que deben resolverse
1. deben de comunicarse los requisitos basicos entre cliente y el ingeniero de software.
2. deben identificarse las clases atributos y metodos.
3. se define una jerarquia de clases
4. deben representarse las relaciones de objeto a objeto
5. debe modelarse el comportamiento del objeto.
6. los pasos del 1-6 son iterativos hasta que el modelo este completo.
MODELADO BASADO EN ESCENARIOS
El modelado del analisis con UML inicia con la construccion de esenarios basados en casos de uso, diagramas de actividad y diagramas de carril
MODELADO ORIENTADO AL FLUJO
Aunque el diagrama de flujo de datos DFD y relacionados no son parte de UML pueden utilizarse par acomprender mejor los requisitos del sistema.
algunas personas piensan que el DFD es de la vieja escuela y no tiene sitio en la practica moderna esta es una vision que excluye una herramienta potencialmente util a nivel de analisis si es de ayuda se recomienda usar DFD
MODELADO DE CLASE-RESPONSABILIDAD-COLABORADOR CRC
proporciona un medio simple para identificar clases y organizar clases relevantes para los requisitos del sitemao producto.
CRC son una coleccion de tarjetas indice estandar que representan clases, estas se dividen entres secciones alo largo del borde superior se escribe el nombre de la clase en el cuerpo se listan las responsabilidades de la clase izquierda y los colaboradores a la derecha, la responsabilidad es cualquier cosa que sabe o hace
una colaboracion implica una solicitud de informacion o de alguna accion
Comentarios