Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 1

Materia: Arquitectura y diseño de Software I.T.S.A .

1.1.- Análisis y diseño orientado a objetos Análisis y diseño orientado a objetos (ADOO) es un enfoque de la ingeniería de software que modela un sistema

como un grupo de objetos que interactúan entre sí. Este enfoque representa un dominio en términos de conceptos

compuestos por verbos y sustantivos, clasificados de acuerdo a su dependencia funcional.

En este método de análisis y diseño se crea un conjunto de modelos utilizando una notación acordada como, por

ejemplo, el lenguaje unificado de modelado (UML). ADOO aplica técnicas de modelado de objetos para analizar los

requerimientos para un contexto - por ejemplo, un sistema de negocio, un conjunto de módulos de software - y para

diseñar una solución para mejorar los procesos involucrados. No está restringido al diseño de programas de

computadora, sino que cubre sistemas enteros de distinto tipo. Las metodologías de análisis y diseño más modernas

son casos de uso guiados a través de requerimientos, diseño, implementación, pruebas, y despliegue.

El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estándar usado en análisis y diseño

orientado a objetos.

Referencias Históricas Definición de Arquitectura y Diseño de Software La Arquitectura de Software es una disciplina emergente del tópico general de diseño de software, relacionada con la

representación y composición de sistemas de software. En este contexto, el diseño de software se propone como una

actividad conciliatoria entre los requerimientos del problema, en términos de una función, y la factibilidad de una

solución en términos de un sistema de software. La idea básica es obtener una visión amplia, completa y humana del

software, como un producto tanto del conocimiento como de la intuición del diseñador de software.

Edsger Djikstra, 1968

Ciencias de la computación como rama aplicada de las matemáticas

Niveles de abstracción

Stack, abrazos mortales, semáforos, algoritmos de camino mas corto

NATO, 1968

F. L. Bauer “Ingeniería de software”

NATO, 1969

P. I. Sharp, “Arquitectura de software”

C. R. Spooner, 1971

“Una arquitectura de software para los 70s”

Referencia accidental

Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 2

Niklaus Wirth, 1971

Niveles de abstracción, Stepwise refinement

DeRemer & Kron, 1976

Programming in the large

Fred Brooks, 1975 – MMM

Diseñador del OS/360, Premio Turing 2000

Arquitectura como interfaz usuario

El arquitecto es un agente del usuario, igual que quien diseña su casa

Importancia de las estructuras de alto nivel y de decisiones tomadas al principio

Arquitectura: qué hacer – Implementación: cómo hacerlo

David Parnas

1972: Módulos – Ocultamiento de información

1974: Estructuras de software

1976: Familias de programas (Árbol de decisión) – Descomposición – Alternativa a diagramas de flujo,

propensión estructural (no funcional)

“Una familia de programas es un conjunto de programas (no todos los cuales han sido construidos o

lo serán alguna vez) a los cuales es provechoso o útil considerar como grupo. Esto evita el uso de

conceptos ambiguos tales como “similitud funcional” que surgen a veces cuando se describen

dominios. Por ejemplo, los ambientes de ingeniería de software y los juegos de video no se

consideran usualmente en el mismo dominio, aunque podrían considerarse miembros de la misma

familia de programas en una discusión sobre herramientas que ayuden a construir interfaces graficas,

que ambos casualmente utilizan”.

Dewayne Perry, Alexander Wolf – 1992

“Foundations for the study of software architecture”

“La década de 1990, creemos, será la década de la arquitectura de software. Usamos el término

“arquitectura” en contraste con “diseño”, para evocar nociones de codificación, de abstracción, de

estándares, de entrenamiento formal (de los arquitectos de software) y de estilo. Es tiempo de re-

examinar el papel de la arquitectura de software en el contexto más amplio del proceso de software

y de su administración, así como señalar las nuevas técnicas que han sido adoptadas”.

Escuela de Carnegie Mellon (CMU-SEI)

Mary Shaw, David Garlan, Paul Clements, Robert Allen

Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 3

1.2.1 Técnicas de modelado de objetos (OMT)

Según la Real Lengua Española: Técnica: es Conjunto de procedimientos y recursos de que se sirve una ciencia o un

arte. Modelado: es una técnica que ayuda a “visualizar” el sistema a construir. Objeto: Un objeto es una

representación detallada, concreta y particular de un “algo”. Tal representación determina su identidad, su estado y

su comportamiento particular en un momento dado.

En conclusión es Una serie de procedimientos para visualizar una serie de caracteristicas asignadas a un objeto.

Metodología OMT (Técnica de Modelado de Objetos): Un modelo es una abstracción de algo, con la finalidad de comprenderlo, antes de construirlo, ya que un modelo omite los detalles no esenciales, es más sencillo manejarlos, que manejar la entidad original. OMT es una de las metodologías de análisis y diseño orientadas a objetos, más maduras y eficientes que existen en la actualidad. La gran virtud que aporta esta metodología es su carácter de abierta (no propietaria), que le permite ser de dominio público y, en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolución para acoplarse a todas las necesidades actuales y futuras de la ingeniería de software. Esta técnica es trilateral, ya que toma en cuenta tres puntos de vista: modelo de objetos, modelo dinámico y modelo funcional. El modelo de objetos. El modelo de objetos es el modelo más importante, ya que en él se identifican las clases dentro del sistema junto con sus relaciones, así como sus atributos y operaciones, lo que representa la estructura estática del sistema. El modelo de objetos, representado en UML con Diagramas de Clase, describe la estructura de un sistema desde el punto de vista de objetos y asociaciones. El modelo dinámico. Representa los aspectos temporales de comportamiento "de control" del sistema, mediante la secuencia de operaciones en el tiempo. El modelo dinámico, representado en UML con Diagramas de Secuencia, Diagramas de colaboración, Diagramas de Actividad y Diagramas de Estado, describe el comportamiento del sistema. El modelo funcional. Representa los aspectos transformacionales "de función" del sistema, mediante la transformación de valores de los datos. Se representa mediante un diagrama de flujo. Cada modelo describe un aspecto del sistema pero contiene referencias a los demás modelos. Lo cual indica que los tres no son totalmente independientes.

El modelo funcional, representado en UML con Diagramas de Caso de Uso, describe la funcionalidad del sistema

desde el punto de vista del usuario.

Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 4

1.2.2 metodología de Booch La Metodología de Booch es una técnica usada en ingeniería de software. Es un lenguaje de modelado de objetos y

una metodología ampliamente usada en el diseño de software orientado a objetos. Fue desarrollada por Grady Booch

mientras trabajaba para Rational Software (hoy parte de IBM).

Los aspectos notables de la metodología de Booch han sido superados por el Lenguaje Unificado de Modelado, que

combina elementos gráficos de la metodología de Booch junto a elementos de la técnica de modelado de objetos y la

Ingeniería de software orientada a objetos

Los aspectos metodológicos de la metodología de Booch fueron incorporados en varias metodologías y procesos,

siendo la principal de ellas el Proceso Racional Unificado (RUP).

1.3 Metodologia RUP (Rational Unified Process)

El Proceso Unificado de Rational (Rational Unified Process en inglés, habitualmente resumido como RUP) es

un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología

estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al

contexto y necesidades de cada organización.

También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye

información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational

Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.

Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 5

Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más

detallada, el Rational Unified Process, que se vendiera como producto independiente.

RUP Forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quién hace qué, cuándo y cómo). RUP es el proceso de desarrollo más general de los existentes actualmente. Los procesos de RUP estiman tareas y horario del plan midiendo la velocidad de iteraciones concerniente a sus estimaciones originales. Las iteraciones tempranas de proyectos conducidos RUP se enfocan fuertemente sobre arquitectura del software; la puesta en práctica rápida de características se retrasa hasta que se ha identificado y se ha probado una arquitectura firme. RUP proporciona muchas ventajas sobre XP (METODOLOGIA EXTREME PROGRAMMING) le da énfasis en los requisitos y el diseño. La ventaja principal de RUP es que se basa todo en las mejores prácticas que se han intentado y se han probado en el campo. (en comparación con XP que se basa en las prácticas inestables que utilizaron juntas se evita que se derribe). RUP se divide en cuatro fases: Inicio (Define el alcance del proyecto) Elaboración (definición, análisis, diseño) Construcción (implementación) Transición (fin del proyecto y puesta en producción) Cada fase concluye con un HITO (T. Decisiones) RUP realiza un levantamiento exhaustivo de requerimientos. Busca detectar defectos en las fases iniciales. Intenta reducir al número de cambios tanto como sea posible. Realiza el Análisis y diseño, tan completo como sea posible. Diseño genérico, intenta anticiparse a futuras necesidades. Las necesidades de clientes no son fáciles de discernir. Existe un contrato prefijado con los clientes.

