La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Istituto di Scienza e Tecnologie dell'Informazione “A. Faedo” Software Engineering Laboratory The Unified Modeling Language An Introduction Dott.ssa Eda.

Presentazioni simili


Presentazione sul tema: "Istituto di Scienza e Tecnologie dell'Informazione “A. Faedo” Software Engineering Laboratory The Unified Modeling Language An Introduction Dott.ssa Eda."— Transcript della presentazione:

1 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

2 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE Calendario 25/11/ Introduzione al Corso, UML e Processo di Sviluppo (Eda Marchetti) 26/11/ Use Case Diagram (Eda Marchetti) 27/11/ Sequence Diagram (Antonino Sabetta 30/11/ Activity Diagram (Antonino Sabetta) 3/12/ Class Diagram - 1a Parte (Guglielmo De Angelis) 4/12/ Class Diagram - 2a Parte (Guglielmo De Angelis) 10/12/2009 – Esercitazione 11/12/ Esercitazione

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

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

5 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE UML 1.1

6 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 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

7 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE UML 1.4 UML 1.4 rilasciata nel 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” ).

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

9 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

10 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

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

12 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE Modello??? » Cosa è un modello? » Quali/Quanti tipi? » A cosa servono i modelli?

13 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE Dallo sviluppatore Vorrei una macchina per il caffè Cliente ?

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

15 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 è utile allo sviluppatore? » E’ possibile avere un modello unico per tutto?

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

17 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

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

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

20 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

21 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE UML concetti base » Diagrams » Views » Extension Mechanisms

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

23 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: its static structure and dynamic interactions; » Non functional: timing requirements, reliability, deployment; » Organizational aspects: work group organization, mapping to code modules.

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

25 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE 4+1 Views Use Case View Implementation View Logical View Deployment ViewProcess View

26 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE Use Case View 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.

27 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE Logical View 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

28 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 Implementation View

29 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 Process View

30 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 Deployment View

31 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE Riassumendo

32 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

33 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

34 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

35 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

36 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE 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.

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

38 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE RUP overview RUP is characterized by: static structure » 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

39 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

40 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE Roles distribution ResourcesRoleActivities PaulDesignerSystem design MaryDesignerUse case design Design reviewerReview the design Test designerDefine test approach BobDesign reviewerReview the design Test designerStructure the test implementation

41 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 Worker Artifacts Activities

42 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

43 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE Workflow – Analysis and Design

44 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE Summing up - process framework

45 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) dynamic structure » 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

46 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

47 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

48 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

49 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

50 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE In un determinato momento

51 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE

52 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE

53 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE

54 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE

55 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE 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 InceptionElaborationConstructionTransition

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

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

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

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

60 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE 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 InceptionElaborationConstructionTransition

61 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 end- users »To establish a supporting environment

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

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

64 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

65 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

66 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE 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. InceptionElaborationConstructionTransition

67 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

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

69 SOFTWARE ENGINEERING LABORATORY ISTITUTO DI SCIENZA E TECNOLOGIE DELL’INFORMAZIONE 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. InceptionElaborationConstructionTransition

70 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

71 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


Scaricare ppt "Istituto di Scienza e Tecnologie dell'Informazione “A. Faedo” Software Engineering Laboratory The Unified Modeling Language An Introduction Dott.ssa Eda."

Presentazioni simili


Annunci Google