The problem of measuring “similarity” of objects arises in
many applications, and many domain-specific measures
have been developed.
complementary approach, applicable in any domain
with object-to-object relationships.
“two objects are similar if
they are related to similar objects.” This general similarity
measure, called SimRank, is based on a simple and intuitive
graph-theoretic model.
Bipartite SimRank nei Domini Omogenei
Bipartite SimRank in Homogeneous Domains
Minimax Variation
The problem of measuring “similarity” of objects arises in
many applications, and many domain-specific measures
have been developed.
complementary approach, applicable in any domain
with object-to-object relationships.
“two objects are similar if
they are related to similar objects.” This general similarity
measure, called SimRank, is based on a simple and intuitive
graph-theoretic model.
Bipartite SimRank nei Domini Omogenei
Bipartite SimRank in Homogeneous Domains
Minimax Variation
This document discusses software services and cloud computing architectures. It begins by providing context on the growing service economy and how businesses are increasingly offering services rather than products. It then defines software-as-a-service (SaaS) and describes how SaaS delivers software applications over the internet, with updates and management occurring remotely. Finally, the document discusses service-oriented architectures and how they support the development and delivery of software services.
The document discusses architecture-centric software development processes. It describes traditional waterfall and iterative development models, and notes that iterative models allow for more flexibility to changing requirements. Agile development methods like eXtreme Programming (XP) are discussed, which emphasize iterative development, collaboration, and rapid delivery of working software. Key practices of XP are outlined, including user stories, testing, pair programming, refactoring, and continuous integration. The role of architecture in agile processes is also addressed.
This document discusses software product lines and product line architectures. It defines a software product line as a set of software systems that share a common set of features addressing a particular market segment. Product lines are developed from a common set of core assets in a prescribed way to reduce costs and increase reuse. A product line architecture is a common framework that standardizes components and maximizes reuse potential. It specifies common functionality and identifies variation points across related products. Variability management is important for providing flexibility without compromising commonality.
6 - Architetture Software - Model transformationMajong DevJfu
This document discusses model transformations in Model-Driven Architecture (MDA). It defines computation independent models (CIMs), platform independent models (PIMs), and platform specific models (PSMs). It explains that model transformations are used to map between these different abstraction levels and ensure consistency. It also discusses model mappings, approaches to transformations, and tools like EMF and ATL that support transformations in Eclipse.
5 - Architetture Software - Metamodelling and the Model Driven ArchitectureMajong DevJfu
The document discusses metamodeling and the Model Driven Architecture (MDA). It covers topics such as model driven engineering, metamodeling, metamodeling in UML, and the OMG technologies that support MDA. Metamodeling involves modeling modeling elements and their relationships. Metamodels define the structure of models, while models are instances that conform to metamodels. The MDA uses metamodels and models to develop and transform systems.
This document provides an overview of software architectures by presenting examples of architectures from various software systems. It begins with an introduction to software architecture and what it entails. It then shows numerous diagrams and visualizations of architectures for different types of systems, such as editors, compilers, operating systems, middleware, and web applications. These examples are intended to demonstrate common architectural patterns and styles. The document discusses analyzing and comparing the architectures visually and recognizing patterns within them.
The document discusses architectural styles and decomposition techniques for software systems. It describes layering and tiering as basic decomposition approaches, with layers representing different levels of abstraction and tiers representing peer modules within the same layer. Several common architectural styles are then introduced, including pipes and filters, repository, client/server, model-view-controller, service-oriented, and peer-to-peer. Closed and open layered architectures are contrasted, and examples of layered systems like virtual machines and the OSI model are provided. Finally, the document notes that complete decompositions often involve both layering and partitioning techniques.
The document discusses key concepts in software architecture, including:
1) Software architecture establishes the overall structure and organization of a system, including its components and relationships.
2) Architectural design involves decomposing a system into subsystems or modules to improve modifiability, reusability, and portability.
3) Key principles for architectural design include simplicity, modularity, low coupling, separation of concerns, abstraction, and postponing decisions.
1 - Architetture Software - Software as a productMajong DevJfu
This document discusses software as a product and industry. It covers how software is a key component in modern technologies and industries. The software industry has grown significantly in recent decades. The document discusses different types of software such as embedded software, middleware, and software as a service. It also covers topics like software architecture, engineering, components, ecosystems, and the challenges in developing software. Overall, the document provides an overview of software as an industrial product and the software development industry.
10 - Architetture Software - More architectural stylesMajong DevJfu
The Microkernel pattern partitions an operating system into isolated, minimal components that communicate through a small, fixed message-passing interface, allowing components to be developed and upgraded independently while maintaining overall system stability and security.
The document discusses architectural UML and provides information on:
1) The elements of a software architecture including views, models, and diagrams.
2) How UML can be used to represent different architectural views including design, process, development, and physical views.
3) An example of using UML models and diagrams to represent different views of a chess game architecture.
UML allows for extending diagrams and modeling elements through three main techniques:
1. Stereotypes allow applying tags to existing modeling elements like classes, associations, etc. to add domain-specific meaning.
2. Profiles extend UML with new modeling elements tailored for specific domains or platforms.
3. Extension mechanisms allow precisely defining new constructs that integrate with the UML metamodel. Together these techniques make UML extensible for multiple domains.
The document discusses metamodeling and the Model Driven Architecture (MDA). It provides an overview of model driven engineering and metamodeling. Specifically, it discusses how metamodels define the structure of models through concepts like classes and relationships. The Model Driven Architecture uses metamodels and modeling to develop software systems from models.
Here are the key differences between objects and classes in UML:
- Classes define the general characteristics (attributes and operations) that objects of that class will have. Objects are specific instances of a class.
- Classes are static definitions, while objects are dynamic instances of classes that exist at run time.
- In class diagrams, classes are represented as boxes containing the attributes and operations. Objects are represented as boxes with the class name followed by a colon and the object name (e.g. Person:John).
- Classes define the common properties for a set of objects, while each object is a unique instance of a class with its own identity and particular values for attributes.
- Classes are abstractions,
The document discusses architectural styles and decomposition techniques. It describes layers as hierarchical sets of subsystems that provide related services by utilizing underlying layers. Tiers partition a system into peer subsystems responsible for classes of services. Common architectural styles include pipes and filters, repository, client/server, model-view-controller, service-oriented, and peer-to-peer. Layers and tiers are often combined for complete decomposition, with subsystems divided into tiers and each tier organized into layers. The pipe and filter style focuses on dynamic interaction by processing data streams through filters connected by pipes.
- Reference architectures that provide templates for common system types
- Design patterns that capture successful solutions to recurring problems
- Architectural patterns that describe best practices for system organization
- Legacy applications that can be analyzed for reusable architectural elements
This document discusses software as a product and the software industry. It covers topics such as why software is important, emerging technologies according to Gartner's hype cycle from 2005-2010, software being an industrial product, the size of the worldwide software industry, different types of software including embedded software and software as a service. It also discusses software components, software architecture and engineering issues, producing software is difficult due to complexity, low productivity in the industry, the software development process, different process models, lifecycle differences around the world, development activities, process models, and software standards.
This short document contains 5 headings but provides no other details or context. It lists the headings "My Heading Here First Second Third Fourth Fifth" but does not elaborate on or explain these headings.
This document provides an overview of various types of architectural standards including conceptual standards like IEEE 1471 and DoDAF that define viewpoints and views, notational standards like UML and SysML, and process standards like TOGAF and RUP. It discusses the benefits of standards in promoting interoperability and network effects while also noting drawbacks like limiting flexibility. The document advises deciding when to adopt a standard based on whether in the early or late phase of a project.
2. A) Introduzione
1 2
B) Prog. ConceGuale (ER)
C) Modello Relazionale,
Algebra relazionale, SQL
1 2 3 4 5 6 7 1 2 3 4 5 6 7
D) Prog. Logica e E) Tecnologia di un DBMS
Normalizzazione
1 2 3 4 1 2 3 4 5 6
F) Programmazione DB
1 2
2 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
3. Altre traduzioni
La traduzione standard è sempre possibile ed è
l’unica possibilità per le associazioni N a M
Altre forme di traduzione delle associazioni sono
possibili per altri casi di cardinalità (1 a 1, 1 a N)
Le altre forme di traduzione fondono in una stessa
relazione enMtà e associazioni
3 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
4. Altre traduzioni
Le altre forme di traduzione:
danno origine a un minor numero di relazioni e
generano quindi uno schema più semplice
richiedono un minor numero di join per la
navigazione aGraverso un’associazione, ovvero per
accedere alle istanze di enMtà connesse tramite
l’associazione
penalizzano le operazioni che consultano soltanto gli
aGribuM di una enMtà che è stata fusa
4 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
5. Associazione binaria 1 a N
traduzione standard:
K1
A1 E1
B1
(1,1) E1 (K1, A1, B1)
AR
R E2 (K2, A2, B2)
BR
(1,n) R (K1,K2, AR, BR)
K2
A2 E2
B2
5 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
6. Associazione binaria 1 a N
Se E1 partecipa con cardinalità (1,1) può essere fusa con
l’associazione, oGenendo una soluzione a due relazioni:
E1(K1, A1, B1,K2, AR, BR)
E2(K2, A2, B2)
Se E1 partecipa con cardinalità (0,1) la soluzione a due
relazioni ha valori nulli in K2, AR, BR per le istanze di E1
che non partecipano all’associazione
6 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
7. Associazione binaria 1 a N
equivale a:
K1
A1 E1
B1
K2 K2 AR BR
A2 E2
B2
7 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
8. Associazione binaria 1 a N
AGenzione : in questo caso, poiché la partecipazione di
E1 è 0,1 o 1,1, si nota facilmente che ad un dato valore
di K1 corrisponde uno e un sol valore di K2 (non è vero
il contrario), quindi si può dire che K1 implica K2 o,
anche, che esiste una dipendenza funzionale da K1 a K2
nella soluzione a 3 relazioni la chiave della relazione che
traduce l’associazione è riducibile a K1:
E1(K1,A1,B1) , E2(K2,A2,B2)
R(K1,K2,AR,BR)
8 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
9. Associazione binaria 1 a N es.
codice codice nome_p
nome_c
nome_c
comune
comune
abitanM
(1,1) abitanM
apparMene
nome_p (1,n)
nome_p
provincia
regione provincia
regione
(senza aGribuM sull’associazione)
9 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
11. Associazione binaria 1 a N es.
CREATE TABLE PROVINCIA
(NOME_P ... NOT NULL,
REGIONE ... PRIMARY KEY (NOME_P));
CREATE TABLE COMUNE
(CODICE ... NOT NULL, NOME_C ...
ABITANTI ..., NOME_P ... NOT NULL
PRIMARY KEY (CODICE)
FOREIGN KEY NOME_P
REFERENCES PROVINCIA);
11 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
12. Associazione binaria 1 a N es.
p_iva
p_iva
nome
cliente nome
cliente
telefono
(0,n) telefono
sconto invia
(1,1) p_iva
numero
ordine numero
data ordine
data
(con aGribuM sull’associazione) sconto
12 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
14. Associazione binaria 1 a N es.
CREATE TABLE CLIENTE (P_IVA ... NOT NULL,
NOME ...,TELEFONO ..., PRIMARY KEY (P_IVA));
CREATE TABLE ORDINE (NUMERO ... NOT NULL,
DATA ... P_IVA ... NOT NULL, SCONTO ...,
PRIMARY KEY (NUMERO)
FOREIGN KEY P_IVA REFERENCES CLIENTE);
con tre relazioni:
14 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
15. Associazione binaria 1 a N es.
CLIENTE (P_IVA, NOME, TELEFONO)
ORDINE (NUMERO, DATA)
INVIA (NUMERO, P_IVA, SCONTO)
FK: P_IVA REFERENCES CLIENTE
FK: NUMERO REFERENCES ORDINE
15 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
16. Associazione binaria 1 a N es.
CREATE TABLE CLIENTE (P_IVA ... NOT NULL,
NOME ...,TELEFONO ..., PRIMARY KEY (P_IVA));
CREATE TABLE ORDINE (NUMERO ... NOT NULL,
DATA ... PRIMARY KEY (NUMERO));
CREATE TABLE INVIA
(P_IVA ... NOT NULL, NUMERO ... NOT NULL,
SCONTO ..., PRIMARY KEY (NUMERO)
FOREIGN KEY P_IVA REFERENCES CLIENTE
FOREIGN KEY NUMERO REFERENCES
ORDINE);
16 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
17. Associazione binaria 1 a N es.
Con idenMficazione esterna
n_stab
nome
stabili‐
reparto parte mento
(1,1) (1,n)
(1,n)
in macchina
(1,1)
num c_inv
17 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
19. Associazione binaria 1 a N es.
CREATE TABLE STABILIMENTO (N_STAB ... NOT
NULL, ..., ..., PRIMARY KEY (N_STAB));
CREATE TABLE REPARTO (NOME ... NOT NULL,
N_STAB ... NOT NULL... PRIMARY KEY (NOME,
N_STAB) FOREIGN KEY N_STAB REFERENCES
STABILIMENTO
CREATE TABLE MACCHINA (NUM ... NOT NULL,
NOME ... NOT NULL, N_STAB ... NOT NULL, ...,
PRIMARY KEY (NUM, NOME, N_STAB )
FOREIGN KEY NOME REFERENCES REPARTO
FOREIGN KEY N_STAB REFERENCES STABILIMENTO);
19 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
20. Associazione binaria 1 a 1
traduzione con una
relazione:
nome_c comune E12 (K1, A1, B1,
abitanM K2, A2, B2,
(1,1)
data AR, BR)
amministra (1,1)
nome_s
sindaco
parMto
20 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
21. Associazione binaria 1 a 1
AMMINISTRAZIONE (NOME_C, ABITANTI, NOME_S,
INDIRIZZO, DATA)
AK: NOME_S
CREATE TABLE AMMINISTRAZIONE
(NOME_C ... NOT NULL, ABITANTI ...,
NOME_S ... NOT NULL UNIQUE,
INDIRIZZO ..., DATA ... ,
PRIMARY KEY (NOME_C));
se le cardinalità minime sono entrambe 1 la
chiave può essere indifferentamente K1 o K2
si sceglierà quella più significaMva
21 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
23. Associazione binaria 1 a 1
assolto
(0,1) (1,1)
cod_f ciGadino servizio
Mpo
nome_c data_n matr data
CITTADINO (COD_F, NOME_C, INDIRIZZO,
DATA_N, MATR, DATA, TIPO)
CREATE TABLE CITTADINO
(COD_F ... NOT NULL, NOME_C ... NOT NULL,
INDIRIZZO ..., DATA_N ..., MATR ..., DATA...,
TIPO ..., PRIMARY KEY (COD_F));
23 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
24. Associazione binaria 1 a 1
Traduzione con due relazioni
l’associazione può essere compaGata con l’enMtà
che partecipa obbligatoriamente (una delle due se
la partecipazione è obbligatoria per entrambe) la
discussione sulla chiave è analoga al caso di
traduzione con una relazione
E1 (K1, A1, B1,...)
E2 (K2, A2, B2,... K1, AR, BR)
24 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
25. Associazione binaria 1 a 1
Traduzione con tre relazioni
la chiave della relazione che traduce l’associazione
può essere indifferentemente K1 o K2, non ci sono
problemi di valori nulli
E1 (K1, A1, B1,...)
E2 (K2, A2, B2,...)
R (K1, K2, AR, BR,...)
25 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
26. Auto associazione N a M
viene tradoGa con:
una relazione per l’enMtà ed
una per l’associazione,
• quest’ulMma conMene due volte la chiave dell’enMtà, è
necessario, però modificare i nomi degli aGribuM, per
non avere omonimia
nome
(0,n)
stato confina
area
(0,n)
26 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
27. Auto associazione N a M
STATO(NOME, AREA)
CONFINA(STATO_A, STATO_B)
FK: STATO_A REFERENCES STATO
STATO_B REFERENCES STATO
CREATE TABLE STATO
(NOME ... NOT NULL, AREA …
PRIMARY KEY (NOME));
CREATE TABLE CONFINA
STATO_A ... NOT NULL, STATO_B ... NOT NULL,
PRIMARY KEY (STATO_A, STATO_B)
FOREIGN KEY (STATO_A)
REFERENCES STATO
FOREIGN KEY (STATO_B)
REFERENCES STATO);
27 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
28. Auto associazione 1 a N
è traducibile con una sola relazione che
conMene due volte l’aGributo chiave: una
volta come chiave ed una come riferimento
all’istanza connessa, con nome diverso per
specificare il ruolo
matr nome
capo
(0,n)
dipendente capo_di
(0,1)
subordinato
28 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
29. Auto associazione 1 a N
DIPENDENTE (MATR, NOME, CAPO)
FK: CAPO REFERENCES DIPENDENTE
CREATE TABLE DIPENDENTE
(MATR ... NOT NULL, NOME ..., CAPO ...
PRIMARY KEY (MATR)
FOREIGN KEY (CAPO)
REFERENCES DIPENDENTE);
nel caso di associazione 1 ad 1 il conceGo di
ruolo assume maggiore importanza:
29 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
30. Auto associazione 1 a 1
matr nome
marito
(0,1)
dipendente sposaM
(0,1)
moglie
su entrambi rami è bene specificare il ruolo:
conviene la soluzione con due relazioni per
evitare ridondanze, vincoli ed eccesso di valori
nulli.
30 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
31. Auto associazione 1 a 1
DIPENDENTE (MATR, NOME)
SPOSATI (MOGLIE, MARITO)
FK: MOGLIE REFERENCES DIPENDENTE
FK: MARITO REFERENCES DIPENDENTE
31 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
32. Auto associazione 1 a 1
CREATE TABLE DIPENDENTE (MATR ... NOT
NULL, NOME ..., PRIMARY KEY (MATR)
CREATE TABLE SPOSATI
(MOGLIE ... NOT NULL, MARITO ... NOT NULL
PRIMARY KEY (MOGLIE)
FOREIGN KEY (MOGLIE) REFERENCES DIPENDENTE
FOREIGN KEY (MARITO) REFERENCES DIPENDENTE);
32 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
33. Associazione n‐aria
segue la traduzione standard
talvolta, nella relazione che traduce l’associazione,
la chiave oGenuta componendo le chiavi di tuGe le
enMtà partecipanM è una superchiave, cioè una
chiave composta il cui set di componenM non è
minimale (la chiave vera è un soGoinsieme)
Esempio: progek‐parM‐magazzini
33 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
34. Associazione n‐aria
prj
progeGo
descrizione
cod_p qta (1,n)
consegna
nome (1,n)
Mpo parte data
(1,n)
(1,n)
cod_m
nome magazzino
distanza
34 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
35. Associazione n‐aria
PROGETTO (PRJ, DESCRIZIONE)
PARTE (COD_P, NOME, TIPO)
MAGAZZINO (COD_M, NOME, DISTANZA)
CREATE TABLE PROGETTO (PRJ... NOT NULL,
DESCRIZIONE... , PRIMARY KEY (PRJ));
CREATE TABLE PARTE (COD_P ... NOT NULL,
NOME…, TIPO…, PRIMARY KEY (COD_P));
CREATE TABLE MAGAZZINO (COD_M…. NOT NULL,
NOME ..., DISTANZA…, PRIMARY KEY (COD_M));
non c’è una relazione per la data
la data era un’enMtà fikzia messa nello schema per
garanMre l’unicità delle consegne, comparirà infak nella
definizione della chiave
35 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
36. Associazione n‐aria
l’associazione diventa:
CONSEGNA (PRJ, COD_P, COD_M, DATA, QTA)
FK: PRJ REFERENCES PROGETTO
FK: COD_M REFERENCES MAGAZZINO
FK: COD_P REFERENCES PARTE
CREATE TABLE CONSEGNA (PRJ ... NOT NULL,
COD_P... NOT NULL, COD_M... NOT NULL,
DATA... NOT NULL, QTA ...
PRIMARY KEY (PRJ, COD_P, COD_M, DATA)
FOREIGN KEY (PRJ) REFERENCES PROGETTO
FOREIGN KEY (COD_M) REFERENCES MAGAZZINO
FOREIGN KEY (COD_P) REFERENCES PARTE);
ipoMzziamo che (PRJ, COD_P, COD_M, DATA)
sia una superchiave:
36 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
37. Associazione n‐aria
una parte esiste in un solo magazzino, quindi COD_P è
associato ad un solo COD_M, cioè determina COD_M,
allora la presenza di COD_M nella chiave è ridondante:
CONSEGNA (PRJ, COD_P, COD_M, DATA, QTA)
FK: PRJ REFERENCES PROGETTO
FK: COD_M REFERENCES MAGAZZINO
FK: COD_P REFERENCES PARTE
• COD_M è ridondante anche nella relazione
37 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
38. Associazione n‐aria
infak, se una parte esiste in un solo magazzino:
prj
descrizione progeGo
cod_p qta (1,n)
nome consegna
(1,n)
Mpo parte data
(1,n)
(1,1)
cod_m
nome magazzino sta
distanza (1,n)
38 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)
42. Commento
nel caso precedente la dipendenza tra magazzino e
parte non era stata espressa sulla associazione n‐aria,
abbiamo ipoMzzato di scoprirla nella fase di progeGo
logico
se il progeGo conceGuale è ben faGo casi del genere
non sono frequenM
diverso è il caso in cui si vogliono esprimere dei vincoli
che richiederebbero un uso complicato di enMtà di
collegamento con idenMficazione esterna
il ricontrollo delle chiavi delle relazioni è quindi
importante
42 Basi di DaM ‐ ProgeGo Logico Relazionale (Parte 2)