Software modelling languages: A wish list

© 2015 IEEE. Contemporary software engineering modelling tends to rely on general-purpose languages, such as the Unified Modeling Language. However, such languages are practice-based and seldom underpinned with a solid theory-be it mathematical, ontological or concomitant with language use. The future of software modelling deserves research to evaluate whether a language base that is compatible with these various elements as well as being philosophically coherent offers practical advantages to software developers

Variations in Conceptual Modeling: Classification and Ontological Analysis

Conceptual models are aimed at providing formal representations of a domain. They are mainly used for the purpose of understanding and communicating about requirements for information systems.Conceptual modeling has acquired a large body of research dealing with the semantics of modeling constructs, with the goal to make models better vehicles for understanding and communication. However, it is commonly known that different people construct different models of a given domain although all may be similarly adequate. The premise of this paper is that variations in models reflect vagueness in the criteria for deciding how to map reality into modeling constructs. Exploring model variations as such can contribute to research that deals with the semantics of modeling constructs.This paper reports an exploratory study in which empirically obtained model variations were qualitatively analyzed and classified into variation types. In light of the identified variation types, we analyzed two ontology-based modeling frameworks in order to evaluate their potential contribution to a reduction in variations. Our analysis suggests that such frameworks may contribute to more conclusive modeling decision making, thus reducing variations. However, since there is no complete consistency between the two frameworks, in order to reduce variations, a single framework should be systematically applied

An Ontological Analysis of Use Case Modeling Grammar

Use case modeling is a popular technique for representing the functional requirements of an information system. The simple graphical notation of use case diagrams, accompanied by well-structured narrative descriptions, makes use case models fairly easy to read and understand. This simplicity, however, belies the challenges associated with creating use case models. There is little, if any, theory underlying use cases, and little more than loose guidelines for creating a complete, consistent, and integrated set of use cases. We argue that there is a need for more rigor and consistency in the grammatical constructs used in use case modeling. Toward this end, we present a theoretically- and practice-based assessment of use case modeling constructs, and make recommendations for future research to improve and strengthen this technique

Systemic Classification of Concern-Based Design Methods in the Context of Enterprise Architecture

Enterprise Architecture (EA) is a relatively new domain that is rapidly developing. The primary reason for developing EA is to support business by providing the fundamental technology and process structure for an IT strategy [TOGAF]. EA models have to model enterprises facets that span from marketing to IT. As a result, EA models tend to become large. Large EA models create a problem for model management. Concern-based design methods (CBDMs) aim to solve this problem by considering EA models as a composition of smaller, manageable parts concerns. There are dozens of different CBDMs that can be used in the context of EA: from very generic methods to specific methods for business modeling or IT implementations. This variety of methods can cause two problems for those who develop and use innovative CBDMs in the field of Enterprise Architecture (EA). The first problem is to choose specific CBDMs that can be used in a given EA methodology: this is a problem for researchers who develop their own EA methodology. The second problem is to find similar methods (with the same problem domain or with similar frameworks) in order to make a comparative analysis with these methods: this is a problem of researchers who develop their own CBDMs related to a specific problem domain in EA (such as business process modeling or aspect oriented programming). We aim to address both of these problems by means of a definition of generic Requirements for CBDMs based on the system inquiry. We use these requirements to classify twenty CBDMs in the context of EA. We conclude with a short discussion about trends that we have observed in the field of concern-based design and modeling

Hybrid model checking approach to analysing rule conformance applied to HIPAA privacy rules, A

