Guía de estudio segundo parcial

¿Qué artefactos se pueden iniciar en la fase de elaboración?


Modelo del dominio: Visualización de los conceptos del dominio;
similar al modelo de información estática de las entidades del
dominio.
Modelo de diseño: Conjunto de diagramas que describen el diseño
lógico: diagramas de clase, de interacción de objetos, paquetes, etc.
Documento de la Arquitectura Software: Un documento que resume
los aspectos arquitectónicos y su resolución en el diseño. Un sumario
de las ideas de diseño más importantes y su motivación.
Modelo de Datos: Esquemas de la base de datos y sus estrategias de
mapeo entre representaciones objetuales y no objetuales (Ej. mapeo
O/R)
UC Storyboards, UI Prototypes: Una descripción de la UI, rutas de
navegación, modelos de usabilidad, etc.

Modelo Dominio
Un Modelo de Dominio ilustra los conceptos importantes en el
dominio del problema. Es una representación de cosas del mundo
real, no componentes software.Es un conjunto de Diagramas
estructurales desde la perspectiva conceptual.
¿Cómo crear un modelo de dominio?
1. Encuentra las clases conceptuales.
2. Dibújelas como clases de un Diagrama de clases UML.
3. Agrega asociaciones y atributos.

Estrategias para Identificar Clases Conceptuales
 Reutiliza o modifica modelos existentes. Es la estrategia primera, más
fácil y mejor.
 Use una Lista de categorias conceptuales.
 Use Identificación de frases sustantivas.

Asociación
Una asociación es una relación entre conceptos que indica alguna conexión
de interés entre los mismos.
Criterios para seleccionar Asociaciones útiles

CP.  Asociaciones derivadas de la Lista de Asociaciones Comúnes.  Sintaxis completa de un atributo en UML:  visibility string } name:type multiplicity=default{  Los atributos deberían ser.  Evita asociaciones redundantes y derivadas. número de teléfono. Number. arribaabajo Atributos Un atributo es un valor de datos lógico de un objeto. Multiplicidad  La Multiplicidad define cuantas instancias de un tipo A pueden ser asociadas con una instancia de tipo B en un momento particular en el tiempo. Los roles pueden tener los siguientes adornos:  Nombre.  Multiplicidad. UPC. Roles  El extremo final de una asociación es llamado Rol.  Navegabilidad. String  Simple: color. Incluye aquéllos para los cuales los requisitos actuales sugieren o implican la necesidad de recordar información.  Nombre las asociaciones VerbPhrase-TypeName basado en la sintaxis: TypeName-  La dirección de lectura por default es izquierda. property- . preferiblemente:  Datos primitivos: Boolean. Date.derecha. Incluya las asociaciones siguientes en el Modelo del Dominio:  Asociaciones para las cuales el “conocimiento de la relación” se requiere preservar durante algún tiempo (Asociaciones “need-to-remember”).

su orden. Se pueden definir contratos para las operaciones del Sistema (su interface pública). Línea guía: dibuja un SSD para el happy path del CU y/o para los escenarios alternativos frecuentes o importantes.Diagrama de Secuencia del Sistema (SSD) Un Diagrama de Secuencia es un dibujo que muestra. una vez que es ejecutada una operación del sistema. La Arquitectura Lógica se recomienda esté basada en algún arquitectónico:  Capas  Repositorio estilo . Los contratos describen el comportamiento detallado del sistema en términos de cambios de estado de los objetos del Modelo del Dominio. El Sistema puede representarse mediante una clase conceptual con sus operaciones. y posibles eventos inter-sistemas. subsistemas y capas. que representan su interface pública. Arquitectura lógica La Arquitectura lógica es la organización a gran-escala de las clases software en paquetes (o namespaces). los eventos que actores externos generan. para un escenario particuar de un CU. Contratos Los Contratos son documentos que describen el comportamiento del sistema.

Un paquete UML ofrece una forma de agrupar elementos (puede agrupar lo que sea: clases. UC. etc. subsistemas. Las capas suelen ser organizadas en capas de “alto” nivel (capa UI) que llaman a los servicios de capas de “bajo” nivel (normalmente no a la inversa). etc. Las capas típicas en un sistema OO incluyen:    User Interface. Application Logic and Domain Objects: objetos software que representan objetos del dominio (tal como el objeto Sale) que satisfacen los requisitos de la aplicación (tal como calcular el total de una venta). Las asociaciones de dependencia UML se utiliza para ello. paquetes. etc. En una Arquitectura estricta de capas. Aplicando UML:Diagramas de Paquetes Los Diagramas de Paquetes suelen utilizarse para ilustrar la Arquitectura Lógica de un sistema (capas. paquetes o subsistemas que tienen un conjunto cohesivo de responsabilidades con relación a un aspecto del sistema. Technical Services: objetos de propósito general y subsistemas que proveen servicios de soporte técnico (tal como la interfaz a una base de datos).). no en sistemas de información). ¿Qué es una capa? Una capa (layer) es un agrupamiento de grano-grueso de clases. Una capa puede modelarse como un paquete UML. Estos servicios suelen ser independientes de la aplicación y reutilizables a través de varios sistemas. una capa solamente llama a servicios de la capa directa inferior (suele tenerse en protocolos de red. paquetes. . En una Arquitectura relajada de capas.) Es común mostrar dependencias o acoplamientos entre paquetes de tal forma que los desarrolladores pueden ver el acoplamiento a gran escala del sistema. Cliente-Servidor  Pipe & Filter. las capas de alto nivel llaman a varias capas de nivel inferior (más común en sistemas de información).

¿Cuál es la conexión entre SSD. recibir eventos UI y delegar solicitudes para lógica de aplicación a objetos no-UI (como los objetos de dominio). El nombre cualificado del elemento contenido incluye sus paquetes. capas. FechaCompromiso. Las capas de una arquitectura se representan mediante divisiones verticales. Tipo. Operaciones de Sistema y Capas? Los eventos de sistema se corresponden con operaciones de sistema. Plaza y Ciudad . Definición: Tiers. FechaInicio.Un paquete UML representa un namespace. particiones La noción original de tier en arquitectura fue capa lógica. Los SSDs ilustran las operaciones de sistema. No pongas lógica de aplicación en los métodos de los objetos UI. 2. Los objetos UI entonces delegan la solicitud de la capa UI a la capa de dominio para su manejo. mientras que las particiones representan una división horizontal de subsistemas de una capa. IDproyecto. Ej. No conectes o acoples objetos no-UI directamente a objetos UI.Client tier (la computadora cliente). Los objetos UI deberían solamente inicializar elementos UI. normalmente existirán objetos en la capa UI que capturan estas solicitudes de operaciones de sistema.. Principio de Separación Model-View: 1. pero ocultan los objetos UI específicos. pero ahora se utiliza más para referirse a un nodo de procesamiento físico (o un cluster de nodos). Nombre. Sin embargo.

Sign up to vote on this title
UsefulNot useful