Desarrollo de Proyectos de Software

Unidad 1: Conceptos introductorios

CONTENIDO OFICIAL
Unidad 1.- Conceptos Introductorios 1.1. La arquitectura de 4+1 vistas 1.2. Desarrollo orientado a objetos 1.3. Diagramacin

ARQUITECTURA
La arquitectura software trata el diseo e implementacin de la estructura de alto nivel del software. Es el resultado de ensamblar un cierto nmero de elementos arquitectnicos para satisfacer la funcionalidad y ejecucin de los requisitos del sistema; as como los requisitos no funcionales del mismo: fiabilidad, escalabilidad, portabilidad, disponibilidad, etc.

ARQUITECTURA
Aunque un Sistema de Software es una nica entidad, al arquitecto del software y a los desarrolladores les resulta til presentar el sistema desde diferentes perspectivas para comprender mejor el diseo. Estas perspectivas son vistas del modelo del sistema.

Todas las vistas juntas representan la Arquitectura.

1.1. ARQUITECTURA DE 4+1 VISTAS

Vista del Modelo de Referencia Vista de Componentes Modulares Vista de Distribucin fsica

(Funcionalidad)

Vista de Casos de Uso

Vista de Implementacin

VISTA DEL MODELO DE REFERENCIA

La vista del Modelo de Referencia (Reference Information Model), est determinada por la arquitectura lgica. La arquitectura lgica es capturada por los diagramas de Clases que contienen las Clases y relaciones que representan las abstracciones esenciales del sistema a desarrollar.
Clases Asociaciones Agregaciones Generalizacin Packages

VISTA DEL MODELO DE REFERENCIA

El Modelo de Referencia se construye en sucesivas iteraciones durante la fase de Formalizacin. Las Clases y Packages del modelo reflejan las decisiones tomadas con respecto a los mecanismos clave del sistema. La implementacin de mecanismos clave requiere seleccionar tambin: Lenguaje de programacin Motor de Base de Datos Interface grfico de usuario look and feel Tratamiento de errores Mecanismos de comunicacin Migracin y distribucin de objetos Networking

Modelo de Referencia

VISTA DEL MODELO DE COMPONENTES MODULARES

La vista de Componentes Modulares refleja la organizacin de mdulos de software dentro del entorno de desarrollo. Esta vista de arquitectura toma en cuenta los requerimientos que facilitan la programacin, los niveles de reutilizacin, y las limitaciones impuestas por el entorno de desarrollo.
Disponemos de dos elementos para modelizar esta vista:
Packages: En esta vista representan una particin fsica del sistema. Componentes: En esta vista representan la organizacin de mdulos de cdigo fuente.

VISTA DEL MODELO DE COMPONENTES MODULARES

Pedido

Informacin de artculos

VISTA DE IMPLEMENTACIN
Esta vista se centra en la estructura de los componentes run-time, los ejecutables del sistema. Esta arquitectura tiene muy en cuenta los siguientes requerimientos no funcionales:
Rendimiento Escalabilidad Seguridad Administracin del sistema Fiabilidad Integridad Sincronizacin

VISTA DE IMPLEMENTACIN
Los componentes run-time muestran los mappings de las Clases a libreras de tipo ActiveX, Applets de Java y libreras dinmicas. Los componentes ejecutables muestran sus interfaces y niveles de dependencia dentro de la aplicacin.

VISTA DE DISTRIBUCIN FISICA

Esta vista presenta el mapping de componentes de software ejecutables con los nodos de procesamiento (hardware). Esta arquitectura tiene en cuenta los siguientes requerimientos:
Disponibilidad del sistema Rendimiento Escalabilidad

Los diagramas de distribucin muestran el despliegue de nodos (locales y remotos), en la organizacin de la empresa. Permite al equipo de desarrollo comprender mejor la topologa de un sistema distribuido.

Modelo de Distribucin fsica

VISTA DE DISTRIBUCIN FISICA

