clevertechsite.files.wordpress.com€¦ · Web viewDocumento de especificación de diseño SDS....

Documento de especificación de diseño SDS

Universidad Piloto de Colombia Sistema de Transporte Fluvial

CleverTech

Ciclo: 2

Tabla de Contenido1. INTRODUCCIÓN.........................................................................................................2

1.1. Objetivo.........................................................................................................21.2. Alcance..........................................................................................................31.3. Definiciones y Abreviaturas...........................................................................4

2. GENERALIDADES DEL PROYECTO...................................................................................52.3. ANÁLISIS DEL DISEÑO CONCEPTUAL INICIAL (ESTRATEGIA)..............................................6

Conceptualización....................................................................................................62.4. ESTÁNDARES DE DISEÑO.........................................................................................7

Convenciones de nombres.......................................................................................7Indentación..............................................................................................................7Comentarios............................................................................................................7Declaraciones..........................................................................................................8Clases......................................................................................................................8

3. ARQUITECTURA DE SOFTWARE......................................................................................83.1. Principales decisiones de diseño...................................................................83.2. Estilo de arquitectura (Patrón de arquitectura).............................................93.3. Justificación...................................................................................................93.4. Estructura del producto a desarrollar en el ciclo 2.........................................93.5. Puntos de vista............................................................................................103.6. Contexto, Funcional, Desarrollo, Información, Despliegue...........................113.7. Descripción de componentes.......................................................................143.8. Asignación de casos de uso a componentes responsables..........................14

4. CONJUNTO DE PERSPECTIVAS.....................................................................................164.1. Seguridad, Usabilidad, Distribución geográfica, Modificabilidad..................16El Proyecto STF busca que no todo el personal tenga acceso a los datos y por eso se buscará que para poder acceder sea necesario una autenticación por medio de un usuario y clave..................................................................................................16

5. DISEÑO DETALLADO.................................................................................................165.1. Diseño de clases..........................................................................................165.3. Diseño de interfaces....................................................................................175.4. Interfaces gráficas de acuerdo a casos de uso............................................195.5. Diseño de datos...........................................................................................23



CleverTech

Ciclo: 2

1. Introducción1.1. Objetivo1.1.1. General

Establecer el diseño, parámetros, elementos y componentes básicos que sirven como base sólida para el desarrollo de la solución propuesta para así implementar el proyecto “Sistema de Transporte Fluvial”.

1.1.2. Específicos Definir una arquitectura que busque el mayor desempeño y

practicidad en la solución, de tal manera que cambiar funcionalidades, realizar mantenimientos o llevar a cabo desarrollo del proyecto no sea tedioso ni complicado.

Establecer detalladamente las clases que hacen parte del mundo del problema para así definir de manera clara que elementos interactúan entre sí, hay que tener en cuenta que en el documento de estrategia marcamos un punto de partida desde los usuarios finales por lo tanto las entidades que surjan del diagrama de clases serán producto del análisis de los requerimientos de este tipo de usuarios.

Analizar los casos de usos que hacen posible llevar a cabo los requerimientos que demanda el sistema de transporte fluvial, esto nos ayudará a definir de manera clara las interfaces que se harán para hacer posible el monitoreo de los sensores, las alertas a los monitores y el servicio al cliente.

Plantear un modelo de datos que se acople de manera correcta a las necesidades del sistema, para ello se determinarán que las entidades existen y como están relacionadas para así crear los respectivos diagramas de datos.

Verificar que los elementos descritos como solución cumplan con los requerimientos definidos para el software y con los atributos de calidad establecidos para el proyecto.

Determinar que herramientas serán usadas para llevar a cabo el desarrollo de la solución y la implementación teniendo en cuenta las posibles limitaciones tecnológicas que se encuentren en el camino, además de como este juego de partes tecnológicas se organizan de manera correcta para que estas trabajen eficazmente.

Dejar una documentación clara para futuras modificaciones.



CleverTech

Ciclo: 2

1.2. Alcance

Este alcance esta dado principalmente por los requerimientos de los usuarios finales, por lo tanto, el diseño está ligado a ellos y marcan unos límites que respetan los parámetros dados en el documento de estrategia ligados al proceso y metodología de desarrollo del proyecto predicho. Además, se debe tener en cuenta en cumplir con cada necesidad funcional dicha en el enunciado del problema tomada al cliente, entre estas funcionalidades el diseño debe velar por los siguientes requerimientos:

