Fayad’s Unified Modeling Language (F-UML)
Fayad’s Unified Modeling Language (F-UML)
Professor Dr. Mohamed E. Fayad
The existing Unified Modeling Language (UML) is not unified, and it has a lot of Problems, Pitfalls, and Criticisms. The UML models an instance (Concepts) of application of software systems and no other does not model other systems and knowledge in any other field of knowledge.
Fayad’s Unified Modeling Language (F-UML) – Modeling Unification and Stability Foundation for Any field of knowledge.
Fayad’s Unified Modeling Language (F-UML) – Modeling Stable and Unified Functional and Non-Fumctional Requirements, Stable Software Design, and Stable Software Architectures in the form of stable analysis patterns (SAPs), stable design patterns (SDPs), stable architecture patterns (SArchPs),
Labels FUML — Modeling Unification & Stability
Goals
(1) Unification
(2) Stability
(3) Standardization
(4) Foundation
(5) Building in more than 50 discoveries, more than 200 innovations & more than 100 cognitive facts per each unified Word
(6) Positive Impacts
Discoveries and Innovations
We have discovered unified and constant innovations based on our discoveries of more than 50 intrinsic and inventive factors called “Discovery keys per each Unified Word, more than 200 abstraction techniques and algorithms called “Innovative keys,” more than 100 of cognitive facts and we have answered more than 300 questions about any word about (a Unified Word).
“A Unified Word is the foundation stone of science and knowledge.”
“A Unified Word is a guide for all nations to follow.”
“A Unified Word for freedom is like a fortress and a shield.”
We have more than 300 questions to answer about a Unified Word:
Do you know the true meaning of a Unified Word?
Do you understand what a Unified Word is?
Do you know the ultimate goal of a Unified Word?
Do you know the functional requirements?
Do you know the nonfunctional requirements?
The answer to all the previous questions is NO.
A Unified word can be documented with more than fifty discovery keys, more than 200 techniques and algorithms of the art of abstraction and a lot of new cognitive data in three to more than five thousand pages.
“A Unified word is closely related to art, science, and engineering.”
“A Unified word does not have synonyms and will be treated as unified, fixed, and unique.”
What is the art of a Unified Word?
It raises other questions, including new science called the “Art of Abstraction.”
What is the significance of a Unified word?
What is the value of a Unified word?
What are the advantages and ethics of a Unified word?
What are the aesthetic qualities of a Unified word?
What is the final and comprehensive definition of any Unified word?
What are the technical uses of a Unified word?
Etc.
What is the science of a Unified word?
It raises other questions, including the result of a new branch of science called Fayad’s Dictionary.
What is a Unified word classification?
What is the unifying goal of any word?
Hint One: It is the only goal for all the Word scenarios.
Hint Two: Most Words have one goal, a few words have two goals each, and scarce Words have three goals each.
Hint Three: Each goal represents a system. Therefore, if a Word has three goals, it means three systems.
What are the positive impacts of the unified goal of any Unified word?
What is the commotion for any Unified word?
What reliable sources for any Unified word?
What is the Unified word ‘s responsibility?
What roles does Unified Wordplay play?
What is the code of honor for a Unified word?
Etc.
What is the engineering of a word?
What is the map of knowledge of a Unified Word?
What are the basic needs and requirements of a Unified Word?
What is the unified and consistent form of a Unified Word?
What are the nonfunctional requirements per Unified Word?
What are the applications of a Unified Word?
What are Unified Word behaviors?
What are the modeling techniques of a Unified Word?
Each of these questions raises many questions.
What are the rules, policies, and constraints of a Unified Word?
Modeling Adequacies
Descriptive Adequacy
Descriptive adequacy refers to the ability to visualize objects in the models. Every defined object should be browse-able, allowing the user to view the structure of an object and its state at a particular point in time. This requires understanding and extracting meta-data about objects that will be used to build a visual model of objects and their configurations. This visual model is domain dependent — that is, based on domain data and objects’ meta-data. Descriptive adequacy requires that all of the knowledge representation is visual, as follows:
Visual models are structured to reflect natural structure of objects and their configurations
All the visual knowledge (data & operations) in the visual model is localized
Relationships among objects in the visual model are well-defined
Interactions among objects in the visual model are limited and concise
The visual model must transcend objects, and instead highlight crosscutting aspects.
Logical Adequacy
Logical adequacy refers to the representation tools that describe the framework components’ behavior, roles and responsibilities.
Synthesis Adequacy
Synthesis adequacy refers to an integrated problem resolution methodology, or built in trouble-shooting tools. Built-in trouble-shooting tools are very important in managing complex distributed systems, because there are typically many potential points of failure.
Analysis adequacy
Analysis adequacy refers to integrated validation and verification tools. With built in validation and verification, the process of maintenance and regression testing can be streamlined and the cost of validation and verification is minimized.
Blueprint Adequacy
Blueprint adequacy refers to the modeling features that provide for integrated system specifications. Integrated system specifications are important because they facilitate the extensibility of the system. An integrated blueprint for an enterprise framework should clearly identify the hot-spots and frozen-spots in the framework.
Epistemological Adequacy
Epistemological adequacy refers to tools for representing objects in the real world. There are two ways to view the world based on simplicity: (1) Perfect but simple view – the world is represented in this view as an ideal environment and (2) As-is, but complex and detailed view – the world is represented as an ultimate reality. There are also two ways to view an organization: 1) Flat and single view and 2) layered and multiple views. It is very obvious that most of modeling techniques, such as unified modeling language (UML) and object-modeling technique (OMT) model the world as an ideal environment and flat or single view of itself. Nevertheless, successful enterprise frameworks have made great leaps in representing objects in the real world and in providing the necessary tools to alter these objects as required by the business.
Notational Adequacy
Notational adequacy refers to the presentation constructs the impact the presentation tools have on the operation of the system as well as the ease of modification.
Procedural Adequacy
Procedural adequacy refers to recognition, and search capabilities.
Contractual Adequacy
Contractual adequacy refers to the client tools for representing the system behavior.
Scalable Adequacy
Scalable adequacy relates to the constructs and tools supporting partitioning, composition, security, and access control. Can your models be scalable in all directions?
Administrative adequacy
Administrative adequacy refers to the tools for modeling the deployed system’s performance, reliability and administrative characteristics and to the actual tools for administering the system. Administrative adequacy also considers the availability of install set builders, start and stop procedures or scripts, integrated database management capabilities, archiving, fail-over mechanisms, etc.
Understanding Adequacy
Understanding adequacy relates to be easy to understand.
Simplicity Adequacy
Simplicity adequacy relates to how simple your models will be.
Extensibility Adequacy
Extensibility adequacy relates to the degree of extensibility, adaptability, customizability, configurability of you’re your models.
Systematic Adequacy
Systematic adequacy relates to the systematic approaches that are utilized in modeling, such as bottom-up, top-down, and middle-out approaches. It also includes functional decomposition techniques, and the selection of the correct level of abstraction at each stage of analysis.
Behavioral Adequacy
Behavioral adequacy relates to the behavioral models that are concentrating on behavioral aspects of the system that you model at hand. It also includes accuracy of your behavioral models, such as scenarios, activity diagrams, sequence diagrams, interaction diagrams, state transition diagrams, etc.
Analytical Thinking Adequacy
Analytical thinking adequacy relates to the analytical thinking approaches and tools that are concentrating on analytical aspects of the system.. It also includes the utilization of analysis patterns
Modeling Essential
It is essential that the model of a system must be complete and mostly accurate () and consider to be the foundation for several applications
Model should be a complete storyteller ()
Modeling Essential = Simplicity ()
Modeling Essential = Easy to understand ()
Modeling Essential = Testability ()
Modeling Essential = Unifications () & Stability ()
Modeling Essential = Visual or graphical
The major properties of an essential model [Fayad-Laitinen 98, Chapter 01, PP10-11,1998]
The model is an abstraction of reality and lets you see the relationship between the parts
and the whole. Modeling is a well-established human activity. All models are descriptions of something (i.e., a representation that is not the real thing), that allow us to answer questions about the real thing, that capture only those features deemed essential by the modeler, and that can be validated by experimenting with physical things or by quizzing experts. A single thing can be represented by many models. There are two types of modeling: intangible modeling (e.g., logical models, behavior models, object models) and tangible modeling (e.g., physical models).
The logical model represents the key abstractions and mechanisms that define the system’s
architecture. The logical model also describes the system behavior and defines the roles and responsibilities of the objects that carry out the system behavior. Logical modeling frees the analysts from the consideration of limitations inherent in real-world mechanisms. Colbert uses object-interaction diagrams and object-class diagrams to illustrate the key abstractions in systems and STDs (State Transition Diagrams) and state charts to model the behavior of the system [Colbert89]. OMT and Shlaer-Mellor both use object model and STDs for the same purposes [Rambaugh91, Shlaer-Mellor92].
The physical model of the system uses symbols to represent things that must be physically
present. In the software sense. The physical model is used to describe either the system’s context or implementation. Colbert and O-ET use system context diagrams as a physical model of the system [Rambaugh91, Fayad94]. There are six properties essential to any good model.
Simple — This property covers those attributes of the object-oriented model that present modeling aspects of the problem domain in the most understandable manner. This property
measures the technique complexity in terms of number of process steps, notational aspects,
constraints and design rules.
Complete (most likely to be correct) – This property ensures that model artifacts are free of
conflicting information and all the required information is present. For example, component
names within the model should be uniform and no incomplete sections of the model should exist.
This property determines if the object-oriented model provides internal consistency and
completeness of the model’s artifacts. The model must be able to convey the essential
concepts of the its properties.
Stable to technological change – Unfortunately, object-oriented models are fuzzy due to the
absence of quantitative heuristics, and most OO models are built upon false assumptions.
Testable — To be testable, the model must be specific, unambiguous, and quantitative wherever
possible. For our purposes we define simulation as an imitation of the actual model. This
definition leads us to validate the characteristics of the model against the user’s requirements.
Easy to understand — In addition to the familiarity of the modeling notations, the
notational aspects, design constraints, and analysis and design rules of the model
should be simple and easy to understand by the customers, users, and domain experts.
Visual or graphical — A picture worth a thousand words. As a user you can visualize and