Istituto di Scienza e Tecnologie dell'Informazione “A. Faedo”
Software Engineering Laboratory
The Unified Modeling Language
An Introduction
Dott.ssa Eda Marchetti
SEL-LAB ISTI
Calendario
25/11/2009 - Introduzione al Corso, UML e Processo di Sviluppo
(Eda Marchetti)
26/11/2009 - Use Case Diagram (Eda Marchetti)
27/11/2009 - Sequence Diagram (Antonino Sabetta
30/11/2009 - Activity Diagram (Antonino Sabetta)
3/12/2009 - Class Diagram - 1a Parte (Guglielmo De Angelis)
4/12/2009 - Class Diagram - 2a Parte (Guglielmo De Angelis)
10/12/2009 – Esercitazione
11/12/2009 - Esercitazione
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
The Unified Modeling Language
“UML is a modeling language to specify,
visualize, manage and document all the
phases and aspects of a software development
process.”
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Un po’ di storia
»
Primi linguaggi di modellazione:
»
»
»
comparsi a metà degli anni 70 e la fine degli anni 80
vari esperimenti per la progettazione Object-Oriented.
Tra il 1989 e il 1994:
»
»
»
da 10 a più di 50
Ognuno caratteristiche specifiche
I metodi più diffusi:
»
»
»
Booch’93 di Booch,
OMT-2 (Object Modelling Technique) di Rumbaugh
OOSE (Object-Oriented Software Engineering) di Jacobson.
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
UML 1.1
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
UML 1.2 e 1.3
»
»
»
La versione 1.2 venne resa disponibile dalla OMG nel
Luglio del 1998. ma non fu mai ufficialmente approvata,
poiché non apportava solo cambiamenti sintattici.
Nel 1999 UML 1.3: era una revisione dell 1.1 in base ai
commenti ricevuti da parte della Revisions Task Force
(RTF)
Principali modifiche:
»
»
»
»
Aggiunti gli stati di sync per la sincronizzazione di attività concorrenti
Ridefinite le relazioni dei casi d’uso: generalizzazione, include ed
estende
Viene aggiunta la specifica di XMI 1.0.
Nei diagrammi di collaborazione e di sequenza, vengono distinte due
forme: la forma descrittore e la forma istanza
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
UML 1.4
UML 1.4 rilasciata nel 2001.
Principali aggiunte:
» Vincoli nei diagrammi di collaborazione
» Definiti anche gli artefatti per specificare i
componenti fisici (file sorgenti, file eseguibili, e
script) che implementano i componenti.
» Aggiunta la visibilità di package (simbolo “ ~ ”)
e la proprietà di ordinamento per gli attributi
(“ordinati” o “non ordinati” ).
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
UML 1.5
UML 1.5 rilasciata nel 2003
Principali aggiunte:
»
»
»
»
aggiunta della semantica delle Azioni:
azione primitiva: non può essere decomposta in altre
azioni (funzioni matematiche, azioni che lavorano su
oggetti in memoria, scambio di messaggi ecc).
Una procedura è gruppo di azioni con un input e un
output.
Definizione del flusso di dati o da flusso di controllo.
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
UML 2.0
»
»
»
agosto 2005 : UML 2.0
aprile 2006: UML 2.1
maggio 2008: UML 2.2
UML 2.0: non una semplice correzione e
evoluzione delle specifiche precedenti, ma
una vera e propria nuova specifica
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
UML 2.0: Principali Novità
»
»
»
»
»
»
»
»
»
»
»
»
Potenziata l’estensione nei casi d’uso
Potenziati i diagrammi di classe
Nuova visualizzazione delle interfacce
Definiti i Gruppi di Generalizzazioni
Aggiunti i Frammenti Combinati nei Diagrammi di Sequenza
Nuovi vincoli temporali nei Diagrammi di Sequenza
Aggiunti i Diagrammi Temporali
Diagrammi di Collaborazione vengono rinominati in Diagrammi di
Comunicazione
Nuova grafica per i Componenti
Le azioni vengono integrate nei diagrammi di attività
Nuova gestione delle Eccezioni
Aggiunte le Regioni di Espansione per raggruppare le azioni
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Torniamo a UML
“UML is a modeling language to specify,
visualize, manage and document all the
phases and aspects of a software development
process.”
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Modello???
»
»
»
Cosa è un modello?
Quali/Quanti tipi?
A cosa servono i modelli?
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Dallo sviluppatore
Vorrei una
macchina per il
caffè
?
Cliente
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Scelta di un modello
»
la scelta del modello da usare dipende
»
»
»
»
»
dal problema che si vuole risolvere
da cosa è richiesto essere messo in evidenza per
raggiungere una soluzione accettabile
modelli esprimibili a differenti livelli di precisione
connessione col mondo reale
vari piccoli modelli correlati (o quasi...)
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Vari livelli di dettaglio
I linguaggi di programmazione sono a tutti gli effetti
dei modelli imperativi/dichiarativi con i quali
“programmate” quotidianamente
»
Ma sono utili con il cliente?
»
E la
»
E’ possibile avere un modello unico per tutto?
è utile allo sviluppatore?
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
I molteplici aspetti di un sistema
»
»
Non è realistico che un singolo
modello/diagramma catturi tutte le
informazioni necessarie per la descrizione di un
software
un sistema (software) espone sempre
molteplici aspetti che devono essere trattati
appositamente:
»
»
»
funzionale
extra-funzionale
aspetti organizzativi (tecnologici e non)
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
I modelli in UML
»
I modelli UML come forma di:
»
»
»
»
programmazione
controllo dell'evoluzione del software
trasformazione automatica (a più livelli e con
“iniezione” di informazioni) dai modelli di
business ai modelli implementativi
altre motivazioni
»
»
»
ridefinire/ristrutturare modelli
reverse engineering
generazione di nuove viste
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Le parole chiavi di UML
“UML is a modeling language to specify, visualize, manage and
document all the phases and aspects of a software development
process.”
specify the system communicating what to do
in terms of requirements to be realized.
»
»
Creating a diagram to trace analysis and design
phases
Using a diagram to discuss about analysis and
design model
visualize the system showing it after its
effective realization.
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
The Unified Modeling Language
“UML is a modeling language to specify, visualize, manage and document all the
phases and aspects of a software development process.”
manage the system driving its construction phases.
»
Round Trip approach: generating code from the
model and bringing back to model the new
modifications.
document the system with expressiveness,
compactness and consistency during all its life cycle (to
replace textual documentation).
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
I modelli UML come forma di progettazione
»
il vero contributo di UML (come ogni altro
linguaggio di modellazione) è nella visione di
migliorare il processo di sviluppo del software
attraverso fasi di raffinamento AUTOMATICHE
»
i diagrammi UML devono essere la base per :
»
»
»
generare skeletons da modelli
generare codice a partire da pattern di esecuzione
risalire a modelli da pattern di codice
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
UML concetti base
» Diagrams
» Views
» Extension
Mechanisms
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Diagrammi
UML 2 definisce 13 diagrammi (contro i 9 di UML 1.x), divisi in categorie:
diagrammi “strutturali”:
»
»
»
»
»
»
diagramma
diagramma
diagramma
diagramma
diagramma
diagramma
delle classi (class)
degli oggetti (object)
dei componenti (component)
delle strutture composite (composite structure)
di deployment (deployment)
dei package (package)
diagrammi “comportamentali di interazione”:
»
»
»
»
diagramma
diagramma
diagramma
diagramma
di sequenza (sequence)
di comunicazione (communication)
dei tempi (timing)
di sintesi dell’interazione (interaction overview)
diagrammi “comportamentali”:
»
»
»
diagramma dei casi d’uso (use case)
diagramma di stato (statechart)
diagramma delle attività (activity)
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
The Views
»To
model complex systems not describable
from a unique point of view.
»A system is described with a number of
different aspects:
»
Functional:
interactions;
its
static
»
Non functional:
deployment;
»
Organizational aspects: work group organization,
mapping to code modules.
timing
structure
and
dynamic
requirements,
reliability,
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
The Views
»The
system is described by a number of views each
representing a particular aspects of it.
»Each view is described in a number of diagrams
containing information that emphasizes a particular
characteristic of the system.
»(Multiple
viewpoints comes from OO methodologies).
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
4+1 Views
Implementation View
Logical View
Use Case View
Deployment View
Process View
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Use Case View
Use Case View describes the functionality the system
should deliver, as perceived by external actors
Used by customers, managers, analysts, designers,
developers and testers
»
»
»
Use Case diagram
Activity diagram
Sequence diagram
»The
Use Case View is central and its content drives the
development of the other views;
»Final goal of the system: providing the functionalities
described in this view.
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Logical View
Logical View describes how the system
functionalities are provided
»Used by analysts, designers, developers.
»It looks inside the system, describing the static
structure and dynamic collaborations:
»
»
»
Interactions diagrams
Class diagrams
Activity e State diagrams
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Implementation View
Implementation View is a description of the
main modules and their dependencies
 Used by developers
 Component diagram
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Process View
Process View deals with the division of the system into
processes and processors
Used by developers and system integrators.

It treats a non functional characteristic of the system used for:
 efficient resource usage,
 parallel execution
 handling of asynchronous events from the environment:



Activity e State diagrams
Interaction and Deployment diagrams
Timing diagrams
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Deployment View
Deployment
View
shows the physical
deployment of the system, such as the
computers and devices (nodes) and how they
connect to each other
Used by developers and testers

Deployment diagram
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Riassumendo
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
UML e il processo di sviluppo
UML è solo una notazione standard
» Non specifica affatto il processo, cioè il modo
in cui deve essere usata la notazione
» UML è più efficace se viene esplicitamente
combinato con un processo di sviluppo
» Gli inventori di UML raccomandano la sua
combinazione con RUP - Rational Unified
Process
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Unified Sw Development Process
»
»
»
Jacobson propose all’inizio degli anni 90 un metodo
per progettazione ad oggetti chiamato Objectory
Nel 1996 Objectory venne scelto da Rational come
processo per UML col nome USDP;
In seguito Rational mise il copyright su questo
processo col nome di RUP - Rational Unified
Process
Nel 2001 IBM ha comprato Rational e continua a
supportare RUP™, che oggi a volte viene chiamato
UP. Dunque
Objectory = USDP = RUP™ = UP
»
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Introduction - RUP
A Web-enabled software engineering process that
improves team productivity and delivers software best
practices to all team members
» makes the process practical by providing an extensive
guidelines, templates, and examples
» Is a customizable framework, which can be adapted
to the different organization exigencies and guides the
user in the use of UML for managing the process
development
» Is supported by tools (tightly integrated with IBM
tools), which automate large parts of the process and
allow development teams go gain the benefits of the
UML and other industry best practices
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Best Practices
Suggests some guidelines for process
development summarize in six best practices:
Develop Software Iteratively
» Manage Requirements
» Use Component-Based Architectures
» Visually Model Software
» Verify Software Quality
» Control Changes to Software
»
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
General schema
The general schema of an iterative process:
Barry W. Boehm, “A spiral model of Software Development and Enhancement”. IEEE Computer, May 1988 .
Each iteration
results in
executable release
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Use Component-Based Architectures
»
A Component Base Development (CBD) permits to:
»
»
»
»
Assembly the software from manageable modules
Reuse or customize the existing components
Reuse the commercially available components
Each iteration produces an executable architecture
that can be measured tested, and evaluated against
the system’s requirements.
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
RUP overview
RUP is characterized by:
» A static structure that describes the
process (who is doing what, how and when)
» A dynamic structure that details how the
process rolls out over time
» An Architecture-centric process that defines
and details the architecture
» A Use-Case Driven Process which specifies
how use cases are used throughout the
development cycle
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
The Static Structure
RUP is presented by four primary modeling element:
» Workers: any individual (or a group of individuals)
performing a role is a worker (Who)
» Activities: express the workers behavior. To each worker is
associated a set of activities (How)
» Artifacts: represent the responsibilities of each worker. A
worker creates, modifies or controls different artifacts (What)
» Workflows: a sequence of activities that produces a result of
observable value (When)
Additional process elements: are added to activities or
artifacts to make the process easier to understand
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Roles distribution
Resources
Role
Activities
Paul
Mary
Designer
Designer
Design reviewer
Test designer
Design reviewer
Test designer
System design
Use case design
Review the design
Define test approach
Review the design
Structure the test
implementation
Bob
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Workers – Example The worker Designer: defines the responsibilities, operations,
attributes, and relationships of one or more classes and
determines how they should be adjusted to the
implementation environment
Activities
Artifacts
Worker
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Core Workflows – Model Association
»
»
Each core workflow has associated with it one or more models,
which are in turn composed of associated artifacts.
The most important artifacts are the models that each core workflow
yields: use-case model, design model, implementation
model, and test model
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Workflow – Analysis and Design
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Summing up - process framework
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
RUP overview
RUP is characterized by:
» A static structure describing the process (who
is doing what, how and when)
» A dynamic structure describing how the
process rolls out over time
» An Architecture-centric process that defines
and details the architecture
» A Use-Case Driven Process which how use
cases are used throughout the development
cycle
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Dynamic Structure
RUP is an iterative process organized in four different
phases:
» Inception: Specifies the end-product vision and defines
the scope of the project
» Elaboration: Plans the necessary activities and required
resources
» Construction: Builds the product, evolves the
architecture, the plans until the product is ready for
delivery
» Transition: Transitions the product to its users, which
includes manufacturing, delivering, training…
Every phase ends with a milestone, i.e. a point in time where goals
have to be reached and critical decisions must to be made
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
RUP Phases
»
»
The four phases constitute a development Cycle and
produce a software generation
The software development starts with an initial development
cycle and evolves in new software generation with evolution
cycle
»
The evolution cycle can be triggered by user-suggest
enhancements, changes in the user’s contest or in the
underlining technology an so on
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Product evolution
Unless the product "dies," it evolves into its
next generation by repeating the same
sequence of inception, elaboration,
construction and transition phases
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Phases structure – general schema
Evolution
Cycle
Emphasis of the various types of activities
over time
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
In un determinato momento
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Phases description - Inception
Inception
»
»
»
Elaboration
Construction
Transition
Goal: to achieve concurrence among all stakeholders
on the lifecycle objectives for the project
is particularly important for new development efforts,
in which there are significant business and
requirements risks which must be addressed before
the project can proceed.
It is not a requirement phase; rather it is a kind of
feasibility phase where just enough investigation is
done to support a decision to continue or to stop
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Inception Phase - Objectives
»
Establish the project scope and boundary conditions, including
an operational vision, acceptance criteria and what is intended
to be in the product and what is not
»
Discriminate the critical use cases of the system, the primary
scenarios of operation
»
Exhibit, and maybe demonstrate, at least one candidate
architecture against some of the primary scenarios
»
Estimate the overall cost and schedule for the entire project
»
Estimate potential risks (the sources of unpredictability)
»
Prepare the supporting environment for the project.
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Brief workflows description
• The stakeholders (customers,
manager, etc) work with the system
analysts to define the scope of the
project
• The system analysts:
• collect stakekholder's opinions
about what the system should
• sketch an initial outline of the
system use-case model (artifact
Use-Case Model)
• The constraints on the development
project (platforms, interfaces) are also
considered.
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Brief workflows description
• The stakeholders (customers,
manager, etc) work with the business
designer to:
• prepare the business case, based
on the early sketches of the vision
(artifact Business Case )
• Define an initial glossary to simplify
the use case model and keep it
consistent (Artifact Glossary)
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Brief workflows description
• The risk list is defined taking into
account business risks (artifact Risk
list)
• The project manager builds:
• a phase plan showing tentative
date for inception elaboration,
construction and transition along
with the major milestones.
• A software development plan
based on the prioritized use cases
and associated risks (artifact
Software development plan).
• A tentative set of iterations with
objectives for each iteration.
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Phases description - Elaboration
Inception
Elaboration
Construction
Transition
The elaboration Phase is the most critical phase of each evolution
cycle
» Goal: to baseline the architecture of the system and provide a
stable basis for the bulk of the design and implementation effort
in the construction phase
» The architecture evolves out of a consideration of the most
significant requirements (those that have a great impact on the
architecture of the system) and an assessment of risks
» It is not the requirements or design phase; rather, it is a phase
where the core architecture is iteratively implemented, and
high risk issues are mitigated
» The stability of the architecture is evaluated through one or more
architectural prototypes
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Elaboration Phase - Objectives
»
To ensure that the architecture, requirements and plans are
stable enough, and the risks sufficiently mitigated to determine
the cost and schedule for the development completion.
»
To address all architecturally significant risks of the project
To establish a baseline architecture, expressed with significant
scenarios, which will support the system requirements at a
reasonable cost and time
To produce prototypes to mitigate specific risks such as:
design/requirements trade-offs; components reuse; product
feasibility or demonstrations to investors, customers, and endusers
To establish a supporting environment
»
»
»
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Brief workflows description
• The project manager:
• works with the architects for
evaluating the architectural risks
(artifact Risk List)
• Define an iteration plan for the
current iteration (artifact
Iteration Plan)
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Brief workflows description
• The architects with project manager
determine which UCs and scenarios should
be focused on this iteration. The UCs and
scenarios will drive the development of the
architecture
• The use-case specifies describe some of the
selected UCs and scenarios in details: high
priority to the most critical and most complex
• System analysts restructure these UCs and in
case modify the Use Case Model (artifact Use
case Model)
• The user interface designer, using the
selected UCs, develop a user-interface
prototype to get feedback from prospective
users (artifact User-interface Prototype)
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Brief workflows description
• architect considers the system requirement,
the UC view and team’s general domain
knowledge to outline the subsystem (artifact
Software architect document).
• designers find classes or objects for the UCs
or scenarios of this iteration. Responsibilities
to the identified classes, relationships and
attributes are identified.
• architect identifies the classes that are
considered architecturally significant,
organizes them in design packages and
relates them to the subsystems (artifact
Design model).
• designers instantiate the classes into objects
• architect analyzes the concurrency required
by the system by using the UCs designed
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Brief workflows description
• System integrator defines the order in
which the UCs must be implemented
(artifact Project plan).
• designers plans the system tests and
the integration test (artifact Test Plan).
• Test designer implements test cases and
test procedures
• System integrator incrementally
integrates the subsystem into an
executable architectural prototype. Each
build is tested.
• Successively the system tester tests the
system
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Phases description - Construction
Inception
»
»
»
Elaboration
Construction
Transition
Goal: clarifying the remaining requirements and
completing the development of the system based upon
the baseline architecture.
is a manufacturing process, where emphasis is placed
on managing resources and controlling operations to
optimize costs, schedules, and quality.
Is a transition from the development of intellectual
property during inception and elaboration, to the
development of deployable products during
construction and transition.
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Construction Phase – Objectives
»
»
»
»
»
Minimizing development costs by optimizing resources and
avoiding unnecessary scrap and rework.
Achieving adequate quality as rapidly as practical
Achieving useful versions (alpha, beta, and other test
releases) as rapidly as practical
To iteratively and incrementally develop a complete product
that is ready to transition to its user community. This implies
describing the remaining use cases and other requirements,
fleshing out the design, completing the implementation, and
testing the software
To decide if the software, the sites, and the users are all
ready for the application to be deployed
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Brief workflows description
• The designer identifies the functionalities that
will be tested together and the stubs and
drivers that must be developed to support the
integration test
• The implementer designs unit tests that
address what the unit does (black box test) and
how it does it (white box test).
• The implementer integrates the subsystem
incrementally from the bottom and the tester
executes the tests.
• The system integrator incrementally adds
subsystems and creates a build that the
integration tester tests with integration testing.
• Once the whole system has been integrated the
system tester tests the system and the
designer
analyzesLABORATORY
the results
SOFTWARE ENGINEERING
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Phases description - Transition
Inception
»
»
»
Elaboration
Construction
Transition
Goal: The focus of the Transition Phase is to ensure
that software is available for its end users.
The Transition Phase can span several iterations, and
includes testing the product in preparation for release,
and making minor adjustments based on user
feedback.
By the end of the Transition Phase the project should
be in a position to be closed out. In some cases, the
end of the current life cycle may coincide with the start
of another lifecycle on the same product, leading to the
next generation or version of the product.
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Transition Phase – Objectives
To ensure that software is available for its end users.
» beta testing to validate the new system against user
expectations
» beta testing to validate the new system against user
expectation
» parallel operation relative to a legacy system that it's
replacing
» converting operational databases
» training of users and maintainers
» roll-out to the marketing, distribution and sales forces
» tuning activities such as bug fixing, enhancement for
performance and usability
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE
Transition Phase – Milestone
The transition phase ends with the Product Release Milestone.
At this point, is necessary to decide if the objectives were met,
and if should start another development cycle. In some cases
this milestone may coincide with the end of the inception
phase for the next cycle.
At the Product Release Milestone, the product is in production
and the post-release maintenance cycle begins. This may
involve starting a new cycle, or some additional maintenance
release
The evaluation criteria are:
» The user is satisfied
» Actual resources expenditures versus planned expenditures
are acceptable
SOFTWARE ENGINEERING LABORATORY
ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE