UML
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
ICONIX as an object-oriented, agile software design process using UML notation
The fact that ICONIX, as a process, is relatively rarely used (this has been changing over the last few years, however), is rooted in the fact that, first and foremost, it requires an understanding of the component-oriented architecture process, it also requires knowledge and understanding of the concept of hexagonal architecture and the associated MVC pattern. Requires knowledge and understanding of many other object-oriented design patterns, requires, above all, abstract thinking and modelling (UML) skills. It requires an understanding that z coding must be preceded by design, because «designing» in code is the least effective form of design (Börger, 2018).The process is also supported by the division into analysis and design and implementation stages (see above diagram: Structure of project roles and products in the ICONIX process). ICONIX is sometimes wrongly associated with a “heavy” software development process such as the Rational Unified Process (which I have hardly written about on my blog). The reason ICONIX is rarely used, is also that, unfortunately, the world was, already in the 1990s, heavily “spoiled” by C++ and Java (architectures built on cascades of inheritance). These are often heavy, monolithic frameworks based on a relational data model, where there is no strict separation between domain logic and environment (MVC). Java is still one of the most costly and least effective application development methods. The EJB framework is to this day described as the source of an object-oriented design anti-pattern called the «anemic domain model». However, the growing developer interest in the C4 model over the last few years shows that analysis and modelling are needed and quietly entering through the back door….The fact that ICONIX, as a process, is relatively rarely used (this has been changing over the last few years, however), is rooted in the fact that, first and foremost, it requires an understanding of the component-oriented architecture process, it also requires knowledge and understanding of the concept of hexagonal architecture and the associated MVC pattern. Requires knowledge and understanding of many other object-oriented design patterns, requires, above all, abstract thinking and modelling (UML) skills. It requires an understanding that z coding must be preceded by design, because «designing» in code is the least effective form of design (Börger, 2018).The process is also supported by the division into analysis and design and implementation stages (see above diagram: Structure of project roles and products in the ICONIX process). ICONIX is sometimes wrongly associated with a “heavy” software development process such as the Rational Unified Process (which I have hardly written about on my blog). The reason ICONIX is rarely used, is also that, unfortunately, the world was, already in the 1990s, heavily “spoiled” by C++ and Java (architectures built on cascades of inheritance). These are often heavy, monolithic frameworks based on a relational data model, where there is no strict separation between domain logic and environment (MVC). Java is still one of the most costly and least effective application development methods. The EJB framework is to this day described as the source of an object-oriented design anti-pattern called the «anemic domain model». However, the growing developer interest in the C4 model over the last few years shows that analysis and modelling are needed and quietly entering through the back door.…
Source: ICONIX jako obiektowo zorientowany, zwinny proces projektowania oprogramowania z użyciem notacji UML – 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
Business continuity management – how to model it
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 …
References
Types instead of inheritance
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?
References
Systems analysis and design
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.
Few comments…
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.
References
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)
- 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…