Microprocessors and Assembler

Introduction to Rational Unified Process

Professor:
Eval Bladimir Bacca Cortes Ph.D.
Research group:
Perception and Intelligent Systems
(P.S.I.)
Email:
[email protected]
Contents

1. Motivation
2. Software development
1. Requirement analysis
2. Diagram of concept
3. Real use cases
4. Sequence diagrams
5. Flow chart or class diagrams
6. Functional or integration tests
Rational Unified Process – RUP
Rational Unified Process – RUP
Rational Unified Process – RUP

• Software Process: In general a process defines WHO is doing

WHAT, WHEN and HOW in order to accomplish a goal.

Software Engineering Software

Requirements Process System

• Problem:
– Different kind of users use a software process.
– Different teams design and implement the software process, then there are
different modeling languages.
– Most of software process use not defined process.
– Most of software process are not automatic.
Rational Unified Process – RUP

• Solution?
– R.U.P. Rational Unified Process

• RUP properties:
– It includes the best programming
practices in the modern software
development.
– It is an effective guide to use
UML.
– It provides to each development
team all tools needed to develop
software.
– It builds and maintains software
models
Rational Unified Process – RUP

• RUP – Best programming practices

Requirements Management

Iterative Visual Quality Component

Development Modeling Check Architecture

Change Control

• Requirement Management:
– To list, organize and document the software functionalities and
constraints.
• Iterative Development:
– Loop: Requirements, Design / Implementation, Tests and
Evaluation
Rational Unified Process – RUP

• Iterative Development
– It allows an incremental understanding of the software
process
– Handling short and reachable challenges are suitable for
getting results.
– It mainly saves time, since it allows discover software bugs
of previous phases.
Rational Unified Process – RUP

• RUP – Best programming practices

Requirements Management

Iterative Visual Quality Component

Development Modeling Check Architecture

Change Control

• Visual Modeling:
– Holding consistency between software design and implementation.
• Quality check:
– It creates test for each situation in order to ensure the
requirements fulfillment.
Rational Unified Process – RUP

• RUP – Best programming practices

Requirements Management

Iterative Visual Quality Component

Development Modeling Check Architecture

Change Control

• Component Architecture:
– The goal is assuming a software architecture for re-using software
components.
• Change Control:
– Strategies to control, supervise and register changes in the
iterative process of software development.
Rational Unified Process – RUP

• RUP phases:

• Inception: It defines the

software project scope.

• Elaboration: Project
planning, characteristics
specification and base
architecture.

• Construction: Iterative
software development.

• Transition: Beta test.

Rational Unified Process – RUP

• RUP Methodology and Results

• Project model: Project scope.

– Results: Scope, development schedule and resource analysis.

• Requirements analysis: To identify functional and non functional

requirements
– Results: Requirements list, conceptual model and real use cases.

• Design: To define the software architecture.

– Results: Sequence diagrams, Database design and Class diagrams.

• Implementation: Software programming

– Results: Source code.

• Tests: Software quality

– Results: functional tests and integration tests
Rational Unified Process – RUP

• Study case:

Using a differential mobile robot, it must be implemented an autonomous vehicle

capable of collecting small balls of polystyrene and bring them back to the
home position.
The small balls of polystyrene are considered trash, and the home position is
considered the trash can. The mobile robot will be doing its job into an
environment limited by walls, which are bigger than the polystyrene balls.
For this project, the following requirements must keep in mind:
• The robot must sense where is the homing position,
• The mobile robot must sense the walls and differentiate them from the
polystyrene balls,
• The mobile robot must know when there is or there is not a polystyrene ball
ready to bring to the home position and it is recommended that the mobile
robot just push the balls instead of carrying them.
 Rational Unified Process – Requirements
Analysis
• Definition: It is a list of capabilities • Guide to do a list of
or functionalities needed to resolve requirements:
a problem through a software
– The WHO are involved? Their
process.
role? Training level?
• List criteria:
– The WHAT, current situation?
– Functionalities Future functionalities?
– Performance – The WHERE the system
– Adaptability and configuration integration is done?
– Reliability – The WHEN the system will be
– User interface working? Transition?
• Types: – The WHY is needed a new
– Functional system?
– Non functional – The HOW the new system must
be working? Constraints?
• Who defines this list? The client, or
the client and the developer.
• Document format
Rational Unified Process – RUP

