Class diagram for electric guitar and bass

Question

Hi I was recently asked this in an interview to represent a 6 string guitar and a 4 string bass in class structure. I am still new to software design and analysis so was not able to complete the answer. Moreover my lack of knowledge about the musical instrument played a big role in my failure. But I tried the same at home and below is what I could create after some online references.

I have never seen a electric guitar except on google while I was working on this problem. So I tried to create the uml diagram as per the information I could find online. In-fact I didn't even knew what a bass was before I worked on this problem.

I created the main Instrument class which would basically refer to guitar or bass or any similar instrument. For InstrumentSpec, I created another class that has guitar or bass common specs. Now since guitar specs would also include Pickups, Strings, Toggle Switch and Control Knobs, I moved them into separate classes.

The interviewer also asked me to design the class diagram in a way so that he could identify if note from one is equal to note from other based on fret positions and string played. So I added Frets class to include the information about position, distance, location and pressure applied and added a field stringName in instrument class to determine what string is being played in the instrument.

I am still new to software class diagrams and thus seeking help in understanding improvements in my class structure.

All comments are appreciated.

Answer 1

I'm not an expert on electric guitars or basses (I'm a drummer myself) but I can tell you that most of the things that you put in your class diagram are irrelevant.

You can't just design a class structure to represent six string guitars and four string basses, that's nonsense. You need to identify the problem domain: what specific problem is my software supposed to solve?

The concept of a guitar or a bass is different for for different kinds of applications. A web store that sells guitars is interested in the brand, the type, the color, the number of strings, which pickups it has and, most importantly, what price they sell it for. A guitar in a video game might be a collectible item that gives the player a special ability or a certain amount of points. Music software might present you with a collection of guitar samples (clean, distorted, overdriven) and a way to compose music by varying pitches and note lengths and arranging them in time.

Well, he actually told you the problem domain. It's not about switches and pickups and control knobs; it's also not about actually tuning or playing a sound. It's about: given an instrument with a bunch of strings tuned to a certain pitch and an amount of frets along the fret board, what note will it play if I press down a) a certain string at b) a certain fret.

I'm not sure if there's an inherent difference between the way a guitar and a bass produce notes but your class structure might be as easy as this (in pseudo-Java):

class FrettedStringInstrument {
  String[] strings; // E, A, D etc in the case of a guitar in standard tuning
  int amountOfFrets; // wait, how many frets does a typical guitar have?

  String noteAt(string, fret) { /* your algorithm here */ }
}

And you use it like this:

FrettedStringInstrument guitar = new FrettedStringInstrument(["E", "A", "D", "G", "B", "E"], ???);
FrettedStringInstrument bass = new FrettedStringInstrument(["E", "A", "D", "G"], ???);

String guitarNote = guitar.noteAt("E", 0); // returns "E"
String bassNote = bass.noteAt("E", 0); // also returns "E"

Maybe things are more complicated than this (I'm pretty sure string length is also involved) but in the real world, I would have visited wikipedia.org and probably some other web sites and looked up how guitars and basses actually produce notes and made sure that I got familiar enough with this domain to be able to express it in software - but that's exactly what you're sometimes supposed to do as a software engineer: get familiar with an unfamiliar domain.

Also, I'm sure the interviewer tried to show you that he is very fond of guitars and basses and maybe expected you to be at least a little familiar with one of his favorite hobbies but not being familiar with the subject doesn't make the question unreasonable.

Answer 2

There are several possible class diagrams. In practice, it is good to keep the class diagram as simple as possible, unless there is a good reason to add complexity. If the only task is to show a 6 string guitar and a 4 string bass in a class diagram, I would draw this:

The second task is to add behavior to identify if a note from one is equal to a note from the other, based on fret positions and string played. I assume a note is a frequency, which is a real number. We use the data type Real for this (a type defined by UML). Fret position is probably a real number too. To produce a note, each class needs an operation. Let's call it playNote.

Now, where do we put the behavior to compare the output of two calls? This could be a static operation isSameNote on a common superclass StringInstrument. To prevent that that superclass needs knowledge about its subclasses, it is good to add its own abstract playNote operation, which can be implemented by each subclass.

Answer 3

You can object that the question is silly because it assumes domain knowledge you cannot be expected to bring with you. People have different hobbies.

Anyway, I happen to know a fair bit about guitars and I suspect they wanted to see a class hierarchy something like this:

Instrument -> StringInstrument -> FrettedStringInstrument -> ChromaticScaleFrettedInstrument

StringInstrument would have a string collection. A string could have a Tuning property. FrettedStringInstrument would add a FretCount. Fret objects have an index, the note can be deducted from this index, knowing the tonal system, which is chromatic for the guitar and bass guitar instances.

Then 4-string bass guitar and 6-string guitar could just be different instances of ChromaticScaleFrettedInstrument with differing string counts, the guitar having 2 extra strings with higher pitched tunings.

I doubt your interviewer would have thought of it this way but it would be a defendable model if you focus on the musicality of the instruments. They probably just wanted to see you play around with inheritance and polymorphism.

Answer 4

We model for a reason.  If we don't have a reason, then any design fine.

Without knowing how a model is to be used, we could really go off the deep end, modeling to a super level of detail, which could include year of manufacture, manufacturer, model/brand, color, shape, size, image, owner (especially if famous), brand of each string, age of each string (an important item for maintenance), cost/value, and on and on and on...

Thus, in many ways, the simplest design is the best, one that assumes no extra requirements beyond given.  It is a reasonable starting point, at least.

In the simplest design, to model a guitar and a base, we need only one class, and two instances.  I would not use inheritance without a good reason, especially as instances will suffice.  (In pseudo code:)

class StringedInstrument {
    String name;
    int stringCount;
}

where

var guitar = new StringedInstrument () { "guitar", 6 };
var bass = new StringedInstrument () { "bass", 4 };

This is (almost) the simplest design that meets the basic requirement to model or "represent a 6 string guitar and a 4 string bass".  It is also easily expandable to accommodate additional requirements.

A factory method would probably be my first choice over inheritance, if we wanted to abstract construction somewhat.

Simple is good — don't model without requirements and purpose. 

Modeling is abstraction as we cannot model everything — so we abstract details irrelevant to our purposes, so that we can concentrate on those the are relevant.

To get purposes, we need to know how the objects we model will be used.  That will go to your ability to elicit requirements — probably a skill they were looking for in the interview.

For example, had they said that the purpose was cataloging instruments rather than playing music, the model might be quite different.

---

Some random comments on your model:

• You've modeled Guitar and Bass, as well as GuitarSpec and BassSpec, though you haven't modeled motivation as to why they are separate subclasses (i.e. there are no added fields or overrides specified).

• You also don't have a way to create a guitar or a bass — it may be assumed that you can create all these objects, but constructors are omitted.

• There is no guarantee that ensures a Guitar is created with a GuitarSpec, and Bass with a BassSpec.

• The use of plurality for Pickups, Strings, Frets, and Control Knobs suggests they are group descriptions, yet tightness, and position are singular.