Let's code a Library Management System - Part 1

Library Management System

Suppose you want to open a library, it will not be fairly large but it has many books, many CDs, many audio cassettes, etc which will be a good sharing experience since you don't use them anymore or not much frequently. And you are fed up of all the clutter they have caused and want to set things in order !

Great, so to manage the library, to keep things in order and to keep track of who has the books or CDs etc you need a system to manage that. So you decide to code it up in say c++ but before doing that one has to think about the design and what changes might happen in future and can the design be robust to handle those changes. Can the design be extended and managed easily, etc.

If you decide to model your software in an Object Oriented(ish) fashion here is what you will need :

• System requirements
• understand what is system supposed to do, gather all the requirements and figure out the length and breadth of the problem
• Use case diagram
• Find out who are the actors in this system and what will they do, what are their use cases
• Class diagram 
• Identify the classes in the system, define relationships between them
• Activity diagrams
• Think about some use case and see how the flow of control happens for that system functionality
• Code
• Once design is clear, sound and reasonable, code it up

While this seems very easy in theory, its easy to get confused or overwhelmed when trying to come up with actual design, so lets keep things concrete crisp and simple to begin with.

System requirements :

- All the items - books, cds, etc should be properly cataloged - one should be able to retrieve any item by searching and one should be able to add new items

- Borrower should be able to checkout an item or reserve an item

- Borrower should have an upper limit of number of books

- Borrower should be able to create an account and get notified of the due dates and any item being available

- Librarian should be able to issue an item and collect fine

- Librarian should be able to open an account and collect deposit and also close an account

- System should notify the Borrower of due dates and other updates

- Each item needs to be uniquely identified

Use case diagram :

Who are the actors and what they do:

- Librarian : will register the user into system, will take deposit money or fine, will issue book/item, will delete a user, will add new items-books, cds etc, can search for items in the system, generate a library card for user using number from system

- Member : can also search for items in system, get a library card with his/her details and unique number, checkout a book, reserve a book

- System : notify the member of due date and late fees, notify the member when a book is available

From this we create a simple use case diagram (click this to know more about use case diagram notations):

Class diagram:

Class diagrams are the most important part of designing a system in object oriented fashion. Classes are basically categories and these diagrams show these categories and the relationships between them. Different kinds of relations can be association, multiplicity, aggregation, composition - these are just confusing names of very simple things as we will see later on. Another useful concept which one often sees in system is generalization - we see three categories each of which "is-a" super category then we abstract that out. For example : We have search library items using author, search using name, search using isbn, search using unique id, each of these "is-a" search and search behaviour can be abstracted out to an abstract category and then other concrete categories talk about details.

There are some fancy arrows used to depict these relationships, but important is that the relationship is clearly understood. Here is a nice video explaining it quickly.

Now lets think about various entities / categories / classes in our library management system, what are the properties and behaviour of  each class and what sort of relationships exist between them :

- Library : The main entity 

- Member : User of library who borrows, this can extend generic Account

- Book : This is a type of Item

- CD : This is a type of Item

- AudioCassette : This is a type of Item

- Item : This can have common attributes

- Catalog : This contains information about all items and search can be done on it
- Librarian : The administrator, this can also extend generic Account
- ItemReservation : Represents item reservation details and also fetches it for item
- ItemIssue : Represents item issue details, fetches it for item and issues it also
- Fine : Generates fine for Member
- Notification : Notifies about due date and reserved book when available
- Rack : Represents the physical location of where an Item is kept

Following is the class diagram :

Since this post has become long, I will break it here and continue in part 2, where I will think about activity diagram, ie control flow and then code it up in c++

Abstraction is everywhere

Abstraction means hiding the non relevant details from the user of a system. This is used to reduce complexity by fixing the desired input and output of a system.

Abstraction is something which happens naturally whenever we are talking about anything. For example if I say : "I slept yesterday at 11pm". Here I am talking about the activity of sleeping. For a listener or reader of that sentence it is one action - sleeping. But actually that one action abstracts or hides details about few more actions - making bed, manage room temperature, turn off light, etc. Now these actions are also abstractions for some more actions , like making bed means setting up pillow and blanket, changing cover etc

So we see that each label for an action hides behind it more details of actions or rather a label represents a set of labels or actions. Everything can not be labels else there will not be actual work done. So there is a set of real actions and then there is a hierarchy of how we label them usefully to hide complexity of all the small real actions - this is abstraction.

