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
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.
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.
Exactly one year ago my first paper in US … (see liflet)
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
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).
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
Business Continuity Management (BCM) projects are really difficult . The main reason is the system complexity: many documents, many tasks, many processes, many associations between all of them. Each task connected to one or more business application. Each documents stored in different database. The applications are integrated. Everything works like one chain … but one broken link can crash everything .
How we can managing risks? We can create Business Architecture model and expand this up to Enterprise Architecture, as a model for trace process, data, IT system and infrastructure.
How we prepare Enterprise Architecture model? Simple version: prepare business model :
Transform this to use case model (application services) :
Build matrix for trace mapping control :
Trace (map) use case to software components :
We have completed model, we can do impact analysis, e.g. what happens and where, when the Ruter go down:
Sometimes we ask: what does the possibility of carrying out the Package Goods task depend on?
How can we do this and what tools do we need? Welcome in my courses, hire me …
Many time we can see requirement written as a “class diagram for project”. What “class diagram” mean? We can use UML class diagram for: architecture model, notions model, sometimes other. Which type of model do you need? Class diagram is a tool. When we say model, we have to provided context: model of what?
We use inheritance in models of notions (for building taxonomies), never in architecture.. In architecture models we use types. In 2015 OMG published UML v.2.5. Inheritance was removed from UML . Why? Welcome in my courses…
Many time we heard about agile in software development. Many times authors wrote that agile provide us to fast and cheapest solutions. It is true but not all the times. Chaos Report (see Standish Group) show us, that is not true all the times.
Generally small projects are not a (big) problem..
Waterfall vs. agile: first one method consume many more time than second one, but we have no time to «big analysis». Second one mean «working too fast», and effect is more prototyping mean cost increasing… many time mean: cancel project before finish caused by budget:
A waterfall is not a solution, but agile is not a good remedy for it. A common problem in software design is system size and complexity:
How to improve quality and chance to succeed software project? We need really good person to business analysis role and only one. More than one person in a first stage, mean more problem with merging parts to one completed and unambiguous requirements document :
Disciplined agile, what is it? Using models in agile, why and for what? Modern system analysis and design is not a waterfall and not a agile style… It is science method used for software engineering . Discover the MDA and patterns as a wand for your success in software projects. See the system as a architecture .
More about general systems and SysML notation coming soon …
Try my courses for improve your skills and your teammates, hire me as a gifted person in your project.
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, 184.108.40.206 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, 220.127.116.11 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.104.22.168 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)
- coöperation (objects coöperate 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…
First and short post. After six years visiting Scotland to visit tourist attractions, spending time on folk festivals and traditional music sessions in pubs (I play whistle), now it’s time to start living in Scotland. It means I have to move and continue my business activities here. What is my business? I’m analyst and system designer, providing business analysis, business logic and software design, systems architecture design. Researcher and lecturer as well.
Wish me luck… try me for free…