• Study case – Requirements Analysis

Universidad del Valle Rev.:
Trash Robot 003

Title: Document: Page:

Trash Robot Functional Trash-001 1/1
Requirements

HISTORIC REVIEW
Rev. Change Description Author Date
001 Document Construction Bladimir Bacca Cortes 2009-09-01
002 Corrections Bladimir Bacca Cortes 2009-11-25
003 Revision Bladimir Bacca Cortes 2010-03-06

Ref # Functions Category

1 E

2 E

3 E

4 E
Rational Unified Process – RUP

• Study case – Requirements Analysis

Universidad del Valle Rev.:
Trash Robot 003

Title: Document: Page:

Trash Robot NONFunctional Trash-002 1/1
Requirements

HISTORIC REVIEW
Rev. Change Description Author Date
001 Document Construction Bladimir Bacca Cortes 2009-09-01
002 Corrections Bladimir Bacca Cortes 2009-11-25
003 Revision Bladimir Bacca Cortes 2010-03-06

Ref # Description Category

1 E

2 E

3 E
Rational Unified Process – Conceptual
Model
• Definition: It represents real world “things”, but it DOES NOT represent software
components. It DOES NOT define software operations.
• It shows: concepts, concepts associations and concepts attributes.
• Examples: physical objects, places, transactions, people roles, PCs, software,
organizations, institutions, events, process, manual, books, catalogues,
• Theory:
– Associations: Relationship between concepts pointing some interesting connection.
– Multiplicity: It defines how many instances of type A can be associated to type B at
some particular time.
Rational Unified Process – RUP

• Study case – Conceptual Model

 Rational Unified Process – Real Use Cases
• Definition: A use case can be defined as a collection of successful and non-
successful situations which describe how the user or actor uses a software
system in order to accomplish a task.
• Properties:
– They are known as histories or situations of how the software process is
used.
– They are not functional requirements. But, they shows and entail software
requirements.
– They describe a complete process, not part of it. Example: it is a use
case buying articles, it is not a use case print a receipt.
– An actor could be a behavior, a person, an institution or other system.
• Identifying use cases:
– They are mainly based on system requirements.
– Actor based: 1. Identifying all actors entailed in the organization or
system. 2. For each actor, it is needed to identify the process started by
actors or where they participate.
– Event based: 1. Identifying all external events to which the system must
respond. 2. To establish a relationship between events and actors.
 Rational Unified Process – RUP
Universidad del Valle Rev.:
Trash Robot
003
Title: Documento : Page:
• Study case – Real Use
Use Case CUR-001
Cases 1/1
Avoid Obstacles
HISTORIC REVISION
Rev. Change Description Author Date
001 Use case construction Bladimir Bacca Cortes 2009-09-01
002 Informatio re-organization Bladimir Bacca Cortes 2010-04-15
GENERAL INFORMATION
Actors:
Goal:
Abstract:
Type: Real

Normal Course of Events

Actor Action System Response

Alternative Course of Events

System Response
Rational Unified Process – Sequence
Diagrams

• Definition: It shows a chronological sequence of messages between software

components. They are based on the use case documentation.
• Normally, in a sequence diagram the following events are shown:
– Self messages send within software components.
– Messages to create objects or systems.
– Messages to destroy objects, tasks or systems.
– Conditionals
– Iterations.
• Sequence diagrams are draw for the normal course of the events. Other
diagrams must show alternative sequence of events.
• Concepts:
– System behavior: It is a description of what the system does without
explain how it does.
– System events: External inputs generated by actors.
– System operations: It is a procedure executed by systems in response to
system events.
 Rational Unified Process – RUP
• Study case – Sequence
Diagrams
– It shows a chronological
sequence of messages
between software
components.
– Normally, in a sequence
diagram the following
events are shown:
• Self messages send
within software
components.
• Messages to create
objects or systems.
• Messages to destroy
objects, tasks or
systems.
• Conditionals
• Iterations.
 Rational Unified Process – RUP
FUNCTIONAL TEST – OBSTACLE AVOIDANCE
Requirements:

• Study case – Integration  The module is able to sense the environment obstacles.

Tests  The module models the perception data.

– Integration testing is a  If any obstacle is found, it computes a new robot heading and it moves the mobile
robot to it.
quality assurance (QA) Type of Integration
Test
process and a type of Hardware The mobile robot perception and motion system.
black box testing that Needed