• Realizar el debido control y monitoreo de los tres transportes de Sistema de Transporte Fluvial: Fluvial-Cab, Fluvial-Cargo y Fluvial-Passengers.• Tener un control respectivo del estado de cada tipo de embarcación, en la siguiente tabla podemos ver tipo de control:

Fluvial-Cab Fluvial-Cargo Fluvial-Passengers

Verificación que la embarcación no está ocupada por un cliente para hacer la debida asignación o relevo de embarcación.

Conocer cuanta capacidad de carga se le ha asignado a cada embarcación

Conocer la cantidad de pasajeros

Conocer puerto de parada


Identificar los horarios de operación en esta

Conocer el estado de la embarcación (Si está en mantenimiento o en servicio)

Conocer el estado de la embarcación (Si está en mantenimiento o en servicio)




CleverTech

Ciclo: 2

• Monitoreo se compone de la posición de los barcos en el rio magdalena, el tiempo que tardan en realizar un trayecto y cumplimiento de las paradas.• Monitorear los 300 sensores del rio magdalena para permitir la navegación de los transportes de Sistema de Transporte Fluvial, dependiendo de la altura del rio:

o Fluvial cargo: mínimo 1.5 metros más 0.3 metros por encima de la altura del rio.

o Fluvial Passanger: mínimo 1.25 metros más 0.3 metros por encima de la altura del rio.

o Fluvial Cab: mínimo 0.03 metros más 0.3 metros por encima de la altura del rio.

• Los datos deben trasmitirse de manera segura, rápida y las 42 horas al día, los 365 días al año.

Por otra parte, se debe definir las formas que ayudará a modelar el mundo del problema:

La arquitectura definitiva del proyecto (Esto nos permite determinar que estructura usar a la hora de crear el sistema de servicio y de que elementos estará conformada)

Los patrones que guiarán el diseño detallado El modelo de interfaces del sistema. El modelo de clases que representa el negocio El modelo de datos propuesto Responsabilidades de las clases

1.3. Definiciones y Abreviaturas UCxx: Hace referencia al código de un caso de uso. STF: Sistema de Transporte Fluvial SDS: Documento de especificación de diseño



CleverTech

Ciclo: 2

2. Generalidades del proyecto2.1. Problema del proyecto

Actualmente STF ha pensado en el presente proyecto para poder resolver principalmente los siguientes problemas;

Problemas

Control oportuno de sus embarcaciones

Conocer la posición actual de todas sus

embarcaciones

El estado de cada una de

ellas.

Enviar la embarcación disponible que se encuentre más cercana al usuario

Controlar la ruta seguida por cualquiera de las embarcaciones Fluvial-Cab, Fluvial-Passanger o Fluvial-Cargo y los tiempos invertidos en cada

trayecto.

Hacer posible las alertas de emergenciaControl y alertas acerca de los sensores

2.2. Definir principales retos de diseño

El principal reto es hacer posible la creación de una estructura de datos y lógica que sea capaz de analizar y guardar los datos emitidos tanto del GPS de las embarcaciones como la de los sensores de altura.

Crear y definir las interfaces correspondientes a los casos de uso de manera que tenga un diseño practico y entendible para los usuarios finales.

Crear una arquitectura capaz de dar respuesta a todo el conjunto de peticiones productos de los estímulos de los factores externos (sensores, botones de pánico, usuarios finales, datos de la embarcación en vivo).



CleverTech

Ciclo: 2

Crear la estructura de datos correcta que sea capaz de almacenar todos los datos relacionados con las embarcaciones, usuarios finales y monitores para la generación de reportes.

Escoger la arquitectura más indicada para poder llevar a cabo un servicio capaz de responder a la necesidad del STF.

2.3.Análisis del diseño conceptual inicial (Estrategia)Análisis de Requisitos

Especificaciones del problemaEn esta parte se identifica y describe los requisitos que se necesitan para poder modelar y estructurar el problema: analizar las especificaciones del problema, los requerimientos funcionales y no funcionales y como se relacionan en la lógica del negocio.Se busca eliminar en esta etapa (antes de que sea más costoso) todas las ambigüedades que se presenten en el proyecto, si es el caso completarlas, especificarlas y estructurarlas: Elegir un nivel apropiado de abstracción para los términos. Evitar expresiones vagas/indirectas. Estandarizar los enunciados.Como resultado se espera la detección de los datos necesarios para el software.

