From UML Specification into Implementation using Object Mapping

In information systems, a system is analyzed using a modeling tool. Analysis is an important phase prior to implementation in order to obtain the correct requirements of the system. During the requirements phase, the software requirements specification (SRS) is used to specify the system requirements. Then, this requirements specification is used to implement the system. The requirements specification can be represented using either a structure approach or an object-oriented approach. A UML (Unified Modeling Language) specification is a well-known for representation of requirements specification in an object-oriented approach. In this paper, we present one case study and discuss how mapping from UML specification into implementation is done. The case study does not require advanced programming skills. However, it does require familiarity in creating and instantiating classes, object-oriented programming with inheritance, data structure, file processing and control loop. For the case study, UML specification is used in requirements phase and Borland C++ is used in implementation phase. Based on the case study, it shows that the proposed approach improved the understanding of mapping from UML specification into implementation.

💡 Research Summary

The paper addresses a persistent gap in software development: the translation of high‑level, object‑oriented requirements captured in UML (Unified Modeling Language) into concrete source code. It proposes a systematic “object‑mapping” methodology that directly relates each UML construct to a corresponding element in a Borland C++ implementation. The authors first emphasize the role of the requirements phase, where functional and non‑functional needs are modeled using UML diagrams—class diagrams for static structure, sequence diagrams for dynamic interactions, and state diagrams for lifecycle behavior.

A set of explicit mapping rules is then defined. Each UML class becomes a C++ class declaration; attributes map to member variables, operations to member functions, and visibility modifiers (+, –, #) to public, private, or protected access specifiers. Generalization relationships are realized as inheritance (public or protected), with multiple inheritance handled via abstract base classes that serve as interfaces. Associations, aggregations, and compositions are expressed through pointers, references, or STL containers (e.g., std::vector), and multiplicities are enforced by container size checks or runtime validation.

Dynamic behavior captured in sequence diagrams is transformed into call sequences in code. Every message translates to a function call, with parameters and return values preserved; guard conditions become conditional statements, and loops in the diagram become for/while constructs. State diagrams are implemented using either a switch‑case dispatch or the State design pattern, ensuring that state‑transition actions and guard conditions are faithfully reproduced.

The methodology is demonstrated through a case study: a modest library‑management system. In the analysis stage, the authors model entities such as Book, Member, and Loan, define their relationships (e.g., a Member can have many Loans), and capture constraints (loan period limits, availability checks). Applying the mapping rules, they generate C++ header and source files. For example, the Book class contains fields for ISBN, title, and author, plus an isAvailable() method; Member inherits from a generic Person class and holds a std::vector to track borrowing history; Loan encapsulates loan and return dates and implements state transitions (borrowed → returned) as defined in the UML state diagram.

Implementation proceeds in Borland C++ because the IDE offers integrated project management, automatic header/source generation, and a straightforward debugging environment. File persistence is handled with the standard fstream library, storing data in plain‑text files. The main program presents a menu‑driven control loop that mirrors the sequence diagram’s interaction flow: users can add, search, modify, delete records, and trigger file save/load operations. Because each menu action directly corresponds to a UML‑defined sequence, developers can verify correctness by cross‑checking the diagram with the code.

Empirical observations from the case study indicate several benefits. First, the one‑to‑one mapping makes the design intent transparent; developers can glance at a UML diagram and predict the resulting class hierarchy and method signatures, reducing misinterpretation. Second, even programmers with limited experience in object‑oriented programming can grasp core concepts (encapsulation, inheritance, polymorphism) through the visual‑to‑code translation, leading to fewer implementation errors. Third, when design changes occur (e.g., adding a new attribute or altering an association), the impact on source code is immediately apparent, facilitating rapid refactoring.

However, the authors acknowledge limitations. The mapping process is manual; while feasible for small educational examples, large industrial systems would benefit from tool‑supported automation to enforce consistency and detect mismatches. The study’s reliance on Borland C++ ties the approach to a specific compiler and IDE, making direct transfer to modern C++ standards, Java, C#, or other platforms non‑trivial. Moreover, the paper does not address advanced UML features such as templates, genericity, or deployment diagrams, which could complicate the mapping in more sophisticated contexts.

In conclusion, the paper demonstrates that a disciplined object‑mapping strategy can bridge the analysis‑implementation divide, improve developers’ comprehension of requirements, and enhance code quality without demanding advanced programming expertise. Future work is proposed to develop semi‑automatic mapping tools and to validate the methodology across diverse programming languages and larger, real‑world systems.