bases its test cases on a

Software Obstacle avoidance task
Needed
set of specifications of Goal To test if the mobile robot properly avoids obstacles of the
the software component environment.
Obstacle Avoidance Task
under test. Goal To test if the mobile robot properly avoids obstacles of the
• Detailed testing: Functional environment.
Test Data The mobile robot perception system uses a set of optical
tests. proximity sensors which brings a stream of binary
– Functions are tested by information. These data shows if an obstacle exists or not
feeding them input and exists in the environment.
Procedure 1. The mobile robot runs a specific program which
examining the output, continuously call the obstacle avoidance task.
and internal program
2. The mobile robot moves in a close environment with
structure is rarely walls and other obstacles.
considered Result 1. When the mobile robot face an obstacle it avoids it.
Expected
2. The mobile robot heading is computed in order to
bound the robot towards a obstacle-free area.
Result This test was successful. The mobile robot heading was
Obtained computed successfully. However, there were problems if the
environment contains a dead-end.
Rational Unified Process – Class Diagrams
(Flow Diagram)

• Definition: It describes graphically the software class specifications and interfaces

• They contain:
– Classes, associations and attributes
– Interfaces with their operations and constants.
– Methods
– Information about the attributes data types.
– Navigability.
– Dependencies.

• Special case: Structured Programming.

– Each actor within a Sequence Diagram is able of being represented as Flow Diagram.
– Advantages: Any one can understand it, it represents the program flow and in
structured programming is the standard way of documenting programs (symbols well
defined).
– Disadvantages: it does not represents how the data is flowing; it does not represent
the process properties neither its interaction methods; it shows partial information.
Rational Unified Process – Class
Diagrams (Flow Diagram)
• Flow diagram symbols.
Rational Unified Process – RUP

• Study case No. 2:

• JMat es una aplicación cliente que le permite a un usuario conectarse

remotamente a un servidor, el cual tiene instalado Matlab. JMat debe
permitirle al usuario remoto poder ejecutar comandos de línea de comandos,
editar el Workspace donde se almacenan las variables que el usuario emplea,
graficar estas variables remotamente, escribir funciones compatibles con
Matlab, ejecutarlas en el servidor, enviar y recibir archivos de datos.

• El desarrollo de JMat hace parte del proyecto de investigación titulado

“Plataforma de Procesamiento Distribuido con Acceso Remoto Multi-usuario y
Emulación de Sistemas Dinámicos para Investigación y Educación en
Ingeniería” financiado por COLCIENCIAS y la UNIVERSIDAD DEL VALLE.
RUP: Requirements Analysis

Universidad del Valle Rev.:

JMAT 003

Title: Document: Page:

JMat Functional Requirements JMat-001 1/1

HISTORIC REVIEW
Rev. Change Description Author Date
001 Document Construction Bladimir Bacca Cortes 2009-09-01
002 Corrections Bladimir Bacca Cortes 2009-11-25
003 Revision Bladimir Bacca Cortes 2010-03-06

Ref # Functions Category

1.0 Interfaz de Comandos de Consola E

1.1 Permitir limpiar la consola e histórico de los comandos

1.2 Permitir grabar la consola de comandos y el histórico de los comandos

1.3 Permitir la configuración del IP del servidor donde se encuentra Matlab instalado E

1.4 Todo comando de texto escrito en la consola debe ejecutarse remotamente en Matlab E

1.5 La respuesta del comando ejecutado debe ser visible por el usuario. E
RUP: Requirements Analysis

Ref # Functions Category

2.0 Gestión del WorkSpace Remoto

2.1 Permitir guardar el WorkSpace remoto en un archivo local al usuario E

2.2 Permitir cargar un WorkSpace previamente grabado en disco. E

2.3 Permitir la actualización del WorkSpace por parte del usuario. E

2.4 Permitir borrar todo el WorkSpace E

2.5 Permitir borrar variables individuales del WorkSpace E

2.6 Graficar cualquier variable 1D, 2D y 3D presente en el WorkSpace E

2.7 Modificar las características de la gráfica como título de los ejes y de la figura misma E

2.8 Visualizar en formato texto el nombre de la variable, el valor o dimensión y el tipo E

3.0 Programación de Scripts de Matlab

3.1 Permitir abrir un script de Matlab previamente guardado E

