Istituto di Scienza e Tecnologie dell'Informazione “A. Faedo” Software Engineering Laboratory...

Istituto di Scienza e Tecnologie dell'Informazione “A. Faedo”Software Engineering Laboratory

The Unified Modeling LanguageAn Introduction

Dott.ssa Eda Marchetti

SEL-LAB ISTI

SOFTWARE ENGINEERING LABORATORY

ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE

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



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.”



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.



UML 1.1



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



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” ).



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.



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



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



Torniamo a UML




Modello???

» Cosa è un modello?» Quali/Quanti tipi?» A cosa servono i modelli?



Dallo sviluppatore

Vorrei una macchina per

il caffè

Cliente

?



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...)



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 è utile allo sviluppatore?

» E’ possibile avere un modello unico per tutto?



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)



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



Le parole chiavi di UML


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.



The Unified Modeling Language


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).



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



UML concetti base

» Diagrams» Views » Extension Mechanisms



Diagrammi

UML 2 definisce 13 diagrammi (contro i 9 di UML 1.x), divisi in categorie:

diagrammi “strutturali”:» diagramma delle classi (class)» diagramma degli oggetti (object)» diagramma dei componenti (component)» diagramma delle strutture composite (composite structure)» diagramma di deployment (deployment)» diagramma dei package (package)

diagrammi “comportamentali di interazione”:» diagramma di sequenza (sequence)» diagramma di comunicazione (communication)» diagramma dei tempi (timing)» diagramma di sintesi dell’interazione (interaction overview)

diagrammi “comportamentali”:» diagramma dei casi d’uso (use case)» diagramma di stato (statechart)» diagramma delle attività (activity)



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: its static structure and dynamic interactions;

» Non functional: timing requirements, reliability, deployment;

» Organizational aspects: work group organization, mapping to code modules.



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).



4+1 Views

Use Case View

Implementation View Logical View

Deployment View Process View



Use Case View

Use Case ViewUse 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.



Logical View

Logical ViewLogical 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



Implementation ViewImplementation View is a description of the main modules and their dependencies Used by developers

Component diagram

Implementation View



Process ViewProcess 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

Process View



Deployment ViewDeployment View shows the physical deployment of the system, such as the computers and devices (nodes) and how they connect to each otherUsed by developers and testers

Deployment diagram

Deployment View



Riassumendo



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



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



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



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



General schema

Each iteration results in

executable release

The general schema of an iterative process: Barry W. Boehm, “A spiral model of Software Development and Enhancement”. IEEE Computer, May 1988.



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.



RUP overview

RUP is characterized by:» A static structurestatic 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



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



Roles distribution

Resources Role Activities

Paul Designer System design

Mary Designer Use case design

Design reviewer Review the design

Test designer Define test approach

Bob Design reviewer Review the design

Test designer Structure the test implementation



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

Worker

Artifacts

Activities



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



Workflow – Analysis and Design



Summing up - process framework



RUP overview

RUP is characterized by:» A static structure describing the process

(who is doing what, how and when)» A dynamic structuredynamic 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



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



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



Product evolution

Unless the product "dies," it evolves into its next generation by repeating the same sequence of inception, elaboration, construction and transition phases



Phases structure – general schema

Evolution Cycle

Emphasis of the various types of activities over time



In un determinato momento











Phases description - Inception

» 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

Inception Elaboration

Construction

Transition



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.



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.




• 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)




• 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.



Phases description - Elaboration

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


Construction

Transition



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 end-users

» To establish a supporting environment




• 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)




• 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)




• 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




• 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



Phases description - Construction

» 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.


Construction

Transition



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




• 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 analyzes the results



Phases description - 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.


Construction

Transition



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



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

Date post:	03-May-2015
Category:	Documents
Upload:	amando-de-rosa
View:	213 times
Download:	0 times

Istituto di Scienza e Tecnologie dell'Informazione “A. Faedo” Software Engineering Laboratory...

Documents