Another common example is Car - what I need to know to drive a car ? Steering, Clutch, Brake, Throttle, Gear changes, Hand Brake. Now Let's pick one, say Throttle pedal - all the driver needs to know is that when it is pressed - the speed of car increases and when the foot is lifted off it, it comes back up and the car does not accelerate anymore. But what details is it hiding behind the hood? Depending on which car you are driving that Throttle pedal might have different implementation - some maybe just electronically controlled, some using metallic wires to turn on air shaft to get more air to engine and gasoline intake regulated by sensors, some may be manipulating the amount of gasoline when wire is pulled rather than just air etc

Unless things don't break - which they eventually will - user just cares about the Input and Output or the simplest tag abstracting out all the details. But when things stop working correctly - for example say throttle wire gets stuck at full throttle and for no input car driver is still getting maximum output. One needs a way to fix it - one has to peel off the layer of abstraction to fix that issue or one can call an "Engineer" to fix it !

Every form is a symbolic representation of something more behind it. For example a face is an abstraction of emotions and thoughts in a persons mind. Interestingly the final abstract impression of emotion delivered by a face is something which is supposed to map the internal emotion. The intermediate details of which muscles are moved or how a picture of face is drawn using light and shadows becomes irrelevant but not unnecessary. In an art form which an artist draws he needs to be very well aware of what and how is he drawing and he has to be aware of all the details and abstract them out properly for an observer to connect seamlessly with the face. In case of a real person, this gets more complicated and real - humans have many layers, some which they think they can control but can not and some which they can. Some which are built by what they have been doing or thinking the whole day, some having impressions of what thoughts they were having for many weeks or years. In this case - all the details just render a real image at a single point in time and how the observer perceives it is an abstract impression. Observer can use some symbols or words to describe some parts of that impression but most details are hidden away in the impression itself.

[ref]

Class called Cat

Class is a blueprint for an object. What that means is that it simply is a template of properties and behaviour.

For example we saw Tom object in previous example. Tom is name of a Cat, there can be many more Cat's like Tom. Say we have Whiskers and FunnyTail as another two Cats. Here each object has different names but all of them are of same class - Cat

Now when we talk of a class Cat, we can think of its state or properties - name, color, nap time, favourite food, date of birth, maximum running speed etc etc . Also Cat can do some actions as behaviour - play, meow, sleep, show anger, show cute eyes, run after something, etc

So we see that the nature and ability of different cats is different and this can be represented by the different state of cat objects.

________________________________________
Cat

________________________________________

properties :

name

color

favourite food

nap time

max running speed
________________________________________

behaviour :

meow

eat

run after something

show anger
________________________________________

Now say Whiskers ran twice as fast as Tom, then when Tom is running after Whiskers, he can never catch up

...
Cat tom = new Cat(*magic*);

Cat whiskers = new Cat(*more magic*);

...

...

tom.runAfter(whiskers);

What is Object Oriented Programming

Object oriented programming is a style of programming that focuses on using objects to design and build applications.

That means if we have to write a software which represents some real world system or some hypothetical system - we try to find out key objects in it and then see how they interact with each other.

For example say a Carrom Board Game - if you wanted to write software for this you will think of main objects in it - the board itself, striker, wood-disk, powder, player, queen, etc. Then you will think about the actors and their actions - player hits striker at some angle, etc

Another example can be say you are writing a File System - here although there are no physical objects - but still there can be concepts which can be modeled - like files, directories, permission, access, owner, user, etc

So it's not just about purely OOP but more about how various parts of code interact with each other. How the dependencies are managed between these pieces of code. How can these pieces of code structure themselves so that they are easily modify-able, how do these structures of code deal with changes and addition of new features.

Common terms one hears when writing code : Object, Class, Encapsulation, Abstraction, Inheritance, Polymorphism

Lets talk about Object, others we can talk about in future posts

Object is the basic building block - it represents a real world entity or a concept. For example - cat named Tom

Now this is a specific Object representing Tom in code. Depending on which language you are using the code will differ, but basically Tom will have some properties - which will represent its current state like - grey color, green eyes, etc and then some methods which will list what kinds of actions he can do - eg since its a cat it can meow, run, follow, eat etc.

So imagine we have this Tom object in our software program, we can simulate actions to it or make it interact with other objects, for example imagine there is a mouse named Jerry. Then we can do :

tom.follow(jerry);