Specific modeling issues for designing the transformation of a smart city

In this short paper, we present methods and solutions for specific issues of concern to engineers and application technologists related to modeling a smart city's transformation. The main body of developing "structural design modeling" for a smart city utilizes the Unified Modeling Language™ (UML®) conceptual approach. Our approach provides an overview of the specific domains (points - nodes) related to the topic. Our discussion does not delve into significant issues. It does not solidify the proposed approaches but as a research proposal, it remains at a level that could be described as a presentation or an argumentative position. Our short paper heavily relies on diagrams of models. This short paper focuses on specific design issues related to modeling mappings specifically for the design and modeling processes for a smart city.


INTRODUCTION
The concept and the design for Smart Cities have in recent years involved completely different approaches from those of the early plans of the 2010-2020 decade.The main reason for these differences lies in the technical and technological development of Information and Communications Technology (ICT) materials and structures.These areas combined with the continuous evolution of materials and equipment.The new areas form hierarchical structures of interdependent relationships and resources that facilitate data collection, draw on multiple resources, and serve services of multiple types, such as smart devices, smart environments, and smart applications (Figure 1).In addition, those directly involved in city operations interact with each other and co-create values through these services.Smart cities incorporate overt design patterns and hidden hierarchies based on local needs [1].The main methodological line we followed was defined by representation packages in Unified Modeling Language (UML).We define constructs that allow the packages involved in the described structures to import and merge classes from one package to another, where dependencies are used that are marked and labeled.
The approach is systematic only from the view of modeling without details because we emphasize a clear understanding of the outcomes as part of the design.Concrete results do not belong in our findings of this short paper but belong to future works.The clear roadmap of our research short paper in addition to the present introduction includes in Chapter 2, we discuss the mappings of interconnected features and implicit behaviors as a preparation for designing and modeling a smart city.In Chapter 3 we focus on specific modeling design issues and in Chapter 4 we cover the field of interconnections of component interfaces and entity dependencies as specific modeling design issues for a smart city.Finally, we conclude the paper with Chapter 5, which discusses the design of database components for modeling a smart city as a special design topic as part of conclusions and future works.

INTERCONNECTED FEATURES AND IMPLICIT BEHAVIORS AS PREPARATION FOR THE DESIGN OF SMART CITY MODELING
The correlations and generalizations of the categories of a "smart transformation" for a city or a region, in diagram class formats, include the following categories: The diagram classes do not refer to how the individual objects or the described entities will be organized.The diagrams depict relationships and "loosely" interconnected attributes, as well as implicit behaviors in the overall system of a Smart City.The Package Diagrams, represent the package points -nodes, at which development provision should be made, but without depicting any hierarchical type.The dependencies of the individual packages relate to the scale of development, the application technologies, and the financial resources of the individual projects.

SPECIFIC MODELING DESIGN ISSUES
The theoretical center of this paper is based and structured on the fact that the modeling for the design of a smart city does not involve a hierarchical gradation for each element-node.The element node operates autonomously technically, independently of the other nodes -nodes both in terms of its functions and in terms of its construction specifications.The second important point for the structuring of this subchapter is that the individual pointsnodes are technically renewed and "evolve" technologically, independently of the others.These "individual" hardware changes do not coincide in time with the overall technical modernization stages.Each point node to update its mechanism and functions must be addressed autonomously.Based on this reality, we utilize promoted mapping techniques, static functions, and interface features of abstract classes and additionally provide defined associations and object diagrams.
From the theory of the UML diagram, we established the position and interpreted some of these notations in detail and highlight.An example of this type of difficulty can be found in the use of the term "interface": a UML interface is a class that has only public functions, without a body of methods [6].Moreover, a representation that concerns the design for the transition of a city to a smart city is usually also exploited as a metamodel.This version of using notations, serves engineers designers, and future project maintainers, to depict the responsibilities of a class in a class diagram (Figure 2).
The scientific question in modeling a smart city concerns the constant evolution of communication technology equipment.Two main characteristics distinguish the continuous evolution of communication technology equipment: Both trends compel a design for continuous transformation, without dependencies on equipment.To design a class for a smart city, in terms of real-world conditions, we organized the individual entities that "participate" in the design as interconnection-dependent entities.To complete the design phases, we used several abstract methods as in reality, the class uses an instance-entity without necessarily "knowing" in detail the technical characteristics of its technical specifications, using methods that are part of the interface.This management has the advantage of making it easier to change the individual parts of the implementation or upgrade it when needed in the upgrade phase.

