Ingegneria del Software. Business Object Technology

Transcript

1 Ingegneria del Software Business Object Technology Premesse I sistemi informativi di qualsiasi organizzazione devono essere capaci di: gestire quantità di dati sempre crescenti fornire supporto a nuovi servizi e processi di business Uno scenario New Business Strategy Marketing Department New System Requirements New Data to Manage IT Department

2 Approccio tradizionale: Applicazioni Stand-Alone Sviluppo di un sistema per ogni classe di servizi da supportare Accrescimento nel tempo delle responsabilità del sistema fino a che non se ne rendeva necessaria la sostituzione Realizzazione di un sistema informativo ad hoc per le esigenze del momento o che si prevedono nell immediato futuro Conseguenze Più sistemi operanti contemporaneamente e con sovrapposizione di responsabilità Duplicazione dei dati con problemi di consistenza Difficoltà di manutenzione e sviluppo

3 Nuovo approccio: Component-Based Systems Sistemi in grado di permettere l accesso ad un set integrato di servizi e/o basi di dati Disponibilità di tecnologie di supporto CORBA J2EE EJB DCOM/COM+ Web Services Definizione: Business Object A Business Object is defined as a representation of a thing active in the business domain, including at least it s business name and definition, attributes, behavior, relationships, rules, policies and constraints. A BO may represent, for example, a person, place, event, business process or concept. Typical examples of business objects are: employee, product, invoice and payment. Documento OMG cf/

4 Business Object (Component) Vision is the concept of a distributed system containing a cloud of Business Objects. They cooperate at different times and in different combinations to perform business processes, and different combinations of business objects can be recombined dynamically at runtime. We can also dynamically introduce new business objects in the run time scenario... Oliver Sims Business Object Vision Essence Process Business Object 1 Business Object 2 4 New Process Business Object BPR New Business Object 3

5 Una prospettiva di sviluppo della Business Object Vision Real World Analysis Design Construction Deployment Run Time Methodology Meta Models Languages Code Libraries Modularization Packaging Infrastructure Operating System Product Specification Language Models Programming Configuration Product Place Order Place Order Definizione: Componente Un componente è una unità software reale che raggruppa un BO con tutto ciò che è necessario a completarlo (classi tecniche, utility, framework, ) E una unità allocabile ed eseguibile indipendentemente Analysis Design Construction Deployment Run Time T F Business Concept U Business Object Distributable Component T U

6 Definizione: Middleware E l infrastruttura tecnologica che supporta il plug&play dei componenti e la loro interazione a runtime Distributable Component Distributable Component Distributable Component Distributable Component Business Object Business Object Business Object Business Object Middleware Sommario Business Objects come concetti di business Una visione di Business Objects interoperabili, capaci di plug&play, che interagiscono dinamicamente a runtime per supportare i processi di business I Componenti come implementazioni di Business Objects I Middleware come infrastruttura tecnologica di supporto ai Componenti distribuibili

7 Sviluppo di un sistema software: obiettivi Consegnare in tempo Le nuove opportunità di business possono essere catturate solo se il sistema viene adeguato in tempo Ottenere un elevato grado di qualità Una maggiore qualità implica una maggiore competitività Rispettare il budget Ottenere una elevata riusabilità dei componenti software sviluppati Un forte riuso dei componenti software consente di adeguare velocemente e ad un minore costo il sistema per le nuove esigenze Approccio tradizionale (Object Oriented): Limiti Le applicazioni tradizionali: Sono isole Sono difficili da manutenere Non si integrano Sono monoliti Impongono confini artificiali Sono orientate alle funzioni Duplicano i concetti Sono resistenti ai cambiamenti Offrono uno scarso livello di riuso

8 Due casi studio Applicazione per la prenotazione di autovetture L applicazione permette la prenotazione di autovetture da parte dei clienti di un tour operator Applicazione per la prenotazione di appartamenti L applicazione permette la prenotazione di appartamenti da parte dei clienti di un tour operator Le applicazioni classiche sono isole Le applicazioni vengono sviluppate come due programmi eseguibili distinti Applicazioni Vista Utente Isole

9 Le applicazioni classiche sono difficili da manutenere Una operazione di manutenzione evolutiva richiede che sia ri-compilata, ri-testata, e rimessa in esercizio l intera applicazione Modifica Modify Re-Build Re-Test Re-Deploy Le applicazioni classiche non si integrano Non consentono il riuso dei componenti (non sono progettate per farlo) L integrazione richiederebbe la disponibilità del codice sorgente e l adattamento da entrambi i lati

10 Le applicazioni classiche sono monolitiche L incapacità di integrarsi, rende le applicazioni classiche dei monoliti perché l unica possibilità di aggiungere nuove funzionalità è quella di incorporarle New functions Le applicazioni classiche costituiscono un deliverable artificiale I concetti di business rilevati in fase di cattura dei requisiti sono modellati con delle classi in fasi di analisi, ma ne viene persa traccia in fase di constraction quando vengono integrati nell applicazione che è vista a quel punto come una black box Requirements Capture Analysis Design Construction Run Time

11 Le applicazioni classiche duplicano i concetti I concetti, e a volte i dati, possono essere duplicati nel caso di applicazioni tradizionali Process Duplication Concept Duplication Data Duplication Le applicazioni classiche... Impongono confini artificiali L utente è invitato a pensare alle business things così come proposto dall applicazione sono function oriented I processi di business non sono espliciti bensì incapsulati nell applicazione sono resistenti ai cambiamenti perché sono isole, difficilmente manutenibili...

12 Approccio orientato ai Componenti Le applicazioni: non sono isole non sono monoliti non sono deliverables artificiali Infrastruttura tecnologica Approccio orientato ai Componenti (2) Le applicazioni non sono orientate alle funzioni, infatti esplicitano i processi di business non impongono confini artificiali Infrastruttura tecnologica

13 Approccio orientato ai Componenti (3) Le applicazioni: Si integrano (i Componenti sono progettati proprio per integrarsi, da soli servono a poco) Non duplicano i concetti New Business Objects (Components) Infrastruttura tecnologica Approccio orientato ai Componenti (4) Le applicazioni: Riusano i componenti Sono altamente manutenibili: un operazione di manutenzione sul componente, richiede la modifica, la ri-costruzione e la rimessa in esercizio del solo componente Infrastruttura tecnologica

14 Classificazione dei Componenti Un Componente ha sia una parte strutturale che una parte comportamentale Data-Centric Components la parte strutturale è predominate rispetto a quella comportamentale Es:,, Process-Centric Components la parte comportamentale è predominate rispetto a quella strutturale Es:,