El cliente interactúa con el equipo de desarrollo mediante reuniones a diferencia de la metodología XP que el cliente

es parte del equipo (in situ).

1.4 Diseño de alto nivel (HLD) y bajo nivel (LLD)

Diseño de Alto Nivel (DAN) es el diseño general del sistema que abarca la arquitectura del sistema y el diseño de

bases de datos. En él se describe la relación entre los diferentes módulos y las funciones del sistema. Flujo de datos,

diagramas de flujo y estructuras de datos están cubiertos por la DAN. El diseño de alto nivel también identifica los

principales candidatos fuera de la plataforma de productos que pueden ser utilizados en el sistema.

Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 6

Alto nivel de diseño es la etapa de transición entre los requisitos de los subsistemas y cómo la arquitectura y las

interfaces del sistema se implementarán para cumplir con los requisitos del sistema. Este proceso incluye la

descomposición de los requisitos del sistema en las arquitecturas de proyecto alternativo y luego de la evaluación de

estas arquitecturas de proyecto para un óptimo rendimiento, funcionalidad, costo, y otros asuntos técnicos y no

técnicos. Participación de los interesados es fundamental para esta actividad. En este paso, las interfaces internas y

externas se identifican con los estándares de la industria es necesario.

Diseño de Bajo Nivel (LLD) es como detalla el Diálogo de Alto Nivel. Se define la lógica real de cada componente del

sistema. Los diagramas de clases con todos los métodos y la relación entre las clases están bajo LLD. Especificaciones

de los programas están cubiertas por LLD.

La funcionalidad de un diseño de bajo nivel es adaptar el diseño que anteriormente se ha realizado (diseño de alto

nivel) al lenguaje de programación.

LLD describe todas y cada módulo de forma elaborada de modo que el programador directamente el código del

programa basado en este. Este será por lo menos un documento para cada módulo y puede haber más de un módulo.

La LLD contendrá:

Detallada lógica funcional del módulo en pseudocódigo - tablas de base de datos con todos los elementos incluyendo su tipo y tamaño

Todos los detalles de la interfaz con referencias completas de la API (ambas solicitudes y respuestas)

Todos los problemas de dependencia

El mensaje de error listados

Entrada completa y salidas de un módulo

1.5 Compresión de los requerimientos

Se tiene que tener una completa comprensión de los requerimientos para poder resolver los problemas que se puedan

presentar así como para tener una participación activa en el desarrollo del software. Si hay un equipo, esta

experiencia puede estar representada en diferentes miembros del grupo, pero al menos una persona debe poder

mantener la visión global del proyecto. Esta persona es el arquitecto del Software quien es el responsable de diseñar

la arquitectura del software, la cual incluye tomar las principales decisiones de diseño y la implementación del

proyecto, se debe de tener experiencia en dominios tanto de problemas como de ingeniería de software.

Tipos de requerimientos

Requerimiento: Atributo del sistema Algo que el sistema debe ser capaz de hacer para cumplir su propósito

Tipos clásicos de requerimientos:

o Funcionales: describen tareas específicas que el sistema debe ser capaz de hacer

Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 7

Ejemplo: imprimir cheques de sueldos

o No-funcionales (restricciones): limitan nuestras opciones para construir una solución. Ejemplo: generar cheques máx. 4 hrs después de recibir listados de contabilidad

Analogía: Requisitos funcionales: los “verbos” (Xear)

Requisitos no-funcionales: los “adverbios” (Xmente)

1.6 Casos de Uso

1.6.1 Introducción Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo

algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores. En el contexto

de ingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y

sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de

uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los

usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de

uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la

generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al

mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.

La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la intención que tiene el actor

(su usuario) al hacer uso del sistema.

Como técnica de extracción de requerimiento permite que el analista se centre en las necesidades del

usuario, qué espera éste lograr al utilizar el sistema, evitando que la gente especializada en informática dirija la

funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos.

A su vez, durante la extracción (elicitation en inglés), el analista se concentra en las tareas centrales del

usuario describiendo por lo tanto los casos de uso que mayor valor aportan al negocio. Esto facilita luego la

priorización del requerimiento.

El diagrama de casos de uso representa la forma en cómo un Cliente (Actor) opera con el sistema en

desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso).

1.6.2 Elementos de Casos de uso.

Un diagrama de casos de uso consta de los siguientes elementos:

Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 8

Actor:

Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante

destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una

persona en particular, sino más bien la labor que realiza frente al sistema.

Caso de Uso:

Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una

petición de un actor o bien desde la invocación desde otro caso de uso.

Relaciones:

Asociación

Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso

de uso). Dicha relación se denota con una flecha simple.

Dependencia o Instanciación

Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se

instancia (se crea). Dicha relación se denota con una flecha punteada.

Generalización

Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo,

que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).

Este tipo de relación está orientado exclusivamente para casos de uso (y no para actores).

Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 9

1.7 Modelos del Dominio

Modelo de Dominio:

Es un artefacto de la disciplina de análisis, construido con las reglas de UML durante la fase de concepción, en la tarea

construcción del modelo de dominio, presentado como uno o más diagramas de clases y que contiene, no conceptos

propios de un sistema de software sino de la propia realidad física.

Los modelos de dominio pueden 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.

Similares a los mapas mentales utilizados en el aprendizaje, el modelo de dominio es utilizado por el analista como un

medio para comprender el sector industrial o de negocios al cual el sistema va a servir.

Los modelos de dominio pueden mostrar:

Objetos del dominio o clases conceptuales.

Asociaciones entre las clases conceptuales.

Atributos de las clases conceptuales.

Nota: Ejemplo de Modelo de Dominio

1.7.1 Visualización de Conceptos

La visualización de los conceptos en el principal propósito del diagrama de dominio, se enfoca en una serie de

conceptos como las asociaciones y los atributos que son vitales para este diagrama, para tener un mejor y fácil

entendimiento.

Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 10

1.7.2 Añadir Asociaciones

Una asociación representa una relación entre clases, y aporta la semántica común y la estructura de muchos tipos de

conexiones entre objetos.

Las asociaciones son los mecanismos que permite a los objetos comunicarse entre sí; Describe la conexión entre

diferentes clases.

Las asociaciones pueden tener un papel que especifica el propósito de la asociación y pueden ser unidireccionales o

bidireccionales (indicando si los dos objetos participantes en la relación pueden intercambiar mensajes entre sí, o es

únicamente uno de ellos el que recibe información del otro). Cada extremo de la asociación también tiene un valor de

multiplicidad, que indica cuántos objetos de ese lado de la asociación están relacionados con un objeto del extremo

contrario.

1.7.3 Añadir Atributos

Un atributo no debería ser un concepto complejo sino que deberían ser cosas simples o tipos de datos. Por ejemplo:

fecha, hora, número, color, código, descripción, cantidad.

Cuando algo está compuesto de más de un elemento, da la idea de estar frente a una entidad y no un atributo. Por

ejemplo, la dirección puede resultar un concepto simple pero en realidad está formada por calle, altura, etc.

Si una entidad puede tener muchos valores simultáneos para un mismo atributo, ese atributo debería ser otra

entidad. Por ejemplo, una persona puede tener muchos números de teléfono, entonces número de teléfono es una

entidad con una asociación de 1 a muchos con la persona.

Una regla importante a tener en cuenta es relacionar las entidades con una asociación y no a través de un atributo.

No existe un único diagrama de dominio correcto, todos serán una aproximación del dominio que estamos

intentando entender. Un buen diagrama captura las abstracciones y da la información necesaria para entender el

contexto.