I'm using Rational Rhapsody Architect for Systems Engineering to implement a domain-specific modeling language my team has designed. I'm building it as a profile that extends the SysML profile.
We have a metaclass that we've implemented as a new term stereotype applied to Class and generalized from Block.
I'd like to have multiple compartments with different names, that can display arbitrary text entered by the modeler in a Block Definition Diagram.
So far, only the Description compartment will display free text.
I can create an approximation by implementing a new term stereotype applied to Constraint. The specifications for those constraints are also free text and they appear in the diagram, but there are two problems: they are restricted to single line, and I can't seem to hide the stereotype name.
Do I have any options?
Related
What is software physical specification and logical specification? I understand about logical specifications which could be derived from user requirements like identifying attributes, entities and use-cases and draw the software using UML in graphical depiction. But what is the physical specification of software?
Logical vs physical terminology
The terminology logical vs. physical specification is related to the idea of an implementation-independent specification (logical) that is then refined to take into account implementation details and related constraints (physical).
This distinction can be made for any system view-point, such as architecture, data-flows and process design. But the terms are mainly used in the context of data modeling (ERD):
the logical specification describes how data meets the business requirements. Typically, you'd describe entities, their attributes and their relationships;
the physical specification describes how a logical data model is implemented in the database, taking into consideration also technical requirements and constraints. Typically, you'd find tables, columns, primary keys, foreign keys, indexes and everything that matters for the implementation.
Remark: The term "physical" probably dates back to the times where you had to design carefully the layout of the data in data (e.g. in COBOL you had to define the fields of a record at the byte level and that layout was really used to physically store the data on the disk; it was also very difficult to change it afterwards).
Purpose oriented terminology
Nowadays, specifications or models tend to be named according to their purpose. But how they are called and whether they are independent models or successive refinements of the same model is very dependent on the methodology. Some popular terminology:
Requirement specification / Analysis model, to express the business needs (i.e. problem space)
Design specification / model, to describe the solution (i.e. solution space)
Implementation specification / model, with all the technical details (i.e. one-to-one with the code, and therefore difficult to keep in sync).
Domain model, to express the design of business objects and business logic in a given domain, but without any application-specific design (i.e. like design model but with only elements that are of interest for the business).
UML
UML is UML and the same kind of diagrams may be used for different purposes. For example:
A use-case diagram represents in general user goal and tend to be mapped to requirements ("logical"). But use-cases can also show the relationship of an autonomous device / independent component to technical actors in its environment ("physical").
A class diagram can be used to document a domain model ("logical"). But a class diagram can also document the implementation details ("physical"). See for example this article with an example of logical vs. physical class diagram.
I have several documents (pdf and txt) in my notebook and I want to construct a knowledge graph using Grakn.
Through Google I found the blog but there is no documentation or readme teaching how to do that.
Also is written in the blog "The script to mine text can be found on our GitHub repo here" but I am failing in understanding what I have to do.
Can someone here advise me how to construct a knowledge graph from text using Grakn?
Grakn is a knowledge engine/network, which understands knowledge by well defined entities and relations (ontologies), so you need to use NLP (Natural Language processing) to make human language accessible to a graph network. also you need OCR (Optical Character Recognition) to convert some image texts to text. also you should teach the network basic ontologies to understand the texts. you are actually heading through Singularity era.
To give an example of how to go from a collection of text to a knowledge graph, let us assume that all of your text is concerned with a certain domain of knowledge - in the example of the blog post you mention, we are dealing with biomedical research publications.
A first step could be to find entities, or defined "things", in the text. To stick with the biomedical example, we could look for drugs and genes mentioned in the publications. This is called named-entity-recognition (NER), a technique applied in text-mining.
If a certain drug is often mentioned in the same publication as a particular gene, they "co-occur" and are likely related in some way. This would be an example of a relationship. The automated extraction of exactly how they are related is a difficult problem and is called relationship-extraction (RE).
Solutions for both NER and RE are usually domain-specific (ranging from simple matching of dictionary terms to AI models).
If you are interested in text-mining, a good place to start in python is NLTK.
The idea of a knowledge graph is to put defined things, called entities, in defined relationships to one another to create context. After you have a list of entities that you have found in all your documents, as well as their relationships (as in the example above, co-occurrance in a document or even a single sentence), you can define a schema and upload the entities and relationships into grakn and use all of its functionality to analyze your data.
For a tutorial on how to use grakn with already extracted data, see here
In contrast to class diagrams, it seems one can model multiple facets of a system in block diagrams such as software, hardware, entities, etc.
Is it possible that a single block can represent both software and hardware? Or would they always be separated into two separate blocks? E.g. When modeling some machinery, let's say the machinery has a physical button, and the machinery's software also has a "Button" software class. Would they be modeled as separate blocks or as an individual block?
The same question could be asked of a database entity that is mapped to an object oriented language as a class, and said entity also represents a real life physical actor (E.g. "User" software class & Real life physical user).
In the case that a single block can represent multiple facets, is there some form of notation to indicate "this block represents both hardware and software" - or would this just be implied based on the block having multiple and differing annotated relationships with other blocks?
A systems engineer would generally want to separate physical components and software components. The "digital twin" in software does not always represent its physical object accurately. For example, bad sensing may cause a digital twin be an inaccurate representation of the component in reality. Imagine an autonomous vehicle's position in traffic, or a "stalling" 737 MAX.
In an information system, the digital twin for a person is different from the actual person it represents. Imagine what would happen if your doctor only treated you according to inaccurate health records. You, the actual person, should be distinguishable from your health records. Moreover, the design of software should be distinguishable from the design of a database schema so the two can vary independently.
To answer your question, there's nothing to stop you from modeling everything as one block, but, if you conflate things in a model, you can't reason about them separately. Why would you want to model a physical thing and its digital twin, or a Java class and a database table as the same SysML block?
It all depends on what you are trying to communicate. Always model and create views with a specific use for the model and views in mind.
If you are just trying to communicate the concept of a system that relates people or a machine that has buttons, be they hardware or software/virtual then a single block works. If you want call attention to any features or relationships between the two possible buttons or other innerworkings of the system, then use a different block for each and create a third "system" block that "has" (aggregates/composes) those two buttons of different types or has a hardware subsystem and a software subsystem that have the buttons. If there are pertinent relationships between the two button types then show those. If the physical hardware button depends on the software implementation of a button class or function, then create that dependency relationship.
Elaborate and add detail as necessary and as soon as you have sufficiently communicated the concept, stop.
If you don't have a specific idea of what you are trying to communicate, but are trying to understand where one concept ends and the next begins and how to even think about the whole mess, try it several ways and you will probably gain a better understanding of the problem and straighten out your thinking. If a combined block doesn't show what you are trying to "say" then try different combinations of blocks and relationships. When you find something useful that solves the problem at hand, stop.
Don't get bogged down with the language
I'm a little confused on what the relationship would be for the scenario below. When examples of composition are used they always tend to use simple ones such as rooms and a building.
This scenario is that doctor patient visits are recorded. Would it be an association, composition or a mix of both? I've included a picture below of the two different relationships I am stuck between. I am thinking composition because the visit belongs to each party?
Derived association
In general my rule of thumb is that when in doubt, always use association rather than composition/aggregation. My reasons for this are:
(1) In Object-oriented analysis and design for information systems Wazlawick notes that the real advantage of composition and aggregation
is that the attributes of the parts are often used to derive attributes of the whole. As an example he mentions that the total value of an order (whole) is derived of the value of each of its items (parts). However, this to him is a design concern rather than a conceptual modelling
concern. From a conceptual modelling perspective, he believes that modellers often apply aggregation and composition inappropriately (that is, where whole-part relations are not present) and that their use seldom have real benefit. Hence he suggests avoiding or even abolishing their use.
(2) UML aims to provide a semi-formalization of part-whole relations through composition/aggregation. However, formalization of part-whole relations is a non-trivial task, which the UML specification does not do justice. Indeed, a number of researchers have pointed out various aspects with regards to aggregation and composition in which the UML specification is under specified. All have proposed means for addressing the shortcomings of the UML specification, but to date these changes have not been incorporated into the UML specification. See for instance Introduction to part-whole relations.
When being in doubt, which kind of associoation to use, use the more generic one. Especially, in your case there is no real "consists of" relation. Further in your EX2, you would have an instance of visit, which is an existance bound instance to an Doctor instance and to Patient instance. This is problem when applying the composition rules, as it also introduces an existence relation between Doctor and Patien implicitely. Thus, this shall not be done.
I guess the concept you are loooking for is an association class. This is a class, which instances give the association between an Doctor instance and Patient instance some further information.
I have a class diagram which has a dictionary (in python terms) as an attribute. This is the basic structure:
serverEntry = { creditCardObj1 : accountBalance1, creditCardobj2 : accountBalance2, ...}
To clarify, creditCardObj1 is an instance of a class CreditCard while accountBalance1 is an integer value and similarly for the other entries in the dictionary.
I read that in Java, it is called HashMap. In any case, I would like to implement it in my UML class diagram. Any tips on how to do that. I am using Visio 2007 so it would even more helpful if someone can explain in terms of that.
I won't put much effort into this, as another answer has been chosen already. That answer does not cover the closest thing in UML to a HashMap: the qualifier. It is drawn as a rectangle between a class and an association. Inside the rectangle is a name and a type. What it means is that given an instance of that type, the association will yield some number of instances of things on the other end of the association. That number of instances is specified with a multiplicity.
For your purposes, you would put creditCard: CreditCard inside the qualifier rectangle, and Integer on the other end of the association, with a multiplicity of 1.
I believe that this question is more about UML than about the programming language. Thus, please allow me to use the language I feel more comfortable in.
C# calls it Dictionary too, Dictionary<string, T> for example with a string for the HashKey. The UML Class Diagram in Visual Studio (I am using the Community Edition of VS 2015 here) is fortunately close enough to code so that the UML Model basically is the language's meta-model and the diagram is just a different view to the real code.
This comes in handy because real programming problems - like the one you asked for - can be addressed directly in the diagram. (Also: no extra code generation or additional parsing necessary to get or maintain the diagram).
I like the way Visual Studio solved this. They offer two options, one that is focussed more on the technicalities (show as Association)
and one that is focussed more on the domain (show as Collection Association).
I am usually using the first one only if I need the diagram to emphasize that the Dictionary class is involved, in every other case the second option is my preferred option.