3.2 Guardar un script de Matlab digitado en el editor de texto. E

3.3 Enviar un script previamente guardado y visible en JMat hacia el servidor E

3.4 Permitir recibir un archivo de datos E

3.5 Permitir transmitir al servidor un archivo de datos. E

3.6 Permitir la edición de scripts de Matlab tipo función. E

RUP: Requirements Analysis

Universidad del Valle Rev.:

JMAT 003

Title: Document: Page:

JMat NON-Functional JMat-002 1/1
Requirements

HISTORIC REVIEW
Rev. Change Description Author Date
001 Document Construction Bladimir Bacca Cortes 2009-09-01
002 Corrections Bladimir Bacca Cortes 2009-11-25
003 Revision Bladimir Bacca Cortes 2010-03-06

Ref # Description Category

Software

1.0 Se utilizará la máquina virtual de java versión 1.5 o superior E

2.0 Se utilizará Easy Java Simulations (EJS) como ambiente de desarrollo. E

3.0 Se utilizara Matlab para el procesamiento de los datos y comandos enviados por JMat E

2.0 Hardware

2.1 Se nenecita tener 89Mbytes como mínimo, en memoria RAM para ejecutar la aplicación E
 RUP: Conceptual Model
• Guide for conceptual
models:
– To do a list of concepts. It
Limpia
could be helpful to group Guarda
Configura

in categories and associate

to each concept a Ejecuta
descriptive substantive. Envía

Ejecuta
– Draw these concepts in a Envía
Maneja
conceptual model Gestiona Envía
considering how they Edita
interact. Grafica

Programa
– Adding associations Envía
Edita
between concepts
Transfiere Envía

– Adding concept attributes.

Envía
Maneja
RUP: Real Use Cases
Universidad del Valle Rev.:
JMAT
003
Title: Documento : Page:
Use Case CUR-001
1/1
Graficar Varialbes del Workspace
HISTORIC REVISION
Rev. Change Description Author Date
001 Use case construction Bladimir Bacca Cortes 2009-09-01
002 Informatio re-organization Bladimir Bacca Cortes 2010-04-15
GENERAL INFORMATION
Actors: Usuario JMat
Goal: Graficar variables 1D, 2D y 3D presentes en el WorkSpace del usuario.
Abstract: El usuario digita el nombre de la variable a graficar, se detecta si es una variable 1D, 2D o 3D y se
procede a mostrar la gráfica correspondiente.
Type: Real

Normal Course of Events

Actor Action System Response
1. El usuario digita el nombre de la variable a graficar y 2. JMat chequea la existencia de la variable en el WorkSpace del usuario.
acciona el botón “Graficar”. 3. JMat determina el tipo de variable y dimensión de la misma.
4. JMat abre una ventana nueva con la gráfica de la variable.

Alternative Course of Events

System Response
En caso que la variable no exista, JMat no procede con la acción especificada.
RUP: Sequence Diagrams

• How to draw it?

– Vertical axis represents
time.

– Horizontal axis lists the

entailed entities.

– Take a use case

description and identify
the system events.

– Afterwards, for each entity

registers the system
operations.

• Software tool: Violet UML

Editor.
RUP: Sequence Diagrams
 RUP: Class Diagrams

• Relationships:
– Inheritance
– Bidirectional: this
means that both
classes are aware of
each.
– Unidirectional: two
classes are related, but
only one class knows
that the relationship
exists
RUP: Class Diagrams

• Relationships:
– Packages: Organizing
models into namespaces
– Interfaces
– Basic aggregation:
“Whole to its parts”, but
the classes entailed are
independent.
– Composition
aggregation: the child
class's instance lifecycle is
dependent on the parent
class's instance lifecycle
 RUP: Functional Tests

PRUEBA DE INTEGRACIÓN – MANEJO DEL WORKSPACE

