Please enable JavaScript.
Coggle requires JavaScript to display documents.
FUNDAMENTOS DE INGENIERÍA DE SOFTWARE. - Coggle Diagram
FUNDAMENTOS DE INGENIERÍA DE SOFTWARE.
4.4 MODELO CASOS DE USO.
Un caso de uso se define como un conjunto de acciones realizadas por e lsistema que dan lugar a un resultado observable
El caso de uso especifica un comportamiento que el sujeto puede realizar en colaboración con uno o más actores, pero sin hacer referencia a su estructura interna.
El caso de uso puede contener posibles variaciones de su comportamiento básico incluyendo manejo de errores y excepciones
Una instanciación de un caso de uso es un escenario que representa un uso particular del sistema (un camino)
Características de los casos de uso:
Los casos de uso proporcionan valores a los actores
• La funcionalidad de un caso de uso debe ser completa
Un caso de uso se inicia por un actor
Notación:
• Elipse con el nombre del caso de uso dentro o debajo de ella. Se puede colocar algún estereotipo encima del nombre y una lista de propiedades debajo.
La representación alternativa es la del símbolo del clasificador con
una elipse pequeña en la esquina superior derecha
Los casos de uso pueden tener asociaciones y dependencias con otros clasificadores.
Relación entre actores y casos de uso:
• Asociación
Generalización: Un caso de uso también se puede especializar en uno o más casos de uso hijos.
• Inclusión: Un caso de uso puede incorporar el comportamiento de otros casos de uso como fragmentos de su propio comportamiento.
• Extensión: Un caso de uso también se puede definir como una
extensión incremental de un caso de uso base
• Realización
4.1 CLASES.
Una clase por lo general representa un sustantivo, como una persona, lugar o (posiblemente bastante abstracta) cosa - es el modelo de un concepto dentro de un programa de computadora.
Una clase es una construcción que se utiliza como un modelo (o plantilla) para crear objetos de ese tipo. El modelo describe el estado y el comportamiento que todos los objetos de la clase que las comparten.
*Subclase es una instancia de una clase.
*Una Superclase es una colección de clases.
MÉTODOS EN LAS CLASES
· Los métodos son el equivalente a las funciones en programación estructurada. Se diferencian de ellos en que es posible acceder a las variables de la clase de forma implícita.
· Cuando se desea realizar una acción sobre un objeto, se dice que se le manda un mensaje invocando a un método que realizará la acción.
IDENTIFICACIÓN DE CLASES
La identificación de clases del dominio del problema se obtiene principalmente de algún documento textual que describa el sistema.
Aunque pudiéramos tomar como punto de partida los documentos desarrollados para el modelo de casos de uso, a menudo la descripción original del problema es suficiente.
Se comienza este proceso mediante la identificación de las clases candidatas, explícitas o implícitas, a las que se refiera la descripción del problema
4.2 OBJETOS.
Nuestra biblioteca de figuras UML puede ayudarte a diseñar cualquier diagrama de objetos personalizado por medio de nuestra herramienta UML en línea.
Ejemplo del diagrama de objetos.
Aplicaciones de los diagramas de objetos
Hay muchos casos en los que a un desarrollador le resultarían útiles los diagramas de objetos. Dichos casos incluyen: :check:
Revisión de una iteración específica de un sistema general. :check:
¿Qué es un diagrama de objetos en UML? Un diagrama de objetos UML representa una instancia específica de un diagrama de clases en un determinado momento en el tiempo.
Obtención de una vista de nivel alto del sistema que desarrollarás. :check:
Prueba de un diagrama de clases que creaste para la estructura general del sistema, por medio de diagramas de objetos para casos de uso específicos.
:check:
Elementos de los diagramas de objetos, Los diagramas de objetos son sencillos de crear: se componen de objetos, representados por rectángulos, conectados mediante líneas. Estos son los elementos principales de un diagrama de objetos: :check:
Objetos - son instancias de una clase. Si un coche es una clase, un Altima 2007 de Nissan es un objeto de una clase. Los objetos en la clase "Padres" son tus padres específicos, por ejemplo, Elaine y Gary.
Atributos de clases - un rectángulo con dos pestañas que indica un elemento de software.
Títulos de clases - los atributos específicos de la clase. En el diagrama de objetos de árbol genealógico, se trata del nombre, género y edad de los integrantes de la familia. Se pueden enumerar como elementos en el objeto o incluso en las propiedades del propio objeto (p. ej., color).
Enlaces - se trata de las líneas que conectan un objeto con otro. El diagrama de objetos corporativo siguiente muestra cómo los departamentos están conectados en un estilo de organigrama tradicional.
Diagrama de objetos en Objective C
Objective C se ha vuelto muy popular desde el lanzamiento de "Objective C 2.0" de Apple, y ahora es el lenguaje de programación preferido para las aplicaciones de la tienda virtual de Apple.
Diagrama de objetos en Java
Este término requiere un poco de desambiguación. Hay diagramas de objetos que se pueden usar en UML para describir instancias que se pueden programar en Java en última instancia.
También existen diagramas que describen objetos Java que no tienen nada que ver con UML.
4.5 MODELO DE DOMINIO
IDENTIFICACION DE CLASES CONCEPTUALES.
Se van añadiendo clases al modelo del dominio a medida que se revisan los escenarios identificados en los casos de uso
Es mejor especificar en exceso un modelo de dominio con muchas clases conceptuales de grano fino que especificar por defecto (Larman, 2002)
Objetivo crear un modelo de dominio de clases conceptuales significativas del dominio de interés
• El modelo no es mejor por tener pocas clases conceptuales
• Es normal obviar clases conceptuales durante la identificación inicial para descubrirlas más tarde (incluso en diseño) al considerar atributos y asociaciones
No se deben excluir clases conceptuales porque los requisitos no indican necesidad obvia de registrar información sobre ella o porque la clase conceptual no tenga atributos.
IDENTIFICACION DE ATRIBUTOS
• Habitualmente hay operaciones asociadas con él, como análisis sintáctico o validación
• Es una abstracción de uno o más tipos con alguna de estas cualidades
• Está compuesta de secciones separadas
Los modelos de dominio puede utilizarse para capturar y expresar el entendimiento ganado en un área bajo análisis como paso previo al diseño de un sistema, ya sea de software o de otro tipo.
En caso de duda es mejor definir algo como una clase conceptual en lugar de como un atributo
El modelo de dominio puede ser tomado como el punto de partida para el diseño del sistema. Esto es así ya que cuando se realiza la programación orientada a objetos, se supone que el funcionamiento interno del software va a imitar en alguna medida a la realidad, por lo que el mapa de conceptos del modelo de domino constituye una primera versión del sistema.
GUIAS PARA HACER UN MODELO DE DOMINIO
• Listar las clases conceptuales candidatas relacionadas con los
requisitos actuales en estudio
Representar las clases en un modelo de dominio
Añadir los atributos necesarios para satisfacer los requisitos
de información
Añadir las asociaciones necesarias para registrar las
relaciones que hay que mantener en memoria
Un modelo de dominio es una representación de las clases conceptuales del mundo real, no de componentes software. No se trata de un conjunto de diagramas que describen clases software, u objetos software con responsabilidades
4.3 MODELO DE REQUISITOS.
El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente desea según la percepción del desarrollador.
El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la formación de todos los demás modelos en el desarrollo de software.
El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la formación de todos los demás modelos en el desarrollo de software.
·
Diseño: La funcionalidad de los casos de uso ya estructurada por el análisis es realizada por el modelo de diseño, adaptándose al ambiente de implementación real y refinándose aún más.
·
Implementación: Los casos de uso son implementados mediante el código fuente en el modelo de implementación.
Pruebas: Los casos de uso son probados a través de las pruebas de componentes y pruebas de integración.
Documentación: El modelo de casos de uso debe ser documentado a lo largo de las diversas actividades, dando lugar a distintos documentos como los manuales de usuario, manuales de administración, etc.
Los tres ejes de modelado del modelo de requisitos. El modelo de comportamiento, basado directamente en el modelo de casos de uso, especifica la funcionalidad que ofrece el sistema desde el punto de vista del usuario.
El modelo de presentación o modelo de interfaces o borde especifica cómo interactúa el sistema con actores externos al ejecutar los casos de uso, en particular, en los sistemas de información ricos en interacción con el usuario, especifica cómo se verán visualmente las interfaces gráficas y que funcionalidad ofrecerá cada una de ellas.
El modelo de información o modelo del dominio del problema especifica los aspectos estructurales del sistema.
Análisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de análisis, que es estable con respecto a cambios, siendo un modelo lógico independiente del ambiente de implementación.
