BookPDF Available

The Unified Modelling Language Reference Manual

Authors:
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 1
Kapitel II: Das Pflichtenheft
II.2: Modell des Problembereichs
Prof. Dr. Gregor Engels
AG Datenbank- und
Informationssysteme
Softwareentwurf
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 2
2
Kapitel II.2
Kapitel II.2
Gliederung Pflichtenheft <-> Vorlesung
Abschnitt 1:
Zielbestimmung
Abschnitt 2:
Produkteinsatz
Abschnitt 3:
Produktfunktionen
Abschnitt 4
Produktcharakteristiken
Abschnitt 1:
Zielbestimmung
Abschnitt 2:
Produkteinsatz
Abschnitt 3:
Produktfunktionen
Abschnitt 4
Produktcharakteristiken
2.1 Beschreibung des Problembereichs
2.2 Glossar
2.3 Modell des Problembereichs
2.4 Geschäftsprozesse
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 2
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 3
3
Pflichtenheft – Abschnitt 2:
Produkteinsatz
Aufgaben der Abschnitte 2.1 – 2.3:
2.1 Beschreibung des Problembereichs:
Erläuterung von Fachbegriffen und Zusammenhängen für den Laien
2.2 Glossar:
Nachschlagewerk für Fachbegriffe
2.3 Modell des Problembereichs:
Nachschlagewerk für Präzisierung der Zusammenhänge
DURCH
graphisches, objektorientiertes Modell
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 4
4
Unified Modeling Language (UML)
graphische, objektorientierte Familie von Modellierungssprachen
Standard, herausgegeben von der Object Management Group (OMG)
seit 11/1997
aktuelle Version: 2.0
http://www.omg.org/uml
Notationsübersicht und Glossar
http://www.oose.de/uml/
Grady Booch, James Rumbaugh, Ivar
Jacobson, The Unified Modeling Language
User Guide, Addison Wesley 1999.
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 3
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 5
5
Von der Realität zum Modell
Realität:
Realität:
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 6
6
Von der Realität zum Modell
Rechte Tür
Linke Tür
Objekte
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 4
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 7
7
Von der Realität zum Modell
Rechte Tür
Linke Tür
Karussell 1 Karussell 2
ermöglicht
Zugang zu
ermöglicht
Zugang zu
Objekte +
Beziehungen
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 8
8
Von der Realität zum Modell
Rechte Tür
Karussell 1
Karussell 1
ermöglicht
Zugang zu Lagerfeld 1
Lagerfeld 2
Lagerfeld 3
...
Objekte + (Teil-Ganzes-)
Beziehungen
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 5
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 9
9
Von der Realität zum Modell
Objekte +
Beziehungen +
Eigenschaften
Karussell 1
Lagerfeld 1
zulässigesGewicht = 700
...
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 10
10
(UML-) Objektdiagramme
beschreiben einen
Schnappschuss der Realität
werden i.A. nur ausschnittsweise
gezeichnet
enthalten
(benannte) Objekte
Beziehungen zwischen Objekten
Eigenschaften (Attribute) von
Objekten (mit Name und Wert) Karussell 1
Lagerfeld 1
zulässigesGewicht = 700
Rechte Tür
ermöglicht
Zugang zu
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 6
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 11
11
Von der Realität zum Modell
Realität:
Realität:
Situation 1
Situation 3
Situation 2
Menge
allgemein möglicher
Situationen
=
Modell des
Problembereichs
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 12
12
Vom konkreten zum allgemeinen Modell
Rechte Tür
Linke Tür
Klassen
Tür
Es gibt eine rechte
und eine linke Tür.
Es gibt Türen.
Klassennamen
im Singular!
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 7
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 13
13
Vom konkreten zum allgemeinen Modell
Tür
Linke Tür
Karussell
Karussell 2
ermöglicht
Zugang zu
ermöglicht
Zugang zu
Klassen +
Beziehungen
(Assoziationen)
Die linke Tür ermöglicht
den Zugang zum
zweiten Karussell.
Türen ermöglichen
den Zugang zu
Karussells.
Unbenannte
Assoziationen
sind sinnlos!
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 14
14
Vom konkreten zum allgemeinen Modell
Reflexive Assoziationen
und Rollennamen
Lagerfach 2
Lagerfach1
Lagerfächer
sind
übereinander
angeordnet.
Lagerfach
Rollen ersetzen
Assoziationsnamen
Lagerfach 3
Oberer Nachbar
Unterer Nachbar
Ein Lagerfach ist
ein oberer
/unterer Nachbar
von einem anderen
Lagerfach
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 8
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 15
15
Vom konkreten zum allgemeinen Modell
Klassen + (Teil-Ganzes-)
Beziehungen
(Aggregation)
Karussell 1
Lagerfeld 1
Lagerfeld 1 ist Teil
des ersten Karussells.
Lagerfelder
sind Teile
von Karussells.
Karussell
Lagerfeld
Raute immer am
Übergeordneten
(Ganzen)!
Aggregationen haben
keinen (speziellen) Namen
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 16
16
Vom konkreten zum allgemeinen Modell
Klassen +
Eigenschaften
(Attribute)
Lagerfeld 1
Lagerfeld 1
zulässigesGewicht = 700
zulässigesGewicht = 700
Lagerfeld 1 hat ein zulässiges
Gewicht von 700 kg.
Lagerfeld
Lagerfeld
zulässigesGewicht : Dezimal
zulässigesGewicht : Dezimal
Lagerfelder haben ein
zulässiges Gewicht, das
durch eine Dezimal-
zahl angegeben wird.
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 9
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 17
17
(UML-) Klassendiagramme
beschreiben allgemein mögliche
Situationen
werden zur Beschreibung des
Modells des Problembereichs
verwendet
enthalten
Klassen (Mengen gleichartiger
Objekte)
Beziehungen zwischen Klassen
(Assoziationen)
Eigenschaften (Attribute) von
Klassen (mit Name und Typ)
Karussell
Lagerfeld
zulässigesGewicht : Dezimal
Tür
ermöglicht
Zugang zu
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 18
18
Notationselemente für
Klassendiagramme
Klassen auf- und zuklappen:
Karussell
Lagerfeld
zulässigesGewicht : Dezimal
Klasse Karussell hat
keine Attribute.
Klasse Karussell hat
keine Attribute.
Karussell
Lagerfeld
Diagramm macht keine Aussage,
ob Klasse Karussell und Klasse
Lagerfeld Attribute haben.
Diagramm macht keine Aussage,
ob Klasse Karussell und Klasse
Lagerfeld Attribute haben.
vs.
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 10
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 19
19
Notationselemente für
Klassendiagramme
Türen ermöglichen
den Zugang zu
Karussells.
Türen ermöglichen
den Zugang zu
Karussells.
Präziser (durch
Kardinalitäten):
Tür
Karussell
ermöglicht
Zugang zu
Jede Tür ermöglicht
den Zugang zu
einem Karussell.
Jede Tür ermöglicht
den Zugang zu
einem Karussell.
Tür
Karussell
ermöglicht
Zugang zu
1
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 20
20
Notationselemente für
Klassendiagramme
Türen ermöglichen
den Zugang zu
Karussells.
Türen ermöglichen
den Zugang zu
Karussells.
Präziser (durch
Kardinalitäten): Zu jedem Karussell hat
man nur Zugang durch
eine Tür.
Zu jedem Karussell hat
man nur Zugang durch
eine Tür.
Tür
Karussell
ermöglicht
Zugang zu
Tür
Karussell
ermöglicht
Zugang zu 1
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 11
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 21
21
Notationselemente für
Klassendiagramme
0..1
1
0..* oder *
4..12
2, 4, 6
ein oder kein
genau ein
beliebig viele (Default)
zwischen vier und zwölf
zwei, vier oder sechs
Karussell Lagerfeld Lagerfach Ware
liegt in
0..*0..14..121126
Kardinalitäten für Beziehungen:
Unbestimmte Kardinalitäten
sind „offiziell“ * , inoffiziell
Schlamperei!
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 22
22
Ware
Notationselemente für
Klassendiagramme
Lagerfach
0..1
Leserichtung von Kardinalitäten für Beziehungen:
Jede Ware liegt in keinem oder einem Lagerfach
Ausgangsklasse Beziehungsname Kardinalität Zielklasse
liegt in
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 12
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 23
23
Notationselemente für
Klassendiagramme
Karussell Lagerfeld Lagerfach
4..121126
Geordnete Assoziationen
{ordered} {ordered}
Lagerfelder eines Karussells besitzen eine Sortierung.
Lagerfächer eines Lagerfeldes besitzen eine Sortierung.
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 25
25
Notationselemente für
Klassendiagramme
Position
Ein- und Auslagerungsaufträge haben gemeinsame Eigenschaften
und Beziehungen.
Einlagerungsauftrag
Auftragsnummer : Dezimal
Bestelldatum : Datum
Auslagerungsauftrag
Auftragsnummer : Dezimal
Bestelldatum : Datum
1..* 1..*
11
Finden von Generalisierungen: Schritt 1
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 13
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 26
26
Notationselemente für
Klassendiagramme
Position
Einlagerungsauftrag
Auftragsnummer : Dezimal
Bestelldatum : Datum
Auslagerungsauftrag
Auftragsnummer : Dezimal
Bestelldatum : Datum
1..* 1..*
11 {xor}
Finden von Generalisierungen: Schritt 2
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 27
27
Notationselemente für
Klassendiagramme
Einlagerungsauftrag
Auftragsnummer : Dezimal
Bestelldatum : Datum
Auslagerungsauftrag
Auftragsnummer : Dezimal
Bestelldatum : Datum
Position
1..*
1
Alle Aufträge haben diese Eigenschaften und Beziehungen.
1
1..* 1..*
1
Auftrag
Auftragsnummer : Dezimal
Bestelldatum : Datum
Finden von Generalisierungen: Schritt 3
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 14
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 28
28
Notationselemente für
Klassendiagramme
Position
1..*
1
Ein- und Auslagerungsaufträge sind spezielle Arten von Aufträgen:
Ein Einlagerungsauftrag ist ein Auftrag.
Ein Auslagerungsauftrag ist ein Auftrag.
Auftrag
Auftragsnummer : Dezimal
Bestelldatum : Datum
Einlagerungsauftrag Auslagerungsauftrag
1
1..* 1..*
1
Auftragsnummer : Dezimal
Bestelldatum : Datum Auftragsnummer : Dezimal
Bestelldatum : Datum
Finden von Generalisierungen: Schritt 4
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 29
29
Notationselemente für
Klassendiagramme
Position
1..*
1
Ein- und Auslagerungsaufträge sind spezielle Arten von Aufträgen:
Ein Einlagerungsauftrag ist ein Auftrag.
Ein Auslagerungsauftrag ist ein Auftrag.
Sie erben die Eigenschaften und Beziehungen.
Auftrag
Auftragsnummer : Dezimal
Bestelldatum : Datum
Einlagerungsauftrag Auslagerungsauftrag
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 15
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 30
30
Notationselemente für
Klassendiagramme
Position
1..*
1
Ein- und Auslagerungsaufträge sind spezielle Arten von Aufträgen:
Sie erben die Attribute und Assoziationen.
Sie können zusätzliche Eigenschaften und Beziehungen haben.
Auftrag
Auftragsnummer : Dezimal
Bestelldatum : Datum
Einlagerungsauftrag Auslagerungsauftrag
Vererbung
Empfänger
hat
1
0..*
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 31
31
Notationselemente für
Klassendiagramme
Klassen
Assoziationen zwischen Klassen
mit Kardinalitäten
Aggregations-Beziehungen
Constraint {ordered}
Eigenschaften von Klassen
(Attribute)
Vererbung
Karussell
Lagerfeld
26
1
{ordered}
zulässigesGewicht : Dezimal
Auftrag
Auftragsnummer : Dezimal
Bestelldatum : Datum
Auslagerungsauftrag
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 16
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 32
32
Vorgehen bei der Entwicklung des
Modells des Problembereichs
Realität:
Konkrete Modelle:
Objektdiagramme
Allgemeines Modell:
Klassendiagramm
Karussell
Lagerfeld
zulässigesGewicht : Dezimal
Karussell 1
Lagerfeld 1
zulässigesGewicht = 700
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 33
33
Die große Frage der Modellierung
Abstraktion = Beschränkung auf das Wesentliche
Was ist denn jetzt
genau das
Wesentliche?
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 17
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 34
34
Qualitäten des MdPs
Ein gutes Modell des Problembereichs ist
Vollständig
Zwei Situationen in der Realität, die sich relevant unterscheiden,
ergeben auch zwei unterschiedliche Objektdiagramme
Präzise
Es werden nur die relevanten Situationen beschrieben
Was für einen Problembereich relevant ist, ist nicht leicht
zu erkennen!
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 35
35
Modell des Problembereichs
und die Realität
Pflichtenheft
Tür
Karussell
Auslagerungsauftrag
Empfänger
1
11
1
Code
class Auslagerungsauftrag
private myEmpf Empfaenger
Warum kann ich jetzt
nicht schnell für die
Innere was mitbestellen?
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 18
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 36
36
Zusammenhang zwischen Klassen-
und Objektdiagramm
Konkrete Modelle:
Objektdiagramme
Allgemeines Modell:
Klassendiagramm
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 37
37
Instanziierung
Karussell
Tür
Allgemeines Modell:
Klassendiagramm Konkrete Modelle:
Objektdiagramme
: Karussell
1
1
ermöglicht
Zugang zu
: Tür
ermöglicht
Zugang zu K1 : Karussell
T1 : Tür
ermöglicht
Zugang zu
unbenannte
Objekte benannte
Objekte
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 19
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 38
38
Instanziierung
Karussell
Tür
Allgemeines Modell:
Klassendiagramm Konkretes Modell:
Objektdiagramme
K1: Karussell
1
1
ermöglicht
Zugang zu
T1: Tür
ermöglicht
Zugang zu K2: Karussell
T2: Tür
ermöglicht
Zugang zu
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 39
39
Instanziierung
Karussell
Tür
Allgemeines Modell:
Klassendiagramm Konkretes Modell:
Objektdiagramme
: Karussell
1
1
ermöglicht
Zugang zu
: Tür
ermöglicht
Zugang zu
ermöglicht
Zugang zu
: Tür
Softwareentwurf WS 2004/05
Kapitel II: Das Pflichtenheft
Kapitel II.2: Modell des
Problembereichs
3.11.2004
Gregor Engels 20
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 40
40
Instanziierung
Allgemeines Modell:
Klassendiagramm Konkretes Modell:
Objektdiagramme
Position
1..*
1
Auftrag
Auftragsnummer : Dezimal
Bestelldatum : Datum
Einlagerungsauftrag
A131:Einlagerungsauftrag
Auftragsnummer = D214V7
Bestelldatum = 3.11.2004
P1:Position P2:Position
Softwareentwurf 2004/05
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels
Universität Paderborn - Gregor Engels 41
41
Pflichtenheft – Abschnitt 2.3:
Modell des Problembereichs
beschrieben durch UML Klassendiagramm
dient dem Nachschlagen der präzisen Zusammenhänge
Übersichtlichkeit durch
graphische Notation
objektorientierte Strukturierung
Präzisierung durch
verschiedene Arten von Beziehungen
Kardinalitäten
Constraints
... Te unifed modeling language (UML) was employed to translate the lingual agnostic IRS architecture into computational artifacts towards its implementation. UML has become the de facto language for modeling software systems [45]. Generally, the structure and behavior of a software system can be efectively modeled in UML in the four design views of software systems, namely, (i) functional view, (ii) static structural view, (iii) behavioral or dynamic structural view, and (iv) architectural view [46]. ...
... To determine the parity of selected indigenous language with English language using the lingual agnostic IRS, the study assumed the English language results as the gold standard. To obtain language parity, the ratios of the average search precision@10, recall@10, and F-measure@10 for each indigenous language to those of the English language expressed as percentages were computed and are presented 68 "Taswirar layuka" da "lambar gidaje" hanya ce da "tsaron kasa" da sauyi da birane da mai karf da Kano 21,30,22,44,23,20,52,25,45,26 69 Rawar da "ilmin addini" da "tsaron kasa" da sauyi da zaman lafya da Nijeriya 4,45,44,30,27,26,25,23,22,20 70 Tsarin bayanin taswirar kasa da hanya ce da "sarrafa laifuka´da GIS da Nijeriya" 21,24,26,37,34,45,53,54,56,65 Te Scientifc World Journal 21 Table 4. Te term "overall" as used in Table 4 depicts the average percentage parity of precision@10, recall@10, or F-measure@10 of the indigenous languages with the English language and, thus, represents the search retrieval performance of the IRS for non-English language speakers. In particular, the overall parity F-measure is taken as the Figure 10: Lingual agnostic IRS recall@10 line graph for selected language topics (source: authors). ...
... To determine the parity of selected indigenous language with English language using the lingual agnostic IRS, the study assumed the English language results as the gold standard. To obtain language parity, the ratios of the average search precision@10, recall@10, and F-measure@10 for each indigenous language to those of the English language expressed as percentages were computed and are presented 68 "Taswirar layuka" da "lambar gidaje" hanya ce da "tsaron kasa" da sauyi da birane da mai karf da Kano 21,30,22,44,23,20,52,25,45,26 69 Rawar da "ilmin addini" da "tsaron kasa" da sauyi da zaman lafya da Nijeriya 4,45,44,30,27,26,25,23,22,20 70 Tsarin bayanin taswirar kasa da hanya ce da "sarrafa laifuka´da GIS da Nijeriya" 21,24,26,37,34,45,53,54,56,65 Te Scientifc World Journal 21 Table 4. Te term "overall" as used in Table 4 depicts the average percentage parity of precision@10, recall@10, or F-measure@10 of the indigenous languages with the English language and, thus, represents the search retrieval performance of the IRS for non-English language speakers. In particular, the overall parity F-measure is taken as the Figure 10: Lingual agnostic IRS recall@10 line graph for selected language topics (source: authors). ...
Article
Full-text available
The exclusion of monolingual natives from cyberspace is a global socioeconomic and cultural problem. Efforts at addressing this problem have been socioeconomic, culminating in training, empowerment, and digital access with the indelible hurt of language inequities. This paper is aimed at the cyber-inclusion of monolingual natives. Since cyber participation is basically through human interaction with cyber-applications in a human language, encapsulating these applications for interaction in any human language will help evade the hurt of language inequities. Information retrieval system (IRS) remains a fundamental cyber-application. Consequently, adopting the design science research methodology, we introduced a lingual agnostic IRS architecture designed on the principle of transparency on user language detection, information translations, and caching. The detailed design of the architecture was done using the unified modeling language. The designed IRS architecture has been implemented using the agile and component-based software engineering approaches. The resultant lingual agnostic IRS (LAIRS) was evaluated using heuristics and system evaluation methods for parity of language of interaction against the default language and was excellently stable across queries and languages, guaranteeing 86% parity with the default language in the use of other languages for information access and retrieval. Furthermore, it has been shown that LAIRS is the most appropriate IRS to address the problem of language barriers to cyber-inclusion compared with existing IRSs.
...  Visualización de consultas y generación de reportes en distintos formatos, inclusive XPDL, para comunicarse con otras aplicaciones. Los pasos son las actividades que deberán realizarse para llevar a cabo algún proceso (Rumbaugh, Jacobson, Booch, 1999). ...
Article
El objetivo de este trabajo es caracterizar un método que permita la trazabilidad y validación de requerimientos funcionales de un sistema de información mediante la transformación de modelos conceptuales. Para lo cual se construyó un software denominado SIAR (Sistema Integral de Administración de Requerimientos) que administra los requerimientos funcionales y utiliza UML (Lenguaje Unificado de Modelado) para su representación como Casos de Uso. La finalidad principal de esta aplicación web es la gestión de Casos de Uso con una herramienta que agilice su registro, normalice su contenido y posibilite la trazabilidad de los cambios e implemente validaciones funcionales. Por ejemplo, un procedimiento automatizado de análisis de consistencia de Casos de Uso, para lo cual el sistema genera un grafo con la transición de estados de cada Caso de Uso que es analizado en un simulador de autómata finito determinista para verificar la cohesión de los escenarios en él definidos.Abstract: The goal of this paper is to characterize a method that allows the traceability and validation of functional requirements of a computer system by transforming conceptual models with SIAR (Integrated System of Requirements Management). This software manages the functional requirements describing them as Use Cases using UML (Unified Modeling Language). The main purpose of this web application is the Use Cases management with a tool to expedite registration, normalize its contents and enable the traceability of changes and implement functional validations. For example, an automated process for consistency analysis of Use Cases, for which the system generates a graph with the state transition of each Use Case. Finally, the graph is analyzed in a deterministic finite automata simulator to verify the consistency of the defined scenarios defined.keywords: Traceability, Validation, Functional requirement, Conceptual model, UML, Deterministic finite automata.
... Por lo tanto, las interfaces requeridoras sólo pueden conectarse a interfaces proveedoras. Tanto los componentes como los conectores así como sus conexiones son visualmente representados en UML 2 (Rumbaugh et al., 1999). Se hace una distinción entre tres clases de componentes (esto también aplica a conectores): tipos de componentes, componentes de software e instancias de componentes. ...
Article
Full-text available
A diferencia de otras áreas de ingeniería, el nivel de reuso en la ingeniería de software es muy bajo. Los sistemas orientados a objetos fallaron en su promesa para crear un mercado de librería de clases. La tecnología de componentes de software está emergiendo como una aproximación que promete alcanzar el nivel de reuso que los sistemas orientados a objetos no pudieron alcanzar. Las plataformas actuales de componentes EJB, COM, .NET y CCM han sido exitosas para lograr ensamblar componentes de software. Sin embargo, en la práctica actual el ensamble de componentes de software es una tarea compleja. Más aún, un diseño realizado para un modelo de componentes, por ejemplo EJB, no puede ser reusado para los otros estándares. El paradigma llamado fábricas de software surge como una alternativa para solucionar esta problemática. Una fábrica de software básicamente involucra el reuso sistemático de recursos como son los requerimientos, diseño arquitectónico, software, y la experiencia de la gente entre otros. Aquí se presenta un marco de trabajo de una fábrica de software, mismo que se enfoca en incrementar el nivel de reuso en dos dimensiones: diseño arquitectónico y componentes de software. Se ilustra la propuesta a través de un caso de estudio para los modelos de componentes de EJB y COM.
... The Unified Modelling Language (Rumbaugh, Jacobson & Booch, 1998) emerged as a standardisation of the leading object-oriented analysis and design methods that were competing for favour in the late 1980s and early 1990s. This unification was brought about by three of the methods advocates joining forces at a major software tools company, Rational Software. ...
Thesis
p>This thesis explores barriers to using formal specification for software development in industry. Empirical assessment techniques are used initially in an exploratory stage and subsequently in testing a hypothesis arising from the first stage. A second hypothesis is investigated by construction of a method and tool with subjective assessment of its effect. The first stage consists of a survey of experienced industrial formal methods users via a questionnaire-based interview. The interview explore the practicalities of using formal methods in an industrial setting. From the many findings in this stage, two hypotheses are selected for further investigation. The first hypothesis is that formal specification are no more difficult to understand than code. This is tested by formal experiment. The subject's ability to understand the functionality of a formal specification is compared with their ability to understand its implementation in program code. The second hypothesis is derived from observations, during the survey stage, that formal specifications are difficult to write. In particular, choosing appropriate abstractions is difficult. We consider what might make formal specification difficult and compare the process with that of programming. The second hypothesis is that a tool supported, graphical modelling notation would be of benefit in the process of writing a formal specification. Such a notation is devised by adapting the UML and augmenting it with a formal text notation. A tool that converts this graphical formal specification into the formal notation, B is described and examples of its use are analysed.</p
... Even though it is a seminal book on UML, The UML User Guide [21] only dedicates a 1-page to briefly introduce templates: using a single example of a class template that shows the graphical notation for the signature, binding relationship, and actual arguments. The UML Reference Manual [22] is the book with the lengthiest sections on templates. Even so, it only introduces class and interface templates. ...
Article
Full-text available
UML templates are possibly the most neglected and misused piece of knowledge in UML modeling. This subject has been disregarded in the research and practice literature and even by modeling tools providers. This paper suggests that such oblivion results from a general misunderstanding that UML templates are just graphical representations of genericity like it is found in programming languages, and from the insufficient support from the modeling tools, with a consequence of poor usage of UML templates in practice. Indeed, the capabilities and potential of UML templates are far-reaching. As such, increasing awareness around them could bring large benefits for UML users, namely in what concerns higher-level of abstraction and reuse. Therefore, this paper provides a distilling tutorial on UML templates that aims to highlight their flexibility and advantages. That presentation follows a tutorial style and is supported by several illustrative examples, varying from simpler to more complex ones. This tutorial reviews the Template construct’s core concepts and terminology, presents constraining classifiers, and shows how to define properties and operations as template parameters. Then, it presents and discusses advanced aspects such as operation templates, parameter defaults, the relationship between binding and generalization, and the specific semantics of package templates. Furthermore, the paper discusses the related work and uncovers some of the UML templates’ limitations and opportunities for improvement.
... A significant difference is however evident during communication with external (Web Services) systems, when it has to perform the ritual of invocation, serialization/deserialization and deployment (Hansen, 2007). At this stage UML modeling symbols proved inadequate and we had to adopt the SOAP router class symbol in Hansen, (2007), which is reproduced in (Rumbaugh et al., 1999). ...
Article
Full-text available
ROA an acronym for Replication Oriented Architecture is speculated as capable of attenuating the scalability defect of Web Services and help application programmers build scalable Web Services solution. For this claim to be considered, it is ordinarily necessary to establish that Web Services solution can be built on ROA; and this is the essence of this paper. We have introduced the implementation equivalent of ROA for a Web Service using Java technologies. The Java technologies were Servlet, Enterprise Java Bean (EJB), Java Messaging Service (JMS) and SOAP with Attachment API for Java (SAAJ). A prototype ATM system has been built using the Java implementation equivalent of ROA for a replica size of three. The development environment was NetBeans Integrated Development Environment version 6.0 (NetBeans 6.0). Sun Java System Application Server Platform Edition 9 was the build and runtime environment for the three service replicas as well as the replication logic; all in the same computer system. The successful deployment and consumption of the prototype system shows that Web Services solution can be built on ROA.
... Activity diagrams are graphical representations of workflows of stepwise activities and actions with support of choice, iteration and concurrency (Rumbaugh & Jacobson, 1999). In unified modelling language, activity diagrams are intended to model both computational and organizational processes (i.e. ...
Thesis
Full-text available
Traditionally, bus ticket purchase has been over the counter in bus terminals, however, today it has evolved with the rapid expansion of e-commerce. This project addresses the study and development of an Online Bus Ticketing System web portal that enable customers (passengers) and the staff to make an online bus ticket sale/purchase, ticket cancel, ticket postponement, driver rating, generating of reports and etc. which also act as an operation tool for bus ticketing companies to operate their organization effectively. This research critically assess and study the reason behind the evolution and the current eticketing systems. This research project also addresses the problems faced by customers and bus drivers especially on illegal bus operations, long wait to purchase a bus ticket, unsafe environment and many more. The project studies some issues on implementation and also recommendations on how Online Bus Ticketing System web portal can take place effectively. This project also recommends a Decision Support System to deal with the customer's requirement whereby it provides reliable choices to a customer to make III decision. This project includes the development of a prototype Online Bus Ticketing System web portal to support the research objective. This web portal will assist in future development that would support a fully integrated system that links staff of the bus company to customers, staff to staff, staff to other mode of transport providers, staff to businesses and staff to government agencies. PHP, CSS, HTML, JavaScript, Ajax, jQuery, MYSQL database and WampServer are the programming tools used in development of this research project.
Article
Full-text available
Dealing with interpretation, we first revisited the theoretical models of hermeneutics (hermeneutical cycle), semantics (triangle) and information sciences, as well as the model of heritage interpretation pedagogy. To design a more appropriate heritage interpretation model that meets the requirements of full public participation, we defined the key concepts (on top of heritage interpretation itself): memory, knowledge and values. The arguments for such a choice have been expounded from three viewpoints: semantics (defining their current meaning and etymology of terms), neuroscience and heritage studies (in Slovenia and some other countries, we use the term ‘heritology’ – denoting the interdisciplinary field of heritage studies). The paper concludes by outlining the heritage interpretation model, graphically presented in two diagrams: the structural one in the form of a three-circle Venn diagram with the corresponding matrix and the process diagram following the adaptive management pattern. The discussion presents critical issues of the model and points out some advantages of its practical implementation.
Conference Paper
BPMN (Business Process Model and Notation) is a standard business process model that is accepted both nationally and internationally. The class diagram is a UML diagram that describes the classes in a system and their relationship between one class and another. As part of the process innovation, this research proposes a generator system that can be time-efficient in creating complex Class Diagrams with BPMN and Database. This research identifies and analyzes every element of BPMN (XPDFL file) and Database (XML file) relevant to making a Class Diagram. While the output of the system is a class diagram that displays classes, attributes contained, methods used, and relations between classes. Evaluating the performance of the Generator System was done by comparing and assessing the class diagrams generated by the system with class diagrams designed by experts. The confusion matrix method was used to measure the performance of the Generator System. The Generator System achieved an accuracy of 97.4%, which means that this proposed system’s performance is good.
Article
Semarang merupakan kota yang memiliki banyak potensi pariwisata, salah satunya yaitu wisata kuliner. Sekarang ini, masyarakat masih mengalami kesulitan dalam menemukan lokasi kuliner yang sesuai dengan preferensi yang diinginkan seperti jenis makanan, harga makanan, lokasi dan fasilitas restoran.Perkembangan teknologi saat ini, informasi bisa didapatkan dimanapun dan kapan pun. Salah satunya yaitu dengan menggunakan smartphone bersistem operasi Android.Sistem Pendukung Keputusan Wisata Kuliner Berbasis GIS pada Perangkat Android dapat digunakan sebagai solusi untuk menentukan lokasi kuliner berdasarkan preferensi yang diinginkan. Metode yang digunakan dalam sistem pendukung keputusan ini adalah Simple Additive Weighting. Sistem ini menggunakan bahasa pemrograman Java untuk client dan bahasa pemrograman PHP untuk administrator, dengan database management system MySQL, dan didukung dengan peta digital Google Maps API. Hasil dari Sistem Pendukung Keputusan ini adalah rangking lokasi kuliner berdasarkan preferensi yang diinginkan dan letak lokasi kuliner tersebut pada Google Maps.
ResearchGate has not been able to resolve any references for this publication.