MDA
now browsing by tag
Mechanism of operation vs. system model
Most often in the course of analysis we use the term model, less often mechanism. The thing is that the term mechanism appears when we want to explain something, e.g. “the mechanism of generating a discount on an invoice”. The thing is that the term mechanism appears when we want to explain something, e.g. “the mechanism for generating a discount on an invoice”. But here beware! A model (block diagrams, formulae, etc.) is documentation, a copyrighted description. The mechanism is what we understood by reading these documentation (model), because the mechanism is protected know-how. The content of the application to the Patent Office is the model (description), but what we patent is the mechanism invented/developed.
Source: Mechanism of operation vs. system model – Jarosław Żeliński IT-Consulting
Ontology-Oriented Data Management and Document Databases
This study presents a method for the storage of data organized in digital documents, which is proven in practice. The discussed method does not bear any disadvantages of the relational model used for data organization, such as the loss of data context and complications evoked by the lack of data redundancy. The method presented here can be used for data organization into documents (digital and paper) as classified aggregates and for data classification. The study also describes a new metamodel for the data structure which assumes that documents, being data structures, form compact aggregates, classified as objects, or event descriptions, thus always assigning them a specific and unambiguous context. Furthermore, the study presents a design method for documents as context aggregates that allows leveling the disadvantages of the relational model and ensures efficient information management. The work also contains practical examples of the application of the described method.
Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases
PIM modelling -Reduction of UML notation
The work is an attempt to systematise the use of key OMG.org notations in the process of system analysis and design. Under the term. and UML of knowledge in the field of object-oriented analysis and design and the notation systems used in this area. The author pays special attention to the differences between data-and responsibility-oriented design methods (chapter Analysis and object-oriented design). The following section describes the conceptual basis described in the SBVR, MOF, MDA specifications and the modelling method using UML notation. The author argues that ontology is not a model of the world, it only describes it.
What is Computation Independent Model
1.A Computation Independent Model (CIM) is a model defined within OMG Model-Driven Architecture as a primary model. This model reflects system and software knowledge from the business perspective. The CIM may contain business knowledge about system organization, roles, functions, processes and activities, documentation, constraints etc. The CIM must contain business requirements for the software system.
Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns
Exactly one year ago my first paper in US ? (see liflet)
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.Chapter Preview Top
Background
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).
Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns
Jaroslaw Zelinski (Independent Researcher)
Source Title: Applications and Approaches to Object-Oriented Software Design: Emerging Research and OpportunitiesCopyright: ? 2020 |Pages: 12DOI: 10.4018/978-1-7998-2142-7.ch003
Why using extend and include stereotypes in OOAD projects is wrong?
Many analyst and UML practitioner use Use Cases as a “process model”. It is really bad idea. As we say “we use OOAD methods”, it means we use object paradigm. The fundatin of OOAD is hermetization, but ‘include’ and ‘extend’ dependencys break this rule.
A lots of time we see diagrams like this:
Uses Case models with include and extend stereotypes
A few citation (UML specification) :
A UseCase is a kind of Behaviored Classifier that represents a declaration of a set of offered Behaviors. Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. UseCases define the offered Behaviors of the subject without reference to its internal structure. These Behaviors, involving interactions between the Actors and the subject, may result in changes to the state of the subject and communications with its environment. A UseCase can include possible variations of its basic behavior, including exceptional behavior and error handling. (UML, 18.1.3.1 Use Cases and Actors)
Important sentence: without reference to its internal structure (see what encapsulation means below).
An Extend is a relationship from an extending UseCase (the extension) to an extended UseCase (the extendedCase) that specifies how and when the behavior defined in the extending UseCase can be inserted into the behavior defined in the extended UseCase. The extension takes place at one or more specific extension points defined in the extended UseCase. (UML, 18.1.3.2 Extends)
The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases. This common part is then extracted to a separate UseCase, to be included by all the base UseCases having this part in common. As the primary use of the Include relationship is for reuse of common parts, what is left in a base UseCase is usually not complete in itself but dependent on the included parts to be meaningful. (UML, 18.1.3.3 Includes).
Object oriented paradigm based on main concepts:
- object (part of system)
- encapsulation (objects hides their implementation)
- polymorphism (one operation could be implemented by more then one methods)
- cooperation (objects cooperate to achieve the particular goal)
In OOAD <<include>> and <<extend>> breaks encapsulation (we can’t use use diagram to modeling any internal application or component structure/architecture). , .
Need more arguments and explanation? Try my courses…