Low Level Design

Interview Outline

---

LLD Process Steps / Memory Map of System Design

Followings steps should be generally taken while Low level designing a system-

1. Clear the system requirement
2. Define all the class’ and their attributes
   1. Important diagrams – Class diagram and sequence diagram
3. Declare all the methods
4. Show class relation
5. Implement methods

1. Clarify the requirement

Objective – This signifies that you are thinking through and not assuming .

Be clear about what functionality is going to be there in iterative model of development and time constrained environment.Don’t assume anything, clarify .

Handle Ambiguity

Object-oriented design (OOD) questions are often intentionally vague in order to test whether you’ll make assumptions or if you’ll ask clarifying questions.

When being asked an object-oriented design question, you should inquire who is going to use it and how they are going to use it. Depending on the question, you may even want to go through the “six Ws”; who, what(in case of parking -car/bike/bus , in case of coffee- latte/capichino ), where, when, how, why.

Example

• If it’s parking lot design
  1. can be clarified if it’s multi level parking
  2. parking can be done by valet also!
  3. when – will there be any closing time for operation? if we want to handle this edge case also?
• If it’s gaming Design
  1. can be clarified it it support 2 or more player
• For example, suppose you were asked to describe the object-oriented design for a coffee maker. This seems straightforward enough, right? Not quite.
  1. Your coffee maker might be an industrial machine designed to be used in a massive restaurant servicing hundreds of customers per hour and making ten different kinds of coffee products. Or it might be a very simple machine, designed to be used by the elderly for just simple black coffee. These use cases will significantly impact your design.

2. Define all the class’ and their attributes

Define What all class you are going to include, and let the other guy know these all class’ you are planning/thinking to use.

Identifying classes can be challenging. Poorly chosen classes can complicate the application’s logical structure, reduce reusability, and hinder maintenance. This article provides a brief overview of object-oriented classes and offers tips and suggestions to identify cohesive classes.

Object-oriented classes support the object-oriented principles of abstraction, encapsulation, polymorphism and reusability. Classes specify knowledge (attributes) – they know things – and behavior (methods) – they do things.

Identifying object-oriented classes is both a skill and an art. It’s a process that one gets better at over time. For example, it’s not unusual for inexperienced designers to identify too many classes. Modeling too many classes results in poor performance, unnecessary complexity and increased maintenance. On the other hand, too few classes tend to increase couplings, and make classes larger and unwieldy. In general, strive for class cohesiveness where behaviour is shared between multiple, related classes rather than one very large class.

Cohesive classes reduce coupling, enable extensibility and increase maintainability.

Therefore, begin class modeling by identifying candidate classes – an initial list of classes from which the actual design classes will emerge. Design classes are the classes that are modeled. Candidate classes exist for the sole purpose of deriving the design classes. Initially, there will be a lot of candidate classes – that’s good. However, through analysis, their number will be reduced as they are dropped, combined and merged

Candidate classes can be discovered in a variety of ways. Here are three:

1. Noun and noun phrases: Identify the noun and noun phrases, verbs (actions) and adjectives (attributes) from the Use Cases, Actor-Goal List, Application Narrative and Problem Description.
2. CRC cards: an informal, group approach to object modeling.
3. GRASP: A formal set of principles that assign responsibilities.

Once the list has been created, analyze the candidate classes for associations with other classes. Look for collaborating classes. How does each relate to each other and to the business process? Sometimes, it’s helpful to ask, “Why keep this class?” In other words, assume the class is redundant or unnecessary. Keep it only if it plays a collaborating role.

Example

Candidate Classes	Design Classes
Student	Student
Teacher	Professor
Class	Course
Subject	Assessment
Grades
Tests

Design classes will emerge from the analysis of the candidate classes.

Associations are the key to identifying cohesive classes. The following subsections identify the various associations that can exist between classes and suggestions to identify them.

Associations

