DESC:FIELD OF THE INVENTION
The present embodiment relates to a Unified Modeling Language (UML) diagram generation tool, and more particularly relates to a system and method for automatic generation of Unified Modeling Language (UML) diagrams.
BACKGROUND OF THE INVENTION
A Unified Modeling Language (UML) diagram is a diagram based on a UML language. High Level Design (HLD) document and Low Level Design (LLD) document contains UML diagrams that are either generated manually or are semi-automated with UML diagram generation tools.
Recently, various tools have been designed to auto-generate the UML diagrams, however, they also require a manual input. The HLD and LLD documents are manually interpreted from the user software requirement document and are then converted into a format that is further fed into the UML generation tool for generating the UML diagrams. The problems associated with these types of tools are that they require manual input and thereby increased risk of errors. These tools may also take time duration of up to 3 months based on the complexity and size of the software project.
Currently, there are no tools available in the market that makes the entire process of the generation of UML diagrams automatic.
Therefore, there is a need of a system and method that helps in overcoming the shortcomings of the existing tools. There is also a need for the system and method for automatic generation of UML diagrams.
OBJECTIVES OF THE INVENTION
An object of the present embodiment is to provide high level design document automation.
Another object of the present embodiment is to provide automated documentation saving millions of dollars lost in manual documentation, errors, delays, maintenance and future updates.
Yet another object of the present embodiment is to provide visual and user-friendly drag and drop designing and programming system.
SUMMARY OF THE INVENTION
In an aspect, a computer-implemented method for automated generation of Unified Modeling Language (UML) diagrams is provided. The method comprises: 1) Classifying client requirements into a plurality of feature groups, wherein the client requirements are listed in a Statement or scope of Work (SOW) document. 2) Categorizing the client requirements into domain design terms, wherein the domain design terms are normalized into domain elements (NDE) or fundamental software constructs (FSC) to define the Normalized Domain Model and System Architecture Definition (NDMSA). 3) Converting the NDMSA model for automatic generation of UML diagrams. 4) Generating UML diagrams based on user requirements, wherein the user requirements include class, use case, activity and sequence.
The preceding is a simplified summary to provide an understanding of some aspects of embodiments of the present invention. This summary is neither an extensive nor exhaustive overview of the present invention and its various embodiments. The summary presents selected concepts of the embodiments of the present invention in a simplified form as an introduction to the more detailed description presented below. As will be appreciated, other embodiments of the present invention are possible utilizing, alone or in combination, one or more of the features set forth above or described in detail below.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 illustrates a computer-implemented method (100) for automatic generation of Unified Modeling Language (UML) diagrams, according to an embodiment herein.
To facilitate understanding, like reference numerals have been used, where possible, to designate like elements common to the figures.
DETAILED DESCRIPTION
As used throughout this application, the word "may" is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include”, “including”, and “includes” mean including but not limited to.
The phrases “at least one”, “one or more”, and “and/or” are open-ended expressions that are both conjunctive and disjunctive in operation. For example, each of the expressions “at least one of A, B and C”, “at least one of A, B, or C”, “one or more of A, B, and C”, “one or more of A, B, or C” and “A, B, and/or C” means A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B and C together.
The term “a” or “an” entity refers to one or more of that entity. As such, the terms “a” (or “an”), “one or more” and “at least one” can be used interchangeably herein. It is also to be noted that the terms “comprising”, “including”, and “having” can be used interchangeably.
The present embodiment provides a computer-implemented system and method for automatic generation of Unified Modeling Language (UML) diagrams. The computer-implemented method for automatic generation of UML diagrams includes the following steps:
At step 102, client requirements are classified into a plurality of feature groups (mentioned in Table 1). In an embodiment, the client requirements are listed in a Statement or scope of Work (SOW) document. In an embodiment, the client requirements are classified through artificially intelligent Natural Language Processing (NLP) system.
In an embodiment, the plurality of feature groups include basic features, workflow features, performance features, optimization features, integration features, information features, privilege feature, security feature, business continuity feature, UI feature and infrastructure feature. In an embodiment, the plurality of feature groups helps in building the basic structure of the UML diagram.
FEATURE CATEGORIZATION
1. Basic Features - Add, Edit, Delete, Import, Export, Print, View
2. Workflow Features - Dynamic process features
3. Performance Features - Within 2 seconds app response, scalability to 10k concurrent connections, etc
4. Optimization Features - Adaptive features e.g. on handheld, mobile, 128kbps network, etc
5. Integration Features - Database to be Oracle, Integration with SAP, Gmail
6. Information Features - Reports, Dashboards, Website (help/public info access)
7. Privileges Features - Roles, Authority, Access Control, etc
8. Security Features - Encryption, Password protection, etc
9. Business Continuity Features - Backup, Archival, Data Storage for 5 years, etc
10. UI Features - Look, Color, Feel, Responsiveness
11. Infrastructure Features - Servers, PCs, etc Hardware to be provided along with the application
Table 1
At step 104, the client requirements are categorized into domain design terms. In an embodiment, the client requirements are categorized through artificially intelligent Natural Language Processing (NLP) system. The domain design terms are normalized into domain elements (NDE) or fundamental software constructs (FSC). The fundamental elements or software constructs are mentioned in Table 2.
NORMALIZED DOMAIN ELEMENTS
1. Attribute
2. Value Object
3. Entity
4. Aggregate
5. Relationship
6. Process
7. Event
8. Payload
9. Rule
10. Condition
11. Task
12. Input
13. Action
14. Output
15. API
16. Report
17. Form
18. Dashboard
19. Website
20. Role
21. Role-Process-Map
Table 2
In an embodiment, Configurational Parameter Specifications (CPS) may be provided by the user. In another embodiment, Configurational Parameter Specifications (CPS) may be set as default. In an embodiment, Configurational Parameter Specifications (CPS) may include parameters such as, but not limited to, programming language, database, deployment server port and IP address.
In an embodiment, the Normalized Domain Elements (NDE) and Fundamental Software Constructs (FSC) together define the Normalized Domain Model and System Architecture Definition (NDMSA). In an embodiment, the NDMSA model may be captured in a standard data format such as JSON/XML.
At step 106, NDMSA model is converted into a suitable format that is required by the present system. In an embodiment, the NDMSA model is used for the automatic generation of UML diagrams.
In an embodiment, features, configuration, architecture, environment and interface is previously documented in the system. In an embodiment, features, configuration, architecture, environment and interface is in the JSON/XML format.
At step 108, UML diagrams are automatically generated on the basis of user requirements. In an embodiment, the user requirements may include class, use case, activity and sequence.
In an embodiment, structural and behavioral diagrams are generated by the present method. In an embodiment, different types of structural diagrams include class diagram, object diagram, component diagram, composite diagram, deployment diagram, package diagram and profile diagram.
The class diagram consists of classes, interfaces, associations, and collaboration. Class diagrams basically represent the object-oriented view of a system, which is static in nature.
A UML object diagram represents a specific instance of a class diagram at a certain moment in time. Object diagram is an instance of a class diagram. That is an example diagram.
Component diagrams are used to model the physical aspects of a system such as executables, libraries, files, documents, etc. Component diagrams are used to visualize the organization and relationships among components in a system.
The following artifacts are to be identified clearly -
• Files used in the system.
• Libraries and other artifacts relevant to the application.
• The component diagram also contains dlls, libraries, folders, etc.
• Relationships among the artifacts.
Organization can be further described as the location of the components in a system. These components are organized in a special way to meet the system requirements.
A composite structure diagram performs a similar role to a class diagram, but allows you to go into further detail in describing the internal structure of multiple classes and showing the interactions between them. Composite Structure Diagrams allow the users to "Peek Inside" an object to see exactly what it is composed of. The internal actions of a class, including the relationships of nested classes, can be detailed. Objects are shown to be defined as a composition of other classified objects.
Deployment diagrams are used for describing the hardware components, where software components are deployed. Component diagrams and deployment diagrams are closely related. Component diagrams are used to describe the components and deployment diagrams show how they are deployed in hardware.
A package is a grouping of related UML elements, such as diagrams, documents, classes, or even other packages. Each element is nested within the package, which is depicted as a file folder within the diagram, then arranged hierarchically within the diagram. Packages are grouping things. Components are replaceable parts of system. Usually packages are identified in the analysis model and components in design model. Component diagrams are used in component based development
Profile diagram provides a generic extension mechanism for customizing UML models for particular domains and platforms. This is similar to Package diagram with additional notations.
An activity diagram provides a view of the behavior of a system by describing the sequence of actions in a process. It basically depicts workflows visually using an activity diagram.
Action: A step in the activity wherein the users or software perform a given task. In Lucidchart, actions are symbolized with round-edged rectangles.
Decision node: A conditional branch in the flow that is represented by a diamond. It includes a single input and two or more outputs.
Control flows: Another name for the connectors that show the flow between steps in the diagram.
Start node: Symbolizes the beginning of the activity. The start node is represented by a black circle.
End node: Represents the final step in the activity. The end node is represented by an outlined black circle
In an embodiment, different types of behavioral diagrams include use case diagram, activity diagram, state machine diagram, sequence diagram, interaction diagram, communication diagram and timing diagram.
In the Unified Modeling Language (UML), a use case diagram can summarize the details of your system's users (also known as actors) and their interactions with the system.
Common components include:
Actors: The users that interact with a system. An actor can be a person, an organization, or an outside system that interacts with your application or system. They must be external objects that produce or consume data.
System: A specific sequence of actions and interactions between actors and the system. A system may also be referred to as a scenario.
Goals: The end result of most use cases. A successful diagram should describe the activities and variants used to reach the goal.
Interaction overview diagram is a variant of the Activity Diagram where the nodes are the interactions or interaction occurrences.
The timing diagram describes how an object underwent a change from one form to another. A waveform portrays the flow among the software programs at several instances of time The cause of the change, as is the case in a state or sequence diagram, is the receipt of a message, an event that causes a change, a condition within the system, or even just the passage of time.
State machine diagram order of states underwent by an object within the system. It captures the software system's behavior. It models the behavior of a class, a subsystem, a package, and a complete system.
A communication diagram is an extension of object diagram that shows the objects along with the messages that travel from one to another. In addition to the associations among objects, communication diagram shows the messages the objects send each other. The communication diagram and the sequence diagram are similar. They're semantically equivalent, that is, the present the same information, and you can turn a communication to a sequence diagram and vice versa.
A sequence diagram is a type of interaction diagram because it describes how—and in what order—a group of objects works together. Sequence diagrams are sometimes known as event diagrams or event scenarios.
The foregoing discussion of the present invention has been presented for purposes of illustration and description. It is not intended to limit the present invention to the form or forms disclosed herein. In the foregoing Detailed Description, for example, various features of the present invention are grouped together in one or more embodiments, configurations, or aspects for the purpose of streamlining the disclosure. The features of the embodiments, configurations, or aspects may be combined in alternate embodiments, configurations, or aspects other than those discussed above. This method of disclosure is not to be interpreted as reflecting an intention the present invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment, configuration, or aspect. Thus, the following claims are hereby incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of the present invention.
Moreover, though the description of the present invention has included description of one or more embodiments, configurations, or aspects and certain variations and modifications, other variations, combinations, and modifications are within the scope of the present invention, e.g., as may be within the skill and knowledge of those in the art, after understanding the present disclosure. It is intended to obtain rights which include alternative embodiments, configurations, or aspects to the extent permitted, including alternate, interchangeable and/or equivalent structures, functions, ranges or steps to those claimed, whether or not such alternate, interchangeable and/or equivalent structures, functions, ranges or steps are disclosed herein, and without intending to publicly dedicate any patentable subject matter.

,CLAIMS:WE CLAIM:
1. A computer-implemented method for automated generation of Unified Modeling Language (UML) diagrams, the method comprises:
- Classifying client requirements into a plurality of feature groups, wherein the client requirements are listed in a Statement or scope of Work (SOW) document;
- Categorizing the client requirements into domain design terms, wherein the domain design terms are normalized into domain elements (NDE) or fundamental software constructs (FSC) to define the Normalized Domain Model and System Architecture Definition (NDMSA);
- Converting the NDMSA model for automatic generation of UML diagrams; and
- Generating UML diagrams based on user requirements, wherein the user requirements include class, use case, activity and sequence.
2. The method as claimed in claim 1, wherein the client requirements are classified through artificially intelligent Natural Language Processing (NLP) system.
3. The method as claimed in claim 1, wherein the plurality of feature groups include basic features, workflow features, performance features, optimization features, integration features, information features, privilege feature, security feature, business continuity feature, UI feature and infrastructure feature.
4. The method as claimed in claim 1, wherein the Configurational Parameter Specifications (CPS) is provided by a user.
5. The method as claimed in claim 1, wherein the CPS includes programming language, database, deployment server port and IP address.