Academia.edu no longer supports Internet Explorer.
To browse Academia.edu and the wider internet faster and more securely, please take a few seconds to upgrade your browser.
2009, Proceedings of the International Workshop on Enterprises & Organizational Modeling and Simulation - EOMAS '09
…
14 pages
1 file
There are only very few approaches to normalizing objectoriented data. In this paper we present an approach to normalization of the object-oriented conceptual model based on UML class diagrams. First part of the paper describes the current status in the area of formal methods used for object-oriented data modeling. Second part presents four normalization rules, which are based on own experience and modied Ambler-Beck approach. These normalization rules are introduced on an example. Our method has been used in education at several universities. It has been and is also used for database design in software development projects, which we carried out. Recently, development of the CASE tool based on this approach has been started. Keywords. Data normalization, object-oriented data model (ODM), relational data model (RDM), rst object-oriented normal form (1ONF), second objectoriented normal form (2ONF), third object-oriented normal form (3ONF), fourth object-oriented normal form (4ONF).
Journal of Database Management, 2000
The Unified Modeling Language (UML) is becoming widely used for software and database modeling, and has been accepted by the Object Management Group as a standard language for object-oriented analysis and design. For data modeling purposes, UML includes class diagrams, that may be annotated with expressions in a textual constraint language. Although facilitating the transition to object-oriented code, UML's implementation concerns render it less suitable for developing and validating a conceptual model with domain experts. This defect can be remedied by using a fact-oriented approach for the conceptual modeling, from which UML class diagrams may be derived. Object-Role Modeling (ORM) is currently the most popular fact-oriented approach to data modeling. This paper examines the relative strengths and weaknesses of ORM and UML for data modeling, and indicates how models in one notation can be translated into the other.
Information Sciences, 1990
design tools have been introduced as a means of reducing the expertise required of the designer, to free him or her from the implementation details, and to aid in managing the complexity of the design task. However, one of the common shortcomings of database design tools is that they are closely tied to specific data models, thus limiting the applicability of their underlaying concepts and restricting the reusability of the design software. Seaweed, a component of the Data Model Compiler (DMC) project, proposes a solution by automatically generating database design software from data model specifications. In this paradigm, a data model specification model, or metamodel of data models, is introduced for specifying particular object-oriented data models. Using the knowledge in the specification, conceptual database design software is automatically generated for the given data model. This paper presents a metamodel for object-oriented data models and offers a technique for expressing the semantics of an object-oriented data model in terms of the metaobject types, which consist of attributes, operations, constraints, and graphical representations.
Advances in Object-Oriented Data Modeling, 2000
Object-oriented Modeling has become the prime methodology for modern software design. Not since the conception of Structured Programming appeared has a new software technology had a similar impact. Today many textbooks, professional guides, and CASE tools support object-oriented software design. However, objectoriented data modeling has not kept pace, and the papers in this volume illustrate a range of issues that are still being dealt with. Object-orientation in software creation is simpler than object-oriented data modeling, because a specific program represents one approach to a solution, and hence one point-of-view. Data are commonly shared, and participants can hence approach the modeling from multiple points-of-view. For instance, early relational systems supported implicitly multiple points-of-view, since they only provided the simple semantics of isolated tables (3). The relational model complements the simple storage structure with algebraic manipulation of these structures. Moving to a calculus allowed automation in processing of "what" queries rather than following programmatic "how" instructions. Having an algebra also enabled the optimizations that were required. Alternate expressions over the tables define alternate views, which are mutually independent. Even now, relational processing capabilities remain weak. The relational SQL language has mainly one verb: "SELECT". UPDATES are severely restricted to the full database, since views, essential to understand subsets of complex data-structures, cannot be updated in general. To assure consistency among views there has to be more, namely a shared model. Entity-Relationship models provided quantitative structural semantics (2), but, until recently, this information remained in the design phase, and at most provided documentation for subsequent program creation. A formalization of the Entity-Relationship model, allowing matching of the relational transfers, the Structural Model (5) did not have a significant impact, since data modeling remained informal until objects started to emerge as first class data structures (1). Subsequent additions to relational systems provide the specification of integrity constraints, and these will limit the structural choices. For instance, combining uniqueness and a reference constraint will assure conformance to a 1:n relationship among two tables. Providing constraints is important for consistency and sharability. Still, the methods used to manage conformance remain outside of this model, so that xii Foreword xviii Preface recent findings in the topic covered, as well as directions for future research and development. This book is unique in that it takes a unified view of different techniques and developments in the area of object-oriented data modeling and reports on recent work that can only be found scattered throughout the literature. This book is useful for both researchers, software professionals, and advanced students who are working, or intending to work, on the area of object-oriented modeling. Some familiarity with object-oriented programming languages and database systems is required. The reader will learn a variety of ways of applying the object-oriented paradigm in the context of data modeling. This book has a dual purpose. It can be used in advanced courses on object-oriented data modeling or object-oriented software development focused around database systems. Furthermore, it represents a valuable source of information for software engineers, developers, and project managers who wish to familiarize themselves with object-oriented data modeling techniques and methodologies and apply some of the material covered in this book into practice. xx Preface Modeling of Reverse Engineering Applications Although the interest in objectoriented databases is growing, a major limitation on their acceptance in the corporate world is the amount of time and money invested in existing databases using the older data models ("legacy systems"). Obviously, the huge undertaking needed to convert from one database paradigm to another is a major expense that few corporations are willing to readily accept. What is needed are tools that allow corporations to generate the conceptual schemata and reveal the hidden semantics of current database applications efficiently and with limited user involvement. This process is known as database "reverse engineering" (or reengineering). Reverse engineering can be defined as a process of discovering how a database system works. Whether using reverse engineering to migrate between different database paradigms (from hierarchical to relational, relational to object-oriented), elucidating undocumented systems, or using it to forward engineer existing systems, reverse engineering involves a wide collection of tasks. The pivotal feature of all these tasks is the need to identify all the components of existing database systems and the relationships between them. This part of the book describes advanced modeling techniques for reengineering legacy database applications. The contribution of these techniques relies not only on proposed (reengineering) methodologies but also on the their use in real environments. Two main approaches for reverse engineering are described. The first approach, by Missaoui, Goding, and Gagnon, presents a complete methodology for mapping conceptual schemata into structurally object-oriented schemata. The main advantages of such a methodology is the use of an adapted clustering technique allowing recursive grouping of objects (e.g., entities and relationships) from an extended entity-relationship schema. xxv Preface any time until the car is picked up. This process requires coordination between the relevant Branch Manager and the Depot Manager, to ensure the Service Diary and the Car Bookings file are in step. When a service has been completed, a description of the work done and the parts and labor cost are added to the car service history, and the parts and labor cost to the service diary.
Informatik - Forschung und Entwicklung, 2004
The most common way of designing databases is by means of a conceptual model, such as E/R, without taking into account other views of the system. New object-oriented design languages, such as UML (Unified Modelling Language), allow the whole system, including the database schema, to be modelled in a uniform way. Moreover, as UML is an extendable language, it allows for any necessary introduction of new stereotypes for specific applications. Proposals exist to extend UML with stereotypes for database design but, unfortunately, they are focused on relational databases. However, new applications require complex objects to be represented in complex relationships, object-relational databases being more appropriate for these requirements. The framework of this paper is an Object-Relational Database Design Methodology, which defines new UML stereotypes for Object-Relational Database Design and proposes some guidelines to translate a UML conceptual schema into an object-relational schema. The guidelines are based on the SQL:1999 object-relational model and on Oracle8i as a product example.
2012
Object-oriented system modeling enables the sharing of responsibilities between system objects at a high level of system abstraction. The UML class diagram is the central part of the object-oriented system model and serves as a "bridge" between the information about the problem domain at the customer's side and the software components at the developer's side. However, UML is not a methodology for how to model the system, but just a notation for "drawing" of model elements. This paper demonstrates the functionality of the BrainTool, which enables the generation of the UML class diagram from the so called two-hemisphere model, where the problem domain is presented as a concatenation of the problem domain processes, incoming and outgoing information flows and their types. BrainTool is developed using Visual Studio .NET for modeling of the two-hemisphere model, the Python programming language for definition of transformation rules and XMI for model interchange with Sparx Enterprise Architect.
1990
This paper describes a design methodology for an object oriented database, based on a semantic network. This approach is based on the assumption that semantic data models are more powerful and more easy to use than current proposed object oriented data models. They are especially more powerful in representing integrity constraints and various relationships. Object oriented data models are generally based only on class hierarchies and inheritance, plus their ability to represent the behaviour of objects. But this latter capability is generally provided through an algorithmic language which cannot be considered as a conceptual language. In this paper, we combine the two categories of data models and give a procedure on how to translate the conceptual model to the logical model.
2010 International Conference on Computer Applications and Industrial Electronics, 2010
The Business Process (BP) requirements is specified in the form of software requirements specification (SRS). This SRS serves as a base for software development. The software needs to be developed in a syllogized software development life cycle (SDLC) stages. The SRS which denote the requirements of BP is used as input to the analysis stage from which the paradigm dependent components are to be abstracted. Hither to the components are abstracted manually with the exception of hiatuses of semiautomated methods for few of the components. The SRS is construed with reference to the specific paradigm through which the design is to be developed. Unfortunately, no complete automated methodology exists for the abstraction of all paradigm dependent components. The automated methodology eliminates the possible human errors which would have ripple effect to damage the entire software. This paper develops an innovative, unique methodology to resurrect the SRS statements as modular statements. Further develops an automated methodology for abstraction of control and data flow graphs. Further it develops an automated methodology for abstraction of useful components required for the class diagram. The class diagram emphasizes both structural and behavioral aspects. This facility is effectively used to abstract object class attributes, object methods, visibility, signature, return type etc. Information systems are developed through software projects which use the specific software requirements specification (SRS) provided for them as the base. The SRS contains details of the information system through which appropriate software can be developed. The information systems are also viewed perceptively with different pragmatics like work, work process or usecase. The usecase is one of the prime perspective views whose sum forms the information system. In this paper, an attempt is made to abstract object class, object class attributes, object methods, interrelationships between object classes and starting with/ending with actor from unformatted, unstructured SRS text. This is achieved through our own developed classing and slicing techniques to identify respectively the class structure & object methods. Then usecase is developed through the interrelationships between object methods of different classes and start with or end with the actor. The stages involve moulding the SRS, designing control flow graph for the SRS & data flow table for the SRS statements, developing appropriate classing and slicing criteria, creating actor & actors' interface attributes table, create slicing criteria for each usecase and then slice relevant statements for each usecase. Here, we have attempted to use Weiser modified algorithm 1 to abstract exact usecase. The slicing criterion is obtained through the intersection of actor's interface attributes and the referenced / defined attributes present between two consecutive actors. Attempts have been made to resolve synonyms & heteronyms present in the SRS. The correctness & completeness of the proposed methodology depends on the realization of actor & actors' interface attributes.
The design of complex information systems requires a transparent model-based methodology. It has been claimed that object orientation will have a signi cant impact on the development of such a methodology, especially as reusability and naturality of conceptual modelling are concerned. The methodology presented in this paper concentrates on four signi cant principles of object oriented database (OODB) design. The basic constituent is stepwise re nement, i.e. to begin the design process with a partial model that is completed and concretized furtheron depending on the growth of application knowledge. Class abstraction, i.e. to support libraries of incomplete parameterized designs that are instantiated and specialized later, is a natural consequence hereof. Declarativity is achieved by constraint centered design with (up to some degree) automatic transformation into consistent transactions. Variations enable the design of information systems with heavy reuse of existing design components. The methodology is based on a theoretically founded object oriented datamodel (OODM). Hence the support of inferences such as deciding the identi ability of objects, detecting the relation of an intended design to components in existing design libraries, and checking operations for reducedness as a prerequisite for the automatic transformation of constraints into consistent transactions.
1991
This paper describes a design methodology for an object oriented database, based on a semantic network. This approach is based on the assumption that Yemantic data models are more powerful and more easy to use than current proposed object oriented data models. They are especially more poweful in representing integrity constraints and various relationships, Object oriented data models are generally based only on class hierarchies and inheritance, plus their ability to represent the behavior of objects, But this latter capability is generally provided through an algorithmic language which cannot be considered as a conceptual language. This paper describes a design procedure which generates an object oriented database schema (both the structural aspect and the dynamic aspect) from an abstract specification giveri in a high level language. This specification language is built upon a semantic network and allows to define integrity constraints and behavior rules. This approach is presented through a CASE tool environment.
—Unified Modelling Language (UML) is as a standard object-oriented modelling notation that is widely accepted and used in software development industry. In general, the UML notation is informally defined in term of natural language description (English) and Object Constraint Language (OCL) which makes difficult to formally analyzed and error-prone. In this paper, we elucidate the preliminary result on an approach to formally define UML class diagram using logic-based representation formalism. We represent how to define the UML class diagram using Description Logics (DLs).
Loading Preview
Sorry, preview is currently unavailable. You can download the paper by clicking the button above.
Scientific Journal of Riga Technical University. Computer Sciences, 2011
Computer Science & Information Technology ( CS & IT ), 2013
Lecture Notes in Computer Science, 2001
German-Argentinian Workshop on Information Technology, 1999
Lecture Notes in Computer Science, 1995
Communications of The ACM, 1992