Sebastian Durandeu Blog

  • Visitantes

Analisis de la Información – FIUBA

Posted by sebastiandurandeu on August 7, 2008

Esto es una resumen de varios temas de la materia Analisis de la Información (75.09) de la Facultad de Ingeniería de la UBA.

UML – Modelo Estructural


A good model includes those elements that have broad effect and omits those minor elements that are not relevant to the given level of abstraction.

We build models so that we can better understand the system we are developing:

  • Models help us to visualize a system as it is or as we want it to be.
  • Models permit us to specify the structure or behavior of a system.
  • Models give us a template that guides us in constructing a system.
  • Models document the decisions we have made.

We build models of complex systems because we cannot comprehend such a system in its entirety.

Modeling allow us to focus on only one aspect at a time –> “Divide and conquer”

All models simplify reality; the trick is to be sure that your simplifications don’t mask any important details.

UML: using a common language for software modeling.

Classes Responsibilities

You don’t want any one class to be too big or too small. Each class should do one thing well.

  • If you abstract classes that are too big, you’ll find that your models are hard to change and are not very reusable.
  • If you abstract classes that are too small, you’ll end up with many more abstractions than you can reasonably manage or understand.

Diagrama de clases

  • No esta mal agregar un identificador a las clases.
  • El rombo de asociación o agregación va en el contenedor.
  • Composición: “Es parte de”. Si elimino el contenedor no tiene sentido las partes.
  • Responsabilidad de una clase: Es un contrato o una obligación que debe cumplir una clase. Una clase debe tener una responsabilidad pero no muchas.

UML – Modelo Dinámico

Diagrama de Colaboración = Communication Diagram

Sequence Diagrams + Communication Diagrams = Interaction Diagrams

Interaction: An interaction goes further by introducing a dynamic sequence of messages that may pass along the links that connect these objects.

Diagrama de Secuencia

En el diagrama de secuencia, sobre la flecha va el nombre del método del objeto destinatario. Si A le manda un mensaje a B sobre la flecha va B.Mensaje().

La línea de vida se corta si el objeto se destruye.

The focus of control is a tall, thin rectangle that shows the period of time during which an object is performing an action, either directly or through a subordinate procedure.

Diagrama de Secuencia vs Diagrama de Colaboración

Because they both derive from the same information in the UML’s metamodel, sequence diagrams and communication diagrams are semantically equivalent. As a result, you can take a diagram in one form and convert it to the other without any loss of information, as you can see in the previous two figures, which are semantically equivalent.

  • To model flows of control by time ordering: Here you’ll use sequence diagrams.
  • To model flows of control by organization: Here you’ll use communication diagrams. Modeling a flow of control by organization emphasizes the structural relationships among the instances in the interaction, along which messages may be passed.

Lo que sigue es un ejemplo de loop (pide el password de una a tres veces) , de ejecución opcional (si el password fue valido) y de ejecución en paralelo (par). Parallel really means that two actions are uncoordinated and can happen in any order.


Sub- Modelos de UML

  • Modelo de Casos de Uso (Dinámico):
    • Diagrama de casos de uso: Organiza los comportamientos del sistema. Representa un conjunto de casos de uso y actores y sus relaciones.
  • Modelo de Objetos (estático) :
    • Diagrama de clases:
    • Diagrama de objetos: Modela las instancias de los elementos contenidos en el diagrama de clases. Muestra un conjunto de objetos y sus relaciones en un momento concreto.
  • Modelo de Interacción entre Objetos:
    • Diagrama de secuencia: Destaca el flujo de interacción entre objetos. Un diagrama de actividades muestra las operaciones que se pasan entre los objetos. Se pueden usar como diagramas de flujo para modelas operaciones.
    • Diagrama de colaboración:
  • Modelo de Estado de Objetos (Dinámico):
    • Diagrama de transición de estado de objetos: Representa una máquina de estados. Muestra las secuencias de estados por las que pasa un objeto a lo largo de su vida en respuesta a eventos, junto con sus respuestas a esos eventos.
  • Modelos de Negocio (Dinámico): Muestra el flujo de actividades en un sistema.
    • Diagrama de actividades: Destaca el flujo de control de actividades.
  • Modelo de Componentes (Estático): Muestra la organización y las dependencias entre un conjunto de componentes (Un componente = uno o mas clases). Los componentes son las cosas físicas que residen en un nodo: ejecutables, bibliotecas, tablas, archivos y documentos.
  • Modelos de Despliegue (Estático): Muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos. Un nodo corre uno o mas componentes.

