Está en la página 1de 55

Análisis de Software

Diseño de Software I
¿Qué comprende la disciplina de análisis en RUP?
• ¿Dónde estamos en el curso?
• ¿A dónde nos dirigimos?
• Definición de la Arquitectura de Software
• Análisis de Casos de Uso
• Identificación y Documentación de los mecanismos de Análisis
¿Dónde Estamos?
Requisitos

Requisitos
Necesidades No Funcionales

Características
Problema

Requisitos
Interesados Funcionales
(CU)

Actores
¿A dónde nos dirigimos?
Requisitos Análisis

Requisitos
Necesidades No Funcionales

Características
Problema

Requisitos
Interesados Funcionales
(CU)

Actores
Arquitectura de Software
Arquitectura de Software
Vista lógica Vista de Implementación

Analistas y
Programadores
Diseñadores

Vista de Emplazamiento

Vista de casos de uso

Usuario final
Funcionalidad
Arquitectura de Software

Vista lógica Vista de Implementación

Analistas y
Programadores
Diseñadores

Vista de Emplazamiento

Vista de casos de uso

Usuario final
Funcionalidad
Arquitectura de Software

Vista lógica Vista de Implementación

Analistas y
Programadores
Diseñadores

Vista de Emplazamiento

Vista de casos de uso

Usuario final
Funcionalidad
¿Qué es la realización de casos de uso?
Relación entre Vistas…
Vista de Casos de Uso Vista Lógica

Modelo de Análisis
Relación entre Modelos de distintas vistas
Vista Lógica
Vista de Casos de Uso
Modelo de Análisis
<<Trace>>
Entradas y Salidas del Proceso
¿Qué es el análisis de casos de uso?
¿Qué es el análisis de casos de uso?
¿Cómo se hace el análisis de casos de uso?
VOPC View of
participating Classes
¿Cómo se hace el análisis de casos de uso?
Análisis de casos de uso
Encontrando clases en los casos de uso
¿Cómo son las clases de análisis?
Estereotipos
Clases de límite (Boundary)
Interfases con otros sistemas
El rol de una clase Boundary

<<boundary>>

<<control>> <<boundary>>

Actor <<boundary>>
Actor

<<entity>> <<entity>>

Modela la interacción entre el sistema y su ambiente


Boundary Classes

Studentr Register for Courses Course Catalog System

RegisterForCoursesForm CourseCatalogSystem
Clase de Entidad (Entity)
El rol de una clase Entidad

Almacenar y manejar información en el sistema


Clase de Control
Rol de una clase Control
Control Classes

• Una clase control por caso de uso

Student Register for Courses Course Catalog System

RegistrationController
Encontrando objetos entidad
Filtrando sustantivos
Escenario inscribirse en cursos-crear un horario
Sustantivos del escenario del caso de uso
inscribirse en cursos-crear un horario
Filtrando el escenario del caso de uso inscribirse en cursos-
crear un horario
Análisis de objetos filtrados en el escenario del caso de uso
inscribirse en cursos-crear un horario
Creando clases entidad
Clases entidad identificadas en el escenario del caso de uso
inscribirse en cursos-crear un horario
Encontrando clases límite
Candidatos a clases límite en el escenario del caso de uso
inscribirse en cursos-crear un horario
Bosquejo de pantalla
Encontrando clases de control
Clases de Control en el caso de uso inscribirse a
cursos
Diagrama de Vista de Clases Participantes (VOPC)
Ejemplo de VOPC
Distribución de Clases dentro del Modelo Lógico de
Arquitectura

Infraestructura

Presentación
Interfaz de Usuario

Conexion a Sistemas Externos

Negocios Lógica del CU

Datos
Entidad para almacenar información
Proyecto en WhiteStar UML
Organización Lógica de la aplicación
• Modelo en Capas

Presentación

Servicios de
Infraestructura
Negocios

Datos
Organización Lógica de la aplicación
• Modelo en Capas
Servicios de
Infraestructura

Presentación

Negocios

Datos
Organización Lógica de la aplicación
• Llamadas permitidas
Servicios de
Infraestructura

Presentación

Negocios

Datos
Organización Lógica de la aplicación
• Llamadas No permitidas
Servicios de
Infraestructura

Presentación

Negocios

Datos
Organización Lógica de la aplicación
• En WhiteStarUML el modelo lógico en capas se modela mediante un
diagrama de Clases de UML.
• Se utilizan paquetes para representar cada capa

Presentación Infraestructura

Negocios

Datos
Organización física de la aplicación
• Uno de los modelos más utilizados es el cliente-Servidor
Organización física de la aplicación
• Una Variación es el Modelo Solicitud-Respuesta de las aplicaciones Web
Organización física de la aplicación
• En WhiteStarUML el modelo físico se modela mediante un diagrama de
emplazamiento (deployment) de UML.

Cliente Web
Equipo Servidor

HTTP Request
<<artifact>> Web Server
Navegador Chrome

HTTP Response

Database Server
Organización física de la aplicación

Cliente Web
Equipo Servidor

HTTP Request
<<artifact>> Web Server
Navegador Chrome

HTTP Response

Database Server

También podría gustarte