Perfil Admon de Sistemas Informaticos
+-+copia.JPG)
- ROBINSON
- OTRO, CASANARE-YOPAL, Colombia
- De acuerdo a los estudios realizados estoy capacitado para desempeñar y realizar mantenimiento y reparación de computadores, configuración de redes LAN.
jueves, 16 de junio de 2011
ACTIVIDADES DE DESARROLLO DE INGENIERIA DE SOFTWARE
Desde la vista de un enfoque orientado a objetos a continuación se presenta una descripción a manera introductoria de las actividades de desarrollo de ingeniería de software.
OBTENCION DE REQUERIMIENTOS
En esta actividad el cliente y los ingenieros de software (analistas, desarrolladores) se colocan de acuerdo en el alcance y propósito del sistema. Generalmente se expresan las funcionalidades que debe soportar el sistema y de igual manera se deben registrar los requerimientos no funcionales.
Como resultado de esta actividad se debe construir una especificación del sistema a través de un modelo de casos de uso (diagrama de casos de uso + plantilla de especificación de cada caso de uso) complementado con un documento donde se especifiquen los requerimientos no funcionales.
ANALISIS
En esta actividad los ingenieros de software deben generar un modelo que describa el dominio de aplicación (entorno donde operara el sistema) denominado modelo de análisis compuesto por tres modelos individuales: el modelo funcional, el modelo de datos y el modelo dinámico. El modelo funcional se representa por medio de diagramas de casos de uso, el modelo de datos se representa a través de un diagrama de clases y el modelo dinámico se representa por medio de diagramas de secuencia.
DISEÑO DE SISTEMA
En esta actividad los ingenieros definen los objetivos de diseño del sistema a partir de los requerimientos no funcionales especificados en la etapa de obtención de requerimientos y de igual manera descomponen el sistema en subsistemas mas pequeños que puedan ser desarrollados por equipos individuales con el fin de reducir la complejidad del sistema. De igual forma, los ingenieros determinan estrategias generales para la construcción del sistema. Adicionalmente en esta etapa se debe tomar la decisión acerca de la plataforma de hardware y software sobre la que se construirá el sistema.
DISEÑO DE OBJETOS
En esta actividad se deben incluir las siguientes tareas:
Especificación de servicios: Se debe especificar cada uno de los métodos o funcionalidades de la interfaz de clase.
Selección de componentes: se deben identificar los componentes hechos que puedan soportar algún subsistema y objetos de solución adicionales para la integración del sistema.
Reestructuración y optimización del modelo de objetos (datos): Se debe transformar el modelo de objetos para mejorar aspectos como comprensibilidad, extensibilidad y criterios de diseño.
IMPLEMENTACION
En esta actividad los ingenieros traducen los modelos diseñados en las etapas anteriores a código fuente, en mayor grado se debe trabajar con el modelo de objetos con la implementación de atributos y métodos de cada objeto individual y luego con la integración de cada uno de ellos para que funcionen como un solo sistema que responda a los requerimientos del cliente.
MODELAMIENTO CON UML
El UML (lenguaje de modelado unificado [OMG 1998] ha sido aceptado como notación estándar en los diferentes sectores de la industria y adicionalmente proporciona un conjunto de elementos que permiten representar diferentes aspectos de un sistema a través de diagramas en forma precisa y resumida.
En este segmento del documento se describen tres notaciones del UML que se necesitan para modelar un sistema como son los diagramas de casos de uso, los diagramas de clase y los diagramas de secuencia.
DIAGRAMAS DE CASOS DE USO
Es una imagen que representa la funcionalidad del sistema desde el punto de vista del usuario y de igual manera permite determinar las fronteras del sistema.
En forma general, un diagrama de caso de uso está conformado por actores, casos de uso, relaciones de comunicación y un contenedor que permite identificar la frontera del sistema.
Los actores son entidades externas que interactúan con el sistema, en forma específica pueden ser personas (roles) u otro sistema con el cual debe interactuar el sistema propuesto.
Los actores se representan en el diagrama a través de un ícono que algunos autores denominan la figura de palillos y en la parte inferior se debe acompañar del identificador del actor.
Los casos de uso describen comportamientos, capacidades o funcionalidades de un sistema tal como es visto por el cliente y los desarrolladores (basados en acuerdos). También se le denomina comportamiento externo.
Un caso de uso describe una funcionalidad proporcionada por el sistema y se operacionaliza a través de un conjunto de eventos que producen un resultado. Los casos de uso por lo general son iniciados por los actores y posteriormente el caso de uso puede iniciar otros casos de uso.
En el diagrama los casos de uso se representan por óvalos en cuyo interior se debe escribir en texto el identificador del caso de uso el cual por lo general se escribe iniciando con un verbo ya que el caso de uso está expresando una funcionalidad.
Cada caso de uso se debe describir con una plantilla de texto que varía de acuerdo a los requerimientos de documentación de los clientes y a las políticas de documentación de las empresas desarrolladoras de software, pero en forma general se puede coincidir que las plantillas deben contener por lo menos los siguientes campos:
• Nombre: Debe ser único y debe ser expresado en términos de verbos.
• Actores participantes: Son los actores que interactúan con el caso de uso en descripción.
• Condiciones iníciales: Expresan las condiciones que deben cumplirse antes de dar inicio al caso de uso.
• Flujo de eventos: Describe la secuencia de acciones que se deben llevar a cabo en el flujo básico del caso de uso. Es posible que en la descripción aparezcan flujos excepcionales los cuales se deben describir en un caso de uso por separado.
• Condiciones de salida: Expresan las condiciones que se cumplen una vez terminado el caso de uso.
• Requerimientos especiales: Se refieren a aquellos requerimientos que no están relacionados con la funcionalidad del sistema y que corresponden a políticas de desempeño del sistema.
Los casos de uso se escriben en lenguaje natural, lo cual permite mejorar la comunicación entre clientes e ingenieros de software debido a que muchas veces los clientes no entienden notaciones formales de la ingeniería del software.
En un diagrama se representan intercambios de información entre actores y casos de uso, entre casos de uso con otros casos de uso, las cuales se simbolizan a través de líneas denominadas relaciones o asociaciones.
Existen cuatro tipos de relaciones: comunicación, extensión, inclusión y generalización.
• Relaciones de comunicación: Se representan con una línea continua y por lo general se emplean para indicar acceso a una funcionalidad y cuando existe un intercambio de información entre actores y casos de uso.
• Relaciones de inclusión: Se representan con una flecha de guiones entre dos casos de uso y cuyo inicio se da en el caso de uso que incluye al otro. Este tipo de relaciones se utiliza cuando en un diagrama existe comportamiento común ya definido lo cual se debe separar en un caso de uso adicional para evitar redundancia y este se incluye en otro caso de uso por medio de una relación de este tipo. Se debe acompañar con el estereotipo include.
• Relaciones de extensión: Indica que una instancia del caso de uso extendido puede incluir cuando se cumplan ciertas condiciones el comportamiento especificado por el caso de uso que extiende. Se representa por una flecha de guiones cuyo inicio esta en el caso de uso excepcional. Se debe acompañar con el estereotipo extend.
• Relaciones de generalización: Por lo general se utilizan para indicar herencia y se simbolizan con una línea dirigida con un triangulo hueco. Pueden ocurrir entre dos actores o entre dos casos de uso lo cual indica que el actor o el caso de uso hijo son un caso del actor o uso básico.
Los actores, casos de uso y relaciones se integran al interior de un contenedor que ayuda a identificar la frontera del sistema.
DIAGRAMAS DE CLASE
Otra vista del sistema diferente a la funcional es la del modelo de datos que se puede representar a través de un modelo de clases, también denominado modelo estático porque no describe acción; lo que hace es mostrar objetos o cosas y sus relaciones.
Los diagramas de clases se diseñan para mostrar todas las piezas del sistema solución y deben transmitir un sentido del sistema que se estructurará en reposo.
Las clases son abstracciones que especifican los atributos y métodos de un conjunto de objetos. Los objetos son instancias de las clases y tienen la misma estructura de la clase que actúa como patrón.
Las clases y objetos se simbolizan a través de cuadros con tres secciones horizontales, en la sección superior se especifica el nombre de la clase u objeto (los nombres de objetos deben ir subrayados), en la sección central especifican los atributos con su respectivo tipo y en la sección inferior muestra los métodos.
Las asociaciones son relaciones entre clases y representan grupos de vínculos (conexión entre dos objetos).
Para la construcción de los diagramas de clase se aplica la fundamentación teórica de la asignatura bases de datos.
DIAGRAMAS DE SECUENCIA
Describen patrones de comunicación entre objetos interactuantes. Un objeto interactúa con otro enviando mensajes. La recepción de un mensaje por parte de un objeto activa la ejecución de una operación, la cual puede enviar mensajes a otros objetos.
Los objetos se ubican en la parte superior del diagrama en la primera fila y cada columna representa un objeto que participa en la interacción. La columna representa el tiempo de arriba hacia abajo para el mismo objeto. Los mensajes se simbolizan a través de flechas con rótulos los cuales representan los mensajes.
Por lo general, la primera columna corresponde al actor que inicia la interacción entre los objetos.
Las columnas normalmente reciben el nombre de líneas de vida, que por definición es un rectángulo con una recta vertical que desciende de ese rectángulo. La línea de vida representa un ejemplo de una clase, y la línea que desciende en forma vertical es un lugar conveniente para sujetar mensajes entrantes y salientes. Agregar múltiples líneas de vida a un solo diagrama y adicionarle mensajes en forma ordenada en el tiempo permiten mostrar todas las clases y mensajes necesarios para completar un caso de uso.
Una línea de vida de objetos toma forma como un objeto que representa una parte de un papel en un caso de uso.
Desde la vista de un enfoque orientado a objetos a continuación se presenta una descripción a manera introductoria de las actividades de desarrollo de ingeniería de software.
OBTENCION DE REQUERIMIENTOS
En esta actividad el cliente y los ingenieros de software (analistas, desarrolladores) se colocan de acuerdo en el alcance y propósito del sistema. Generalmente se expresan las funcionalidades que debe soportar el sistema y de igual manera se deben registrar los requerimientos no funcionales.
Como resultado de esta actividad se debe construir una especificación del sistema a través de un modelo de casos de uso (diagrama de casos de uso + plantilla de especificación de cada caso de uso) complementado con un documento donde se especifiquen los requerimientos no funcionales.
ANALISIS
En esta actividad los ingenieros de software deben generar un modelo que describa el dominio de aplicación (entorno donde operara el sistema) denominado modelo de análisis compuesto por tres modelos individuales: el modelo funcional, el modelo de datos y el modelo dinámico. El modelo funcional se representa por medio de diagramas de casos de uso, el modelo de datos se representa a través de un diagrama de clases y el modelo dinámico se representa por medio de diagramas de secuencia.
DISEÑO DE SISTEMA
En esta actividad los ingenieros definen los objetivos de diseño del sistema a partir de los requerimientos no funcionales especificados en la etapa de obtención de requerimientos y de igual manera descomponen el sistema en subsistemas mas pequeños que puedan ser desarrollados por equipos individuales con el fin de reducir la complejidad del sistema. De igual forma, los ingenieros determinan estrategias generales para la construcción del sistema. Adicionalmente en esta etapa se debe tomar la decisión acerca de la plataforma de hardware y software sobre la que se construirá el sistema.
DISEÑO DE OBJETOS
En esta actividad se deben incluir las siguientes tareas:
Especificación de servicios: Se debe especificar cada uno de los métodos o funcionalidades de la interfaz de clase.
Selección de componentes: se deben identificar los componentes hechos que puedan soportar algún subsistema y objetos de solución adicionales para la integración del sistema.
Reestructuración y optimización del modelo de objetos (datos): Se debe transformar el modelo de objetos para mejorar aspectos como comprensibilidad, extensibilidad y criterios de diseño.
IMPLEMENTACION
En esta actividad los ingenieros traducen los modelos diseñados en las etapas anteriores a código fuente, en mayor grado se debe trabajar con el modelo de objetos con la implementación de atributos y métodos de cada objeto individual y luego con la integración de cada uno de ellos para que funcionen como un solo sistema que responda a los requerimientos del cliente.
MODELAMIENTO CON UML
El UML (lenguaje de modelado unificado [OMG 1998] ha sido aceptado como notación estándar en los diferentes sectores de la industria y adicionalmente proporciona un conjunto de elementos que permiten representar diferentes aspectos de un sistema a través de diagramas en forma precisa y resumida.
En este segmento del documento se describen tres notaciones del UML que se necesitan para modelar un sistema como son los diagramas de casos de uso, los diagramas de clase y los diagramas de secuencia.
DIAGRAMAS DE CASOS DE USO
Es una imagen que representa la funcionalidad del sistema desde el punto de vista del usuario y de igual manera permite determinar las fronteras del sistema.
En forma general, un diagrama de caso de uso está conformado por actores, casos de uso, relaciones de comunicación y un contenedor que permite identificar la frontera del sistema.
Los actores son entidades externas que interactúan con el sistema, en forma específica pueden ser personas (roles) u otro sistema con el cual debe interactuar el sistema propuesto.
Los actores se representan en el diagrama a través de un ícono que algunos autores denominan la figura de palillos y en la parte inferior se debe acompañar del identificador del actor.
Los casos de uso describen comportamientos, capacidades o funcionalidades de un sistema tal como es visto por el cliente y los desarrolladores (basados en acuerdos). También se le denomina comportamiento externo.
Un caso de uso describe una funcionalidad proporcionada por el sistema y se operacionaliza a través de un conjunto de eventos que producen un resultado. Los casos de uso por lo general son iniciados por los actores y posteriormente el caso de uso puede iniciar otros casos de uso.
En el diagrama los casos de uso se representan por óvalos en cuyo interior se debe escribir en texto el identificador del caso de uso el cual por lo general se escribe iniciando con un verbo ya que el caso de uso está expresando una funcionalidad.
Cada caso de uso se debe describir con una plantilla de texto que varía de acuerdo a los requerimientos de documentación de los clientes y a las políticas de documentación de las empresas desarrolladoras de software, pero en forma general se puede coincidir que las plantillas deben contener por lo menos los siguientes campos:
• Nombre: Debe ser único y debe ser expresado en términos de verbos.
• Actores participantes: Son los actores que interactúan con el caso de uso en descripción.
• Condiciones iníciales: Expresan las condiciones que deben cumplirse antes de dar inicio al caso de uso.
• Flujo de eventos: Describe la secuencia de acciones que se deben llevar a cabo en el flujo básico del caso de uso. Es posible que en la descripción aparezcan flujos excepcionales los cuales se deben describir en un caso de uso por separado.
• Condiciones de salida: Expresan las condiciones que se cumplen una vez terminado el caso de uso.
• Requerimientos especiales: Se refieren a aquellos requerimientos que no están relacionados con la funcionalidad del sistema y que corresponden a políticas de desempeño del sistema.
Los casos de uso se escriben en lenguaje natural, lo cual permite mejorar la comunicación entre clientes e ingenieros de software debido a que muchas veces los clientes no entienden notaciones formales de la ingeniería del software.
En un diagrama se representan intercambios de información entre actores y casos de uso, entre casos de uso con otros casos de uso, las cuales se simbolizan a través de líneas denominadas relaciones o asociaciones.
Existen cuatro tipos de relaciones: comunicación, extensión, inclusión y generalización.
• Relaciones de comunicación: Se representan con una línea continua y por lo general se emplean para indicar acceso a una funcionalidad y cuando existe un intercambio de información entre actores y casos de uso.
• Relaciones de inclusión: Se representan con una flecha de guiones entre dos casos de uso y cuyo inicio se da en el caso de uso que incluye al otro. Este tipo de relaciones se utiliza cuando en un diagrama existe comportamiento común ya definido lo cual se debe separar en un caso de uso adicional para evitar redundancia y este se incluye en otro caso de uso por medio de una relación de este tipo. Se debe acompañar con el estereotipo include.
• Relaciones de extensión: Indica que una instancia del caso de uso extendido puede incluir cuando se cumplan ciertas condiciones el comportamiento especificado por el caso de uso que extiende. Se representa por una flecha de guiones cuyo inicio esta en el caso de uso excepcional. Se debe acompañar con el estereotipo extend.
• Relaciones de generalización: Por lo general se utilizan para indicar herencia y se simbolizan con una línea dirigida con un triangulo hueco. Pueden ocurrir entre dos actores o entre dos casos de uso lo cual indica que el actor o el caso de uso hijo son un caso del actor o uso básico.
Los actores, casos de uso y relaciones se integran al interior de un contenedor que ayuda a identificar la frontera del sistema.
DIAGRAMAS DE CLASE
Otra vista del sistema diferente a la funcional es la del modelo de datos que se puede representar a través de un modelo de clases, también denominado modelo estático porque no describe acción; lo que hace es mostrar objetos o cosas y sus relaciones.
Los diagramas de clases se diseñan para mostrar todas las piezas del sistema solución y deben transmitir un sentido del sistema que se estructurará en reposo.
Las clases son abstracciones que especifican los atributos y métodos de un conjunto de objetos. Los objetos son instancias de las clases y tienen la misma estructura de la clase que actúa como patrón.
Las clases y objetos se simbolizan a través de cuadros con tres secciones horizontales, en la sección superior se especifica el nombre de la clase u objeto (los nombres de objetos deben ir subrayados), en la sección central especifican los atributos con su respectivo tipo y en la sección inferior muestra los métodos.
Las asociaciones son relaciones entre clases y representan grupos de vínculos (conexión entre dos objetos).
Para la construcción de los diagramas de clase se aplica la fundamentación teórica de la asignatura bases de datos.
DIAGRAMAS DE SECUENCIA
Describen patrones de comunicación entre objetos interactuantes. Un objeto interactúa con otro enviando mensajes. La recepción de un mensaje por parte de un objeto activa la ejecución de una operación, la cual puede enviar mensajes a otros objetos.
Los objetos se ubican en la parte superior del diagrama en la primera fila y cada columna representa un objeto que participa en la interacción. La columna representa el tiempo de arriba hacia abajo para el mismo objeto. Los mensajes se simbolizan a través de flechas con rótulos los cuales representan los mensajes.
Por lo general, la primera columna corresponde al actor que inicia la interacción entre los objetos.
Las columnas normalmente reciben el nombre de líneas de vida, que por definición es un rectángulo con una recta vertical que desciende de ese rectángulo. La línea de vida representa un ejemplo de una clase, y la línea que desciende en forma vertical es un lugar conveniente para sujetar mensajes entrantes y salientes. Agregar múltiples líneas de vida a un solo diagrama y adicionarle mensajes en forma ordenada en el tiempo permiten mostrar todas las clases y mensajes necesarios para completar un caso de uso.
Una línea de vida de objetos toma forma como un objeto que representa una parte de un papel en un caso de uso.
sábado, 11 de junio de 2011
Suscribirse a:
Comentarios (Atom)