Diseo de Sistemas

CRITERIOS DE EVALUACIN:
Materia Anual 100% de trabajos prcticos aprobados para poder rendir los exmenes parciales. Parciales requieren :Nota mnima cuatro (4) para considerarse aprobado. Pero se requiere un mnimo de 7 (siete) para lograr la promocin especial. 100% de los evaluativos peridicos aprobados para tener derecho a presentarse en los parciales. 100% de exmenes parciales aprobados para regularizar la materia. Cuatro (4) exmenes parciales. En caso de no reunir alguno de estos requisitos de regularidad, el alumno deber ir a una instancia de recuperacin integral. Aprobar un examen Final, nota mnima cuatro (4).

En sntesis

Como son los Evaluativos y Parciales?

En su mayora escritos. Pero en algunas ocasiones algn examen ser dado en forma de presentacin, o como un feedback de preguntas y respuestas.

Qu pasa si falto a alguna de las evacualciones o desapuebo alguna de ellas?

Todas las evaluaciones tienen recuperacin que sern dadas en el momento oportuno.

Cuntas veces puedo recuperar un evaluativo o un parcial?

Para recuperar evaluativos se tienen 3 oportunidades. Para recuperar los parciales se tienen 2 recuperaciones y un integral.

Qu pasa si no presento algn practico?

Los prcticos son obligatorios y si no se presentan se considera ausente en el examen parcial.

Y si no apruebo un practico?
Todos los prcticos tienen 3 instancias de recuperacin, si aun as no se aprueba entonces junto con la cuarta presentacin se deber rendir adems un evaluativo terico-practico del tema correspondiente al practico.

Si solo tengo los evaluativos, prcticos y parciales aprobados puedo aprobar la materia?

No, es obligatorio la presentacin y aprobacin del trabajo de investigacin.

COMENZAMOS!!!

Unidad 1:

Introduccin al Anlisis y Diseo Orientado a Objetos

MODELO es una forma de representacin abstracta que se utiliza para el

entendimiento del comportamiento de cualquier sistema.

En la Metodologa Estructurada, se utiliza bsicamente los siguientes modelos: el diagrama de contexto, el DFD, el modelo entidad-relacin , el modelo de procesos y el diccionario de datos.

En la Metodologa Orientada A Objetos, se utilizan bsicamente los siguientes modelos: diagrama de casos de usos, el diagrama de clases, el diagrama de objetos, el diagrama de colaboracin, el diagrama de transicin de estados y otros modelos dinmicos.

Orientacin a Objetos

Cambio de mentalidad
Mentalidad O-O Qu objetos configuran el sistema? Cual es la estructura y funcin de cada objeto? Cmo puedo precisar la dinmica del sistema a travs del comportamiento o la interaccin de sus objetos? Posponer las funciones algortmicas Posponer el modelo de datos

Mentalidad Procedural Qu hace el sistema? Qu objetivos tiene ? Cmo diseo y codifico para conseguir los objetivos? Enfoque dirigido a los algoritmos Enfoque centrado en los datos

Beneficios del enfoque OO

Segn [Booch, 1986], los beneficios del enfoque OO son: Primero, el uso del modelo OO nos ayuda a explotar el poder expresivo de todos los lenguajes de programacin basados en objetos y los orientados a objetos. Segundo, el uso del modelo OO alienta el reuso no solo del software, sino de diseos completos. Tercero, produce sistemas que estn construidos en formas intermedias estables y por ello son ms resistentes al cambio en especificaciones y tecnologa.

Desarrollo Iterativo

Cada iteracin resulta en un elemento ejecutable

Requerimiento s Planeamiento Anlisis y Diseo

Planeamiento Inicial

Ambiente de Administracin Evaluacin

Implementacin

Prueba Distribucin

Tecnologa orientada a objetos

Observa el mundo como objetos en lugar de procedimientos (procesos). propiedades ms valores

acciones y reacciones a mensajes propiedad que lo distingue de los dems objetos

Objeto
Dentro del AyD orientado a objeto, un objeto es cualquier cosa, real o abstracta, acerca de la cual almacenamos datos y los mtodos que controlan dichos datos.

Mtodos
Los mtodos especifican la forma en que se controlan los datos de un objeto. Los mtodos en un tipo de objeto slo hacen referencia a la estructura de datos de ese tipo de objeto. No deben tener acceso directo a las estructuras de datos de otros objetos. Para utilizar la estructura de datos de otro objeto, deben enviar un mensaje a ste.

