Metodologías de Análisis y Diseño de Sistemas

Prof. Hugo Moncayo LópezDepartamento de SistemasUAM – AzcapotzalcoTrim. 06-I

Programa sintético Introducción a los sistemas de información Ciclo de vida del desarrollo de sistemas Tareas del análisis de sistemas Conceptos generales del análisis y diseño orientado

a objetos Modelo de objetos del dominio del problema Modelo de casos de uso Análisis de robustez Modelo de comportamiento

Diagramas de secuencia Diagramas de estado

Impacto de la seguridad en el modelado de sistemas

Estructura de la UEA Introducción a sistemas de información

Sistemas de información Las fases del desarrollo de SI

UML Diagrama de clases Diagrama de objetos Diagrama de casoso de uso Diagramas de secuencia Diagramas de colaboración Diagramas de estado Diagramas de actividad Diagrama de Componentes Diagrama de distribución

Estructura de la UEA El Proceso Unificado (RUP)

Análisis y diseño orientado a objetos Características del PU Iteraciones en el PU Fases dentro de las iteraciones

Inicio Elaboración Construcción Transición

Esteuctura de la UEA El Proceso Unificado (cont.)

La captura de requerimientos Análisis Diseño Implementación Pruebas

Desarrollo iterativo e incremental Inicio Elaboración Construcción Transición

Introducción al desarrollo de sistemas de información

Sistemas de información

Mundo realSistema de información

Desarrollo de sistemas Análisis preliminar (Estudio de factibilidad) Análisis Diseño Construcción Pruebas Instalación Operación normal

Análisis y diseño de sistemas Análisis

Análisis es la investigación de requerimientos de información

Se basa en conocer y documentar el dominio del problema

Diseño Propone una solución conceptual que satisface

los requerimientos de información La solución podrá ser implementada de diversas

maneras

Análisis y diseño orientado a objetos

Análisis Descubrir y documentar los objetos del dominio

del problema Determinar la forma en que los objetos del

dominio del problema se relacionan entre sí Diseño

Definición de objetos de software y sus formas de colaboración para satisfacer los requerimientos determinados en el análisis

UML

Diagrama de clases

Diagrama de clases

Vehiculo

+placas#marca#submarca-modelo

+getEstado()

Nombre de la clase

Atributos

Funciones

Visivilidad + Publica - Privada # Protegida

Ámbito Clase subrayado Objeto no subrayado

+display(){polymorphic,sequential}+getId() : int{sequential}

+origenIcon{root}

-height : int-width : int

RectangularIcon

+display(){sequential}

Button{leaf}

+isinside () : bool-edge

ArbitraryIcon

Polimorfismo

Atributos origen Solo nombre + origen Nombre y visibilidad origen : Point Nombre y tipo de dato vertice[2..n] Nombre y cardinalidad pos : Point = (0,0) Nombre, tipo y valor inicial id : int {frozen} Nombre, tipo y propiedad

Operaciones display +display set(p : Point, s : integer, out ok : bool) getId() : Integer restart(){sequential}

isQuery Solo lectura sequential No debe invocarse de manera concurrente guarded Ejecuciones concurrentes se serializan concurrent Soporta varios flujos de control

Plantillas de clases

+add()+getValue()

Map

key, value, buckets:int

«bind»(string,int,)

+add()+getValue()

«utility»Directorio

Interfaces

+openConnection()+parseURL()+setURL()+toExternalForm()

«interface»URLStreamHandler +openConnection()

+parseURL()+setURL()+toExternalForm()+startUp()+shutDown()+connect()

-authorizationLevelSetTopControler

PowerManager

ChannelIterator

«friend»

Controler EmbeddedAgent

Herencia múltiple

Realización

Asociación

Dependencia

Tipos de dependencia bind

La fuente instancia la plantilla destino derive

La fuente puede ser calculada a partir del destino Se usa para calcular datos virtuales

friend La fuente puede ver miembros privados del destino

instanceOf El objeto fuente es instancia de la clase destino

Tipos de dependencia powertype

El destino es un powertype de la fuente Los objetos de una clase powertype son todos los hijos de

un hijo dado refine

La fuente es una abstracción más fina que el destino use

La semántica del elemento fuente depende de la semántica de la parte pública del elemento destino

Generalización Generalización, herencia Es una relación entre una clase general (base,

padre o superclase) y una clase especializada (derivada, hija o subclase)

La clase derivada hereda todos los atributos y funciones de la clase base

La clase derivada puede tener atributos y funciones adicionales

La clase derivada puede ser usada en donde se requiera la clase base

Una clase puede derivarse de varias clases base (herencia múltiple)

Generalización

InterestearingItem