En la mayora de los casos un Nodo puede representar una pieza de hardware, desde un perifrico a un servidor. Las Conexiones entre Nodos muestran las lneas de comunicacin con las que el sistema tendr que interactuar. Los Componentes, en un diagrama de distribucin, representan los mdulos fsicos de cdigo, los cuales, se corresponden con los Packages de ejecutables. De esta manera, el diagrama muestra donde corre cada Package en el sistema. Las Dependencias muestran cmo los componentes se comunican con otros componentes.

VISTA DE FUNCIONALIDAD
Esta vista certifica la validez de las cuatro vistas anteriores, con la funcionalidad requerida del sistema. Utilizamos los siguientes elementos para describir la funcionalidad: Diagramas de Casos de Uso Especificacin de Casos de Uso Diagramas de Interaccin (Escenarios) Diagramas de Actividad (Flujos de Trabajo) Diagramas de Estados (Dinmica)

Modelo de las 4+1 vistas (Kruchten)

Modelo de objetos, clases, entidadrelacin, etc

Vista del Modelo de Vista Lgica Referencia

Vista de Casos de Uso Escenarios

(Funcionalidad)

Vista de Componentes Desarrollo Modulares

Org. Esttica del sw en su Entorno de desarrollo Vista de componentes, .jar, etc) (libreras,

Vista de Vista de Implementacin Procesos

Modelo de concurrencia y sincronizacin

Vista de Vista Fsica Distribucin fsica

Modelo de correspondencia software-hardware

Relacin entre las vistas

La vista de escenarios o casos de uso es la de arranque, de ah, se pasa a la vista lgica. Despus de la vista lgica se realiza la de desarrollo y procesos; una vez que tenemos lo anterior, se concluye en la vista fsica.

Arquitectura y UML
Vista Escenarios Lgica Desarrollo UML Casos de Uso Clases, de Estados y Colaboracin Componentes

Fsica
Procesos

Despliegue
Actividades, Estados y Secuencia

Vistas, Diagramas y conceptos claves

1.2. DESARROLLO ORIENTADO A OBJETOS

El desarrollo Orientado a objetos es el proceso de realizar software utilizando como base el paradigma OO. Para el desarrollo de software orientado a objetos no basta usar un lenguaje orientado a objetos. Tambin se necesitar realizar un anlisis y diseo orientado a objetos.

Desarrollo Orientado a Objetos

POO

DOO

AOO

AOODOOPOO
El Anlisis Orientado a Objetos concierne al desarrollo del modelo de objetos del dominio de la aplicacin. El Diseo Orientado a Objetos trata del desarrollo del modelo del sistema orientado a objetos para implementar los requerimientos La Programacin Orientada a Objetos trata de la realizacin del Diseo Orientado a Objetos utilizando algn lenguaje de programacin orientada a objetos como C++ o Java.

Ventajas de desarrollar utilizando Orientado a Objetos

Fomenta la reutilizacin y extensin del cdigo. Permite crear sistemas ms complejos. Relacionar el sistema al mundo real. Facilita la creacin de programas visuales. Construccin de prototipos Agiliza el desarrollo de software Facilita el trabajo en equipo Facilita el mantenimiento del software

ANLISIS Y DISEO ORIENTADO A OBJETOS

Metodologa, conceptos, anlisis y diseo OO

ANLISIS ORIENTADO A OBJETOS

El Anlisis Orientado a Objetos (AOO), se basa en principios para modelar, describir y representar el comportamiento de modelos de datos, funcional y de comportamiento. Estos principios forman la base para el enfoque del Anlisis Orientado a Objetos.

DISEO ORIENTADO A OBJETOS

El Diseo de Software Orientado a Objetos (DOO), requiere la definicin de una arquitectura de software, especificacin de subsistemas, y bloques de construccin del sistema, con descripcin de mecanismos de comunicacin permitiendo la fluidez entre los datos, capas, subsistemas y objetos.

El modelo del proceso de OO

Identificar clases candidatas

Planifica cin Com un. Con el client e Evalua cin del cliente

Anli sis de riesg os

Construir n-sima Iteracin del sistema

Buscar clases en biblioteca

Ingenier a Constru cc. Y termin.

Aadir las Nuevas clases a la biblioteca

Extraer nuevas Clases si existen

Desarrollar las clases Si no existen Anlisis OO Diseo OO Programacin OO Pruebas OO

Analisis Orientado a Objetos

El propsito del AOO es definir todas las clases (y las relaciones y comportamientos asociadas con ellas) que son relevantes al problema que se va a resolver. Para cumplirlo se deben ejecutar las sig. Tareas: 1. Los requisitos bsicos del comunicarse entre el cliente y el IS usuario deben

2.Identificar las clases (atributos y mtodos) 3.Se debe especificar una jerarqua de clases 4.Representan las relaciones (conexiones de objetos) objeto a objeto

5.Modelar el comportamiento del objeto 6.Repetir iterativamente las tareas de la 1 a la 5 para completar el modelo.

Objetivo del AOO

El Objetivo del AOO es desarrollar una serie de modelos que describan el software de computadora al trabajar para satisfacer un conjunto de requisitos definidos por el cliente.

EL PROCESO DE AOO
El proceso de AOO no comienza con una definicin de los objetos, sino con una comprensin de la manera en la que se usar el sistema: por las personas, por otras mquinas o por otros programas. Una vez que se ha definido el escenario, comienza el modelado del software. Una tcnica para recopilar requisitos bsicos del usuario y despus permite definir un modelos de anlisis para un sistema OO son los CASOS DE USO (uses cases)

CASOS DE USO

Una vez que se han recopilado los requisitos, el IS puede crear un conjunto de escenarios, de manera que cada uno identifique una parte (hilo)del uso que se le dar al sistema a construir.
Para crear un caso de uso, el analista debe primero identificar los diferentes tipos de personas (o dispositivos) que usan el sistema o producto. Estos actores representan papeles ejecutados por personas (o dispositivos) cuando el sistema est en operacin.

 Un actor es cualquier cosa que se comunique con el sistema o producto y que sea externo a l. En el modelo de AOO no se identifican todos los actores en la primera iteracin.

Una vez que los actores han sido identificados pueden desarrollarse casos de uso. EL CASO DE USO DESCRIBE LA FORMA EN LA CUAL UN ACTOR INTERACTUA CON EL SISTEMA

DISEO ORIENTADO A OBJETOS

El diseo orientado a objetos transforma el modelo de anlisis creado usando el anlisis orientado a objetos en un modelo de diseo que sirve como un anteproyecto para la construccin del software. La naturaleza del DOO se apoya en cuatro importantes conceptos de diseo del software: ABSTRACCIN OCULTAMIENTO DE LA INFORMACIN INDEPENDENCIA FUNCIONAL MODULARIDAD

EL DISEO ORIENTADO A OBJETOS

 La capa del subsistema contiene una representacin de cada uno de los subsistemas que le permiten al software conseguir que los requisitos definidos por el cliente e implementar la estructura tcnica que los soporta. La capa de clases y objetos. Contiene las jerarquas de clases que permiten crear el sistema usando generalizacioens y especializaciones mejor definidas incrementalmente. Esta capa tambien contiene representaciones de diseo para cada objeto. La capa de mensajes. Contiene los detalles que le permiten a cada objeto comunicarse con sus colaboradores. Esta capa establece las interfaces externas e internas para el sistema. La capa de responsabilidades. Contiene las estructuras de datos y el diseo algortmico para todos los atributos y operaciones de cada objeto.

CONVERSION DEL MODELO DE ANLISIS EN UN MODELO DE DISEO DURANTE EL DISEO DE OBJETOS

Modelo de Anlisis Clases Atributos Mtodos Relaciones Comportamiento

Modelo de Diseo Objetos Estructuras de datos Algoritmos Mensajes Control

CONCLUSIONES
El AOO es el fundamento de cualquier proceso OO en el que se quiera desarrollar un SW con cualidades que le permitan incorporar una Ingeniera de componentes de forma natural. El Diseo Orientado a Objetos es un medio para disear software de tal forma que los componentes del diseo representen objetos con su estado y operaciones privadas propias en lugares de funciones

Metodologas de Desarrollo de Sw
Booch OMT Shlaer && Mellor OOSE XP CRC y RDD Coad Yourdon

EXPOSICIN

1.3. DIAGRAMACIN
La diagramacin se refiere al uso de mtodos y notaciones grficas que llevan como fin facilitar la expresin y comunicacin de ideas. En cuanto al rea de software existen varias herramientas de diagramacin, entre las ms utilizadas actualmente est el UML (Lenguaje Unificado de Modelado), el cual es una notacin grfica para dibujar diagramas de conceptos de software.

Aportaciones de los creadores de UML

Jacobson

Jacobson

Booch

Rumbaugh

UML para Diagramar

Se puede utilizar para dibujar diagramas de un dominio del problema, un diseo del software propuesto o una implementacin de un software ya completado. Existen tres niveles diferentes: Conceptual, Especificacin, Implementacin.

Niveles de Diagramacin
Los Diagramas de los niveles de especificacin y de implementacin. Tienen una conexin fuerte con el cdigo fuente. Su propsito es que un diagrama del nivel de especificacin se transforme en cdigo fuente, y que un diagrama del nivel de implementacin describa un cdigo fuente existente. Los Diagramas en el nivel conceptual. No estn tan fuertemente relacionados con el cdigo fuente. No siguen reglas semnticas estrictas y, por tanto su significado puede ser ambiguo y sujeto a interpretacin.

TIPOS DE DIAGRAMAS
UML tiene tres clases principales de diagramas. Los diagramas estticos describen la estructura lgica invariable de los elementos software representando clases, objetos, estructuras de datos y las relaciones entre ellas. Los diagramas estructurales sirven para visualizar, especificar, construir y documentar los aspectos estticos de un sistema. Los diagramas de comportamiento se emplean para visualizar, especificar, construir y documentar los aspectos dinmicos de un sistema.

PANORAMA GENERAL
UML Elementos Estructurales
Casos de uso Clase Interfaz Componente Colaboracin Nodo

Relaciones De anotacin
Nota Dependencia Asociacin Generalizacin

Diagramas
Casos de uso Clases Objeto Secuencia Colaboracin Estados Actividad Componente Despliegue

De comportamiento
Interaccin Mq. De estados

De agrupacin
Paquete Subsistema Marco de trabajo

Elementos Estructurales
Los elementos estructurales son los sustantivos de los modelos UML. Estos son la mayora de las partes estticas de un modelo, representando elementos que son conceptuales o fsicos.

Elementos Estructurales (Cont.)

Clases Una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones, y semnticas. Atributos Un atributo es una propiedad de una clase que describe un rango de valores que las instancias de la clase pueden retener. Operacin Una operacin es la implementacin de un servicio que puede ser solicitado por cualquier objeto de la clase para afectar un comportamiento.

Clases

Elementos Estructurales (Cont.)

Caso de Uso Un caso de uso especifica el comportamiento o la parte de un sistema y es una descripcin de un conjunto de secuencias de acciones, incluyendo variantes, que un sistema desarrolla para brindar un resultado observable del valor a un actor.

Actor Un actor representa un conjunto coherente de roles que los usuarios de los casos de uso desempean cuando interactan con estos casos de uso.

Casos de Uso y Actor

Elementos Estructurales (Cont.)

Interfaz Una interfaz es un conjunto de operaciones que especifican un servicio de una clase o componente.

Colaboracin Una colaboracin define una interaccin y es una sociedad de roles y otros elementos que trabajan conjuntamente para proveer algn comportamiento cooperativo que es mayor que la suma de todos los elementos.

Interfaz y Colaboracin

Elementos Estructurales (Cont.)

Clases Activas Una clase activa es una clase cuyos objetos poseen uno o ms procesos o hilos de ejecucin (threads) y por lo tanto pueden inicializar una actividad de control. Componente Un componente es una parte fsica y reemplazable que conforman y provee la realizacin de un conjunto de interfaces. Nodo Un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional.

Clase Activa, Componente y Nodo

Elementos de Comportamiento
Los elementos de comportamiento son las partes dinmicas de los modelos UML. Estos son los verbos de un modelo, representando el comportamiento a travs del tiempo y el espacio.

Elementos de Comportamiento (Cont.)

Interaccin Una interaccin es un comportamiento que abarca un conjunto de mensajes intercambiados entre un conjunto de objetos dentro de un contexto particular o logran un propsito especfico. Mquina de Estado Una mquina de estado es un comportamiento que especifica las secuencias de estados de un objeto o una interaccin realizada durante su tiempo de vida en respuesta a eventos, junto con su respuesta a estos eventos.

Interaccin y Mquina de Estado

Elementos de Agrupacin
Los elementos de agrupacin son organizacionales de los modelos UML. la partes

Paquetes Un paquete es un mecanismo de propsito general para organizar elementos en grupos.

Elementos de Anotacin
Los elementos de anotacin son las partes explicativas de los modelos UML.
Nota Una nota es un smbolo simple para establecer condiciones y comentarios ligados a un elemento o coleccin de elementos.

 Dependencia Una dependencia es una relacin de uso que un cambio en la especificacin de un elemento puede afectar a otro elemento que lo utiliza, pero no necesariamente lo contrario.
Asociacin Una asociacin es una relacin estructural que especifica que objetos de un elemento estn conectados a objetos de otro.

Relaciones

Dependencia y Asociacin

Relaciones (Cont.)
Agregacin Una agregacin es una forma especial de asociacin que especifica una relacin todo/parte entre el agregado (el todo) y un componente (la parte). Una variacin es la composicin. Generalizacin Un generalizacin es una relacin entre un elemento general y un tipo ms especfico de ese elemento. Algunas veces llamada una relacin es-parte-de.
Realizacin Una realizacin es una relacin semntica entre clasificadores, en donde, un clasificador especifica un contrato que otro clasificador garantice para realizar.

Agregacin, Generalizacin y Realizacin

DIAGRAMAS

Sus diagramas

Modelado
Establecimiento de los requisitos de usuario Modelado de la estructura esttica Modelado de interaccin

Diagrama
Diagrama de Casos de Uso Diagrama de Clases Diagrama de Colaboracin Diagrama de Secuencia Diagrama de Estados Diagrama de Actividades Diagrama de Componentes Diagrama de Despliegue

Modelado dinmico

Modelado de implementacin

Diagrama de Clases
Una Clase representa a un tipo de objetos que comparten:
Las mismas propiedades (Atributos)

El mismo comportamiento (Mtodos)

Las mismas relaciones con (asociaciones y agregaciones) otros objetos

La misma semntica dentro del sistema

Ejemplo
La clase Persona tiene Nombre, Direccin y Nmero del Seguro social. Una Persona puede trabajar en algn proyecto y ganar un salario. Una Compaa tiene un Nombre, Direccin, Nmero telefnico y Producto Primario. Una Compaa contrata y despide Personas. Persona y Compaa tienen una relacin de muchos-muchos. Hay dos tipos de Personas: Trabajadores y Administradores. Cada Trabajador est involucrado en varios Proyectos; cada Administrador es responsable de varios proyectos. En un proyecto pueden trabajar varios trabajadores y un solo administrador. Cada proyecto tiene Nombre, Presupuesto y una Prioridad interna para asegurar recursos. Adems, una Compaa est compuesta de mltiples Departamentos; cada Departamento dentro de una Compaa se identifica de forma nica por su Nombre. Un Departamento usualmente tiene un Administrador. La mayora de los administradores manejan un departamento; y algunos administradores no estn asignados a ningn departamento. Cada departamento, manufactura varios productos; mientras que cada producto est hecho por un solo departamento. Un Producto tiene Nombre, Costo y Peso.

DIAGRAMA DE CLASES PARA PERSONAS QUE TRABAJAN EN COMPAAS

Persona Nombre Direccin RFC
Compaa

Empleado

Empleador

trabaja-para

Nombre Direccin Telfono Producto

Trabajador

Administrador

*
administra
0..1 0..1 1 Departamento

*
trabaja-en

responsable-de

manufactura

*
Nombre Presupuesto Prioridad

*
Proyecto Nombre Costo Peso

*
Producto

A partir de este diagrama se podran definir los Requerimientos bsicos?

Diagrama de Casos de Uso

Muestran la granularidad del sistema en piezas de funcionalidad reutilizables

Muestran la interaccin de los Actores con la funcionalidad del Sistema

Organizan visualmente los requerimientos del usuario

Permiten certificar contractualmente la funcionalidad

Formalizan el mapa de procesos de negocio

Ventajas de los Casos de Uso

Lenguaje de comunicacin desarrolladores entre usuarios y

Comprensin detallada de la funcionalidad del Sistema Acotacin precisa de las habilitaciones de los usuarios Trazabilidad desde los requerimientos al cdigo ejecutable

<<Incluye>>
Tramitador

Matricular Alumnos

<<Incluye>> Validar Requisitos <<Incluye>>

Identificar Alumno <<Incluye>> <<Incluye>> <<Incluye>>

Generar NIP <<Extiende>>

Generar
Generar Mov. Tasa
Cod. Anonimato

Imprimir
Abonar Recibo

<<Incluye>> Generar Rfaga Banc.

Calcular
Importe Matrcula

Diagrama de Actividad
Muestra la secuencia de actividades que se desarrollan en el flujo de trabajo de un Caso de Uso, como pieza de funcionalidad concreta Muestra el flujo de trabajo que se desarrolla en un proceso configurado como un paquete de Casos de Uso

Diagrama de Actividad

Diagrama de Secuencia
Describe la interaccin de objetos que requiere la funcionalidad de los distintos escenarios de un Caso de Uso Los objetos son representados con su ciclo de vida dentro de una serie temporal
Cada posible escenario de un Caso de Uso puede representarse con un diagrama de secuencia

Diagrama de Colaboracin
Muestra lo mismo que un diagrama de secuencia cmo interaccionan los objetos dentro de un Caso de Uso
A diferencia de un diagrama de secuencia no hay referencia a una serie temporal Su propsito es mostrar la topologa del proceso distribuido entre los distintos objetos

Diagrama de Estado Transicin

Muestra los distintos estados en que un objeto puede existir Presenta la visin dinmica del sistema Describe el comportamiento de un objeto, desde que nace hasta que muere Identifica todos los eventos necesarios para realizar la transicin de un estado a otro

Diagrama de Estados

Diagrama de Componentes
Muestra la vista fsica del modelo
Muestra los componentes de software que configuran el sistema y su interdependencia

Presenta dos tipos de componentes:

Ejecutables Libreras de cdigo Cada clase del modelo es mapeada con el cdigo fuente de un componente

Vista de los componentes ejecutables

Conta.exe
Sistema Contabilidad

Matrcula.exe

Agentes.dll

Cursos.dll
Cursos

Usuarios

Alumnos

Profesores

Curso

Oferta de Cursos

Diagrama de Despliegue
Muestra la distribucin fsica de los componentes en nodos locales y remotos de la red Un nodo puede representar una pieza de hardware, desde un perifrico a un servidor
Presenta los distintos componentes arquitectura en tres capas (3Tier) de una

Servidor de datos Servidor de aplicaciones Cliente

Vista de la distribucin fsica de nodos de proceso