Modelado De Sistemas - Universidad Autónoma Metropolitana

Metodologías de Análisisy Diseño de SistemasProf. Hugo Moncayo LópezDepartamento de SistemasUAM – AzcapotzalcoTrim. 06-I

Programa sintético Introducción a los sistemas de informaciónCiclo de vida del desarrollo de sistemasTareas del análisis de sistemasConceptos generales del análisis y diseño orientadoa objetosModelo de objetos del dominio del problemaModelo de casos de usoAnálisis de robustezModelo de comportamiento Diagramas de secuenciaDiagramas de estadoImpacto de la seguridad en el modelado de

Estructura de la UEA Introducción a sistemas de información Sistemas de informaciónLas fases del desarrollo de SIUML Diagrama de clasesDiagrama de objetosDiagrama de casoso de usoDiagramas de secuenciaDiagramas de colaboraciónDiagramas de estadoDiagramas de actividadDiagrama de ComponentesDiagrama de distribución

Estructura de la UEA El Proceso Unificado (RUP) Análisis y diseño orientado a objetosCaracterísticas del PUIteraciones en el PUFases dentro de las iteraciones InicioElaboraciónConstrucciónTransición

Esteuctura de la UEA El Proceso Unificado (cont.) La captura de asDesarrollo iterativo e incremental InicioElaboraciónConstrucciónTransición

Introducción al desarrollode sistemas deinformación

Sistemas de informaciónMundo realSistema de información

