Está en la página 1de 25
INGENIERÍA DE
INGENIERÍA DE
INGENIERÍA DE SOFTWARE MODELADO DEL ANÁLISIS JOSÉ DAVID SÁNCHEZ ARTEAGA Especialista en gerencia informática Especialista en
INGENIERÍA DE SOFTWARE MODELADO DEL ANÁLISIS JOSÉ DAVID SÁNCHEZ ARTEAGA Especialista en gerencia informática Especialista en

SOFTWARE MODELADO DEL ANÁLISIS

INGENIERÍA DE SOFTWARE MODELADO DEL ANÁLISIS JOSÉ DAVID SÁNCHEZ ARTEAGA Especialista en gerencia informática Especialista en
INGENIERÍA DE SOFTWARE MODELADO DEL ANÁLISIS JOSÉ DAVID SÁNCHEZ ARTEAGA Especialista en gerencia informática Especialista en

JOSÉ DAVID SÁNCHEZ ARTEAGA Especialista en gerencia informática Especialista en seguridad informática Cel. 3218034744 E-mail: jdsancheza@hotmail.com

INGENIERÍA DE SOFTWARE MODELADO DEL ANÁLISIS JOSÉ DAVID SÁNCHEZ ARTEAGA Especialista en gerencia informática Especialista en
Análisis de Requisitos  El análisis de los requisitos genera la especificación de características operacionales de
Análisis de Requisitos  El análisis de los requisitos genera
Análisis de Requisitos
El
análisis
de
los
requisitos
genera

la

especificación de características operacionales de software.

  • Interfaz

del

software

con otros elementos del

sistema y establece las restricciones que tiene el

software

  • Permite

al

ingeniero

de

software construir

elementos que representen escenarios del usuario, actividades funcionales, clases de problemas y sus relaciones.

  • La especificación

de

requisitos

ofrecen

al

desarrollador y al cliente los medios para evaluar

la calidad una vez construido el software.

Filosofía y objetivos generales El modelo de análisis debe cumplir tres objetivos primarios:  1. Describe

Filosofía y objetivos

generales
generales

El modelo de análisis debe cumplir tres objetivos primarios:

  • 1. Describe lo que requiere el cliente

  • 2. Establecer una base para la creación de un diseño de software

  • 3. Definir un conjunto de requisitos que puedan validarse una vez construido el software.

Reglas prácticas para el Modelado de Análisis  El modelo debe centrarse en los requisitos visibles

Reglas prácticas para el

Modelado de Análisis
Modelado de Análisis
  • El modelo debe centrarse en los requisitos visibles dentro del problema o dominio de negocio.

  • Se debe minimizar el acoplamiento sistema

de

todo

el

  • Se debe tener la seguridad de que el modelo de análisis proporciona valor a todos los interesados.

  • El modelo debe mantenerse tan simple como sea posible.

Análisis del Dominio  El análisis del domino es encontrar o crear aquellas clases de análisis
Análisis del Dominio  El análisis del domino es encontrar o crear aquellas clases de análisis
Análisis del Dominio
El
análisis
del
domino
es
encontrar
o
crear
aquellas
clases
de
análisis
o
funciones
y

características comunes que se aplican ampliamente para que puedan reutilizarse.

  • El papel del analista de dominio es descubrir y

definir patrones de análisis reutilizables, clases de análisis e información relacionada que pueda usar mucha gente en aplicaciones parecidas.

Enfoques de modelado de análisis
Enfoques de modelado de
análisis
  • Análisis Estructurado: Los objetos de datos se

modelan en una forma que define sus atributos y

relaciones.

  • Análisis

Orientado

a

Objetos: Se centra

en

la

definición de clases y en la manera en que éstas

colaboran entre ellas para efectuar los requisitos del sistema.

Enfoques de modelado de análisis
Enfoques de modelado de
análisis
Conceptos del modelado de datos El modelado de datos es definir todos los objetos de datos
Conceptos del modelado de datos
Conceptos del modelado de
datos