The classes in an application system don’t exist in a vacuum. Classes are associated with, or related to, other classes.These relationships occur when a class has, uses, knows about, or is acquainted with, one or more classes.

A relationship is an association between classes.

When identifying relationships, start with the class that interacts with as many other classes as possible; perhaps, the core classes of the application. It’s helpful to ask, “Who cares about this class?”, “Who is interested in this class?”, “Why is this class necessary?” Starting with the core classes will quickly identify the other relationships

Start with core associations.

An association is usually modeled using a solid line that connects two classes.

Most times, a single line doesn’t provide enough information. Form a practice of giving each association a name to clarify the relationship. Use verbs or simple verb phrases as association names.

Association roles

Associations also have roles. Each class in an association has a role that describes its meaning in the relationship. Roles are optional and if, used, should describe the role as a noun. For example, a Professor is an instructor to a Student who is a learner or pupil.

Multiplicity Indicators

A role can have multiplicity – an indication of how many objects participate in the relationship. Multiplicity indicators can be conditional or unconditional.

Examples of multiplicity indicators are:

In Figure 4, the first two indicators (that start with “0…”) are conditional meaning no objects need be present in the relationship. The last two indicators (that start with “1..”) are unconditional meaning at least one object must be present in the relationship. For example:

In Figure 5, a Professor can exist without the existence of a Student. Therefore, the multiplicity for the Student is 0…*. However, the same is not true for the Student. A Student must have at least one Professor. Hence, the 1…* indicator for the Professor.

Multiplicity indicators are also referred to as cardinalities.

Unconditional indicators may impose a referential integrity constraint. Consider the following example:

Class A and class B depend on the existence of the other. Since the multiplicity is unconditional the following is implied:

1. When class A (or class B) is removed, the corresponding class B (or class A) must also be removed.
2. When class A (or class B) is added, the corresponding class B (or class A) must also be added.

Unconditional indicators must be checked for referential integrity constraints..

Association class

An association can also possess its own attributes and behavior – just like a class. Sometimes, data exist that does not strictly belong to any of the participating classes. In these cases, an Association class is created to map the data to the participating classes. The class, then, becomes the association. The association class will contain attributes that include pointers, or references, to instances of the two classes.

(e.g one table with people and another with relation based on thier id i.e child and pid )

For example, a Student class has an association to a Course class. A student can take many courses, and a course can be taken by many students. However, who is responsible for the grade? Placing the grade in the Student class gives a student the same grade for all courses. Placing the grade in the Course class gives all students taking the same course the same grade.

The Association class resolves this issue by linking (or mapping) the grade (and other attributes) to the Student and the Course classes. Now, a Student can have many grades for many courses, but each grade in the StudentClassAssociation is associated to a single student and course.

Association classes often occur in many-to-many associations

Composition

Sometimes a class is composed of other classes. Composition associations form a whole-part relationship. In this relationship, the life of the part depends on the whole. In other words, when the whole is destroyed or removed, the part is also. Moreover, the part cannot belong to more than one whole. This implies that the cardinality of the whole to the part is always “1”.

In a composition association, the whole manages the lifecycle of the part.

To identify composition associations, look for classes that can not exist without other classes. Look for “wholes” and “parts”. Ask, “Is this class part of another class?” For example, a Sentence class is part of a Paragraph class that is part of a Chapter class that is part of a Book class. “Does this class depend on another class?”

The key question to ask, “Is this class destroyed when another class is destroyed?”

Aggregation

Aggregation is a weaker form of a composition. The key difference between an aggregation and a composition is, in an aggregation, the part is not destroyed when the whole is destroyed. In an aggregation relationship, the part may be independent of the whole but the whole requires the part. An automobile, for example, is composed of an engine, chassis, wheels, etc.. The wheels are required for the definition for an automobile, but, they are independent and not necessarily destroyed when the automobile is destroyed. Aggregation is often referred to as a “Has-a” relationship, as in, an Automobile Has-a(n) engine.