ConceptualizaciónSe busca responder a la pregunta ¿Cómo representarlo?, recogiendo la semántica de los requerimientos para luego estructurarlos: Sustantivos como tipos de entidad/atributos Nombres propios como ocurrencias de tipo entidad frases verbales indican un tipo de relación frases preposicionales indican una interrelación los atributos son datos de un objeto.Por medio de estas relaciones semánticas se busca pasar del lenguaje del problema a un diseño conceptual para tratar los datos.



CleverTech

Ciclo: 2

2.4.Estándares de diseño

Convenciones de nombres Clases

Los nombres de las clases deben ser sustantivos, cuando son compuestos tendrán la primera letra de cada palabra que lo forma en mayúsculas. Intentar mantener los nombres de las clases simples y descriptivas.

MétodosLos métodos deben ser verbos, cuando son compuestos tendrán la primera letra en minúscula, y la primera letra de las siguientes palabras que lo forma en mayúscula.

Variablestodas las instancias y variables de clase o método empezarán con minúscula. Las palabras internas que lo forman (si son compuestas) empiezan con su primera letra en mayúsculas, el nombre esta designado para indicar a un observador casual su función. Los nombres de variables de un solo carácter se deben evitar, excepto para variables índices temporales.

ConstantesLos nombres de las variables declaradas como constantes deben ir totalmente en mayúsculas separando las palabras con un subguión

IndentaciónSe deben emplear cuatro espacios como unidad de indentación. No utilizar líneas de más de 80 caracteres, ya que no son manejadas bien por muchas terminales y herramientas.Cuando una expresión no entre en una línea, romperla de acuerdo con estos principios: Romper después de una coma, romper antes de un operador, alinear la nueva línea con el comienzo de la expresión al mismo nivel de la línea anterior.Saltar de líneas por sentencias “if” deberá seguir generalmente la regla de los 8 espacios, ya que la indentación convencional (4 espacios) hace difícil ver el cuerpo.

ComentariosEsta sección es reservada para los comentarios de implementación, que se deben usar para dar descripciones de código y facilitar información adicional que no es legible en el código mismo. Los comentarios deben contener sólo información que es relevante para la lectura y entendimiento del programa.



CleverTech

Ciclo: 2

Los comentarios de implementación son aquellos que se ven delimitados por /*...*/, y //.Los comentarios no deben encerrarse en grandes cuadrados dibujados con asteriscos u otros caracteres, los comentarios nunca deben incluir caracteres especiales.

DeclaracionesInicializar las variables locales donde se declaran. La única razón para no inicializar una variable donde se declara es si el valor inicial depende de algunos cálculos que deben ocurrir. Poner las declaraciones solo al principio de los bloques (un bloque es cualquier código encerrado por llaves "{" y "}".)

ClasesNingún espacio en blanco entre el nombre de un método y el paréntesis "(" que abre su lista de parámetros. La llave de apertura "{" aparece al final de la misma línea de la sentencia declaración, La llave de cierre "}" empieza una nueva línea indentada para ajustarse a su sentencia de apertura correspondiente.

3. Arquitectura de software3.1. Principales decisiones de diseño

Además de los estándares mencionados anteriormente, para la facilidad de la documentación, se ha decidido implementar en el proyecto la semántica de documentación Javadoc.La documentación para Javadoc ha de incluirse entre símbolos de comentario que han de empezar con una barra y doble asterisco, y terminar con un asterisco y barra simple (/** **/).La ubicación le define a Javadoc qué representa el comentario: si está incluido justo antes de la declaración de clase se considerará un comentario de clase, y si está incluido justo antes de la signatura de un constructor o método se considerará un comentario de ese constructor o método. En Javadoc se usan ciertas palabras reservadas precedidas por el carácter "@", dentro de los símbolos de comentario Javadoc. Si no existe al menos una línea que comience con @ no se reconocerá el comentario para la documentación de la clase.



CleverTech

Ciclo: 2

3.2. Estilo de arquitectura (Patrón de arquitectura)Para el proyecto se deberá documentar todas las clases, indicándolo que hace la clase, el autor y la versión del programa, hablada en el debido documento de control de versiones. /** * Resumen de la función de la clase * * @author Nombre del autor – rol * @version versión del documento */Documentar todos los métodos indicando lo que hace el método, los parámetros de entrada: Para cada parámetro hay que escribir el nombre del parámetro, una descripción de lo que se espera en el parámetro. El resultado que devuelve y una descripción de lo que devuelve, el método puede no retornar ni tener parámetros, por ello no se documentan, las excepciones que maneja el método. /** * Descripción del método * * @paramnombreDelParametro descripción del parámetro * @return Descripción de lo que retorna * @throwsNombreExcepcion descripción del porqué de la excepción */Se puede utilizar @see en los métodos o clases para asociaros con otra clase o método.