Requerimientos:
• Tener un espacio para observar el listado actual de variables del WorkSpace.
• Permitir salvar, guardar con otro nombre y cargar un WorkSpace.
• Permitir el borrado de variables en el WorkSpace.
• Permitir la actualización del WorkSpace.
• Permitir re-iniciar el WorkSpace a su estado por defecto.
• Permitir la graficación de las variables del WorkSpace.
• Permitir modificar propiedades de las gráficas como: el título principal y las etiquetas de los ejes coordenados (XYZ).
Type of Test Integración
Hardware Needed PC cliente y PC servidor.
Software Needed JMat – Cliente y JMat – Servidor.
Goal Probar el buen funcionamiento de la interfaz para el manejo del WorkSpace, lo cual incluye: la gestión de archivos para guardar,
salvar y cargar un WorkSpace, la gestión de las variables del WorkSpace y la graficación de las variables del WorkSpace
Graficación de las Variables del WorkSpace
Goal Probar las funcionalidades de JMat relacionadas con la visualización / graficación de diferentes tipos de variables, las cuales se
incluyen: constantes, enteras, flotantes, arreglos, matrices e imágenes. Adicionalmente la modificación de los parámetros de
las gráficas como título general y etiquetas de los ejes.
Test Data Son una serie de comandos compatibles con Matlab y que se digitan en la interfaz de comandos, esto con el fin de obtener
una serie de variables válidas en el WorkSpace del cliente JMat:
$myChar = 'hola';
$myChar1 = 'c';
$myChar2 = $myChar';
$myChar3 = ['hola'; 'bola']
$myInt = int32(34);
$myIntArr = int32([1:25].*[1:25]);
$myIntArr1 = $myIntArr';
 RUP: Functional Tests
Test Data $miDobleArray = sin([1:360/25:360].*(2*pi/180));
$x = [-2: 4/50: 1.98];
$y = $x;
$miDoble2D = getSurfaceFromVectors($x,$y);
$img3 = imread('xray2.jpg');
$myData = get3D(50);
Procedimiento 1. Digitar los comandos compatibles con Matlab mostrados anteriormente en la consola de comandos.
2. Cargar el archivo “xray2.jpg” en el servidor de Matlab.
3. Digitar, grabar y transferir la función compatible con Matlab “getSurfaceFromVectors”.
4. Digitar el nombre de la variable $myInt y mostrar su valor.
5. Digitar el nombre de la variable $myIntArr y mostrar su valor.
6. Digitar el nombre de la variable $myDobleArray y mostrar su valor.
7. Digitar el nombre de la variable $myDoble2D y mostrar su valor.
8. Digitar el nombre de la variable $img3 y mostrar su valor.
9. Digitar, grabar y transferir la función compatible con Matlab “get3D.m”.
10. Digitar el nombre de la variable $myData y mostrar su valor.
Resultado Esperado 1. La gráfica de la variable $myInt es mostrada como una constante en una ventana emergente.
2. La gráfica de la variable $myIntArr es mostrada como una función cuadrática en una ventana emergente.
3. La gráfica de la variable $miDobleArray es mostrada como una función seno en una ventana emergente.
4. La gráfica de la variable $miDoble2D es mostrada como una función en 2D en una ventana emergente.
5. La gráfica de la variable $img3 es mostrada como una imagen en RGB en una ventana emergente.
6. La gráfica de la variable $myData es mostrada como una función 3D en una ventana emergente.
7. Graficar la variable $miDoble2D y modificar sus propiedades como el título de la figura.
8. Graficar la variable $myData y modificar las etiquetas de sus ejes.
 RUP: Functional Tests

Resultado Obtenido Prueba satisfactoria. A continuación se detalla la secuencia de los resultados mostrados en las imágenes:
• Los datos estipulados anteriormente se digitan en la consola de comandos de Matlab, ver figura (a).
• La gráfica de variables enteras es mostrada en la figura (b).
• La gráfica de arreglos de enteros es mostrado en la figura (c).
• La gráfica de arreglos de flotantes es mostrada en la figura (d).
• La gráfica de funciones matriciales en 2D es mostrada en la figura (e).
• La gráfica de imágenes en RGB es mostrada en la figura (f).
• La modificación del título de una gráfica es mostrado en la figura (g).
• La modificación de las etiquetas de los ejes es mostrado en la figura (h).
Comentarios Las pruebas funcionales reportadas aquí no solo verifican el buen funcionamiento de JMat – Cliente, sino de JMat – Servidor,
ya que sin éste último no sería posible obtener alguna respuesta de Matlab en relación a la sintaxis e idoneidad de los
comandos ejecutados.
RUP: Functional Tests

a)
b)
RUP: Functional Tests

d)
c)
RUP: Functional Tests

f)
e)
RUP: Functional Tests

h)
g)
Questions?