Encapsulado
El objeto esconde sus datos de los dems objetos y permite el acceso a los datos mediante sus propios mtodos. El encapsulamiento evita la corrupcin de los datos de un objeto. El encapsulado protege los datos del uso arbitrario y no pretendido. Los usuarios se dan cuenta de las operaciones que puede solicitar del objeto, pero desconocen los detalles de cmo se lleva a cabo la operacin.

Mensajes
Para que un objeto haga algo, le enviamos una solicitud. Esta hace que se produzca una operacin. La operacin ejecuta el mtodo apropiado y, de manera opcional, produce una respuesta. El mensaje que constituye la solicitud contiene el nombre del objeto, el nombre de una operacin y, a veces, un grupo de parmetros.

Para trabajar
Vamos a dividir el trabajo en tres grandes fases: Planeacin y Elaboracin Anlisis Diseo

RequerimientosSon una descripcin de las necesidades o deseos de un producto. La meta principal consiste en identificar y documentar lo que en
realidad se necesita.

Aqu se describen en pocas palabras el o los objetivos generales del sistema.(presentar el sistema)

Descripcin del cliente.

Aqu se describe que es lo que se pretende que haga el software en beneficio del cliente.

UML

Que es UML?
UML quiere decir Unified Modeling Language (Lenguaje de Modelado Unificado)

UML es un lenguaje standard para visualizar, especificar, construir y documentar los artefactos de un sistema de software. UML puede usarse en las diferentes etapas del ciclo de vida del desarrollo y en diferentes tecnologas de implementacin UML es independiente del proceso de desarrollo de software

Qu no es UML

UML no es un mtodo de desarrollo. No te va a decir cmo pasar del anlisis al diseo y de este al cdigo. No son una serie de pasos que te llevan a producir cdigo a partir de unas especificaciones. UML al no ser un mtodo de desarrollo es independiente del ciclo de desarrollo que vayas a seguir, puede encajar en un tradicional ciclo en cascada, o en un evolutivo ciclo en espiral o incluso en los mtodos giles de desarrollo.

Porque Modelamos?
Un modelo es una simplificacin de la realidad

Construimos modelos para comprender mejor el sistema que estamos desarrollando

Modelado Visual
Modelo Conceptual Diagramas de Casos de Uso Diagramas de Actividad Diagramas de Secuencia Diagramas de Colaboracin Diagramas de Clases Diagramas de Estados

Subsistemas Modelado Visual eleva el nivel de abstraccin Clases Cdigo

Qu es abstraccin?
1 . Es un proceso mental que se aplica al seleccionar algunas caractersticas y propiedades de un conjunto de cosas del mundo real, excluyendo otras no pertinentes. En otras palabras, es una representacin mental de la realidad. 2 . En desarrollo de software, cualquier tcnica de generalizacin que ignora u oculta detalles para capturar algo en comn entre las diferentes instancias, con el propsito de controlar la complejidad intelectual de los sistemas de software.

Casos de Uso

Director Gestionar las encuestas

Cliente

QU ES UN CASO DE USO?
Describen una interaccin tpica entre un usuario (actores) y un sistema de cmputo. Es una tcnica para capturar informacin de cmo un sistema o negocio trabaja actualmente, o de cmo se desea que trabaje Produce algo de valor para algn actor como el clculo de algn resultado Describe qu hace un sistema pero no especifica cmo lo hace El caso de uso capta alguna funcin visible para el usuario. El caso de uso puede ser pequeo o grande. El caso de uso logra un objetivo discreto para el usuario. Un caso de uso debe ser simple, claro y conciso

PARA QUE SIRVEN LOS CASOS DE USO?

Para capturar el comportamiento deseado del sistema sin tener que especificar como se implementa ese comportamiento Como medio de comprensin del sistema para desarrolladores, usuarios finales y expertos del dominio Ayudan a validar la arquitectura y a verificar el sistema en el transcurso del desarrollo de este

CMO SE REPRESENTAN?
Un caso de uso se representa en UML como un valo: Nombre del Caso de Uso

En UML, un actor se representa como un mueco

Actor

Relaciones
Comunicacin

Generalizacin

<<include>>

Inclusin o uso

<<extends>>

Extencin

 Representa un conjunto de roles que los usuarios de los casos de uso juegan al interactuar con stos Representa un rol que es jugado por una persona, un dispositivo hardware u otro sistema que interacte con nuestro sistema Se puede definir categoras generales de actores (como cliente) y especializarlos (como ClienteComercial) a travs de relaciones de generalizacin
actor Cliente generalizacin Cliente actor Comercial

