Post on 13-Mar-2016
description
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