INTERCONNECTIONS, INTERFACES, AND DEPENDENCIES, AS SPECIFIC MODELING DESIGN ISSUES FOR THE PLANNING OF A SMART CITY
To design and model a smart building we used interfaces, entities, abstract classes, and controllers.In abstract classes, we are not required to concretize, i.e., to create entities in direct contact with the final arrangement, as implementations are "transitioned" through controllers of a secondary class that provides handles and controls input events [3].We can concretize an instance-entity [4], of some of its secondary classes, as an abstract class usually, has one or more abstract functions (abstract method).Also, an abstract method is not bound by the implementation, and is just a statement, so that the designers and developers of the class functions do not need to be "forced" by the constraints of the implementation in real-world situations (Figure 3).Component Diagrams in their general function represent provided and required "interfaces", but in some cases also represent the internal structure of individual components.The "Components" of Smart Energy Resource Management, Smart Transportation Management, and Smart Economy are the individual components of the design for Smart Governance, which includes all the scaling phases of Sustainable Development, from Strategic Environmental Planning of the area to the control of transport during congestion, to the planning of public transport expenditures, whether state or local.The interface as a condition requires the implementation The individual correlations could form a sequence of dependencies, where each package would model a specific role [7].In a Component Diagram, the existence of packages as individual components can be illustrated.These packages do not deal with the physicality of components, and do not show how specific components fit in at the physical level, but rather depict dependency associations (Figure 4).The physical substance of the components are results that will be requested by implementation engineers while completing the project of transforming the city or its area under development.In the same way, other diagrams of components that derive from the dependencies of Figure 3 could be formed, provided that their representation shows only their logical substance or the substance they take at the time of "realization" and execution of the policy for the design and implementation of a project.

DESIGN CONCRETE COMPONENTS OF A DATABASE FOR SMART CITY
An embodiment may contain improved performance on some individual interaction features.By programming based on the interface rather than the implementation, we avoid changing all the code in case we need to make some changes or organize a different implementation of the design.The design and more generally the modeling of a smart city should be programmed based on the interfaces and always using the general modeling types.The evolution of the modeling implementation could provide a multitude of variations of improved performance, and some different interaction features between entities [2], leveraging distributed databases [8].Exploiting distributed databases requires modeling a large system, whose package diagram associations are integrated into common code representing the structure at a large scale.In this way, the dependencies between packages are also a summary of the dependencies between their contents.Each dependency, but also each aggregation-grouping of packages, has its semantics and stereotypes.In addition, before the implementation of the Database, a check was made for the degrees of stability for both the individual correlations and the overall structure [5].The testing of the large-scale structure of the system is ongoing and is part of the sequence of creating a database for the design of a smart city.The package structure of Figure 6 has a clear flow towards dependencies, which is defined by ontological design but at this level can be easily identified.The design and modeling to build a database for a smart city is a pattern evolution, and it is structured in specific associations and captures the pure flow of these associations.The correlations flow in respective directions and act as insulating layers between the domain packages and the databases following Mapper Patterns.The smart energy smart buildings and smart transportation management packages communicate with the core smart economy package whose final correlation is formed as a discrete package in the database.The mapping follows the "Acyclic Dependency Principle" by supporting the minimum number of dependencies that come in each package.We insisted on the minimum number of dependencies as any change in the interface should propagate to all packages that depend on its Stable Dependency Principles.Stable packages have a higher percentage of interfaces and abstract classes than the rest -Stable Abstractions Principles.The concept of dependencies generates the final confirmation of the fact and is very useful in the implementation practice.In future work, we suggest further enhancing clarity in terminology and providing practical examples.Additionally, it would be beneficial to articulate concrete objectives more explicitly and maintain a secure coherent thread that connects the various sections.

Figure 1 :
Figure 1: The hierarchical structure of services and applications related to a Smart City

1 )
Smart management of energy resources 2) Smart transport 3) Smart governance and smart democratic control 4) Smart economy and trade 5) Smart education structures 6) Smart b8uildings 7) Smart insurance services and direct intervention in natural disasters 8) Smart health and wellness service delivery systems.

Figure 2 :
Figure 2: Illustration of responsibilities in a class diagram

Figure 3 :
Figure 3: The problem of constantly evolving communications technology equipment

Figure 4 :
Figure 4: Component Diagram as a snapshot for the design and implementation of a "smart city"

Figure 5 :
Figure 5: The relation of the package diagram for modeling and designing a smart city

Figure 6 :
Figure 6: Package diagram relations for the implementation and application with a database