Desarrollo de sistemas Análisis preliminar (Estudio de nstalaciónOperación normal

Análisis y diseño de sistemas Análisis Análisis es la investigación de requerimientos deinformaciónSe basa en conocer y documentar el dominio delproblemaDiseño Propone una solución conceptual que satisfacelos requerimientos de informaciónLa solución podrá ser implementada de diversasmaneras

Análisis y diseño orientado aobjetos Análisis Descubrir y documentar los objetos del dominiodel problemaDeterminar la forma en que los objetos deldominio del problema se relacionan entre síDiseño Definición de objetos de software y sus formas decolaboración para satisfacer los requerimientosdeterminados en el análisis

UML

Diagrama de clases

Diagrama de clasesNombre de la claseAtributosFuncionesVehiculo placas#marca#submarca-modelo getEstado()Visivilidad Publica- Privada# ProtegidaÁmbitoClase subrayadoObjeto no subrayado

PolimorfismoIcon{root} origen display(){polymorphic,sequential} getId() : int{sequential}RectangularIcon-height : int-width : intButton{leaf} display(){sequential}ArbitraryIcon-edge isinside () : bool

Atributos origenSolo nombre origenNombre y visibilidadorigen : Point Nombre y tipo de datovertice[2.n] Nombre y cardinalidadpos : Point (0,0) Nombre, tipo y valor inicialid : int {frozen} Nombre, tipo y propiedad

Operaciones display displayset(p : Point, s : integer, out ok : bool)getId() : Integerrestart(){sequential} isQuerysequentialguardedconcurrentSolo lecturaNo debe invocarse de manera concurrenteEjecuciones concurrentes se serializanSoporta varios flujos de control

Plantillas de claseskey, value, buckets:intMap add() io add() getValue()

InterfacesHerencia ntroler«interface»URLStreamHandler openConnection() parseURL() setURL() toExternalForm()Realización-authorizationLevel openConnection() parseURL() setURL() toExternalForm() startUp() shutDown() ndencia

Tipos de dependencia bind derive La fuente puede ser calculada a partir del destinoSe usa para calcular datos virtualesfriend La fuente instancia la plantilla destinoLa fuente puede ver miembros privados del destinoinstanceOf El objeto fuente es instancia de la clase destino

Tipos de dependencia powertype refine El destino es un powertype de la fuenteLos objetos de una clase powertype son todos los hijos deun hijo dadoLa fuente es una abstracción más fina que el destinouse La semántica del elemento fuente depende de lasemántica de la parte pública del elemento destino

Generalización Generalización, herenciaEs 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 yfunciones de la clase baseLa clase derivada puede tener atributos y funcionesadicionalesLa clase derivada puede ser usada en donde serequiera la clase baseUna clase puede derivarse de varias clases base(herencia múltiple)

lEstateStockBond

Asociación Establece una conexión entre objetosde dos clases-tiene -manejada Visibilidad user owner-keyUsuarioUserGroup*Contrase;a1*

CalificaciónSe usa para indicar el elemento necesario para localizarel objeto en el otro extremo de la asociación.Ejemplo:BancoTrabajo requiere jobId para localizar 10.1

ComposiciónAutomovilMotorCarroceria

Clases de asociaciónPuestoTrabajo-descripcion : string-fechaContrato : object-salario : decimal**CompañíaPersona-empleador-empleado

Diagrama de casos deuso

Casos de usoSystemfrontera del sistemaRecibeAutoConsultaEstadoactorAsesor ServicioSolicitaAutorizacionEntrega autocaso de uso

Relaciones en casos de uso«extends»Coloca ordenColoca ordenurgente«uses»Revisa orden«uses»«extends»Verifica contraseñaValida usuario«extends»Rastreo de retina

Objetivos de los casos de uso Captar los requerimientos de los usuariosRepresentar los requerimientos en una formacomprensible para usuarios y desarrolladoresSe enfocan en el valor agregado para elusuarioSon el punto de partida para el desarrollo delsistemaRefuerzan las metas de la ingeniería desoftware “Crear productos que le permitan alos clientes realizar trabajo útil”

Actor principal Es la entidad que interactua directamentecon el sistema para realizar algún trabajo útilPuede ser una persona u otro sistema

Personal involucrado Personas o sistemas interesados o afectadospor la operación del sistemaAyuda a determinar las operaciones quedebe realizar el sistema cuando interactuacon el actor principal aunque éste no estedirectamente involucrado

Precondiciones Establecen los requisitos en los que se iniciael caso de usoNo es necesario verificar en el caso de uso elcumplimiento de las precondicionesGeneralmente hacen referencia a laconclusión exitosa de otro caso de uso

Poscondiciones Definen el estado consistente del sistemadespués de haber concluido el caso de uso

Escenario principal Se le llama también “camino feliz”Establece las acciones del actor principal y elsistema cuando no se presenta ningunasituación anormalNo trata situaciones de excepción ya queestas harían más confuso el flujo normal deoperaciones

Flujos alternativos Establecen las acciones que responden a lasexcepciones en escenario principalGeneralmente resultan más complejas que elescenario principalEs conveniente que se puedan relacionar confacilidad a los pasos del escenario principalCada flujo alternativo tiene Una condiciónUn conjunto de accionesPuede modelarse como otro caso de uso

Tecnología involucrada Lista las tecnologías que deberán tomarse encuenta para el desarrollo del sistemaPueden contener Tipos de terminalesUso de protocolos

Requisitos especiales Contiene los requerimientos no funcionalesPuede especificar Volumen de transaccionesTiempo de respuestaRequisitos de calidadEscalabilidadConectividad

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

Diagramas deinteracción

Diagramas de interacción Modelan el aspecto dinámico del sistemaMuestran un conjunto de objetos y susinteraccionesTipos de diagramas Secuencia Hace énfasis en el tiempoColaboración Hace énfasis en la organización estructural

Diagramas de secuencia

Diagramas de secuencia La línea de vida representa la existencia de unobjeto durante un cierto tiempoLos objetos que se crean inician su línea de vida enel momento que reciben el mensaje de creación( create Algunos objetos pueden ser destruidos al recibir elmensaje correspondiente destroy )El control de foco muestra el tiempo en que unobjeto está activo (tiene un stack frame)

Diagramas de colaboración

Diagramas de colaboración Resalta la organización de los objetosparticipantesLa cronología se presenta mediante unnúmero secuencia que se asigna a cadamensaje

Diagramas de estado

Diagrama de acciónSeleccionar sitioCotizar plan()/ No aceptadoComisionar arquitectoDesarrollar planRealiza construcciónContrata personalTermina construcciónCertificado de ocupación

Diagramas de acción Muestran el flujo de actividadesLas acciones pueden ser atómicas o estarcompuestas por otra máquina de estadoLos diagramas de acción se componen de: AccionesTransicionesObjetos

Uso de carriles de nataciónClienteAlmacénVentasSolicita ProductoProcesa Ordeno:Orden[En proceso]Recibe OrdenPaga Facturaf:Factura [Pagada]Elabora Facturaf:Factura [Pendiente de pago]Cierra OrdenRecaba materialesEmbarca Ordeno:Orden [Embarcada]

RUP

El proceso unificado Conjunto de actividades necesarias paratransformar un conjunto de requerimientos deusuario en un sistema de softwareBasado en componentesSe utiliza UMLCaracterísticas Dirigido por casos de usoCentrado en la arquitecturaIterativoIncremental

Dirigido por casos de uso Énfasis en los requerimientos del usuario Un caso de uso: Representa una interacción de un usuario con el sistemaEs una porción de funcionalidad que proporciona algúnresultado de valor para el usuarioEl conjunto de todos los casos de uso constituyen elmodelo de casos de uso El usuario puede ser una persona u otro sistemaQue hace el sistema para cada usuario¿Qué se supone que hace el sistema para cadausuario?

Arquitectura Conjunto de decisiones significativasrespecto a la organización de un sistemaSelección de los componentes estructuralese interfases que constituyen un sistemaSistema operativo, tecnologías de desarrollo,base de datos, protocolos decomunicaciones, framework

Arquitectura Se deben considerar UsoFuncionalidadRendimientoCapacidad de recuperación de fallasReutilizaciónCompresibilidadRestricciones tecnológicas y económicas

Centrado en la arquitectura Casos de uso – FunciónArquitectura – FormaLos casos de uso y la arquitectura sedesarrollan y evolucionan en paraleloLos casos de uso debe poder tener cabidaen la arquitectura

Iterativo e incremental Los proyectos empresariales son muy grandes yrequieren varios meses o años para su desarrolloEs necesario dividirlos en miniproyectos quecorresponden a una iteraciónEs más fácil la planeación y control de losminiproyectosFacilita el proceso de aprendizaje de usuarios ydesarrolladoresProporciona productos de software utilizables por laempresa (buscar mínima inversión, máxima utilidad)

Producto de una iteraciones Un producto de software listo para sudistribuciónCódigo de los componentes del sistemaManuales para el uso del sistemaDocumentación técnica asociadaSolución de problemas críticos a corto plazoExperiencia para la siguiente iteración

Fases del desarrollo InicioElaboraciónConstrucciónTransición

Proceso UnificadoInicioElaboraciónConstrucciónIteración 1TransiciónIteración 2Inicio ElaboraciónConstrucciónIteración ión

Flujos de trabajo uebasIter Iter 12 Iter Itern-1 n

Inicio Definir Objetivos del proyectoDefinir alcance y limitacionesEstimar los recursos necesariosDeterminar la viabilidad (costo – beneficio)Productos Visión y análisis del negocioModelo de casos de usoGlosarioPlan de gestión de riesgoPrototiposPlan de iteración

Inicio La fase de inicio debe tener una duracióncortaCodificación de prototipos (prueba deconceptos)Bocetos de interfaz de usuarioNo hacer documentación no indispensableCrear un repositorio de documentos en líneaSeleccionar una arquitectura acorde a losrequerimientos

Fase de inicio Establecer los objetivos generales delsistemaDeterminar su viabilidadRealizar estimaciones respecto a su costo ytiempo de desarrolloDeterminar los riesgos implícitos en eldesarrollo

Artefactos de la fase de inicio Visión y análisis del negocioModelo de casos de usoEspecificaciones no funcionalesGlosarioLista de riesgos y planes de contingenciaPrototiposPlan de iteraciónMarco de desarrollo

Flujos de trabajo en entaciónPruebas