BancAccount

InsurableItem

Assets

RealEstate Security

CheckAccount SavingsAccount Stock Bond

Asociación Establece una conexión entre objetos

de dos clases

Cliente Cuenta-tiene

1

-manejada por

*

Navegabilidad

Usuario Contrase;a1 *

Visibilidad

Usuario Contrase;a+owner

1

-key

*UserGroup

+user

*

Calificación

BancoTrabajo ArticuloRechazadojobId

1 0..1

Se usa para indicar el elemento necesario para localizarel objeto en el otro extremo de la asociación.

Ejemplo:BancoTrabajo requiere jobId para localizar articuloRechazad

Composición

Automovil

Motor Carroceria

Clases de asociación

Compañía Persona

-descripcion : string-fechaContrato : object-salario : decimal

PuestoTrabajo

*

-empleador

*

-empleado

Diagrama de casos de uso

Casos de uso

System

RecibeAuto

ConsultaEstado

SolicitaAutorizacion

Entrega auto

Asesor Servicio

actorcaso de uso

frontera del sistema

Relaciones en casos de uso

Valida usuario

Revisa orden

Coloca orden Coloca ordenurgente

Verifica contraseña

Rastreo de retina

«extends»

«uses»

«uses»

«extends»

«extends»

Objetivos de los casos de uso Captar los requerimientos de los usuarios Representar los requerimientos en una forma

comprensible para usuarios y desarrolladores Se enfocan en el valor agregado para el

usuario Son el punto de partida para el desarrollo del

sistema Refuerzan las metas de la ingeniería de

software “Crear productos que le permitan a los clientes realizar trabajo útil”

Actor principal Es la entidad que interactua directamente

con el sistema para realizar algún trabajo útil Puede ser una persona u otro sistema

Personal involucrado Personas o sistemas interesados o afectados

por la operación del sistema Ayuda a determinar las operaciones que

debe realizar el sistema cuando interactua con el actor principal aunque éste no este directamente involucrado

Precondiciones Establecen los requisitos en los que se inicia

el caso de uso No es necesario verificar en el caso de uso el

cumplimiento de las precondiciones Generalmente hacen referencia a la

conclusión exitosa de otro caso de uso

Poscondiciones Definen el estado consistente del sistema

después de haber concluido el caso de uso

Escenario principal Se le llama también “camino feliz” Establece las acciones del actor principal y el

sistema cuando no se presenta ninguna situación anormal

No trata situaciones de excepción ya que estas harían más confuso el flujo normal de operaciones

Flujos alternativos Establecen las acciones que responden a las

excepciones en escenario principal Generalmente resultan más complejas que el

escenario principal Es conveniente que se puedan relacionar con

facilidad a los pasos del escenario principal Cada flujo alternativo tiene

Una condición Un conjunto de acciones Puede modelarse como otro caso de uso

Tecnología involucrada Lista las tecnologías que deberán tomarse en

cuenta para el desarrollo del sistema Pueden contener

Tipos de terminales Uso de protocolos

Requisitos especiales Contiene los requerimientos no funcionales Puede especificar

Volumen de transacciones Tiempo de respuesta Requisitos de calidad Escalabilidad Conectividad

Requisitos (FURPS) Funcionales (Functional) Usabilidad (Usability) Fiabilidad (Reliability) Rendimiento (Performance) Soporte (Supportability)

Diagramas de interacción

Diagramas de interacción Modelan el aspecto dinámico del sistema Muestran un conjunto de objetos y sus

interacciones Tipos de diagramas

Secuencia Hace énfasis en el tiempo

Colaboración Hace énfasis en la organización estructural

Diagramas de secuencia

Diagramas de secuencia La línea de vida representa la existencia de un

objeto durante un cierto tiempo Los objetos que se crean inician su línea de vida en

el momento que reciben el mensaje de creación (<<create>>

Algunos objetos pueden ser destruidos al recibir el mensaje correspondiente <<destroy>>)

El control de foco muestra el tiempo en que un objeto está activo (tiene un stack frame)

Diagramas de colaboración

Diagramas de colaboración Resalta la organización de los objetos

participantes La cronología se presenta mediante un

número secuencia que se asigna a cada mensaje

Diagramas de estado

Diagrama de acción

Seleccionar sitio

Comisionar arquitecto

Desarrollar plan

Cotizar plan()

Realiza construcción Contrata personal

Termina construcción

/ No aceptado

Certificado de ocupación

Diagramas de acción Muestran el flujo de actividades Las acciones pueden ser atómicas o estar

compuestas por otra máquina de estado Los diagramas de acción se componen de:

Acciones Transiciones Objetos

Uso de carriles de nataciónAlmacén

Ventas

Cliente

Solicita Producto

Procesa Orden Recaba materiales

Embarca Ordeno:Orden[En proceso]

o:Orden [Embarcada]Recibe Orden Elabora Factura

Paga Factura

f:Factura [Pagada]

f:Factura [Pendiente de pago]

Cierra Orden

RUP

El proceso unificado Conjunto de actividades necesarias para

transformar un conjunto de requerimientos de usuario en un sistema de software

Basado en componentes Se utiliza UML Características

Dirigido por casos de uso Centrado en la arquitectura Iterativo Incremental

Dirigido por casos de uso Énfasis en los requerimientos del usuario

El usuario puede ser una persona u otro sistema Un caso de uso:

Representa una interacción de un usuario con el sistema Es una porción de funcionalidad que proporciona algún

resultado de valor para el usuario El conjunto de todos los casos de uso constituyen el

modelo de casos de uso Que hace el sistema para cada usuario

¿Qué se supone que hace el sistema para cada usuario?

Arquitectura

Conjunto de decisiones significativas respecto a la organización de un sistema

Selección de los componentes estructurales e interfases que constituyen un sistema

Sistema operativo, tecnologías de desarrollo, base de datos, protocolos de comunicaciones, framework

Arquitectura Se deben considerar

Uso Funcionalidad Rendimiento Capacidad de recuperación de fallas Reutilización Compresibilidad Restricciones tecnológicas y económicas

Centrado en la arquitectura Casos de uso – Función Arquitectura – Forma Los casos de uso y la arquitectura se

desarrollan y evolucionan en paralelo Los casos de uso debe poder tener cabida

en la arquitectura

Iterativo e incremental Los proyectos empresariales son muy grandes y

requieren varios meses o años para su desarrollo Es necesario dividirlos en miniproyectos que

corresponden a una iteración Es más fácil la planeación y control de los

miniproyectos Facilita el proceso de aprendizaje de usuarios y

desarrolladores Proporciona productos de software utilizables por la

empresa (buscar mínima inversión, máxima utilidad)

Producto de una iteraciones Un producto de software listo para su

distribución Código de los componentes del sistema Manuales para el uso del sistema Documentación técnica asociada Solución de problemas críticos a corto plazo Experiencia para la siguiente iteración

Fases del desarrollo Inicio Elaboración Construcción Transición

Proceso Unificado

Iteración 1

Iteración 2

Iteración n

…

Inicio

Elaboración

Construcción

Transición

Inicio

Elaboración

Construcción

Transición

Inicio

Elaboración

Construcción

Transición

Flujos de trabajo (workflows)

Itern

Iter1

Iter2

Itern-1

… …

Inicio Elaboración Construcción Transición

Requerimientos

Análisis

Diseño

Implementación

Pruebas

Inicio Definir

Objetivos del proyecto Definir alcance y limitaciones Estimar los recursos necesarios Determinar la viabilidad (costo – beneficio)

Productos Visión y análisis del negocio Modelo de casos de uso Glosario Plan de gestión de riesgo Prototipos Plan de iteración

Inicio La fase de inicio debe tener una duración

corta Codificación de prototipos (prueba de

conceptos) Bocetos de interfaz de usuario No hacer documentación no indispensable Crear un repositorio de documentos en línea Seleccionar una arquitectura acorde a los

requerimientos

Fase de inicio Establecer los objetivos generales del

sistema Determinar su viabilidad Realizar estimaciones respecto a su costo y

tiempo de desarrollo Determinar los riesgos implícitos en el

desarrollo

Artefactos de la fase de inicio Visión y análisis del negocio Modelo de casos de uso Especificaciones no funcionales Glosario Lista de riesgos y planes de contingencia Prototipos Plan de iteración Marco de desarrollo

Flujos de trabajo en Inicio

Requerimientos Análisis Diseño Implementación Pruebas

Recursos

Elaboración Objetivos

Definir la mayoría de los casos de uso Establecer los cimientos arquitectónicos que

sirvan de guía en la construcción y transición Implementación y prueba de elementos básicos

de la arquitectura Continuar el monitoreo de los riesgos críticos Complementar el plan de trabajo (estimación de

tiempo y costo del proyecto total)

Prácticas en la elaboración Dos y cuatro iteraciones de entre dos y seis

semanas Empezar pronto con la programación Diseñar e implementar las partes críticas de

la arquitectura Realizar pruebas realistas Corregir las deficiencias detectadas en las

pruebas Detallar la mayoría de los casos de uso

Artefactos de la Elaboración Modelo del dominio Modelo de diseño Documento de arquitectura de software Modelo de datos Modelo de pruebas Modelo de implementación Casos de uso Prototipo de interfaz de usuario

