Abstract
Publications, including academic handbooks, contain numerous inconsistencies in the descriptions of applications of architectural methods and patterns hidden under the abbreviations such as MOF, MDA, PIM, MVC, BCE. An efficient analysis and the following software design, particularly when we are speaking of projects realized in large teams, requires standardization of the production process and the applied patterns and frameworks. This study attempted to sort out the system of notations describing this process and used to describe architectural patterns. Analysis of key notations—MOF and MDA, patterns MVC and BCE—was carried out, and a consistent system combining them into a whole was created.
TopBackground
In this study, Object Management Group notation systems have been used. MOF (Meta Object Facility) specification describes three abstraction levels: M1, M2, M3 and level M0 that is real items (OMG MOF, 2016). M0 is a real system, M1 level is abstraction of the items of this system (its model). Level M2 comprises of relationships between classes of these objects (names of their sets) that is system metamodel. M3 level is a meta-metamodel describing the modeling method with the use of named elements with specified semantics and syntactic.
The analysis and design process is based on the MDA (Model Driven Architecture) specifications. This process has three phases understood as creation of subsequent models: CIM (Computation Independent Model), PIM (Platform Independent Model), PSM (Platform Specific Model) and code creation phase. The CIM model is documented with the use of BPMN (Business Process Model and Notation) (OMG BPMN, 2013) and SBVR notation (Semantic of Business Vocabulary and Rules) (OMG SBVR, 2017). These are, respectively: business process models and notation models and business rules. PIM and PSM models are documented with the use of UML notation (Unified Modeling Language) (OMG UML, 2017).
Between CIM and PIM models, determination of the list of application services (system reactions) occurs, whose realization mechanism is described by PIM model. The standard pattern used for modeling application architecture is MVC pattern. Component Model of this pattern is modeled with the use of the BCE architectural pattern.
Semiotics vs. UML
Semiotics, as a science dealing with symbols and their meanings, provides us with the tool enabling determination of relationships between an object (thing), its name (expression) and definition of notation represented by the name (or sign, meaning). These relationships are referred to as the semiotic triangle. Figure 1 represents this triangle on the left (OMG SBVR, 2017).
The UML notation (OMG UML, 2017) operates instance classifier and class notations. To the right, Figure 1 demonstrates an equivalent to semiotic triangle expressed with those terms.
The UML notation further operates the general structure notation, which is the content of each correct UML diagram. Structures may express a conceptual model (Namespace) or model (also metamodel) of system architecture (e.g. software) in the form of a chart (Architecture).
Conceptual models are structures based on taxonomies, visualizing conceptual relationships (relationships between names) between them. The notation of class represents name (expression) of a set of designations. The notation of classifier refers to definition (meaning) of the notation. In the UML, definition of a class of objects is the set of their common traits that is attributes and operations. The notation of object refers to designations (thing). In the UML notation, we add the classifier name defining the object (class to which it belongs) to the name of the object after the colon.
In the UML conceptual models, generalization relationships (taxonomies) and associations (semantic relationships between them) are used, whereas architecture models use composition relationships (whole-part relationship), use relationships (dependency relationship) and realization relationships (specification and implementation relationship). Architecture models express the structure and mechanism of action of modeled systems.
Key Terms in this Chapter
Metamodel: Model generalization, in other words if a model is an abstraction of a specific reality, then metamodel is generalization of specific class (set) of such models (abstractions). Any metamodel represents all systems compliant with this metamodel. Moreover, metamodel as a class of models defines semantics and syntactic of the specified model class.
Fact: What occurred or occurs in reality, in SBVR notation an element combining notions in one context.
Use Case: Represents a behavior or set of system behaviors specified, initiated by the actor (user), whose objective is the predetermined result useful for the actor, it may include possible variants of its basic behavior, including special behavior such as error handling, means a specific (aiming at obtaining a concrete effect) System use; key notions associated with Use Cases are Actor and System creating a certain theory, log, a comprehensive and ordered set of tasks connected with the relations of logical result.
Platform-Specific Model: Model describing application implementation architecture in the context of technology used for implementation.
Information: Message about something or communication of something; data processed by computer.
Business model: A description of a company’s activity that ensures its profit. This comes down to defining the role of the organization in the market value chain in which it operates and describing the mechanism of creating this value within the organization. Such models are expressed in the form of business models and structures as well as their dynamics. Typical elements of a business model: superior market value chain, internal value chain model, market five forces model, as well as SWOT context analysis.
Abstraction: Description from a certain perspective or in a certain context, consisting in omitting details that are irrelevant in this context, allowing an approach from a particular point of view and at a higher degree of generality.
Model-Driven Engineering: An analysis and design methodology orientated at the creation of models of the given domain, including notation models and others, built from various distinct perspectives in order to describe a problem and its specifics; it is based on the use of abstraction and models of mechanisms governing the given domain instead of individual calculations and algorithms.
Model-Driven Architecture: An architecture based on open standards of Object Management Group, enabling separation in the analysis and design of business logic, application logic and its implementation.
Component: A constituent forming a constructively closed element of a system, capable of being a separate subject of supply or realization, characterized by specified behavior (interface), own life cycle, can be replaced with another of the same external traits, without impact on the remaining system elements and system as a whole.
Boundary, Control, Entity: Assumes modeling of structure of any application with the use of three construction blocks: Boundary (system boundary, interface), Control (the only place of system logic realization), Entity (place of information, data storage, memory); UML includes stereotypes of classes or objects, all should possess operations, abstract models may not have attributes; the pattern can be applied also for object organization modeling.
Computation Independent Model: Model (perspective) which is independent of the calculation system, understood as a model disregarding technology.
Model: Abstract representation of a product or system, enabling verification of its traits before commencement of its production, constitutes a set of assumptions, notions and relationships between them enabling description (modeling) a determined aspect of reality in a given context; model is not simplification, it is an abstraction; it can be expressed with mathematic formulas or a flow chart (nominal, abstract model) or as a simplified real construction (real model).
System: Any notion or physical entity, comprising of mutually interlinked and interacting parts; a set of elements and relationships between them capable of realizing specified objectives; set of elements with specified structure and enabling logically ordered whole, arranged set of statements, views.
Business Process Model and Notation: A notation system and graphic notation enabling modeling and documentation of business processes and procedures in a graphic form; it further enables modeling and documenting cooperation between organizations.
Semantics of Business Vocabulary and Rules: Defining the method of creation of business rules and creation of business terms dictionary, the specification further includes a description of notation for the creation of the so called fact diagrams, which are graphic representation of business term dictionary and a method of modeling and control of cohesion of domain notation system (namespace).