2017 Summer.Includes bibliographical references.Many of today's computing systems must show evidence of conformance to rules. The rules may come from business protocol choices or from multi-jurisdictional sources. Some examples are the rules that come from the regulations in the Health Insurance Portability and Accountability Act (HIPAA) protecting the privacy of patient information and the Family Educational Rights and Privacy Act (FERPA) protecting the privacy of student education records. The rules impose additional requirements on already complex systems, and rigorous analysis is needed to show that any system implementing the rules exhibit conformance. If the analysis finds that a rule is not satisfied, we adjudge that the system fails conformance analysis and that it contains a fault, and this fault must be located in the system and fixed. The exhaustive analysis performed by Model Checking makes it suitable for showing that systems satisfy conformance rules. Conformance rules may be viewed in two, sometimes overlapping, categories: process- aware conformance rules that dictate process sequencing, and data-aware conformance rules that dictate acceptable system states. Where conformance rules relate to privacy, the analysis performed in model check- ing requires the examination of fine-grained structural details in the system state for showing conformance to data-aware conformance rules. The analysis of these rules may cause model checking to be intractable due to a state space explosion when there are too many system states or too many details in a system state. To over- come this intractable complexity, various abstraction techniques have been proposed that achieve a smaller abstracted system state model that is more amenable to model checking. These abstraction techniques are not useful when the abstractions hide the details necessary to verify conformance. If non-conformance occurs, the abstraction may not allow isolation of the fault. In this dissertation, we introduce a Hybrid Model Checking Approach (HMCA) to analyse a system for both process- and data-aware conformance rules without abstracting the details from a system's detailed process- and data models. Model Checking requires an analysable model of the system under analysis called a program graph and a representation of the rules that can be checked on the program graph. In our approach, we use connections between a process-oriented (e.g. a Unified Modelling Language (UML) activity model) and a data-oriented (e.g. UML class model) to create a unified paths-and-state system model. We represent this unified model as a UML state machine. The rule-relevant part of the state machine along with a graph-oriented formalism of the rules are the inputs to HMCA. The model checker uses an exhaustive unfolding of the program graph to produce a transition system showing all the program graph's reachable paths and states. Intractable complexity during model checking is encountered when trying to create the transition system. In HMCA, we use a divide and conquer approach that applies a slicing technique on the program graph to semi- automatically produce the transition system by analysing each slice individually, and composing its result with the results from other slices. Our ability to construct the transition system from the slices relieves a traditional model checker of that step. We then return to use model checking techniques to verify whether the transition system satisfies the rules. Since the analysis involves examining system states, if any of the rules are not satisfied, we can isolate the specific location of the fault from the details contained in the slices. We demonstrate our technique on an instance of a medical research system whose requirements include the privacy rules mandated by HIPAA. Our technique found seeded faults for common mistakes in logic that led to non-conformance and underspecification leading to conflicts of interests in personnel relationships

Supporting Automatic Interoperability in Model-Driven Development Processes

By analyzing the last years of software development evolution, it is possible to observe that the involved technologies are increasingly focused on the definition of models for the specification of the intended software products. This model-centric development schema is the main ingredient for the Model-Driven Development (MDD) paradigm. In general terms, the MDD approaches propose the automatic generation of software products by means of the transformation of the defined models into the final program code. This transformation process is also known as model compilation process. Thus, MDD is oriented to reduce (or even eliminate) the hand-made programming, which is an error-prone and time-consuming task. Hence, models become the main actors of the MDD processes: the models are the new programming code. In this context, the interoperability can be considered a natural trend for the future of model-driven technologies, where different modeling approaches, tools, and standards can be integrated and coordinated to reduce the implementation and learning time of MDD solutions as well as to improve the quality of the final software products. However, there is a lack of approaches that provide a suitable solution to support the interoperability in MDD processes. Moreover, the proposals that define an interoperability framework for MDD processes are still in a theoretical space and are not aligned with current standards, interoperability approaches, and technologies. Thus, the main objective of this doctoral thesis is to develop an approach to achieve the interoperability in MDD processes. This interoperability approach is based on current metamodeling standards, modeling language customization mechanisms, and model-to-model transformation technologies. To achieve this objective, novel approaches have been defined to improve the integration of modeling languages, to obtain a suitable interchange of modeling information, and to perform automatic interoperability verification.Giachetti Herrera, GA. (2011). Supporting Automatic Interoperability in Model-Driven Development Processes [Tesis doctoral no publicada]. Universitat Politècnica de València. https://doi.org/10.4995/Thesis/10251/11108Palanci

