rfc2119 – Słowa kluczowe reguł

Od czasu do czasu spotykam się z zaskoczeniem, gdy mówię, że pewne słowa kluczowe w specyfikacjach są “standaryzowane”. Otóż specyfikacje notacji na OMG.org mają narzucone pewne słownictwo. Przykładem niech będzie specyfikacja notacji BPMN v.2.0.2, zawiera ona taki oto rozdział :

3.2 Normative
OMG UML
? OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2 –
(jest już UML 2.5.)
OMG MOF
? Object Management Group – Meta Object Facility (MOF) Core Specification, V2.0
https://www.omg.org/spec/MOF/2.0
RFC-2119
? Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, IETF RFC 2119, March 1997
http://www.ietf.org/rfc/rfc2119.txt

Oznacza to, że do poprawnej interpretacji specyfikacji notacji należy znać specyfikacje: MOF, UML oraz także RFC-2119. O MOF i UML pisałem nie raz, dzisiaj kilka słów o tej ostatniej.

Jest to dokument opisujący rekomendowany sposób formułowania wymagań (np. w stosunku do elementów diagramu i ich użycia). Wymagania są tu rozumiane szeroko, jako sformułowania normatywne. “Słowa kluczowe do wykorzystania, w RFC do wskazania poziomów wymagań” to słowa i zwroty o tu ustalonym znaczeniu :

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.?(?Key words for use in RFCs to Indicate Requirement Levels,? 1997)?

Wymienione słowa kluczowe odnoszą się do formułowania reguł (przy stosowaniu określonych zasad będących wymaganiami) i oznaczają:

  1. MUSI (oryg. MUST) oznacza, że to zachowanie (określona reguła, wymaganie) jest absolutnym wymogiem, alternatywnie: WYMAGA SIĘ, NALEŻY
  2. NIE MOŻE (oryg. MUST NOT) oznacza, że określone zachowanie jest absolutnie zakazane, alternatywnie: NIE NALEŻY
  3. POWINIEN (oryg. SCHOULD) oznacza, że określone zachowanie jest rekomendowane, a więc jedynie w ściśle określonych okolicznościach, jeżeli istnieją określone powody, określone zachowanie może być pominięte, alternatywnie: REKOMENDUJE SIĘ,
  4. NIE POWINIEN (oryg. SHOULD NOT) oznacza, że pewne zachowania odradza się (rekomenduje się nie wykonywać określonego zachowania), a więc zachowanie to jest dopuszczalne jedynie w określonych okolicznościach, alternatywnie: ODRADZA SIĘ, NIE REKOMENDUJE SIĘ,
  5. MOŻE (oryg. MAY) oznacza, że określone zachowanie jest opcjonalne, a więc skutki tego realizacji lub pomięcia określonego zachowania są całkowicie neutralne, alternatywnie: OPCJONALNIE

Powyższe odnosi się do wszelkich wymagań, do decyzji o zastosowaniu czegoś (np. określonej konstrukcji w danej notacji). Pod pojęciem “zachowania (się)” rozumiemy interpretację zapisów np. o stosowaniu lub wymaganiu czegoś lub nie.

Biorąc pod uwagę fakt, że definicje pojęć to klasyfikatory i stanowią one sobą reguły (coś jest lub nie jest czymś) słowa te stanowią także bazowy element składni treści reguł biznesowych (elementy predykatów), np. “kierowca NIE MOŻE przekraczać dozwolonej prędkości”, “kierowca POWINIEN zachować bezpieczną odległość od poprzedzającego go pojazdu”, “kierowca MOŻE przewozić pasażerów”, a ogólnie rzecz biorąc “kierowca MUSI przestrzegać zasad Kodeksu Drogowego”, a ten to nic innego jak właśnie zbiór reguł.

Źródła

