In a Conceptual class diagram, should Abstract Classes and arrowed lines be utilised?

You show in your UML diagram as much detail as you need. Do you need inheritance or dependency relationships? If you do, you add them. I will not tell you that must omit things either. However, adding stuff you do not need is not required, and usually counterproductive.

In UML, diagrams are additive. For example, if you have the same class in multiple different diagrams, but they have different attributes or relationships... it means the actual class would have all of them, from all the diagrams.

Thus, you do not have to include all the details in a diagram. You include only those that you need for what you are doing. If necessary, you can add more diagrams to add detail.

---

There are some predefined levels of detail. I suggest to not even worry about what level of details are there when making a diagram, just make your diagram. Afterwards, if you really want to (or somebody asks, which never happened to me), you can see which level of detail does your diagram fit.

I'll remind you that you do not have to put the whole system in a single UML diagram. UML diagrams do not have to be complete. For example, you can represent a class with all the details in one diagram, and only use a box (details suppressed) in other diagrams. You may have one diagram with all the relationships and each class represented as a box, and then one diagram per class with the other details... Those are just two ways out of many to break a diagram into multiple ones. For example, if paper or screen are limitations.

To reiterate, if details are missing in a particular UML diagram, that is OK.

---

Finally, do not forget that UML is a tool.

A hammer does not tell you the kinds of furniture you can make. And if it is better for you to attach the pieces with screws instead of nails, you need a different tool set.

The UML specification does not define a "conceptual Class diagram". However, the idea of conceptual, logical, and physical concepts come from what I've seen practiced in entity-relation (ER) modeling for database design where conceptual models focus on the business objects and their relations, the logical model adds attributes and other entities that are required for operation, and the physical model is a blueprint of the design of the entities and their relations. This seems similar to what Martin Fowler has written about in the context of UML Modes - sketch, notes, blueprint, and programming language.

For me, the advantage of the UML is the standardized notation. If you use a symbol on a diagram or model, there are clear definitions of what that symbol is. If you state that your diagram is created using the UML, you do not need to create a legend or key that defines what your notation is, since the Object Management Group has not only done that, but created a more rigorous specification of the language. This is independent of the level of abstraction that is shown in your diagram or model of the system - as long as you follow the rules of the language, you can use one of many levels of abstraction.

To answer your specific question, it depends on exactly what you mean by "conceptual class diagram". If you follow definitions like those from conceptual ER models, it depends on if the abstract class is something that exists in the domain of the business objects or if it is done for technical reasons. If it exists in the domain, then I would include it. However, if it is added to provide a technical benefit to the organization of the software system, then I would not include it unless you were moving more toward the idea of a logical model in the ER world. In the end, though, you should communicate in a way that is effective for the stakeholders of the model or diagram to do their work.

Since we are just describing the problem domain rather than showing how the actual software will be designed, does that mean that we should not need abstract classes to show inheritance and arrowed lines to symbolise relationships, such as dependencies?

If you're describing the problem domain you do not need to show relations, inheritances, abstract classes, or even a conceptual classes. You need to show the problem.

A typical class diagram isn't about the problem domain. It's full of implementation details. The big question it answers is what classes will know about what classes.

That has nothing at all to do with the problem domain. The problem domain is about your requirements. What problem are you trying to solve? What are your use cases?

If what you're really trying to ask is if it's ok for your actual class implementation to deviate from your class design document the answer is sure. So long as no one needs your old class design document anymore.

Can abstract classes and arrowed lines be omitted? Sure, if doing so makes your real point clear and doesn't surprise people. If you're concerned about that you can always add a note to that effect: "abstract classes omitted", "dependencies on utility classes omitted", "Framework X dependencies omitted".

There is no hard and fast rule here. Do what makes the most sense.

The goal of an UML is to create clarity, so the only rule is "try to make things as clear as you can". Sometimes, clarity is achieved by sticking to a predetermined convention that your viewers already understand. But there are also times where deviating from the rules ends up with an easier to digest schema.

If the clarity from deviating outweighs the drawback from deviating from the expected norm, then you've made the right decision.

Everything below this line is just examples of why I use different ways of visualizing data in different scenarios.

---

For example, I tend to create entities that all derive from a common BaseEntity which houses the ID and some audit fields. Putting that BaseEntity on a UML diagram, while pedantically correct, would lead to a hurricane of associations that are going to make the diagram much harder to parse.
You're going to get association lines crossing eachother (or, even worse, moving under the class objects to wrongly imply that the association ends there) which is going to end up confusing your viewers.

However, sometimes I do use inheritance for my entities, where the base class and each derived class has its own specific properties. They usually do get shown on the diagram, because it highlights the difference between an association with the base class (all BaseFoo derivations have a Bar) and an association with a derived class (only ThisSpecificDerivedFoo has a Bar).
It also helps to highlight any issues in the diagram, e.g. if I wrongly added the association to all derived classes instead of adding it once to the base class.

---

For clarity, I often use a different arrow style (triangular arrowhead, compared to the usual V-shaped arrowhead I use) and color (in my case blue) for inheritance lines. And a different color for abstract classes (in my case grey).

Where possible, I try to make sure that classes involved in an inheritance are group together (visually) and stick to a simple tree shape where the children are horizontally/vertically aligned adjacent to their parent (like this).

---

When using a DDD approach with aggregate roots, I often end up drawing boxes around the aggregates, and coloring the aggregate roots diferently. As far as I'm aware, that's not a predetermined convention, but I find that it massively helps in quickly getting the lay of the land when looking at the diagram.

---

When I'm dealing with a small diagram, about the size where it fits on 4 A4 pages in a 2x2 grid, I put everything (entities, properties, associations) on it.

For larger diagrams, I tend to omit the properties, and only show the classes and associations. I then create a second diagram which shows the classes and all of their properties, but without associations.

For sufficiently large diagrams, I make several diagrams where I make a diagram of each aggregate, which contains all the classes of the aggregate plus any directly related classes (so that their association to the rest of the diagram is clear. Those "outsider" classes are marked in a different color (grey) and are put on the outer edge of the diagram to help showcase that they don't belong on this diagram except for the association they have with classes that do belong on this diagram.

Depending on the complexity of an aggregate diagram, I either add the properties to it or make separate association/property diagrams (just like I mentioned before).