Estimation des risques d'incohérence liés à l'emploi d'UML pour le développement des systèmes

Les modèles UML peuvent présenter des incohérences dont le risque doit être maîtrisé par une méthodologie particulière: le management des risques. Nos travaux concernent une de ses étapes: l'estimation des risques. Les premières approches utilisées sont l'interview d'experts et le retour d'expériences sur des modèles UML déjà développés. Nous présentons les résultats obtenus par leurs usages puis leurs avantages et leurs limites. Une estimation analytique statique est ensuite proposée pour répondre aux limites mentionnées. Elle se base sur une mesure de complexité des parties du méta-modèle UML impliquées dans l'expression des règles de cohérence. Cette mesure de complexité utilise l'entropie de l'information issue de la théorie de Shannon. Des exemples d'application de cette nouvelle métrique à des règles de cohérence UML illustrent notre méthode.------------------------------------------------------------The UML models may involve inconsistencies whose risk has to be controlled by a specifie method: the risk management. Our works focus on one of its steps: the risk assessment. First, two approaches are used: interviews of experts and experience feedbacks on developed UML models. We present the results obtained using them, and then their benefits and limits. Second, a static analytic estimation method is proposed to handle the highlighted limits. It is based on a measurement of the complexity of the parts of the UML meta-model involved in the expressions of the consistency mies. This complexity measurement uses the information entropy principle from Shannon theory. This new measurement is applied on examples to illustrate its us

The resource-event-agent ontology as a foundation for business modeling

