Post on 24-Mar-2020
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