El modelado de datos es definir todos los objetos de datos que se procesan dentro del sistema y las relaciones entre los objetos de datos.

  • Objetos de datos: Es una representación de casi cualquier información compuesta (se refiere a que tiene muchas propiedades o atributos) que el software debe entender. Ejemplo: un lugar, un auto, una persona.

  • Atributos: Los atributos definen las propiedades de un objeto de datos, se definen uno o más atributos como un identificador, éste se convierte en una clave para identificar un registro. Ejemplo: cedula, nombre, edad, altura de una persona.

Conceptos del modelado de datos  Relaciones : La relación se refiere a establecer una conexión
Conceptos del modelado de datos 
Conceptos del modelado de
datos

Relaciones: La relación se refiere a establecer una conexión entre objetos. Ejemplo: persona posee auto (posee es la relación).

Conceptos del modelado de datos  Relaciones : La relación se refiere a establecer una conexión
Conceptos del modelado de datos Cardinalidad: La cardinalidad establece el número de objetos que pueden participar
Conceptos del modelado de datos Cardinalidad: La cardinalidad establece el número de objetos que pueden participar
Conceptos del modelado de
datos
Cardinalidad: La cardinalidad establece el número de
objetos que pueden participar en una relación. Las

relaciones pueden ser:

  • 1. De uno a uno

  • 2. De uno a muchos

  • 3. De muchos a muchos

Conceptos del modelado de datos Cardinalidad: La cardinalidad establece el número de objetos que pueden participar
Análisis Orientado a Objetos Se refiere a definir todas las clases relevantes para el problema y
Análisis Orientado a Objetos
Análisis Orientado a Objetos

Se refiere a definir todas las clases relevantes para el problema y que deben resolverse. Esto se logra llevando a cabo algunas tareas:

Deben comunicarse los requisitos básicos del usuario entre el cliente y el ingeniero de software.

Deben identificarse las clases, es decir, definir los atributos y métodos.

Se define una jerarquía de clases.

Deben representarse las relaciones de objeto a objeto.

Debe modelarse el comportamiento del objeto.

Las tareas 1 a 5 se vuelven a aplicar de manera iterativa hasta que el

modelo esté completo.

Modelado basado en escenarios El modelado de análisis con UML comienza con la creación de escenarios
Modelado basado en escenarios
Modelado basado en
escenarios

El modelado de análisis con UML comienza con la

creación de escenarios en la forma de casos de uso,

diagramas de actividad y diagramas de carril.

  • Diagrama de casos de uso:

Un caso de uso especifica la manera en la que los actores interactúan con el sistema en un conjunto específico de circunstancias. El desarrollo de una

serie de casos de uso se comienza haciendo una

lista de las funciones o actividades que realiza un actor específico.

Diagramas de Casos de Uso

Diagramas de Casos de

Uso
Uso
Diagrama de Actividades Complementa el caso de uso al proporcionar una representación grafica del flujo de
Diagrama de Actividades
Diagrama de Actividades

Complementa el caso de uso al proporcionar una representación grafica del flujo de interacción dentro de un escenario específico.

Diagrama de Carril Es una variación útil del diagrama de actividad, ya que permite al modelador
Diagrama de Carril
Diagrama de Carril

Es una variación útil del diagrama de actividad, ya

que permite al modelador la representación del flujo

de actividades descritas por el caso de uso y al mismo tiempo indicar que actor o clases de análisis tiene la responsabilidad de la acción descrita

mediante un rectángulo de actividad.

Diagrama de Carril
Diagrama de Carril
Diagrama de Carril
Diagrama de Carril
Modelo orientado al flujo Tiene una visión del sistema del tipo entrada- proceso-salida. Los objetos de
Modelo orientado al flujo Tiene una visión del sistema del tipo entrada-
Modelo orientado al flujo
Tiene
una
visión
del
sistema
del
tipo
entrada-

proceso-salida. Los objetos de datos fluyen hacia el interior del software, se transforman mediante elementos de procesamiento y los objetos de datos resultantes fluyen al exterior del software.

Modelo orientado al flujo Tiene una visión del sistema del tipo entrada- proceso-salida. Los objetos de
Modelado basado en clases Una clase orientada a objetos encapsula atributos de los datos pero también