In de praktijk zijn bedrijfsinformatiesystemen—zoals een boekhoudsysteem, een voorraadbeheersysteem, een kostprijscalculatiesysteem, een ordermanagementsysteem — onderdeel van een veel grotere informatieverwerkende omgeving. Bijgevolg is het volgens Moody en Shanks onnuttig om bedrijfsinformatiesystemen los van elkaar te bekijken. In [MS03] stellen en tonen ze aan dat het beschouwen van informatiesystemen binnen deze bredere context cruciaal is voor het verkrijgen van kwaliteitsvolle informatiesystemen. Daarom voegen zijn ‘integratie’toe aan een lijst van reeds bestaande kwaliteitsfactoren voor het ontwerpen van informatiesystemen. Met integratie bedoelen ze de mate waarin de onderliggende infrastructuurmodellen van verschillende bedrijfsinformatiesystemen met elkaar overeenstemmen, wat de samenwerking tussen en het uitwisselen en hergebruik van data door deze systemen moet vergemakkelijken. Bij het ontwerpen van een informatiesysteem starten we met een conceptueel ontwerp. Zo’n conceptueel ontwerp stelt het beoogde informatiesysteem voor zonder details die specifiek zijn voor de gekozen technologie — zoals een webpagina, een database, software — te tonen. Een conceptueel model focust dus op het voorstellen van een conceptuele oplossing voor een bestaand probleem nog voor de technologische oplossing wordt ontworpen. Hoewel zo’n conceptueel model slechts een deel van de uiteindelijke oplossing voorstelt, stelt het de essentie van de oplossing voor—die dan eventueel in verschillende technologie¨en tegelijk kan worden uitgewerkt. Omdat deze oplossing essentieel is, moet een conceptueel model aan een reeks kwaliteitsparameters voldoen. Zo moet een conceptueel model een zo eenvoudig mogelijke maar toch volledige oplossing bieden voor een probleem. Ook moet de oplossing, voorgesteld in het conceptueel model, verstaanbaar zijn voor anderen dan de ontwerpers—bijvoorbeeld de programmeurs die de praktijkoplossing uitwerken of de klant die het systeem besteld heeft en zal gebruiken. Vaak probeert men ook te bereiken dat een systeem flexibel is, waarmee men bedoelt dat de oplossing rekening houdt met mogelijke veranderingen in de omgeving — zonder in te gaan tegen wat als gangbaar wordt beschouwd binnen de bredere informatieverwerkende omgeving of zonder moeilijk te verwezenlijken te zijn binnen het vooropgestelde budget en de beoogde planning. Zonder deze kwaliteitsfactoren uit het oog te verliezen, focussen we in deze doctoraatsthesis op de integratie van informatiesysteemontwerpen, die door Moody en Shanks werd voorgesteld en waarvan zij substanti¨ele voordelen aantoonden. Aangezien er vele verschillende soorten conceptuele modellen bestaan, kiezen wij er in deze thesis twee specifieke soorten uit, namelijk conceptuele datamodellen en simulatiemodellen. We kiezen datamodellen omdat zij een van de meest essenti¨ele soorten conceptuele modellen voorstellen. Conceptuele datamodellen stellen immers de basis van elke informatiesysteem voor. Bijgevolg is de keuze voor of het ontwerp van een datamodel een van de meest cruciale stappen in het ontwerp van een informatiesysteem die invloed heeft op o.a. de uiteindelijke kost van het project, de flexibiliteit van het resulterende systeem, de klantentevredenheid en de integratie met andere (bestaande) informatiesystemen. Waar conceptuele datamodellen ons toelaten een ontwerp te maken voor de data die in informatiesystemen worden bijgehouden over de huidige toestand en historiek van een voor ons relevant deel van de realiteit, laten simulatiemodellen ons toe een ontwerp — dat met potenti¨ele toekomstige situaties kan omgaan — te formuleren van een voor ons relevant deel van een omgeving. Samen laten conceptuele data- en simulatiemodellen ons dus toe het verleden, heden en de toekomst van een voor ons relevant deel van de realiteit voor te stellen. In deze thesis is dat relevant deel van de realiteit de bedrijfseconomische context. Aangezien deze bedrijfseconomische context dynamisch — en dus inherent onstabiel — is met steeds wijzigende en slechts gedeeltelijk gespecificeerde systeemvereisten — wat flexibiliteit vereist — is een speciale aanpak noodzakelijk. Deze aanpak heet ‘Design Science’ [HMJR04] en houdt ook rekening met hoe succesvolle informatiesysteemontwerpen afhankelijk zijn van de cognitieve en sociale vaardigheden van de mensen die deze systemen gebruiken, ontwikkelen en ontwerpen. Om deze flexibiliteit en sociale en cognitieve vaardigheden te ondersteunen, gebruiken we een ontologie als basis voor het ontwerpen van de conceptuele dataen simulatiemodellen in deze doctoraatsthesis. Zo’n ontologie is een gedeelde beschrijving van het probleemdomein (bijvoorbeeld de bedrijfseconomische realiteit). Dat deze beschrijving gedeeld wordt, ondersteunt de sociale en cognitieve vaardigheden van de groep mensen die een informatiesysteem ontwerpt, omdat de beschrijving kan gebruikt worden als een referentiekader voor deze groep mensen. Daarenboven kan dit delen ervoor zorgen dat de beschrijving hergebruikt en verbeterd wordt bij opeenvolgende projecten door verschillende groepen. Dit hergebruik van de beschrijving van het probleemdomein ondersteunt dan impliciet de integratie tussen verschillende projecten, aangezien ze gebaseerd zijn op (verschillende delen van) dezelfde probleembeschrijving. De ontologie die wij in deze thesis hoofdzakelijk hanteren is de Resource- Event-Agent (REA) ontologie. Deze ontologie werd begin jaren ’80 ontwikkeld voor boekhoudinformatiesystemen, met het oog op een gedeelde dataomgeving waarin boekhouders en niet-boekhouders informatie delen over dezelfde economische gebeurtenissen — zoals aankopen, verkopen, productie. De ‘Resources’ beschrijven de producten (i.e. goederen en diensten) die verhandeld en geproduceerd worden. De ‘Events’ beschrijven de gebeurtenissen die de voorraden van deze producten veranderen. Bijvoorbeeld, een verkoop van producten vermindert de voorraad van de verkoper en vermeerdert de voorraad van de aankoper. De ‘Agents’ beschrijven de economische actoren die de goederen en diensten produceren, verkopen en aankopen. Ondertussen werd de REA-ontologie al gebruikt als basis voor boekhoudinformatiesystemen en een ISO open-edi standaard [ISO07] voor het uitwisselen van elektronische bedrijfsdocumenten, als methode voor het onderwijzen van boekhoudinformatiesystemen en nog veel meer. [GLP08] In het eerste hoofdstuk van datamodelsectie gebruiken we de REA- en UFOontologie om conceptuele datamodellen te structureren en af te bakenen zodat ze makkelijker te interpreteren zijn, voornamelijk door onervaren systeemontwerpers. De UFO (i.e. Unified Foundational Ontology) is een ontologie die speciaal werd ontworpen om conceptuele modellen te duiden. [BGHS+05] Van de gestructureerde conceptuele datamodellen wordt verwacht dat ze onervaren ontwerpers helpen conceptuele datamodellen te maken die compleet zijn en geen overbodige onderdelen bevatten. Onvolledige modellen en overbodige onderdelen zijn immers de meest voorkomende fouten die onervaren ontwerpers maken. De gestructureerde datamodellen die aan de onervaren ontwerpers worden aangeboden zijn patronen waarvan al bewezen is dat ze waardevolle oplossingen zijn voor bepaalde problemen binnen een specifieke context. Door deze patronen te structureren volgens de REA- en UFO-ontologie wordt de ontwerper verwacht sneller de overbodige en ontbrekende delen van een patroon te kunnen identificeren, naargelang van het probleem dat hij wenst op te lossen. Door de aangeboden structuur kan de ontwerper ook op zoek naar ontbrekende delen van zijn oplossing in andere patronen, die hij dan kan integreren in zijn bestaande onvolledige oplossing. Dit integreren van patronen heeft twee voordelen. Ten eerste wordt de integratie tussen systemen die (delen) van dezelfde patronen bevatten vergemakkelijkt, ten tweede wordt de kwaliteit van de modellen die werden gemaakt door onervaren informatiesysteemontwerpers verhoogd. In het tweede hoofdstuk van de datamodelsectie gebruiken we de REA-ontologie als basis voor het ontwikkelen van een conceptueel referentiedatamodel dat geschikt is om zowel productie- als transactiedata van verschillende handelspartners voor te stellen. Dat het datamodel data van verschillende handelspartners tegelijkertijd kan voorstellen, heeft als gevolg dat de integratie tussen de bedrijfssystemen van deze handelspartners sterk vergemakkelijkt wordt. Zowel het integreren van de verschillende informatiesystemen van elke individuele handelspartner (bijvoorbeeld verkoopsysteem en voorraadbeheer) als het integreren van informatiesystemen van verschillende handelspartners (bijvoorbeeld een aankoopsysteem met een verkoopsysteem) worden vergemakkelijkt. Het voorstellen van productieen transactiedata van verschillende handelspartners wordt verwezenlijkt door zowel het perspectief van de individuele handelspartners als het perspectief van een onafhankelijke derde partij expliciet in het datamodel te integreren. Door deze keuze is het datamodel geschikt om volledige waardesystemen voor te stellen. Zo’n waardesysteem bestaat uit de transacties tussen handelspartners in een waardenetwerk of toeleveringsketen (supply chain) en de bedrijfsprocessen die elk van deze handelspartners uitvoert. In het derde en laatste hoofdstuk van de datamodelsectie gebruiken we het conceptuele datamodel dat werd voorgesteld in het tweede hoofdstuk om een toepassing te ontwikkelen die het mogelijk maakt historische, huidige en toekomstige product- en geldstromen te volgen in een waardesysteem. Het gekozen voorbeeld toont hoe akkerbouwgewassen worden gebruikt voor humane consumptie en veevoeder. De dierlijke producten worden dan weer gebruikt voor humane consumptie en samen met de landbouwgewassen verwerkt in consumentenproducten. De excrementen vloeien terug naar de akkerbouw. Het beschreven waardesysteem toont hoe goederen- en geldstromen kunnen worden gevolgd bij transacties tussen handelspartners (bijvoorbeeld akkerbouwer en voedermolen) en hoe goederenstromen kunnen worden gevolgd doorheen de productieprocessen van deze handelspartners (bijvoorbeeld het verwerken van akkerbouwgewassen van verschillende herkomst in een lading veevoer). Bovendien toont de ontwikkelde toepassing dat diezelfde data kunnen worden gebruikt om de transacties tussen handelspartners weer te geven (bijvoorbeeld een akkerbouwer die graan verkoopt aan een voedermolen en daarvoor een vergoeding ontvangt). Diezelfde informatie kan dan ook gebruikt worden om geldstromen in kaart te brengen zoals gebeurt met de goederenstromen. Daarenboven wordt gedemonstreerd hoe niet alleen huidige en gewezen, maar ook hoe toekomstige transacties en goederen- en geldstromen in kaart kunnen worden gebracht (o.a. aan de hand van contracten en productieschema’s). In de levensmiddelenindustrie hebben dergelijke systemen voor het traceren van huidige en gewezen goederenstromen al hun nut bewezen wanneer gecontamineerde voedingstoffen werden aangetroffen of getransporteerd vee ziek bleek. Aan de mogelijkheden van dergelijke traceringsystemen voegen wij toe dat niet enkel de bron van de besmetting, maar ook het doel van de goederen en de geldstromen, kan worden ge¨ıdentificeerd. Hierdoor kunnen we de economische gevolgen van zo’n besmetting inschatten aan de hand van contracten en productieschema’s. Met de beschikbare informatie kunnen dan eventueel noodscenario’s worden uitgewerkt om de economische gevolgen van zo’n besmetting te beperken. Ook in andere sectoren kan zo’n traceringssysteem nuttig zijn. Zo kan het in kaart brengen van een volledig waardenetwerk voorkomen dat namaakgoederen in de reguliere handel terechtkomen, of dat geldstromen uit de reguliere economie worden gebruikt om illegale activiteiten wit te wassen of te financieren. Waar het tweede en derde hoofdstuk van de datamodelsectie REA-gebaseerde datamodellen voor de integratie van de informatiesystemen van handelspartners voorstellen, bevat de simulatiemodelsectie REA-gebaseerde simulatiemodelelementen die het toelaten bedrijfsprocesmodellen over bedrijfsgrenzen heen met elkaar te integreren zodat ook simulatiemodellen voor volledige waardesystemen kunnen worden ontwikkeld. De hoofdstukken in de datamodelsectie bevatten dus geen bedrijfsprocesmodellen, maar superstructuren die het mogelijk maken bedrijfsprocesmodellen te hergebruiken en te integreren over de grenzen van de onderneming heen. Daarenboven werden deze superstructuren zo ontworpen dat ze ook als zelfstandige elementen van simulatiemodellen voor transacties tussen handelspartners kunnen worden gebruikt. Dit betekent dan wel dat men abstractie maakt van de bedrijfsprocessen die deze transacties ondersteunen. Het eerste hoofdstuk van de simulatiemodelsectie analyseert de mogelijke configuraties (bijvoorbeeld eerst betalen dan halen, eerst halen dan betalen) voor transacties tussen handelspartners en de manier waarop deze configuraties de interne structuur van een bedrijf be¨ınvloeden. In deze analyse wordt er vooral gekeken naar het vermogen van een bedrijf om zijn activiteiten te financieren met het krediet dat handelspartners verlenen (bijvoorbeeld de betalingstermijn op facturen, voorschotten). De structuren in dit hoofdstuk worden voorgesteld als Petri-net gebaseerde workflowmodellen. Deze workflowmodellen laten toe te evalueren of een gegeven sequentie van transacties externe financiering (bijvoorbeeld een banklening) vereist of niet. Door de verschillende configuraties voor een sequentie van transacties te evalueren kan men de meest optimale (bijvoorbeeld diegene die zo min mogelijk externe financiering vereist) selecteren. Het tweede hoofdstuk van de simulatiemodelsectie bouwt voort op de modellen in het voorgaande hoofdstuk om ook statistische analyses van deze verschillende configuraties mogelijk te maken. In deze analyses hoeft men dus niet meer te vertrekken van een gegeven sequentie van transacties, maar kan men ook onzekerheid en variatie in rekening brengen. Door de REA-elementen toe te voegen aan simulatiemodelelementen, worden de capaciteiten van de huidige generatie statistische simulatiemodellen uitgebreid van het analyseren van logistieke processen naar het analyseren van volledige bedrijfsmodellen met inbegrip van de financi¨ele parameters en resultaten. In tegenstelling tot de workflowmodellen in het eerste hoofdstuk van de simulatiemodelsectie, hebben de statistische simulatiemodellen een gelaagde opbouw. De bovenste laag modelleert de transacties tussen bedrijven, de middelste laag modelleert de interne financi¨ele structuur van bedrijven en de onderste laag bevat bedrijfsprocesmodellen voor individuele bedrijfsprocessen. De gelaagde opbouw laat ons toe zowel de individuele lagen te simuleren als bedrijfsprocesmodellen in interne structuurmodellen te integreren en deze dan weer in transactiemodellen te integreren. In deze thesis ontwikkelen we dus een benadering voor het ontwikkelen en integreren van modellen binnen een bedrijfseconomische context. Deze benadering houdt in dat we conceptuele modellen ontwikkelen vanuit en toetsen aan een bedrijfseconomische ontologie. De bedrijfseconomische ontologie die we in deze thesis gebruiken is de REA-ontologie. Deze thesis toont aan dat de REA-ontologie geschikt is als basis voor het ontwikkelen en integreren van zowel conceptuele datamodellen als simulatiemodellen binnen een bedrijfseconomische context. Door het gebruik van deze benadering zouden we de bedrijfswereld niet enkel moeten kunnen uitrusten met robuustere datamodellen voor de bedrijfsinformatiesystemen die ze dagdagelijks gebruiken, maar ook met krachtigere beslissingsondersteunende hulpmiddelen die hen voorzien van de informatie die ze nodig hebben voor het evalueren en voorspellen van de prestaties van hun bedrijf. Die informatie kan dan zowel van financi¨ele (bijvoorbeeld winstmarges) als operationele (bijvoorbeeld wachttijden) aard zijn. Het evalueren kan gebeuren op basis van de data die zijn opgeslagen in de bedrijfsinformatiesystemen en het voorspellen kan gebeuren door het genereren van hypothetische data in simulatiemodellen voor toekomstige bedrijfsprocessen en omgevingsomstandigheden

Formalization of the whole-part relationship in the unified modeling language

A formal definition for the semantics of the Whole-Part relationship in the Unified Modeling Language or UML is introduced. This provides a fully directly usable specification which that can be incorporated into version 2.0 of UML. An improvement to the current metamodel fragment relating to relationships is proposed, supplemented by the introduction of axioms expressed in the Object Constraint Language or OCL. The overall formalizatlon relates to a clear and concise emphasis on carefully enunciated (primary) characteristics that apply to all instances of a new Whole-Part metatype. Specific kinds of the Whole-Part relationship are defined in terms of secondary characteristics, which must be possessed by subtypes: In UML 1.4, these are Aggregation (a.k.a. white diamond) and Composition (a.k.a. black diamond). Primary and secondary characteristics may then be consistently combined with each other. Consequently, this allows the possible introduction of supplementary forms of Whole-Part. Such a revision is necessary since Aggregation and Composition in UML 1.4 do not cover the full spectrum of Whole-Part theory