ACTORES

Un actor y un caso de uso se pueden comunicar a travs de una asociacin en donde cada uno de ellos pueden enviar y recibir mensaje.

Ademas
Cuando el actor corresponde a un sistema informtico externo se usa una notacin alternativa. Por ejemplo para un sistema de autorizacin de pagos cualquiera de las tres opciones siguientes es aceptada.

Generalizacin de ACTORES

Cuenta del cliente

Realizar Transaccin Con tarjeta Procesar factura Del cliente
Cliente Comerci o

Ajustar transacciones
Cliente Cliente individual corporativo

Gestionar cuenta Del cliente

Entidad financier a

RELACIONE S Para extraer el comportamiento de los casos de uso en los que se

incluye y poniendo ese comportamiento en otros casos de uso que lo extiende Tipos: Generalizacin Extensin Inclusin Generalizacin

<<include>>

Inclusin o uso

<<extends>>

Extensin

Ejemplos de Relaciones
Lmite extiende
Sistema de Pub

Informar Bodega

Sistema de Bodega extend

incluye
Vender Bebida Barmen include

caso de uso

Registrar Venta

actor

GENERALIZACIN
El caso hijo hereda el comportamiento y significado de caso de uso padre El hijo puede aadir o redefinir el comportamiento del padre El Caso de Uso fuente hereda la especificacin del Caso de Uso destino

Caso de uso destino Caso de uso origen

INCLUSIN
Un caso base de uso base incorpora explcitamente el comportamiento de otro caso de uso en el lugar especificado en el caso base. Se usa para evitar describir el mismo flujo de eventos repetidas veces, poniendo comportamiento comn en un caso de uso aparte Se representa como una dependencia estereotipada con <<include>>

REPRESENTACIN :

<<include>> Caso de uso destino

Caso de uso origen

EJEMPLO:
Buscando datos de producto <<include>> <<include>>

Ingresando pedido Empleado de ventas

Obtener reporte De Ventas por producto Gerente

EXTENSIN

Significa que un caso de uso base incorpora implcitamente el comportamiento de otro caso de uso en el lugar especificado indirectamente por el caso de uso que extiende al base Se usa esta relacin cuando se tiene un caso de uso que es similar a otro, pero que hace un poco ms.

<<extends>> Caso de uso destino Caso de uso origen

EJEMPLO:

Realizar Llamada telefnica

Red telefnica Actores

<<extend>>

Realizar llamada Con conferencia

relacin de extensin Recibir llamada telefnica

<<extend>>

Recibir llamada adicional

Casos de uso Usar agenda

Usuario

frontera del sistema

Telfono mvil

Tener en cuenta que En UML, cada caso de uso debe tener al menos un actor. Esta

forma de ver el sistema nos ayuda a concebirlo como un todo.

Un diagrama de casos de uso es un diagrama que muestra un conjunto de casos de uso, actores y sus relaciones. Son importantes para modelar el comportamiento de un sistema. Normalmente los casos de uso contienen:
Casos de Uso Actores Relaciones de dependencia, generalizacin y asociacin.

Los Diagramas de Casos de Uso Cubren principalmente el comportamiento del sistema.

Es un tipo especial de diagrama, por su contenido particular. Se emplean para modelar la vista de casos de uso esttica.(comportamiento, servicios externos). Para modelar el contenido de un sistema Dibujar una lnea alrededor de todo el sistema, los actores quedarn fuera del sistema e interactan con el, se especificara los actores y el significado de los roles. Para modelar los requisitos de un sistema Especificar que debera hacer el sistema, independientemente de cmo se haga, se especificar el comportamiento deseado del sistema. Permite ver el sistema entero como una caja negra.

Casos de uso de negocio

Director Gestionar las encuestas

Cliente

Casos de uso del software

Elaborar encuestas Usuario Marketing Procesar encuestas Usuario Director

Usuario Cliente

Llenar encuestas Generar reportes Consultar resultados de encuestas

Conclusiones
Los Casos de Uso no son parte del diseo (cmo), sino parte del anlisis (qu). Los Casos de Uso son qu hace el sistema desde el punto de vista del usuario. Es decir, describen un uso del sistema y cmo este interacta con el usuario. Los diagramas de casos de uso muestran las relaciones entre los casos de uso de un sistema y sus actores. En una relacin << extends>>, un actor que lleve a cabo el caso de uso base puede realizar o no sus extensiones. Mientras, en una relacin <<include>> el actor que realiza el caso de uso base tambin realiza el caso de uso incluido.

Trabajo Practico N1