Modelado basado en clases

Una clase orientada a objetos encapsula atributos de los datos pero también incorpora las operaciones que manipulan los datos implicados por dichos

atributos. Las clases se manifiestan en la siguiente

forma: entidades externas, sucesos o eventos, cosas, papeles o roles, unidades organizacionales, sitios y estructuras.

Representación de una

clase
clase
Representación de una clase CLIENTE Numero de cuenta Cedula Nombres Apellidos Teléfono Dirección ingresar_tarjeta( ) ingresar_clave(

CLIENTE

Numero de cuenta Cedula Nombres Apellidos

Teléfono

Dirección

ingresar_tarjeta( ) ingresar_clave( ) ingresar_monto( ) retirar_dinero( ) revisar_cuenta( ) retirar_tarjeta( ) retirar_comprobante( )

Modelo de Clase- Responsabilidad- Colaborador(CRC) El modelado de Clase-Responsabilidad-Colaborador (CRC) proporciona un medio simple para identificar

Modelo de Clase-

Responsabilidad- Colaborador(CRC)
Responsabilidad-
Colaborador(CRC)

El modelado de Clase-Responsabilidad-Colaborador

(CRC) proporciona un medio simple para identificar y

organizar las clases relevantes para los requisitos del sistema o producto. Un modelo CRC es una colección de tarjetas índices estándar que representan clases. El objeto es desarrollar una

representación organizada de las clases.

Modelo de Clase- Responsabilidad- Colaborador(CRC) El modelado de Clase-Responsabilidad-Colaborador (CRC) proporciona un medio simple para identificar
Modelo de Clase- Responsabilidad- Colaborador(CRC) Clases: tienen diferentes categorías:  Clases de entidad: llamadas clases de

Modelo de Clase-

Responsabilidad- Colaborador(CRC)
Responsabilidad-
Colaborador(CRC)

Clases: tienen diferentes categorías:

  • Clases de entidad: llamadas clases de modelo o negocios, se extraen de manera directa del enunciado del problema.

  • Clases de frontera: se utilizan para crear la interfaz que el usuario ve y con la cual interactúa cuando se utiliza el software.

  • Clases de controlador: manejan una “unidad de trabajo” desde el inicio hasta el final.gh

Modelo de Clase- Responsabilidad- Colaborador(CRC) Responsabilidad: son los atributos y las operaciones relevantes para la clase.

Modelo de Clase-

Responsabilidad- Colaborador(CRC)
Responsabilidad-
Colaborador(CRC)

Responsabilidad: son los atributos y las operaciones relevantes para la clase.

Colaboradores: son aquellas clases que se requieren

para que una clase reciba la información necesaria

para completar una responsabilidad.

Agregación: son las subclases que forman parte de

una clase, se conectan a través de una relación de tipo es parte de.

Asociaciones y Dependencias  Asociaciones : son las relaciones entre clases.  Dependencia : en el

Asociaciones y

Dependencias
Dependencias
  • Asociaciones: son las relaciones entre clases.

Asociaciones y Dependencias  Asociaciones : son las relaciones entre clases.  Dependencia : en el
  • Dependencia: en el contexto de las clases va ligada a las operaciones, indicando que una clase utiliza otra como argumento en la signatura de una operación .

Asociaciones y Dependencias  Asociaciones : son las relaciones entre clases.  Dependencia : en el
Modelos de Comportamiento
Modelos de Comportamiento
Modelos de Comportamiento El modelo de comportamiento indica la forma en que el software responderá a

El modelo de comportamiento indica la forma en que el software responderá a los eventos o estímulos externos.

  • Diagrama de estado: representa el comportamiento de las clases cuando el sistema

realiza sus funciones.
realiza sus funciones.
Modelos de Comportamiento 
Modelos de Comportamiento
Modelos de Comportamiento  Diagrama de Secuencia: representa el comportamiento al describir la forma en que

Diagrama de Secuencia: representa el comportamiento al describir la forma en que las clases se mueven de estado a estado.

Modelos de Comportamiento  Diagrama de Secuencia: representa el comportamiento al describir la forma en que