3.3. JustificaciónJavadoc es una utilidad de Oracle para la generación de documentación de APIs en formato HTML a partir de código fuente Java, que si se implementa desde el principio del proyecto es fácil de administrar y aporta un gran soporte en las etapas de mantenimiento del proyecto

3.4. Estructura del producto a desarrollar en el ciclo 2La estructura del ciclo uno, se basará en lo planteado para formalizar la estrega, que se basa en:

Identificación de entidades (clases, métodos, ...) Agrupar métodos en clases Identificar relaciones entre clases Refinar las clases



CleverTech

Ciclo: 2

Seguido del diseño detallado, en donde se Definen los atributos y argumentos de las operaciones y se Codifican interfaces

3.5. Puntos de vistaEl principal propósito del sistema es describir los elementos funcionales del sistema, tanto, así como las principales responsabilidades, interfaces y las interacciones dentro de los puntos de vista que se han introducido y han sido referenciadas por los stakeholders dentro de los documentos de arquitectura que afecta ciertos modelos desde los puntos de vista como la información, el estado, la ubicación, entre otros.

El punto de vista posee un impacto significativo a los atributos del sistema tanto la posibilidad de tener ciertas mejoras a futuro o ser modificado, este tendrá cierto grado de seguridad y restricciones, buscando un equilibrio entre la ejecución y el desempeño.

Se han definido los siguientes ítems:

- Descripción de la capacidad funcional del sistema de transporte fluvial- Descripción y asignación de los elementos tales como las

responsabilidades, las interfaces a mostrar, las interacciones que se dan entre estos.

- Asignación de interfaces como muestra al sistema- Asignación de la estructura interna del sistema

Se han utilizado ciertos modelos o patrones para el diseño de la solución entre ellos se han utilizados los diagramas de componentes, los modelos funcionales (estructura), siendo este el que define que se quiere hacer bien sea de tipo implícito o explícito.

Según el diseño como atributo de calidad se busca que el sistema sea escalable, sea seguro y que tenga buen desempeño, la filosofía de diseño implementada en el proyecto se basa en buenos principios de construcción con flexibilidad, coherencia, buen acoplamiento, gran interacción entre elementos y cohesión.

Se utiliza diagrama UML por cada elemento del sistema representado en un icono del componente, se pueden utilizar modelos de programación para hacer más cara la estructura funcional del programa.



CleverTech

Ciclo: 2

3.6. Contexto, Funcional, Desarrollo, Información, Despliegue.3.6.1. Vista de Contexto

3.6.2. Vista Funcional



CleverTech

Ciclo: 2



CleverTech

Ciclo: 2

3.6.3. Vista de Información

3.6.4. Vista de Despliegue



CleverTech

Ciclo: 2

3.7. Descripción de componentes Embarcación

Es el medio por el cual un usuario se puede desplazar por el rio Magdalena, es el servicio que se está prestando. Existen tres (3) tipos de embarcaciones las cuales son: Fluvial Cargo (Es una embarcación destinada al envió de una encomienda, sólo es para cualquier tipo de carga), Fluvial Cab (Es una embarcación que se dedica al desplazamiento de usuarios bajo una petición, es un servicio personalizado que no cuenta con horarios específicos) y Fluvial Passenger (Es una embarcación que se encarga de movilizar un grupo de personas desde un puerto a otro siguiendo un horario establecido).La embarcación reporta su posición actual en tiempo real gracias al caso de uso consultar embarcación, el cual reporta los datos generales de la unidad a consultar: estado, tipo, marca, modelo y la ubicación actual a la hora de consultarla. La aplicación también reportara de forma continua en un mapa utilizando el mismo caso de uso pero con



CleverTech

Ciclo: 2

actualización continua la posición de la embarcación y se podrá evidenciar el desplazamiento de esta, controlando así la ubicación de las embarcaciones y el cumplimiento de las rutas de las embarcaciones (con excepción del servicio Fluvial Cab que no tiene una ruta definida).

ProblemaEste surge cuando durante un viaje la embarcación y usuario sufren algún imprevisto, puede considerarse cualquier daño técnico o mecánico de las embarcaciones, se considera también cuando la caudal suba o baje y que la embarcación se vea en riesgo de un accidente.

