Posts

Showing posts from March, 2018

Software Engineering: Phenomena and Concepts

Image
This'll be a sort of  abridged  summary of the topic, any more information you might need, I recommend you try the book (name in bottom of the post). When talking about concepts  and phenomena  (in the context of the book) as follows: Phenomena -  It is what we refer to as Reality,  as in things we perceive in the real world, things that are concrete. Concepts  - More abstract, it is the idea  of a given phenomena. An example of this can be something like a Car. Phenomena: Automobile -> Concept: Car A car is a concept (an idea) of an automobile, where an automobile can be anything in the real word that serves that specific purpose. We can also take things a step further, with the type of entity that we use. Atomic Entities Compound Entities Atomic Entities: Individual entities, broken down to it's most basic representation. (For the purpose of the domain that you wish to represent) Example: Chair Desk Monitor Computer K

Software Engineering: Documents

Image
This'll be a sort of abridged summary of the topic, any more information you might need, I recommend you try the book (name in bottom of the post). In the professional realm documentation is everything (according to this book, it's probably true), lack thereof can make your job a living nightmare every time there's an update. Even if tedious proper documentation can go a long way. In Dines' Book there are 3 main types of documentation, each different but of equal importance. Informative Documentation Descriptive Documentation Analysis Documentation It can get a bit tricky trying to differentiate them so let me try  to explain it. Informative Documents are basically documents where you talk about the domain and everything involving it (like partners, place, the scope, etc) without necessarily going into detail about the technical stuff involved in your domain. In an informative document you can find the following: Descriptive Documents  

Software Engineering: The Triptych of Software Engineering

Image
Actually just a triptych of a peacock, not of Software Engineering. This'll be a sort of abridged  summary of the topic, any more information you might need, I recommend you try the book (name in bottom of the post). In any given domain  that you will work on, you will encounter the following things inside them: Entities These are comparable to variable types in any programming language, the bread and butter of domain engineering. Without them you can't do much. In this book, we use a language called RSL (or eRAISE ), created by the books author Dines Bjørner to explain our domain in a more technical way. In RSL Entities are refered to as " types ". Say we are working on a domain for a super market, the entities (types) could be: customer, employee, money, merchandise, etc. Functions Now with functions, they tell you what the domain will do with those entities, called values in RSL. Like any function, it will take in an input (or not) and produce an outpu