Use Cases

Writing Effective Use Cases (Resumen Libro)

A use case need not be the best to be useful.

A use case captures a contract between the stakeholders of a system about its behaviour.

A well-written use case is easy to read. It consists of senteces written in only one grammatical form -a simple action step- in which an actor achieves a result or passes information to another actor. Learning to read a use case should not take more than a few minutes.

Business process people write business use cases to describe the operation of their business, while a software development team writes system use cases for their requirements.

A use case valid in one project might not be valid in another project.

Use cases reveal user goal the system will support.

In one use case:

  • All the interaction relate to the same goal of the same primary actor.
  • The use case starts at the triggering event and continues until de goal is delivered or abandoned, and the system completes its responsibilities with respect to the interaction.

A step in a use case can be drilled down to another use case.

Use case brief: Is a two-to-six sentence description of use case behavior, mentioning the actors, the goals an only the most significant activity and failures.

An actor might be a person, a company or organization, a computer program or a computer system- hardware, software or both.

Relations between use cases:

  • <<include>>: One use case refers or calls another.
  • <<extends>: Create extension use cases only when you need to, because they are harder for people to understand and mantain. Two Situations:
      • Many asynchronous or interrupting services the user might use, which should not disturb the use case. Example:Edit document –> Check Spelling –> Change template–> Find synonym
      • Writting additions to locked requirements.

Supporting Actors (or secondary actors): A supporting actor in a use case is an external actor that provides a services to the system under design. These are sets of actors that support the use cases provided by the system and those that support the system itself.

Actions of supporting actors involve to provide additional information or take some decisions.

An actor can be primary in one use case and supporting in another.

Primary actor: The primary actors are the ones for whom the system is built; they are the ones to whom the system provides sufficient economic value to warrant its construction. It is both necessary and correct that we should concentrate our efforts primarily on these actors and the users that will take on these roles.

When writing use cases: KEEP THE GOAL IN MIND.

Common mistakes:

– Avoid a use case where every statement is accomplished by the actor

– Customer enters card and PIN

– customer enters “Withdrawal” and amount.

– Customer takes cash, card and receipt.

– Avoid detailing user interfaces in the use case.

– Remember every use case must show the primary actor actions.

– Remember always naming who is doing the action, avoiding passive voice.

Use Cases Modeling (Resumen Libro)

We don’t consider the operating system, database, or other utilities as actors. Although we certainly make use of their capabilities, we are not required by the system to use them in specific ways at specific times.

A use case is focused on what the system must do, whereas code is an expression of how the system will do those things.

Prototypes: As the saying goes, a picture is worth a thousand words. If that’s true, a prototype is invaluable. Use prototypes to describe the user interface, leaving the use cases to describe what happens behind the screens.

The whole point of a use case is to capture a description of something that the system must do. It is an expression of a desired behavior of the system. The system must behave that way no matter how it is designed and implemented.

Make sure that each use case provides the user of the system with something of value.

Glossary: Use cases often contain a lot of information that can be better presented in other ways. Using a glossary of terms is one way to present necessary information that can otherwise be distracting to the reader.

Every use case has two exits: succed or fail.

Sub-flujos / Flujos Alternativos

  • “Named” Subflows: Sections that perform important behaviors but that are not essential to understanding the basic flow of events. Ej. Perform Authenticate Customer.
  • “Alternative” flows: Flows of events that occur when something other than the normal course of events has occurred.

Rational Unified Process

Esto es un resumen de todo lo que se da en la teórica sobre RUP.

