Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Prepara tus exámenes
Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Prepara tus exámenes con los documentos que comparten otros estudiantes como tú en Docsity
Encuentra los documentos específicos para los exámenes de tu universidad
Estudia con lecciones y exámenes resueltos basados en los programas académicos de las mejores universidades
Responde a preguntas de exámenes reales y pon a prueba tu preparación
Consigue puntos base para descargar
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Comunidad
Pide ayuda a la comunidad y resuelve tus dudas de estudio
Ebooks gratuitos
Descarga nuestras guías gratuitas sobre técnicas de estudio, métodos para controlar la ansiedad y consejos para la tesis preparadas por los tutores de Docsity
Asignatura: Metodologia del software, Profesor: Tona Mozota, Carrera: Enginyeria tècnica en informàtica de sistemes, Universidad: URL
Tipo: Apuntes
1 / 25
Esta página no es visible en la vista previa
¡No te pierdas las partes importantes!
Capítulo: 2 Análisis Orientado a Objetos
El contenido de este documento es sólo una tabla de contenidos con la relación de imágenes y direcciones de internet vistas o recomendadas en el curso. Se recomienda estudiar los temas directamente de las fuentes citadas en la bibliografía.
Capítulo: 2 Análisis Orientado a Objetos
El desarrollador (analista) debe transformar los requerimientos (requisitos) del cliente en una descripción completa , no ambigua y en una notación que el cliente pueda entender y ratificar (validar).
Algunos autores definen requisitos como:
-Los requerimientos para un sistema son la descripción de los servicios proporcionados por el sistema y sus restricciones operativas.
-Un requerimiento puede ser una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste.
-Un requerimiento es una definición detallada y formal de una función del sistema.
El standard Standard Glossary of Software Engineering Terminology IEEE 610.12-1990 define:
Def. de “Requerimiento”:
Un requerimiento es una representación documentada de una condición o de una capacidad que necesita un cliente o usuario para solucionar un problema o alcanzar un objetivo.
Un requerimiento es una representación documentada de una condición o de una capacidad que debe poseer un producto o componente para resolver o satisfacer un contrato, un estándar, una especificación, o un documento impositivo.
Def. de “Requerimientos del producto”:
Traducción de las necesidades del cliente en términos de los desarrolladores del producto, lo que permite hacer explícitos los requerimientos. El desarrollador utiliza los requerimientos para diseñar y construir el producto.
Capítulo: 2 Análisis Orientado a Objetos
2.2.2.1 Clasificación tradicional
[Sommerville 7ªed.]
Esta clasificación de requerimientos funcionales y no funcionales es la más extendida y tradicional. Hay diferentes niveles de descripción: Requerimientos del usuario (nivel de abstracción alto) Requerimientos del sistema (detalles)
Ejemplo:
Fuente: [Sommerville7ªEd]
Requerimientos funcionales
Capítulo: 2 Análisis Orientado a Objetos
Ejemplo:
Fuente: [Sommerville7ªEd]
2.2.2.2 Clasificación usada en RUP
[Larman]
En el RUP los requisitos se clasifican de acuerdo con el modelo FURPS+ definidos por [Grady 92]:
de previsión
uso de los recursos,…
configurabilidad,…
A estos últimos 4 tipos de requisitos se le llama las –ilities de un sistema o requisitos de calidad.
Implementación: limitación de recursos, lenguajes y herramientas, hardware,… Interfaz: restricciones impuestas para la interacción con sistemas externos Operaciones: gestión del sistema en su puesta en marcha Empaquetamiento Legales: licencias,…
¿Cómo se recolectan los requisitos?.
En algunos casos (en pocos casos) la lista de requerimientos pueden estar dadas por el cliente como podría ser el ejemplo de alguna licitación pública.
Capítulo: 2 Análisis Orientado a Objetos
En la mayoría de los casos tendremos que entrevistarnos con el cliente para obtenerlos.
Entrevista
Lectura obligatoria:
Consultar en la web de la asignatura
2.2.4.1 Specification Requirements Software (SRS)
(Especificación de Requerimientos Software (ERS))
El documento
Es un estándar IEEE 830-1998.
Dirección web donde descargarse el documento si os conectáis desde La Salle:
http://ieeexplore.ieee.org/xpl/tocresult.jsp?isNumber=
Consultar el documento 02-SRSStandardIEEE830.pdf en la web de la asignatura
Ejemplos de especificaciones escritas en SRS
Ejemplo 1: Sistema bibliográfico http://es.tldp.org/I+D/donantonio/doc-ers_ieee830-donantonio-servidor/donantonio-servidor- html/index.html Comentarios: es corto y poco específico
Ejemplo 2: Gestión de PC’s http://64.233.183.104/search?q=cache:hTavNQP7l1kJ:kybele.escet.urjc.es/documentos/ISI/Ejemplo_ ERS.PDF+ERS+documento&hl=es&ct=clnk&cd=4&gl=es Comentarios: está muy bien
Actividad: Especificación de requisitos en ERS Consultar actividad en la web de la asignatura el documento Actividad_ERS.pdf
2.2.4.2 Artefactos del proceso de recogida y especificación de requisitos según RUP
[Larman]
En RUP la especificación de requisitos queda reflejada en los siguientes artefactos:
Capítulo: 2 Análisis Orientado a Objetos
Consultar en la web de la asignatura
3. Documento especificación complementaria (Supplementary Specification SS)
Contiene los otros requisitos +
Consultar en la web de la asignatura
4. Documento Glosario
Agrupa y define los términos que se utilizan en los requisitos.
Contiene el diccionario de datos que reúne los requisitos relacionados con los datos, como reglas de validación, valores aceptados,….
Consultar en la web de la asignatura
Larman dice: Los artefactos en RUP son opcionales. El equipo de desarrollo debe seleccionar el subconjunto de artefactos que sirvan para su problema. En general, centrarse en un pequeño conjunto de artefactos que demuestren tener un gran valor práctico.
Actividad: Especificación de requisitos en VISION Consultar el documento Actividad_VISION.pdf en la web de la asignatura
Capítulo: 2 Análisis Orientado a Objetos
Ver apartado 5.1 del capítulo 5
Ver apartado 5.2 del capítulo 5
Ver apartado 5.3 del capítulo 5
Puede haber dos niveles de requerimientos: los orientados tanto a cliente como a desarrolladores, típicamente contractual la documentación más técnica, típicamente orientada a desarrolladores
Mantener dos documentos de requerimientos puede complicar su mantenimiento. En todo caso, si se mantienen estos dos niveles es importante dar unos consejos prácticos aplicables a ambos ámbitos:
Sobre el modelo del negocio Identificar los actores Escribir un glosario del proyecto Identificar y describir los casos de uso del negocio Ilustrar los casos de uso con: Diagramas de casos de uso Diagramas de comunicación (opcional, los veremos en el análisis dinámico) Diagramas de actividad (opcional)
.... hemos realizado así un Modelo del Negocio
Desde la perspectiva del desarrollador Descubrir la especialización de actores (generalizaciones) Descubrir las relaciones en los casos de uso ( includes , extends ) Descripción textual de los casos de uso ( precondiciones , postcondiciones , herencia , ... ) Requerimientos suplementarios Boceto de la interfaz de usuario Priorización de los casos de uso
.... hemos realizado así un Modelo de los Requerimientos del Sistema
[Sommerville 7ºEd.] pag 144-
La validación de requerimientos trata de mostrar que éstos realmente definen el sistema que el cliente desea.
1) Verificaciones a realizar
Capítulo: 2 Análisis Orientado a Objetos
se trata de generar casos de prueba para los requerimientos (antes de su implementación) si una prueba es difícil o imposible de diseñar, normalmente significa que el requerimiento en cuestión será difícil de implementar y se debería cuestionar.
Es difícil y prácticamente imposible asegurar que un conjunto de requerimientos cumple las necesidades del usuario.
Es inevitable que haya cambios adicionales de requerimientos para corregir omisiones y malas interpretaciones después de que el documento de requerimientos haya sido aprobado.
En RUP es más fácil hacer frente a estos cambios por su característica incremental.
Capítulo: 2 Análisis Orientado a Objetos
Es necesario para poder entender el análisis y diseño OO que tengáis claros los conceptos de clase, objeto, herencia, acoplamiento, cohesión, polimorfismo, encapsulamiento, etc. Para ello se recomienda la lectura de los siguientes apartados:
[ODocherty] Capítulo 2
Objeto. Atributos. Operaciones (2.2) Encapsulación (2.5) Asociación y Agregación (2.6)
Clases (2.14). Herencia. Generalización y Especialización. Polimorfismo
[ODocherty] Capítulo 7
Analysis is about discovering what the system is going to handle, rather than deciding how to do the handling.
We need to decompose a complex set of requirements into the essential elements and relationships on which we will base our solution.
Analysis is our first opportunity to get to grips with modeling the real world as objects.
An analysis model has both static (relación entre objetos) and dynamic (comportamiento de los objetos) parts :
- We can depict the static analysis model using a class diagram .A class diagram shows the objects that the system will handle and how those objects are related to each other.
Once we ’ve completed static analysis ,our sponsors will be able to confirm that our understanding of the business objects is correct,before we let the objects influence our design.
The static analysis model is also valuable when it comes to designing a database schema (for those business objects that need to be stored).
- For the dynamic analysis model ,we can use communication diagrams to demonstrate that our static model is feasible.
After dynamic analysis ,we will be confident that our analysis objects support the required system functionality.
There are two inputs to analysis: (Los comentados anteriormente en 2.2.7 )
Capítulo: 2 Análisis Orientado a Objetos
2.3.2.1 Identificar clases
[Odocherty] 7.4.1 Finding Classes pag. 170 [Sommerville 7ªEd.] 14.2.3 pag. 297 [Larman] pag 127
Identificación
La identificación de clases es una tarea difícil.
Sommerville 14.2.3 pag. 297 dice que hay varios enfoques que pueden seguirse para la identificación de objetos, atributos y operaciones. A saber:
Los sustantivos y locuciones representan objetos y atributos Los verbos representarán operaciones o servicios (por el momento esto no nos interesa)
Ejemplos de objetos del dominio: factura, libro,
Ejemplos de roles: cliente, socio biblioteca, estudiante,
Aquí se trata de analizar los casos de uso
Capítulo: 2 Análisis Orientado a Objetos
Larman propone tener una lista de categorías de clases conceptuales e identifica con la ayuda de esta tabla a los objetos.
Conceptual Class Category Examples physical or tangible objects Register Airplane specifications, designs, or descriptions of things
ProductSpecification FlightDescription places Store, Airport transactions Sale, Payment Reservation transaction line items SalesLineItem roles of people Cashier Pilot containers of other things Store, BinAirplane things in a container Item, Passenger other computer or electro- mechanical systems external to the system
CreditPaymentAuthorizationSystem, AirTrafficControl
abstract noun concepts Hunger, Acrophobia organizations SalesDepartment, ObjectAirline events Sale, Payment, Meeting Flight, Crash, Landing processes (often not represented as a concept, but may be)
SellingAProduct BookingASeat
rules and policies RefundPolicy CancellationPolic Catalogs ProductCatalog PartsCatalog records of finance, work, contracts, legal matters
Receipt, Ledger, EmploymentContract MaintenanceLog financial instruments and services
LineOfCredit Stock manuals, documents, reference papers, books
DailyPriceChangeList RepairManual
Table 10.1 Conceptual Class Category List.
No olvidar que un objeto es algo que tiene estado (atributos), comportamiento(métodos) e identidad(identificación única).
2.3.2.2 Identificar relaciones entre clases
[Odocherty] 7.4.2 Identifying Class Relationships pag. 171 [Larman] [Sommerville 7ªEd.]
Relaciones entre clases
Capítulo: 2 Análisis Orientado a Objetos
Ejemplos: Una FACTURA está formada por LINEAFACTURA (cuando desaparece la factura desaparecen las líneas de la factura
Herencia (también llamada generalización) Una subclase hereda todos los atributos y comportamiento de su superclase Describe una relación “estática” (compile-time) entre clases.
Ejemplos: MIEMBROPERSONAL puede ser una clase que generaliza a las clases PERSONALADMINISTRATIVO, PERSONALCREATIVO y DIRECTORCONTABILIDAD. ANUNCIO puede ser una clase que generaliza a las clases ANUNCIOPRENSAy ANUNCIOTELEVISION
En una primera aproximación al determinar las asociaciones se podría hacer sin especificar de qué tipo son las asociaciones y después en un refinamiento se podrían determina qué asociaciones son de agregaciones y cuales composiciones.
Cómo identificar relaciones [Larman] p
Larman utiliza la siguiente lista de las asociaciones más comunes:
Capítulo: 2 Análisis Orientado a Objetos
2.3.2.3 Identificar atributos de las clases
[Odorchety] 7.4.5 Attributes 178 [Larman] p
Un atributo es una propiedad de un objeto, por ejemplo su tamaño, posición, nombre, precio, … Los atributos son parte de la descripción esencial de una clase.
Identificación
Aquellas cosas para la que los requisitos (casos de uso) sugieren o implican una necesidad de registrar la información.
Tipos [ Odocherty] pag 179