To identify aggregation associations, ask, “Is this class part of another class and is it independent of the other class?”

To avoid confusion, when the decision to use the composition/aggregation association is unclear, it’s best to model the relationship as a simple association.

Generalization/Specialization

The generalization/specialization association exists when one class is a specialized version of another class. In this relationship, a common, or base, class forms the foundation for more specialized, or derived, classes. This association is commonly referred to as inheritance because the derived classes inherit the functionality of their base classes to provide specialized behavior.

Inheritance provides the mechanism for new classes to be formed from the attributes and behavior of existing classes.

As base classes are specialized into derived classes, hierarchies are formed that represent is-a or kind-of relationships. For example, an Algebra course is-a specialization of a Math course; a student is a kind-of Person

To identify inheritance relationships, ask, “Is this class a specialization of a more general class?”

Beware of the tendency to see all associations in terms of inheritance. This leads to complex and deep class hierarchies that are difficult to develop. As a rule of thumb, limit hierarchies to six or fewer levels.

Inheritance is best suited for relatively shallow class hierarchies.

Use Inheritance when:

1. The inheritance hierarchy represents an is-a relationship and not a has-a (composition/aggregate) relationship.
2. The same behavior is applied to different data types.
3. The class hierarchy is reasonably shallow, and unlikely to become much deeper over time.

Interface inheritance

Closely related to inheritance is the concept of interface inheritance. Like an inherited class, an interface provides a common specification for behavior, but, unlike an inherited class, an interface cannot be created. An interface simply specifies common behaviour that other classes inherit but implement differently. This implies that unrelated classes can provide independent implementations for the same behavior specification (polymorphism).

For example, the .NET framework provides the IComparable interface that defines a generalized comparison method. This interface is typically used for sorting purposes. Classes that inherit the IComparable interface implement behavior specific to their needs. So, using the same IComparable interface, an Integer class can sort integers, a Byte class can sort bytes, a Student class can sort students, and so on.

The behavior has been abstracted out from any particular class and specifically implemented by all classes that need it.

Use interface inheritance when:

• Unrelated object types need to provide the same behavior.
• Multiple inheritance is needed (very difficult to implement using the inheritance association).
• Inheritance is prohibited. For example, C# structures cannot inherit from classes, but they can implement interfaces.

The Strategy Design Pattern is an excellent candidate for an interface inheritance.

Additional Link-

• How to create Class diagram http://www.agilemodeling.com/artifacts/classDiagram.htm#DesignClassDiagrams

3. Declare all the methods

Define methods as per the requirement. no need to write implementation of method at this stage, just he purpose should suffice at this stage.

4. Show class relation

• This class will be calling what – using graphical representation you can explain.
  1. Composition- Which objects are members of which other objects?
  2. Inheritance – Do any objects inherit from any others?
  3. Association – Are relationships many-to-many or one-to-many?
     • If any entity is singleton.

For example, in the restaurant question, we may come up with the following design:

1. Party should have an array of Guests.
2. Server and Host inherit from Employee
3. Each Table has one Party , but each Party may have multiple Tables.
4. There is one Host for the Restaurant

Be very careful here—you can often make incorrect assumptions. For example, a single Table may have multiple Parties (as is common in the trendy “communal tables”at some restaurants). You should talk to your interviewer about how general purpose your design should be.

5. Implement methods

As per situation you can proceed with implementation of method(if being asked) or you want to extend.

At this point, you should have the basic outline of your object-oriented design. What remains is to consider the key actions that the objects will take and how they relate to each other. You may find that you have forgotten some objects, and you will need to update your design

For example, a Party walks into the Restaurant, and a Guest requests a Table from the Host. The Host looks up the Reservation and, if it exists, assigns the Party to a Table. Otherwise, the Party is added to the end of the list. When a Party leaves, the Table is freed and assigned to a new Party in the list.