UsuarioEs la persona que contrata o adquiere el servicio, es la persona que paga por usar cualquier de las tres (3) embarcaciones.

MonitorEs la persona que se encuentra en los puertos encargada de estar supervisando los viajes, los sensores y las embarcaciones. Es el encargado de supervisar los horarios, disponibilidad e información de las embarcaciones.

SensorSon dispositivos ubicados en el rio para el control, administración y supervisión del caudal y embarcaciones que están en servicio.

3.8. Asignación de casos de uso a componentes responsables

ComponentesUC CASO DE USO Embarcación Problema Usuario Monitor SensorUC- 001 Consultar Sensores xUC- 002 Consultar embarcación x UC- 003 Asignar embarcación x UC- 004 Alertas de embarcación x UC- 005 Alertas de nivel de agua x UC- 006 Generar informe x UC- 007 Enviar Informe x UC- 008 Loguearse x UC- 009 Crear Usuario x UC- 010 Cambiar Contraseña x UC- 011 Recuperación Contraseña x



CleverTech

Ciclo: 2

UC- 012 Solicitar Servicio x UC- 013 Cancelar Servicio x UC- 014 Pedir Multa x UC- 015 Dejar Calificación x UC- 016 Agregar Embarcación x



CleverTech

Ciclo: 2

4. Conjunto de perspectivas4.1. Seguridad, Usabilidad, Distribución geográfica, Modificabilidad.

El Proyecto STF busca que no todo el personal tenga acceso a los datos y por eso se buscará que para poder acceder sea necesario una autenticación por medio de un usuario y clave.

5. Diseño detallado5.1. Diseño de clases

5.2. Diagrama de Clases por componente



CleverTech

Ciclo: 2

5.3. Diseño de interfaces



CleverTech

Ciclo: 2



CleverTech

Ciclo: 2

5.4. Interfaces gráficas de acuerdo a casos de uso



CleverTech

Ciclo: 2



CleverTech

Ciclo: 2

5.5. Diseño de datos

Teniendo en cuenta que vamos a mover gran cantidad de datos y que el problema planteado se puede modelar con entidades relacionales es conveniente utilizar bases de datos relacionales y más específicamente SQL ya que estas son eficientes y rápidas a la hora de utilizarlas, además el equipo de trabajo posee el conocimiento básico para plantear el problema en este tipo de estructuras de datos. Las operaciones que debe ser capaz de llevar a cabo son consultar, borrar, agregar y actualizar registros. Teniendo en cuenta lo anterior proseguiremos a escoger la base de datos que conviene:

WINDOWS GRATUITA

INTERFAZ DE USO

ORACLE O X 8MYSQL O O 8SQL SERVER O X 6POSTGRESQ

L O O 7

Tabla comparativa de SGBD

Como podemos ver por precio y utilidad decidimos escoger MYSQL, además que el equipo de trabajo reconoce muy bien tal gestor.

Teniendo en cuenta que el lenguaje que usa MYSQL es SQL (valga la redundancia) se debe llevar a cabo una correcta signatura en las consultas, codificación y notación de los elementos que hacen parte de la implementación de la solución en este SGBD, para esta tarea se usarán NORMAS DE PROGRAMACION T-SQL además la forma de nombrar las entidades deben ser mayúsculas, los atributos minúsculos y todas las palabras reservadas utilizadas de SQL deben estar en mayúsculas.

Para llevar a cabo un diseño de datos es imprescindible identificar las principales entidades que hacen parte del mundo del problema. Teniendo



CleverTech

Ciclo: 2

en cuenta lo dicho anteriormente encontramos las siguientes entidades que hacen parte del problema con sus respectivos atributos:

Embarcación

Tipo de embarcación Capacidad Calado Horarios Identificador de embarcación Estado Ruta Actual Canoero Asignado Actualmente

Usuarios

Nombre Cedula Tipo de pago Teléfono Contraseña Nombre de Usuario

Monitor

Nombre Tipo de Permisos Login Pass

Puertos

Ubicación Capacidad Nombre

Sensores

Ubicación Identificador



CleverTech

Ciclo: 2

Estado

Canoeros

Nombre Cedula Teléfono Comentarios

Viaje

Puerto Origen Puerto Destino Embarcación Canoero Asignado Hora Partida Hora Llegada Problemas Comentarios

clevertechsite.files.wordpress.com€¦ · Web viewDocumento de especificación de diseño SDS....

Documents

Transcript of clevertechsite.files.wordpress.com€¦ · Web viewDocumento de especificación de diseño SDS....