Mejores prácticas para el desarrollo de software.

  • Proceso iterativo e incremental.
  • Dirigido por casos de uso
  • Arquitectura basada en componentes (reusabilidad).
  • Modelización visual
  • Gestión del cambio
  • Verificación de calidad

Contribución del RUP a las buenas prácticas

Iterativo e Incremental

  • 1 ciclo compuesto de distintas fases:
    • Inicio
    • Elaboración
    • Construcción
    • Transición
  • Cada una de estas fases tiene mas de una iteración. En cada una de las iteraciones hay diferentes disciplinas en las que se gasta mas o menos esfuerzo dependiendo de la fase en la que se esta.
    • Captura de requisitos
    • Análisis
    • Diseño
    • Implantación
    • Pruebas y Despliegue
  • Además de esto hay componentes de soporte del proceso:
    • Gestión de cambios: Trackear requerimientos de cambio. Versionado.
    • Administración de proyecto: Risk Managment. Monitoring process.
    • Gestión de ambiente: Preparación de ambiente de desarrollo (procesos y herramientas necesarios para el desarrollo).

Matriz de Esfuezo

Define el esfuerzo dedicado a cada disciplina en cada fase.


Dirigido por casos de uso

Los casos de uso se utilizan a lo largo de todo el proceso. Los casos de uso son una buena forma de capturar requerimientos y guiar la implementación y las pruebas. La arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida.


  • En la captura de requisitos: Los casos de uso se unan para capturar y validar los requerimientos.
  • En análisis y diseño y en implantación: Se implementan los casos de uso.
  • En las pruebas: Se realizan las pruebas que verifiquen el cumplimiento de los casos de uso.

Arquitectura basada en componentes

Se trata de diseñar una arquitectura base ejecutable en forma temprana.

Arquitectura base ejecutable

  • Flexible
  • Fácil de modificar
  • Promover la reutilización de componentes

RUP apoya el desarrollo basado en componentes, tanto nuevos como preexistentes.

Modelización visual

Utilización intensiva de UML.

Gestión del Cambio

Los cambios pueden ser de requisitos o de funcionalidades. Los cambios son inevitables.

Como gestionar cambios?

  • Evaluación: Son realmente necesarios? Cual es su impacto?
  • Rastreo y monitoreo.

RUP provee herramientas para controlar, rastrear y monitorizar los cambios dentro del proceso de desarrollo.

Verificación de la calidad

RUP provee herramientas para planificar, diseñar, implementar, ejecutar y evaluar pruebas que verifiquen la calidad del desarrollo. De esta forma vemos que la calidad forma parte del proceso de desarrollo y no es responsabilidad de un grupo separado.

  • Funcionalidad
  • Rendimiento
  • Confiabilidad.

Matriz de Hitos y Productos de Cada Fase



Caso de Negocio: The Business Case provides the necessary information from a business standpoint to determine whether or not this project is worth investing in. For a commercial software product, the Business Case should include a set of assumptions about the project and the order of magnitude return on investment (ROI) if those assumptions are true. For example, the ROI will be a magnitude of five if completed in one year, two if completed in two years, and a negative number after that. These assumptions are checked again at the end of the Elaboration phase, when the scope and plan are defined with more accuracy.

RUP como Proceso de Desarrollo de software


  • Quien hace que cosa?
  • Que hace?
  • Como lo hace?
  • Cuando lo hace?

Sobre el Quien RUP define tres tipos de elementos:

  • Trabajador: define el comportamiento y las responsabilidades de un individuo.
  • Actividad: A unit of work in the RUP that a role may be asked to perform. An activity may be decomposed in steps. Activities produce or modify artifacts.
  • Artefacto: Artifacts are either final or intermediate work products that are produced and used during a project. Artifacts are used to capture and convey project information.


  • Trabajador (Worker) :
    • Comportamiento –> Rol: A definition of the behavior and responsibilities of an individual, or a set of individuals working together as a team, within the context of a software engineering organization.
      • Analista
      • Diseñador
      • Ing. Pruebas
    • Responsabilidad: Actividad que va a realizar la persona, que será responsable de una serie de artefactos.
  • Actividad: Es una unidad de trabajo que se asigna a un determinado trabajador. No debería durar menos de dos horas y mas de veinte dias. Debe involucrar un solo trabajador y pocos artefactos. Ejemplos:
    • Planificar una iteración
    • Encontrar actores y casos de uso
    • Ejecutar pruebas unitarias
    • Ejecutar pruebas de performance
    • Diseñar casos de uso
  • Artefactos: Elementos de información producidos, modificados o utilizados durante el proceso. Son el resultado de actividades y utilizados además como inputs a otras actividades. Ejemplos:
    • Modelos: Modelo de caso de uso. Modelo de objetos.
    • Elemento de un modelo: Caso de uso. Clase.
    • Documentos: Caso de negocio. Documento de arquitectura del sistema.
    • En etapa de construcción: Código Fuente. Código ejecutable.

Matriz de Asignaciones


Análisis Estructurado

El modelo esencial supone que se tiene disponible una tecnología perfecta y que se puede obtener fácilmente. (Yourdon p.358) Un modelo se tiene que componer de gráficos y documentos de texto. Uno o mas gáficos debieran ser el documento primario al que se dirige el usuario para poder entender el sistema; los documentos textuales debieran servir de material de referencia para consultar en caso de necesidad (Yourdon p.152)

Modelo Ambiental




Diagrama de Contexto


  • Las personas, organizaciones y sistemas con los que se comunica el sistema.
  • Los datos que el sistema recibe del mundo exterior.
  • Los datos que se envían al mundo exterior.
  • Los almacenes de datos externos al sistema.
  • A veces conviene dibujar a los objetos externos mas de una vez.

Lista de Eventos

En todo evento va a ocurrir un estímulo y una respuesta.


  • Externos: Entidad Externa + Verbo + Objeto
  • Temporales
    • Tipo 1: Período + Verbo + Objeto (Nadie espera lo que se emite)
    • Tipo 2: Período + Ent. Externa + Verbo + Objeto (La entidad externa solicita el objeto)

Lista de Estímulos y Respuestas

  • Los almacenamientos van en plural.
  • Usar:
    • Mensualmente vs Todos los meses

    Modelo de Comportamiento

    Modelo de Procesos

  • DFD: Modelo las funciones que lleva a cabo un sistema. Evitar los verbos: Hacer, Manejar y Procesar. Son verbos muy genéricos.
  • Diagrama de Transición de estados: Modela el comportamiento dependiente del tiempo de un sistema.

    Modelo de Datos

  • Diccionario de datos: Un listado organizado de todos los datos pertenecientes al sistema para tener un entendimiento común de:

    • Todas las entradas, salidas y almacenes y cálculos intermedios del sistema.
    • Relaciones entre almacenes del DER.
    • () –> Se usa para un dato opcional.

    DER: Describe la distribución de datos almacenados en un sistema.

    • Los tipos de objeto van en singular.
    • Puede haber relaciones entre el mismo tipo de objeto (Relación reflexiva. Ej. Curso correlativo de curso).
    • Cada instancia tiene que poder identificarse en forma univoca.
    • La relación entre tipo de datos es algo que debe ser recordado por el sistema.
    • Objetos no instanciables (unicos en todo el sistema) no van en el DER.
    • Herencia:


    El nombre de una asociación solo va si la asociación es pura.



    2 Responses to “Analisis de la Información – FIUBA”

    1. Manuel Gonzalez Pan said

      Recomiendo ALTAMENTE empezar a ver patrones para cuando tengas/n que hacer diagramas de clases/Use Case.
      En la materia Diseño de Sistemas fueron muy ásperos conmigo, y tuve que remarla mucho porque nunca había visto el QUE/COMO/CUANDO de un patrón.
      El que necesite una mano en esto se la puedo dar ( me encanta hacer diseño de sistemas 😀 )

    Leave a Reply

    Fill in your details below or click an icon to log in: Logo

    You are commenting using your account. Log Out /  Change )

    Google photo

    You are commenting using your Google account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )

    Connecting to %s

    %d bloggers like this: