Models and architecture
now browsing by category
The main category of my posts, my experience and research as well.
In this place, I have been collecting some speaks about the SysML language. It is origin from UML (it is a UML profile). SysML is the main MBSE method we use for documenting mechatronics models.
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
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 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, 220.127.116.11 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.104.22.168 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, 22.214.171.124 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…