Taller de Sistemas de Taller de Sistemas de ProgramasProgramas

http://www.ldc.usb.ve/http://www.ldc.usb.ve/~~gescuela/ci3715.htmlgescuela/ci3715.html

Clase 2Clase 2

Dpto. de Computación y T.I.Dpto. de Computación y T.I.

AgendaAgenda1.1.Revisión Proyecto 1:Revisión Proyecto 1: Conformación Conformación

microempresa, informe, trabajo en equipo.microempresa, informe, trabajo en equipo.2.2.Introducción a RUP y Casos de UsoIntroducción a RUP y Casos de Uso3.3.Asignación Proyecto 2Asignación Proyecto 2

Introducción a RUPIntroducción a RUP Rational Unified ProcessRational Unified Process es un proceso de es un proceso de

Ingeniería de SoftwareIngeniería de Software Asigna actividades y responsabilidades dentro de Asigna actividades y responsabilidades dentro de

una organización de desarrollo una organización de desarrollo Asegura la producción de software de alta calidadAsegura la producción de software de alta calidad Mejora la productividad del equipo de trabajoMejora la productividad del equipo de trabajo Activa, mantiene y crea ModelosActiva, mantiene y crea Modelos Es una guía para usar efectivamente UML Es una guía para usar efectivamente UML

Introducción a Rational Unified Process Introducción a Rational Unified Process

Es soportado por Es soportado por herramientasherramientas, las cuales , las cuales automatizan gran parte del proceso.automatizan gran parte del proceso.

Las herramientas son utilizadas para mantener Las herramientas son utilizadas para mantener los diversos los diversos artefactos artefactos (cualquier producto del (cualquier producto del trabajo) del proceso de Ingeniería de Software: trabajo) del proceso de Ingeniería de Software: modelado visual, programación, pruebas, etc.modelado visual, programación, pruebas, etc.

Es un proceso configurableEs un proceso configurable Captura las Captura las mejores prácticasmejores prácticas en el desarrollo en el desarrollo

de software modernode software moderno

Proceso iterativo e incrementalProceso iterativo e incrementalRequirements

Design

Implementation &Test & Integration

& More Design

Final Integration & System Test

Requirements

Design

3 weeks (for example)The system grows incrementally.

Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration N+1.

Iterations are fixed in length, or timeboxed.

TimeImplementation &Test & Integration

& More Design

Final Integration & System Test

Requerimientos en el tiempoRequerimientos en el tiempoEarly iterations are farther from the "true path" of the system. Via feedback and adaptation, the system converges towards the most appropriate requirements and design.

In late iterations, a significant change in requirements is rare, but can occur. Such late changes may give an organization a competitive business advantage.

one iteration of design, implement, integrate, and test

Requerimientos en el tiempoRequerimientos en el tiempo

Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5

20%2%

requ

irem

ents

softw

are

30%

5%re

quire

men

ts

softw

are

50%

8%

90% 90%

20%10%

requirements workshops

Imagine this will ultimately be a 20-iteration project.

In evolutionary iterative development, the requirements evolve over a set of the early iterations, through a series of requirements workshops (for example). Perhaps after four iterations and workshops, 90% of the requirements are defined and refined. Nevertheless, only 10% of the software is built.

1 2 3 4 5 ... 20

week 1

M T W Th F

week 2

M T W Th F

week 3

M T W Th F

kickoff meeting clarifying iteration goals with the team. 1 hour

team agile modeling & design, UML whiteboard sketching.5 hours

start coding & testing

a 3-week iteration

de-scope iteration goals if too much work

final check-in and code-freeze for the iteration baseline

demo and 2-day requirements workshop

next iteration planning meeting;2 hours

Most OOA/D and applying UML during this period

Use-case modeling during the workshop

Fases de RUPFases de RUP

inc. elaboration construction transition

iteration phase

development cycle

release

A stable executable subset of the final product. The end of each iteration is a minor release.

increment

The difference (delta) between the releases of 2 subsequent iterations.

final production release

At this point, the system is released for production use.

milestone

An iteration end-point when some significant decision or evaluation occurs.

Disciplinas de RUPDisciplinas de RUP

Iterations

SampleUP Disciplines

Business Modeling

Requirements

Design

Implementation

Test

Deployment

Configuration & Change Management

Project Management

Environment

Focus of this book

Note that although an iteration includes work in most disciplines, the relative effort and emphasis change over time.

This example is suggestive, not literal.

A four-week iteration (for example). A mini-project that includes work in most disciplines, ending in a stable executable.

DisciplinasDisciplinas

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

objects, attributes, associations

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

Vision

SupplementarySpecification

Glossary

scope, goals, actors, features

terms, attributes, validation

non-functional reqs, quality attributes

requirements

Process Sale

1. Customer arrives ...2. Cashier makes new sale.3. ...

Ejemplo de artefactos en la fase de inicioEjemplo de artefactos en la fase de inicio

Visión y Análisis del negocioModelo de Casos de UsoGlosarioLista de Riesgos y plan de gestión de riesgosPlan de iteraciónPlan de desarrollo de Software

UML y el proceso de desarrolloUML y el proceso de desarrollo

UML es un lenguaje para especificar, UML es un lenguaje para especificar, visualizar, construir y documentar los visualizar, construir y documentar los artefactos de los sistemas de software, artefactos de los sistemas de software, así como para el modelado del negocio así como para el modelado del negocio y otros sistemas no software (OMG) y otros sistemas no software (OMG)

-- Controlado por los casos de uso Controlado por los casos de uso -- Centrado sobre la arquitectura Centrado sobre la arquitectura -- Iterativo e incrementalIterativo e incremental

Definición del modelo de Definición del modelo de dominio o contextodominio o contexto

Una descomposición del dominio conlleva una identificación de los conceptos, atributos y asociaciones que se consideren significativas.El resultado se puede expresar en un modelo de dominio que se ilustra mediante un conjunto de diagramas que muestran los objetos o conceptos del dominio

Ejemplo Modelo de dominioEjemplo Modelo de dominio

Register

Item

Store

addressname

Sale

date time

Payment

amount

SalesLineItem

quantity

Stocked-in

*

Houses

1..*

Contained-in

1..*

Records-sale-of

0..1

Paid-by

1

1

1

1

1

1

0..1

1

Captured-on

conceptor domain object

association

attributes

Artefactos en el Modelo de DominioArtefactos en el Modelo de DominioDomainModel

Requirements

BusinessModeling

Design

Partial artifacts,refined in each

iteration.

Use-Case Model

textuse

cases

:System

foo( x )

systemoperationcontracts

systemsequencediagrams

bar( y )

usecase

diagrams

**

Design Model

systemoperations

Artefactos en el Modelo de Caso de UsoArtefactos en el Modelo de Caso de Uso

Requirements

Partial artifacts, refined in each iteration.

Use-Case Model

textuse

cases

:System

foo( x )

systemoperationcontracts

systemsequencediagrams

bar( y )

usecase

diagrams

systemoperations

Análisis Diseño y Realización

Prueba

Capturar, clarificar y validar los

C.U.

Realizar los C.U.

Verificar que los C.U. se

satisfagan

Los C.U. señalan las diferentes Los C.U. señalan las diferentes actividades y etapas del procesoactividades y etapas del proceso

Los C.U. forman la unión

Diagrama de Casos de UsoDiagrama de Casos de UsoNextGen POS

Manage Users

. . .

Cashier

SystemAdministrator

actor

use case

communicationsystem boundary

PaymentAuthorization

Service

«actor»Tax Calculator

«actor»Accounting

System

alternatenotation for a computer system actor

«actor»HR System

Cash In

«actor»Sales Activity

System

Manage Security

Analyze Activity

Customer

Manager

Process Sale

Handle Returns

Diagrama de Casos de UsoDiagrama de Casos de Uso

NextGen

Process Sale

. . .Cashier

Show computer system actors with an alternate notation to human actors.

primary actors on the left

supporting actors on the right

For a use case context diagram, limit the use cases to user-goal level use cases.

«actor»Payment

AuthorizationService

Formatos de Caso de Uso (texto)Formatos de Caso de Uso (texto)Formato resumidoFormato resumido El formato resumido se elabora para que sea leido por una persona El formato resumido se elabora para que sea leido por una persona

que participa en el proceso de desarrollo de una forma gerencial o que participa en el proceso de desarrollo de una forma gerencial o por una persona sin los conocimientos técnicos necesarios para por una persona sin los conocimientos técnicos necesarios para entender el formato extendido (Ej: cliente).entender el formato extendido (Ej: cliente).

Caso de uso:Caso de uso: <nombre del caso de uso> <nombre del caso de uso>Actor principal:Actor principal: <nombre del actor iniciador> <nombre del actor iniciador>Expertos e interesados:Expertos e interesados: <nombre del actor interesado 1>, ..., <nombre del actor interesado 1>, ..., <nombre del actor interesado N><nombre del actor interesado N>Descripción:Descripción: <Texto general que describe el caso de uso>. <Texto general que describe el caso de uso>.Frecuencia:Frecuencia: <Frecuencia de ocurrencia del caso de uso> <Frecuencia de ocurrencia del caso de uso>Preguntas abiertas:Preguntas abiertas:

<Pregunta abierta 1> <Pregunta abierta 1> ... ... <Pregunta abierta N><Pregunta abierta N>

Formatos de Caso de Uso (texto)Formatos de Caso de Uso (texto)Formato expandidoFormato expandido Describe todas las implicaciones técnicas del caso de uso. Está dirigido a los desarrolladores o Describe todas las implicaciones técnicas del caso de uso. Está dirigido a los desarrolladores o

mantenedores del sistema.mantenedores del sistema. Caso de uso:Caso de uso: <nombre del caso de uso> <nombre del caso de uso>

Actor principal:Actor principal: <nombre del actor iniciador> <nombre del actor iniciador>Expertos e interesados:Expertos e interesados:   <nombre del actor interesado 1>: <proceso donde está involucrado>.   <nombre del actor interesado 1>: <proceso donde está involucrado>.   ...   ...   <nombre del actor interesado N>: <proceso donde está involucrado>.   <nombre del actor interesado N>: <proceso donde está involucrado>.Precondiciones:Precondiciones: (premisas que deben ser ciertas antes de la ejecución del caso)(premisas que deben ser ciertas antes de la ejecución del caso)   <Precondición 1>   <Precondición 1>   ...   ...   <Precondición N>   <Precondición N>Éxito garantizado (Poscondiciones):Éxito garantizado (Poscondiciones): (establece lo que debe cumplirse en caso de haber sido (establece lo que debe cumplirse en caso de haber sido completado el curso principal o algún curso alterno exitoso)completado el curso principal o algún curso alterno exitoso)   <Precondición 1>   <Precondición 1>   ...   ...   <Precondición N>   <Precondición N>Escenario principal de éxito (Curso básico):Escenario principal de éxito (Curso básico): (describe el curso típico que satisface el interés (describe el curso típico que satisface el interés de los relacionados con el caso de uso. Tres tipos de paso: interacción entre actores, de los relacionados con el caso de uso. Tres tipos de paso: interacción entre actores, validaciones y cambios al sistema)validaciones y cambios al sistema)  Actor 1 SistemaActor 1 Sistema 1.  1.

Paso 1    Paso 1    Paso 2 Paso 2  Paso 3 Paso 3 

Formatos de Caso de Uso (texto)Formatos de Caso de Uso (texto)Extensiones (Cursos alternos):Extensiones (Cursos alternos): (indican otros escenarios tanto de éxito como de falla)(indican otros escenarios tanto de éxito como de falla)

   3a) <error>:   3a) <error>:      1. Paso 1      1. Paso 1      2. Paso 2      2. Paso 2   3b) <error>:   3b) <error>:      1. Paso 1      1. Paso 1      2. Paso 2      2. Paso 2Requerimientos especiales:Requerimientos especiales: (requerimientos no funcionales relacionados con el caso de uso)(requerimientos no funcionales relacionados con el caso de uso)

<Requerimiento 1> <Requerimiento 1> ... ... <Requerimiento N> <Requerimiento N> Tecnología y lista de variaciones de datos:Tecnología y lista de variaciones de datos: (detalles técnicos que deben ser considerados)(detalles técnicos que deben ser considerados) <Detalle técnico 1> <Detalle técnico 1> ... ... <Detalle técnico N> <Detalle técnico N> Frecuencia:Frecuencia: <Frecuencia de ocurrencia del caso de uso> <Frecuencia de ocurrencia del caso de uso>

Preguntas abiertas:Preguntas abiertas: <Pregunta abierta 1> <Pregunta abierta 1> ... ... <Pregunta abierta N> <Pregunta abierta N> Referencias cruzadas:Referencias cruzadas: <Número de requerimiento funcional relacionado 1>, ..., <Número de <Número de requerimiento funcional relacionado 1>, ..., <Número de

requerimiento funcional relacionado N>requerimiento funcional relacionado N>

Proyecto IIProyecto II

Aplicación Web de avisos clasificados gratuitos para la comunidad de la USB

RecursosRecursos Craig Larman: Applying UML and Patterns: An Craig Larman: Applying UML and Patterns: An

Introduction to Object-Oriented Analysis and Introduction to Object-Oriented Analysis and Design and Iterative Development. 2005. Design and Iterative Development. 2005. http://www.craiglarman.com/book_applying/applying.htmhttp://www.craiglarman.com/book_applying/applying.htm