Flujos de trabajo en Elaboración

Requerimientos Análisis Diseño Implementación Pruebas

Recursos

Construcción Produce un sistema ejecutable en el

ambiente del usuario (versión beta) Se detallan el resto de los casos de uso Se ajusta la arquitectura Productos

Plan de trabajo para la fase de transición El software ejecutable Diagramas y documentación del sistema Manual del usuario (preliminar)

Flujos de trabajo en Construcción

Requerimientos Análisis Diseño Implementación Pruebas

Recursos

Diagramas de secuencia del sistema

:Cajero Object1

CrearNuevaVenta

IntroducirArticulo

Descripción, total

FinalizaVenta

Total con impuestos

Realizar pago

Cambio y recibo

Procesa venta1.- El cliente llega al PDV2.- El cajero inicia nueva venta3.- El cajero inserta el id del artículo…

Modelo del dominio

LineaDeVenta Articulo

Venta

Tienda

Caja

Pago

-Contiene

0..1

-Participa

1..*

-Contenida1..*

-Contiene1

-Es pagada1

-Paga1

-Inventariado*

-Tiene1

-Capturada

*

-Captura

1

-Tiene1

-Esta en1..*

Identificación de clases conceptuales Objetos tangibles Especificaciones de cosas Lugares (representan instncias) Transacciones (depósito, traspaso, etc.) Roles de personas (médico, enfermera, etc.) Contenedores de cosas Conceptos abstractos (póliza, diagnóstico, orden de

laboratorio, cita médica) Organizaciones (Laboratorio, Departamento de

angiología)

Transición Objetivos

Satisfacer los requerimientos planteados a satisfacción de los usuarios

Correcciones a la versión beta Obtener un producto operacional en el ambiente

del usuario Detectar y corregir deficiencias Capacitar a los usuarios en el uso del sistema Afinar los manuales de usuario

Flujos de trabajo en Transición

Requerimientos Análisis Diseño Implementación Pruebas

Recursos

Actividades de la Transición Instalación del sistema en sitios selectos Atender los reportes de fallas o deficiencias Adaptar el producto a las circunstancias del

usuario Revisar y complementar la documentación Determinar cuando termina el proyecto

Uso de patrones de diseño

Que son? Soluciones a problemas repetitivos Un patrón es un par problema – solución Se le asigna un nombre para facilitar su

referencia Los problemas que resuelven son repetitivos No se trata de ser original sino aprovechar la

experiencia

Patrones GRASP General Responsability Assignement

Software Patterns Experto en información Creador Alta cohesión Bajo acoplamiento Controlador

Experto en información La responsabilidad se asigna a la clase que

posee la información necesaria Simplifica el diseño evitando dependencia de

otras clases (reduce el acoplamiento) Incrementa la cohesión del sistema Aunque una clase conozca los datos no se

responsabiliza de operaciones con bases de datos

Experto en información (ejemplo)

La clase venta contienelos datos necesariospara el cálculo deltotal

-fecha-hora

Venta

-cantidadLineaDeVenta -ArticuloId

-descripcion-precio

EspecificacionProducto

-contiene1

-pertenece1..*

-descrito

0..*

-participa

1

Experto en información

esp:EspecificacionProducto

v:Venta

v:LineaVenta

Importe

precio

getPrecio

getImporte

crea

Creador

A debe crear a B si: A agrega objetos de B A contiene instancias de B (o colecciones) A registra instancias de B A utiliza estrechamente objetos de B A contiene la información necesaria para crear B

(A es un experto en la creación de B)

Bajo acoplamiento Es una medida de dependencia de un objeto

respecto a otro Un alto acoplamiento

Dificulta el mantenimiento Dificulta la comprensión del sistema Genera dificultades para reutilización

Bajo acoplamiento

r:Registro v:Venta

p:Pago

agregaPago

crea

Bajo acoplamiento

p:Pago

v:Ventar:Registro

creaPagorealizaPago

Alta cohesión Un componente tiene cohesión funcional

cuando está orientado a un función específica

Una vaja cohesión provoca Dificultad en la compensión Dificulta la reutilización

Controlador Se usan para concentrar en un solo objeto el

proceso un conjunto de eventos del sistema El conjunto de eventos pertenecen a un sistema,

módulo o fachada de un programa Puede corresponder a un caso de uso (deseable) Un controlador no pertenece a la interfaz del

usuario Es la fachada de un programa en la capa del

negocio Debe ser ligero. Delega el trabajo en otras clases

Controlador

:JFramePagoCheque

:PagoChequeControlador

pagarCheque

Capa deinterfazdel usuario

Capa del negocio