Hepburn, B., & Andersen, H. (2021). Scientific Method. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2021). Metaphysics Research Lab, Stanford University. https://plato.stanford.edu/archives/sum2021/entries/scientific-method/
Ozkaya, M. (2023, April 9). Microservices Architecture. Design Microservices Architecture with Patterns & Principles. https://medium.com/design-microservices-architecture-with-patterns/microservices-architecture-2bec9da7d42a
Weiss, M., & Hari, A. (2004). ICDM - an Integrated Methodology for the Conceptual Design of New Systems. https://www.academia.edu/59514794/ICDM_an_Integrated_Methodology_for_the_Conceptual_Design_of_New_Systems
Włodarska-Dziurzyńska, K. (2012). Pojęcie produktu. Nieuczciwe praktyki rynkowe : ocena regulacji, 141–143. https://ruj.uj.edu.pl/server/api/core/bitstreams/c5d331c9-8945-4f12-9a9b-12eddee0be30/content
Mahesh, B. (2019). Machine Learning Algorithms -A Review. https://doi.org/10.21275/ART20203995
Martin, R. C., & Martin, R. C. (2018). Clean architecture: a craftsman’s guide to software structure and design. Prentice Hall.
Foote, B., & Yoder, J. (1997). Big Ball of Mud. Department of Computer Science University of Illinois at Urbana-Champaign 1304 W. Springfield Urbana, IL 61801 USA. https://www.researchgate.net/publication/2938621_Big_Ball_of_Mud
Alencar, F. (2000). Closing the GAP between organizational requirements and object oriented modeling. Journal of the Brazilian Computer Society. https://www.academia.edu/83364710/Closing_the_GAP_between_organizational_requirements_and_object_oriented_modeling
Rumpe, B. (2007). Model-driven development of complex software: A research roadmap. https://www.academia.edu/16456630/Model_driven_development_of_complex_software_A_research_roadmap
Harmon, P. (2010, December 14). What is a Business Process. BPTrends, 8(21), 6. http://www.bptrends.com/publicationfiles/advisor20101214.pdf
Harmon, P., & Garcia, J. (2020). The States of the Business Process Management Process 2020 (No. 2020). BP Trends Associations. www.bptrends.com
Harmon, P. (2016). The State of Business Process Management 2016. BT Trends. https://www.club-bpm.com/Contenido/Estudios/BPT-Survey-Report.pdf
Nanayakkara, C. (2023, July 7). Microservices Patterns: The Saga Pattern. Cloud Native Daily. https://medium.com/cloud-native-daily/microservices-patterns-part-04-saga-pattern-a7f85d8d4aa3
Gaiardelli, S., Spellini, S., Panato, M., Tadiello, C., Lora, M., Cheng, D. S., & Fummi, F. (2024). Enabling Service-oriented Manufacturing through Architectures, Models and Protocols. IEEE Access, 1–1. https://doi.org/10.1109/ACCESS.2024.3385634
Huang, S.-C. (2006). A semiotic view of information: Semiotics as a foundation of LIS research in information behavior. Proceedings of the American Society for Information Science and Technology, 43(1), 1–17. https://doi.org/10.1002/meet.1450430166
Nuninger, L., Verhagen, P., Libourel, T., Opitz, R., Rodier, X., Laplaige, C., Fruchart, C., Leturcq, S., & Levoguer, N. (2020). Linking Theories, Past Practices, and Archaeological Remains of Movement through Ontological Reasoning. Information, 11, 338. https://doi.org/10.3390/info11060338
Gradim, A., & Moura, C. (2015). COMMUNICATING AND EVALUATING SCIENCE. https://www.researchgate.net/profile/Catarina_Gracio_De_Moura/publication/324314608_Communicating_and_Evaluating_Science/links/5c6485c8299bf1d14cc4bc1c/Communicating-and-Evaluating-Science.pdf#page=181
Machado, I. (2015). Graphic argumentation: diagrammatic modeling in the communication of science. Communicating and Evaluating Science. Covilhã: Labcom, 177–202. https://www.researchgate.net/profile/Catarina_Gracio_De_Moura/publication/324314608_Communicating_and_Evaluating_Science/links/5c6485c8299bf1d14cc4bc1c/Communicating-and-Evaluating-Science.pdf#page=181
Machado, I. (n.d.). Graphic argumentation: diagrammatic modeling in the. Communication and Evaluating Science, 177–202. Retrieved April 11, 2024, from https://www.academia.edu/download/92934020/Irene_Machado.pdf
Jerzy Zajadło. (2019). Banał formuły “dura lex sed lex.” Banał formuły “dura lex sed lex,” R. 64, nr 5, 5–12. https://palestra.pl/pl/czasopismo/wydanie/5-2019/artykul/banal-formuly-dura-lex-sed-lex
Korycka-Zirk, M., & Dobrzeniecki, K. (2018). Logika dla prawników: kompendium i zadania (Wydanie II rozszerzone). Towarzystwo Naukowe Organizacji i Kierownictwa “Dom Organizatora.”
Lewandowski, S., & Malinowski, A. (Eds.). (2002). Logika dla prawników. Wydaw. Prawnicze “LexisNexis.”
Lewandowski, S., Machińska, H., Malinowski, A., Petzel, J., & Pełka, M. (Eds.). (2022). Logika dla prawników (Wydanie 13). Wolters Kluwer.
Lewandowski, S., Malinowski, A., & Petzel, J. (Eds.). (2021). Logika dla prawników: słownik encyklopedyczny (3. wydanie zaktualizowane i rozszerzone). Wolters Kluwer.
Friedman, J. (1997). What’s wrong with Libertarianism. Critical Review, 11(3), 407–467. https://doi.org/10.1080/08913819708443469
Singla, A., Nathan, V. T., & Vageesh, S. (2016). Model Based Self‐Learning System Engineering Approach. INCOSE International Symposium, 26(s1), 219–233. https://doi.org/10.1002/j.2334-5837.2016.00327.x
Sarnowski, J. (2022). Podatki w krajach nordyckich a gospodarka i dobrobyt. Doradztwo Podatkowe - Biuletyn Instytutu Studiów Podatkowych, 5(309), 4–14. https://doi.org/10.5604/01.3001.0015.8617
Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ideału: kształtowanie przyszłości organizacji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne. https://repozytorium.kozminski.edu.pl/pl/pub/3442
Babalola, V. (2016). Public Private Partnership: Imperative in Educational Planning and Management for Human Security in Nigerian Schools. 6.
Keet, C. M., & Fillottrani, P. R. (2015). An Analysis and Characterisation of Publicly Available Conceptual Models. In P. Johannesson, M. L. Lee, S. W. Liddle, A. L. Opdahl, & Ó. Pastor López (Eds.), Conceptual Modeling (Vol. 9381, pp. 585–593). Springer International Publishing. https://doi.org/10.1007/978-3-319-25264-3_45
Busboom, A. (2024). Automated generation of OPC UA information models — A review and outlook. Journal of Industrial Information Integration, 100602. https://doi.org/10.1016/j.jii.2024.100602
Michalak. (n.d.). Ustawa o prawie autorskim i prawach pokrewnych. Komentarz. Wolters Kluwer. Retrieved March 23, 2024, from https://www.ksiegarnia.beck.pl/media/product_custom_files/1/8/18361-ustawa-o-prawie-autorskim-i-prawach-pokrewnych-komentarz-arkadiusz-michalak-fragment_1.pdf
Brambilla, M., Cabot, J., & Wimmer, M. (2012). Model-driven software engineering in practice. Morgan & Claypool.
Boisot, M., & Canals, A. (2004). Data, information and knowledge: have we got it right? Journal of Evolutionary Economics, 14(1), 43–67. https://doi.org/10.1007/s00191-003-0181-9
Chen, M., Ebert, D., Hagen, H., Laramee, R. S., Van Liere, R., Ma, K.-L., Ribarsky, W., Scheuermann, G., & Silver, D. (2008). Data, information, and knowledge in visualization. IEEE Computer Graphics and Applications, 29(1), 12–19. https://ieeexplore.ieee.org/abstract/document/4736452/
Floridi, L. (2005). Is Semantic Information Meaningful Data? Philosophy and Phenomenological Research, 70(2), 351–370. https://doi.org/10.1111/j.1933-1592.2005.tb00531.x
Zins, C. (2007). Conceptual approaches for defining data, information, and knowledge. Journal of the American Society for Information Science and Technology, 58(4), 479–493. https://doi.org/10.1002/asi.20508
Foehr, M., Vollmar, J., Calà, A., Leitão, P., Karnouskos, S., & Colombo, A. (2017). Engineering of Next Generation Cyber-Physical Automation System Architectures. In Multi-Disciplinary Engineering for Cyber-Physical Production Systems: Data Models and Software Solutions for Handling Complex Engineering Projects (pp. 185–206). https://doi.org/10.1007/978-3-319-56345-9_8
(N.d.).
(N.d.).
Therefore, use a Repository, the purpose of which is to encapsulate all the logic needed to obtain object references. The domain objects won’t have to deal with the infrastructure to get the needed references to other objects of the domain. They will just get them from the Repository and the model is regaining its clarity and focus. (n.d.).
Therefore, a new concept is necessary to be introduced, one that help to encapsulate the process of complex object creation. This is called Factory. Factories are used to encapsulate the knowledge necessary for object creation, and they are especially useful to create Aggregates. When the root of the Aggregate is created, all the objects contained by the Aggregate are created along with it, and all the invariants are enforced. (n.d.).
Therefore, use Aggregates. An Aggregate is a group of associated objects which are considered as one unit with regard to data changes. The Aggregate is demarcated by a boundary which separates the objects inside from those outside. Each Aggregate has one root. The root is an Entity, and it is the only object accessible from outside. The root can hold references to any of the aggregate objects, and the other objects can hold references to each other, but an outside object can hold references only to the root object. If there are other Entities inside the boundary, the identity of those entities is local, making sense only inside the aggregate. (n.d.).
A Service should not replace the operation which normally belongs on domain objects. We should not create a Service for every operation needed. But when such an operation stands out as an important concept in the domain, a Service should be created for it. There are three characteristics of a Service: 1. The operation performed by the Service refers to a domain concept which does not naturally belong to an Entity or Value Object. 2. The operation performed refers to other objects in the domain. 3. The operation is stateless. (n.d.).
Entities are important objects of a domain model, and they should be considered from the beginning of the modeling process. It is also important to determine if an object needs to be an entity or not, which is discussed in the next pattern. (n.d.).
(N.d.).
(N.d.).
However, when domain-related code is mixed with the other layers, it becomes extremely difficult to see and think about. Superficial changes to the UI can actually change business logic. To change a business rule may require meticulous tracing of UI code, database code, or other program elements. Implementing coherent, model-driven objects becomes impractical. (n.d.).
In an object-oriented program, UI, database, and other support code often gets written directly into the business objects. Additional business logic is embedded in the behavior of UI widgets and database scripts. This some times happens because it is the easiest way to make things work quickly. (n.d.).
Patrz architektura heksagonalna. (n.d.).
Tagi: , , , , ,

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.