This site is from a past semester! The current version will be here when the new semester starts.

Week 4 [Fri, Jan 29th] - Topics

[W4.1] Requirements: Prose, User Stories, Feature Lists

Prose

[W4.1a] Requirements → Specifying Requirements → Prose → What :

Feature Lists

[W4.1b] Requirements → Specifying Requirements → Feature Lists → What :

User Stories

[W4.1c] Requirements → Specifying Requirements → User Stories → Introduction :
[W4.1d] Requirements → Specifying Requirements → User Stories → Details :
[W4.1e] Requirements → Specifying Requirements → User Stories → Usage :

[W4.2] Design Principles - Part 1

[W4.2a] Principles → Separation of concerns principle :
[W4.2b] Principles → Single responsibility principle :

[W4.3] Design Principles - Part 2

[W4.3a] Principles → Liskov substitution principle
[W4.3b] Principles → Open-closed principle
[W4.3c] Principles → Law of Demeter
[W4.3d] Principles → Interface segregation principle : OPTIONAL
[W4.3e] Principles → Dependency inversion principle : OPTIONAL
[W4.3f] Principles → SOLID principles

[W4.4] Some Other Principles

[W4.4a] Principles → YAGNI principle
[W4.4b] Principles → DRY principle
[W4.4c] Principles → Brooks' law

[W4.1] Requirements: Prose, User Stories, Feature Lists

Video

Prose

W4.1a :

Requirements → Specifying Requirements → Prose → What

Can explain prose

A textual description (i.e. prose) can be used to describe requirements. Prose is especially useful when describing abstract ideas such as the vision of a product.

The product vision of the TEAMMATES Project given below is described using prose.

TEAMMATES aims to become the biggest student project in the world (biggest here refers to 'many contributors, many users, large code base, evolving over a long period'). Furthermore, it aims to serve as a training tool for Software Engineering students who want to learn SE skills in the context of a non-trivial real software product.

Avoid using lengthy prose to describe requirements; they can be hard to follow.

Feature Lists

W4.1b :

Requirements → Specifying Requirements → Feature Lists → What

Can explain feature list

Feature list: A list of features of a product grouped according to some criteria such as aspect, priority, order of delivery, etc.

A sample feature list from a simple Minesweeper game (only a brief description has been provided to save space):

Basic play – Single player play.
Difficulty levels
- Medium levels
- Advanced levels
Versus play – Two players can play against each other.
Timer – Additional fixed time restriction on the player.
...

User Stories

W4.1c :

Requirements → Specifying Requirements → User Stories → Introduction

Can write simple user stories

User story: User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. _{[Mike Cohn]}

A common format for writing user stories is:

User story format: As a {user type/role} I can {function} so that {benefit}

Examples (from a Learning Management System):

As a student, I can download files uploaded by lecturers, so that I can get my own copy of the files
As a lecturer, I can create discussion forums, so that students can discuss things online
As a tutor, I can print attendance sheets, so that I can take attendance during the class

You can write user stories on index cards or sticky notes, and arrange them on walls or tables, to facilitate planning and discussion. Alternatively, you can use a software (e.g., GitHub Project Boards, Trello, Google Docs, ...) to manage user stories digitally.

^{[credit: https://www.flickr.com/photos/jakuza/2682466984/]}

^{[credit: https://www.flickr.com/photos/jakuza/with/2726048607/]}

^{[credit: https://commons.wikimedia.org/wiki/File:User_Story_Map_in_Action.png]}

a. They are based on stories users tell about similar systems
b. They are written from the user/customer perspective
c. They are always written in some physical medium such as index cards or sticky notes

a. Reason: Despite the name, user stories are not related to 'stories' about the software.
b.
c. Reason: It is possible to use software to record user stories. When the team members are not co-located this may be the only option.

Critique the following user story taken from a software project to build an e-commerce website.

As a developer, I want to use Python to implement the software, so that we can reuse existing Python modules.

Refer to the definition of a user story.

This user story is not written from the perspective of the user/customer.

Bill wants you to build a Human Resource Management (HRM) system. He mentions that the system will help employees to view their own The number of leave days not yet takenleave balance. What are the user stories you can extract from that statement?

Remember to follow the correct format when writing user stories.

User story format: As a {user type/role} I can {function} so that {benefit}

As an employee, I can view my leave balance, so that I can know how many leave days I have left.

Note: the {benefit} part may vary as it is not specifically mentioned in the question.

W4.1d :

Requirements → Specifying Requirements → User Stories → Details

Can write more detailed user stories

The {benefit} can be omitted if it is obvious.

As a user, I can login to the system ~~so that I can access my data~~

It is recommended to confirm there is a concrete benefit even if you omit it from the user story. If not, you could end up adding features that have no real benefit.

You can add more characteristics to the {user role} to provide more context to the user story.

As a forgetful user, I can view a password hint, so that I can recall my password.
As an expert user, I can tweak the underlying formatting tags of the document, so that I can format the document exactly as I need.

You can write user stories at various levels. High-level user stories, called epics (or themes) cover bigger functionality. You can then break down these epics to multiple user stories of normal size.

[Epic] As a lecturer, I can monitor student participation levels

As a lecturer, I can view the forum post count of each student
so that I can identify the activity level of students in the forum
As a lecturer, I can view webcast view records of each student
so that I can identify the students who did not view webcasts
As a lecturer, I can view file download statistics of each student
so that I can identify the students who did not download lecture materials

You can add conditions of satisfaction to a user story to specify things that need to be true for the user story implementation to be accepted as ‘done’.

As a lecturer, I can view the forum post count of each student so that I can identify the activity level of students in the forum.

Conditions:

Separate post count for each forum should be shown
Total post count of a student should be shown
The list should be sortable by student name and post count

Other useful info that can be added to a user story includes (but not limited to)

Priority: how important the user story is
Size: the estimated effort to implement the user story
Urgency: how soon the feature is needed

More examples extra

User stories for a travel website (credit: Mike Cohen)

As a registered user, I am required to log in so that I can access the system
As a forgetful user, I can request a password reminder so that I can log in if I forget mine
[Epic] As a user, I can cancel a reservation
- As a premium site member, I can cancel a reservation up to the last minute
- As a non-premium member, I can cancel up to 24 hours in advance
- As a member, I am emailed a conﬁrmation of any cancelled reservation
[Epic] As a frequent ﬂyer, I want to book a trip
- As a frequent ﬂyer, I want to book a trip using miles
- As a frequent ﬂyer, I want to rebook a trip I take often
- As a frequent ﬂyer, I want to request an upgrade
- As a frequent ﬂyer, I want to see if my upgrade cleared

Choose the correct statements

a. User stories are short and written in a formal notation.
b. User stories is another name for use cases.
c. User stories describes past experiences users had with similar systems. These are helpful in developing the new system.
d. User stories are not detailed enough to tell us exact details of the product.

Explanation: User stories are short and written in natural language, NOT in a formal language. They are used for estimation and scheduling purposes but do not contain enough details to form a complete system specification.

W4.1e :

Requirements → Specifying Requirements → User Stories → Usage

Can use user stories to manage requirements of project

User stories capture user requirements in a way that is convenient for i.e. which features to include in the productscoping, i.e. how much effort each feature will takeestimation, and i.e. when to deliver each featurescheduling.

[User stories] strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written. _{[Mike Cohn, MountainGoat Software 🔗]}

User stories differ from e.g. a description of the requirements written in prosetraditional requirements specifications mainly in the level of detail. User stories should only provide enough details to make a reasonably low risk estimate of how long the user story will take to implement. When the time comes to implement the user story, the developers will meet with the customer face-to-face to work out a more detailed description of the requirements. [more...]

User stories can capture non-functional requirements too because even NFRs must benefit some stakeholder.

Requirements → Requirements →

Non-functional requirements

Requirements can be divided into two in the following way:

Functional requirements specify what the system should do.
Non-functional requirements specify the constraints under which the system is developed and operated.

Some examples of non-functional requirement categories:

Data requirements e.g. size, how often do data changevolatility, saving data permanentlypersistency etc.,
Environment requirements e.g. technical environment in which the system would operate in or needs to be compatible with.
Accessibility, Capacity, Compliance with regulations, Documentation, Disaster recovery, Efficiency, Extensibility, Fault tolerance, Interoperability, Maintainability, Privacy, Portability, Quality, Reliability, Response time, Robustness, Scalability, Security, Stability, Testability, and more ...

Business/domain rules: e.g. the size of the minefield cannot be smaller than five.
Constraints: e.g. the system should be backward compatible with data produced by earlier versions of the system; system testers are available only during the last month of the project; the total project cost should not exceed $1.5 million.
Technical requirements: e.g. the system should work on both 32-bit and 64-bit environments.
Performance requirements: e.g. the system should respond within two seconds.
Quality requirements: e.g. the system should be usable by a novice who has never carried out an online purchase.
Process requirements: e.g. the project is expected to adhere to a schedule that delivers a feature set every one month.
Notes about project scope: e.g. the product is not required to handle the printing of reports.
Any other noteworthy points: e.g. the game should not use images deemed offensive to those injured in real mine clearing activities.

You may have to spend an extra effort in digging NFRs out as early as possible because,

NFRs are easier to miss e.g., stakeholders tend to think of functional requirements first
sometimes NFRs are critical to the success of the software. E.g. A web application that is too slow or that has low security is unlikely to succeed even if it has all the right functionality.

Given below are some requirements of TEAMMATES (an online peer evaluation system for education). Which one of these are non-functional requirements?

a. The response to any use action should become visible within 5 seconds.
b. The application admin should be able to view a log of user activities.
c. The source code should be open source.
d. A course should be able to have up to 2000 students.
e. As a student user, I can view details of my team members so that I can know who they are.
f. The user interface should be intuitive enough for users who are not IT-savvy.
g. The product is offered as a free online service.

(a)(c)(d)(f)(g)

Explanation: (b) are (e) are functions available for a specific user types. Therefore, they are functional requirements. (a), (c), (d), (f) and (g) are either constraints on functionality or constraints on how the project is done, both of which are considered non-functional requirements.

An example of an NFR captured as a user story:

As a	I want to	so that
impatient user	to be able experience reasonable response time from the website while up to 1000 concurrent users are using it	I can use the app even when the traffic is at the maximum expected level

Given their lightweight nature, user stories are quite handy for recording requirements during early stages of requirements gathering.

A recipe for brainstorming user stories

Given below is a possible recipe you can take when using user stories for early stages of requirement gathering.

Step 0: Clear your mind of preconceived product ideas

Even if you already have some idea of what your product will look/behave like in the end, clear your mind of those ideas. The product is the solution. At this point, we are still at the stage of figuring out the problem (i.e., user requirements). Let's try to get from the problem to the solution in a systematic way, one step at a time.

Step 1: Define the target user as a persona:

Decide your target user's profile (e.g. a student, office worker, programmer, salesperson) and work patterns (e.g. Does he work in groups or alone? Does he share his computer with others?). A clear understanding of the target user will help when deciding the importance of a user story. You can even narrow it down to a persona. Here is an example:

Jean is a university student studying in a non-IT field. She interacts with a lot of people due to her involvement in university clubs/societies. ...

Step 2: Define the problem scope:

Decide the exact problem you are going to solve for the target user. It is also useful to specify what related problems it will not solve so that the exact scope is clear.

ProductX helps Jean keep track of all her school contacts. It does not cover communicating with contacts.

Step 3: List scenarios to form a narrative:

Think of the various scenarios your target user is likely to go through as she uses your app. Following a chronological sequence as if you are telling a story might be helpful.

A. First use:

Jean gets to know about ProductX. She downloads it and launches it to check out what it can do.

After playing around with the product for a bit, Jean wants to start using it for real.

...

B. Second use: (Jean is still a beginner)

Jean launches ProductX. She wants to find ...

...

C. 10th use: (Jean is a little bit familiar with the app)

...

D. 100th use: (Jean is an expert user)

Jean launches the app and does ... and ... followed by ... as per her usual habit.

Jean feels some of the data in the app are no longer needed. She wants to get rid of them to reduce clutter.

More examples that might apply to some products:

Jean uses the app at the start of the day to ...

Jean uses the app before going to sleep to ...

Jean hasn't used the app for a while because she was on a three-month training programme. She is now back at work and wants to resume her daily use of the app.

Jean moves to another company. Some of her clients come with her but some don't.

Jean starts freelancing in her spare time. She wants to keep her freelancing clients separate from her other clients.

Step 4: List the user stories to support the scenarios:

Based on the scenarios, decide on the user stories you need to support. For example, based on the scenario 'A. First use', you might have user stories such as these:

As a potential user exploring the app, I can see the app populated with sample data, so that I can easily see how the app will look like when it is in use.

As a user ready to start using the app, I can purge all current data, so that I can get rid of sample/experimental data I used for exploring the app.

To give another example, based on the scenario 'D. 100th use', you might have user stories such as these:

As an expert user, I can create shortcuts for tasks, so that I can save time on frequently performed tasks.

As a long-time user, I can archive/hide unused data, so that I am not distracted by irrelevant data.

Do not 'evaluate' the value of user stories while brainstorming. Reason: an important aspect of brainstorming is not judging the ideas generated.

Other tips:

Don't be too hasty to discard 'unusual' user stories:
Those might make your product unique and stand out from the rest, at least for the target users.
Don't go into too much details:
For example, consider this user story: As a user, I want to see a list of tasks that needs my attention most at the present time, so that I pay attention to them first.
When discussing this user story, don't worry about what tasks should be considered needs my attention most at the present time. Those details can be worked out later.
Don't be biased by preconceived product ideas:
When you are at the stage of identifying user needs, clear your mind of ideas you have about what your end product will look like. That is, don't try to reverse-engineer a preconceived product idea into user stories.
Don't discuss implementation details or whether you are actually going to implement it:
When gathering requirements, your decision is whether the user's need is important enough for you to want to fulfil it. Implementation details can be discussed later. If a user story turns out to be too difficult to implement later, you can always omit it from the implementation plan.

While use cases can be recorded on e.g. index cards or sticky notesphysical paper in the initial stages, an online tool is more suitable for longer-term management of user stories, especially if the team is not physically in the same locationco-located.

You can create issues for each of the user stories and use a GitHub Project Board to sort them into categories.

Example Project Board:

Example Issue to represent a user story:

You can break the user story into issue subject and description in this way:

title	`As a user I can add a deadline`
Description	`... so that I can keep track of my deadlines`

Alternatively, you can put the entire user story in the description.

title	`Add deadline`
Description	`As a user I can so that I can keep track of my deadlines`

In both cases, apply the type.Story label.

A video on GitHub Project Boards:

Example Google Sheet for recording user stories:

Example Trello Board for recording user stories:

This article by Mike Cohn from MountainGoatSoftware explains how to use user stories to capture NFRs.

[W4.2] Design Principles - Part 1

W4.2a :

Principles → Separation of concerns principle

Video

Can explain separation of concerns principle

Separation of concerns principle (SoC): To achieve better modularity, separate the code into distinct sections, such that each section addresses a separate concern. -- Proposed by Edsger W. Dijkstra

A concern in this context is a set of information that affects the code of a computer program.

Examples for concerns:

A specific feature, such as the code related to the add employee feature
A specific aspect, such as the code related to persistence or security
A specific entity, such as the code related to the Employee entity

Applying Separation of ConcernsSoC reduces functional overlaps among code sections and also limits the ripple effect when changes are introduced to a specific part of the system.

If the code related to persistence is separated from the code related to security, a change to how the data are persisted will not need changes to how the security is implemented.

This principle can be applied at the class level, as well as at higher levels.

The n-tier architecture utilizes this principle. Each layer in the architecture has a well-defined functionality that has no functional overlap with each other.

This principle should lead to higher cohesion and lower coupling.

Can explain coupling

Coupling is a measure of the degree of dependence between components, classes, methods, etc. Low coupling indicates that a component is less dependent on other components. High coupling (aka tight coupling or strong coupling) is discouraged due to the following disadvantages:

Maintenance is harder because a change in one module could cause changes in other modules coupled to it (i.e. a ripple effect).
Integration is harder because multiple components coupled with each other have to be integrated at the same time.
Testing and reuse of the module is harder due to its dependence on other modules.

In the example below, design A appears to have more coupling between the components than design B.

Discuss the coupling levels of alternative designs x and y.

Overall coupling levels in x and y seem to be similar (neither has more dependencies than the other). (Note that the number of dependency links is not a definitive measure of the level of coupling. Some links may be stronger than the others.). However, in x, A is highly-coupled to the rest of the system while B, C, D, and E are standalone (do not depend on anything else). In y, no component is as highly-coupled as A of x. However, only D and E are standalone.

Explain the link (if any) between regressions and coupling.

When the system is highly-coupled, the risk of regressions is higher too e.g. when component A is modified, all components ‘coupled’ to component A risk ‘unintended behavioral changes’.

Discuss the relationship between coupling and a measure of how easily a given component can be testedtestability.

Coupling decreases testability because if the Software Under TestSUT is coupled to many other components, it becomes difficult to test the SUT in isolation of its dependencies.

Choose the correct statements.

a. As coupling increases, testability decreases.
b. As coupling increases, the risk of regression increases.
c. As coupling increases, the value of automated regression testing increases.
d. As coupling increases, integration becomes easier as everything is connected together.
e. As coupling increases, maintainability decreases.

(a)(b)(c)~~(d)~~(e)

Explanation: High coupling means either more components are required to be integrated at once in a big-bang fashion (increasing the risk of things going wrong) or more drivers and stubs are required when integrating incrementally.

Can explain cohesion

Cohesion is a measure of how strongly-related and focused the various responsibilities of a component are. A highly-cohesive component keeps related functionalities together while keeping out all other unrelated things.

Higher cohesion is better. Disadvantages of low cohesion (aka weak cohesion):

Lowers the understandability of modules as it is difficult to express module functionalities at a higher level.
Lowers maintainability because a module can be modified due to unrelated causes (reason: the module contains code unrelated to each other) or many modules may need to be modified to achieve a small change in behavior (reason: because the code related to that change is not localized to a single module).
Lowers reusability of modules because they do not represent logical units of functionality.

“Only the GUI class should interact with the user. The GUI class should only concern itself with user interactions”. This statement follows from,

a. A software design should promote separation of concerns in a design.
b. A software design should increase cohesion of its components.
c. A software design should follow single responsibility principle.

(a)(b)(c)

Explanation: By making ‘user interaction’ the GUI class’s sole responsibility, we increase its cohesion. This is also in line with the separation of concerns (i.e., we separated the concern of user interaction) and the single responsibility principle (the GUI class has only one responsibility).

W4.2b :

Principles → Single responsibility principle

Video

Can explain single responsibility principle

Single responsibility principle (SRP): A class should have one, and only one, reason to change. _{-- Robert C. Martin}

If a class has only one responsibility, it needs to change only when there is a change to that responsibility.

Consider a TextUi class that does parsing of the user commands as well as interacting with the user. That class needs to change when the formatting of the UI changes as well as when the syntax of the user command changes. Hence, such a class does not follow the SRP.

Gather together the things that change for the same reasons. Separate those things that change for different reasons. _{―- Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin}

An explanation of the SRP from www.oodesign.com
Another explanation (more detailed) by Patkos Csaba
A book chapter on SRP written by the father of the principle itself, Robert C Martin

[W4.3] Design Principles - Part 2

W4.3a

Principles → Liskov substitution principle

Video

Can explain Liskov Substitution Principle

Liskov substitution principle (LSP): Derived classes must be substitutable for their base classes. _{-- proposed by Barbara Liskov}

LSP sounds the same as substitutability but it goes beyond substitutability; LSP implies that a subclass should not be more restrictive than the behavior specified by the superclass. As you know, Java has language support for substitutability. However, if LSP is not followed, substituting a subclass object for a superclass object can break the functionality of the code.

Paradigms → OOP → Inheritance →

Substitutability

Every instance of a subclass is an instance of the superclass, but not vice-versa. As a result, inheritance allows substitutability: the ability to substitute a child class object where a parent class object is expected.

An AcademicStaff is an instance of a Staff, but a Staff is not necessarily an instance of an AcademicStaff. i.e. wherever an object of the superclass is expected, it can be substituted by an object of any of its subclasses.

The following code is valid because an AcademicStaff object is substitutable as a Staff object.

Staff staff = new AcademicStaff(); // OK

But the following code is not valid because staff is declared as a Staff type and therefore its value may or may not be of type AcademicStaff, which is the type expected by variable academicStaff.

Staff staff;
...
AcademicStaff academicStaff = staff; // Not OK

Suppose the Payroll class depends on the adjustMySalary(int percent) method of the Staff class. Furthermore, the Staff class states that the adjustMySalary method will work for all positive percent values. Both the Admin and Academic classes override the adjustMySalary method.

Now consider the following:

The Admin#adjustMySalary method works for both negative and positive percent values.
The Academic#adjustMySalary method works for percent values 1..100 only.

In the above scenario,

The Admin class follows LSP because it fulfills Payroll’s expectation of Staff objects (i.e. it works for all positive values). Substituting Admin objects for Staff objects will not break the Payroll class functionality.
The Academic class violates LSP because it will not work for percent values over 100 as expected by the Payroll class. Substituting Academic objects for Staff objects can potentially break the Payroll class functionality.

The Rectangle#resize() method can take any integers for height and width. This contract is violated by the subclass Square#resize() because it does not accept a height that is different from the width.

class Rectangle {
    ...
    /** sets the size to the given height and width*/
    void resize(int height, int width) {
        ...
    }
}


class Square extends Rectangle {
    
    @Override
    void resize(int height, int width) {
        if (height != width) {
            //error
       }
    }
}

Now consider the following method that is written to work with the Rectangle class.

void makeSameSize(Rectangle original, Rectangle toResize) {
    toResize.resize(original.getHeight(), original.getWidth());
}

This code will fail if it is called as makeSameSize(new Rectangle(12, 8), new Square(4, 4)). That is, the Square class is not substitutable for the Rectangle class.

If a subclass imposes more restrictive conditions than its parent class, it violates Liskov Substitution Principle.

True
False

True.

Explanation: If the subclass is more restrictive than the parent class, code that worked with the parent class may not work with the child class. Hence, the substitutability does not exist and LSP is violated.

W4.3b

Principles → Open-closed principle

Video

Can explain open-closed principle (OCP)

The Open-Closed Principle aims to make a code entity easy to adapt and reuse without needing to modify the code entity itself.

Open-closed principle (OCP): A module should be open for extension but closed for modification. That is, modules should be written so that they can be extended, without requiring them to be modified. _{-- proposed by Bertrand Meyer}

In object-oriented programming, OCP can be achieved in various ways. This often requires separating the specification (i.e. interface) of a module from its implementation.

In the design given below, the behavior of the CommandQueue class can be altered by adding more concrete Command subclasses. For example, by including a Delete class alongside List, Sort, and Reset, the CommandQueue can now perform delete commands without modifying its code at all. That is, its behavior was extended without having to modify its code. Hence, it is open to extensions, but closed to modification.

The behavior of a Java generic class can be altered by passing it a different class as a parameter. In the code below, the ArrayList class behaves as a container of Students in one instance and as a container of Admin objects in the other instance, without having to change its code. That is, the behavior of the ArrayList class is extended without modifying its code.

ArrayList students = new ArrayList<Student>();
ArrayList admins = new ArrayList<Admin>();

Which of these is closest to the meaning of the open-closed principle?

a. We should be able to change a software module’s behavior without modifying its code.
b. A software module should remain open to modification as long as possible.
c. A software module should be open to modification and closed to extension.
d. Open source software rocks. Closed source software sucks.

(a)

Explanation: Please refer the handout for the definition of OCP.

W4.3c

Principles → Law of Demeter

Video

Can explain the Law of Demeter

Law of Demeter (LoD):

An object should have limited knowledge of another object.
An object should only interact with objects that are closely related to it.

Also known as

Don’t talk to strangers.
Principle of least knowledge

More concretely, a method m of an object O should invoke only the methods of the following kinds of objects:

The object O itself
Objects passed as parameters of m
Objects created/instantiated in m (directly or indirectly)
Objects from the objects that are held by instance variables ofdirect association of O

The following code fragment violates LoD due to the following reason: while b is a ‘friend’ of foo (because it receives it as a parameter), g is a ‘friend of a friend’ (which should be considered a ‘stranger’), and g.doSomething() is analogous to ‘talking to a stranger’.

void foo(Bar b) {
    Goo g = b.getGoo();
    g.doSomething();
}

LoD aims to prevent objects from navigating the internal structures of other objects.

An analogy for LoD can be drawn from Facebook. If Facebook followed LoD, you would not be allowed to see posts of friends of friends, unless they are your friends as well. If Jake is your friend and Adam is Jake’s friend, you should not be allowed to see Adam’s posts unless Adam is a friend of yours as well.

Explain the Law of Demeter using code examples. You are to make up your own code examples. Take Minesweeper as the basis for your code examples.

Let us take the Logic class as an example. Assume that it has the following operation.

setMinefield(Minefield mf): void

Consider the following that can happen inside this operation:

mf.init();: this does not violate LoD since LoD allows calling operations of parameters received.
mf.getCell(1, 3).clear();: this violates LoD because Logic is handling Cell objects deep inside Minefield. Instead, it should be mf.clearCellAt(1, 3);.
timer.start();: this does not violate LoD because timer appears to be an internal component (i.e. a variable) of Logic itself.
Cell c = new Cell(); c.init();: this does not violate LoD because c was created inside the operation.

This violates the Law of Demeter.

void foo(Bar b) {
    Goo g = new Goo();
    g.doSomething();
}

True
False

False

Explanation: The line g.doSomething() does not violate LoD because it is OK to invoke methods of objects created within a method.

Pick the odd one out.

(b)

Explanation: Law of Demeter, which aims to reduce coupling, is also known as ‘Don’t talk to strangers’ and ‘Principle of least knowledge’.

W4.3d : OPTIONAL

Principles → Interface segregation principle

Can explain interface segregation principle

Interface segregation principle (ISP): No client should be forced to depend on methods it does not use.

The Payroll class should not depend on the AdminStaff class because it does not use the arrangeMeeting() method. Instead, it should depend on the SalariedStaff interface.

public class Payroll {
    // ...    
    private void adjustSalaries(AdminStaff adminStaff) { // violates ISP
        // ...
    }

}

public class Payroll {
    // ...    
    private void adjustSalaries(SalariedStaff staff) { // does not violate ISP
        // ...
    }
}

W4.3e : OPTIONAL

Principles → Dependency inversion principle

Can explain dependency inversion principle (DIP)

Dependency inversion principle (DIP):

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

Example:

In design (a), the higher level class Payroll depends on the lower level class Employee, which is a violation of DIP. In design (b), both Payroll and Employee depend on the Payee interface (note that inheritance is a dependency).

Design (b) is more flexible (and less coupled) because now the Payroll class need not change when the Employee class changes.

Which of these statements is true about the Dependency Inversion Principle?

a. It can complicate the design/implementation by introducing extra abstractions, but it has some benefits.
b. It is often used during testing to replace dependencies with mocks.
c. It reduces dependencies in a design.
d. It advocates making higher level classes depend on lower level classes.

Explanation: Replacing dependencies with mocks is Dependency Injection, not DIP. DIP does not reduce dependencies, rather, it changes the direction of dependencies. Yes, it can introduce extra abstractions but often the benefit can outweigh the extra complications.

W4.3f

Principles → SOLID principles

Can explain SOLID Principles

The five OOP principles given below are known as SOLID Principles (an acronym made up of the first letter of each principle):

Principles →

Single responsibility principle

Single responsibility principle (SRP): A class should have one, and only one, reason to change. _{-- Robert C. Martin}

If a class has only one responsibility, it needs to change only when there is a change to that responsibility.

Gather together the things that change for the same reasons. Separate those things that change for different reasons. _{―- Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin}

An explanation of the SRP from www.oodesign.com
Another explanation (more detailed) by Patkos Csaba
A book chapter on SRP written by the father of the principle itself, Robert C Martin

Principles →

Open-closed principle

The Open-Closed Principle aims to make a code entity easy to adapt and reuse without needing to modify the code entity itself.

In object-oriented programming, OCP can be achieved in various ways. This often requires separating the specification (i.e. interface) of a module from its implementation.

ArrayList students = new ArrayList<Student>();
ArrayList admins = new ArrayList<Admin>();

Which of these is closest to the meaning of the open-closed principle?

a. We should be able to change a software module’s behavior without modifying its code.
b. A software module should remain open to modification as long as possible.
c. A software module should be open to modification and closed to extension.
d. Open source software rocks. Closed source software sucks.

(a)

Explanation: Please refer the handout for the definition of OCP.

Principles →

Liskov substitution principle

Liskov substitution principle (LSP): Derived classes must be substitutable for their base classes. _{-- proposed by Barbara Liskov}

Paradigms → OOP → Inheritance →

Substitutability

The following code is valid because an AcademicStaff object is substitutable as a Staff object.

Staff staff = new AcademicStaff(); // OK

Staff staff;
...
AcademicStaff academicStaff = staff; // Not OK

Now consider the following:

The Admin#adjustMySalary method works for both negative and positive percent values.
The Academic#adjustMySalary method works for percent values 1..100 only.

In the above scenario,

The Admin class follows LSP because it fulfills Payroll’s expectation of Staff objects (i.e. it works for all positive values). Substituting Admin objects for Staff objects will not break the Payroll class functionality.
The Academic class violates LSP because it will not work for percent values over 100 as expected by the Payroll class. Substituting Academic objects for Staff objects can potentially break the Payroll class functionality.

class Rectangle {
    ...
    /** sets the size to the given height and width*/
    void resize(int height, int width) {
        ...
    }
}


class Square extends Rectangle {
    
    @Override
    void resize(int height, int width) {
        if (height != width) {
            //error
       }
    }
}

Now consider the following method that is written to work with the Rectangle class.

void makeSameSize(Rectangle original, Rectangle toResize) {
    toResize.resize(original.getHeight(), original.getWidth());
}

This code will fail if it is called as makeSameSize(new Rectangle(12, 8), new Square(4, 4)). That is, the Square class is not substitutable for the Rectangle class.

If a subclass imposes more restrictive conditions than its parent class, it violates Liskov Substitution Principle.

True
False

True.

Principles →

Interface segregation principle

Interface segregation principle (ISP): No client should be forced to depend on methods it does not use.

The Payroll class should not depend on the AdminStaff class because it does not use the arrangeMeeting() method. Instead, it should depend on the SalariedStaff interface.

public class Payroll {
    // ...    
    private void adjustSalaries(AdminStaff adminStaff) { // violates ISP
        // ...
    }

}

public class Payroll {
    // ...    
    private void adjustSalaries(SalariedStaff staff) { // does not violate ISP
        // ...
    }
}

Principles →

Dependency inversion principle

Dependency inversion principle (DIP):

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

Example:

Design (b) is more flexible (and less coupled) because now the Payroll class need not change when the Employee class changes.

Which of these statements is true about the Dependency Inversion Principle?

a. It can complicate the design/implementation by introducing extra abstractions, but it has some benefits.
b. It is often used during testing to replace dependencies with mocks.
c. It reduces dependencies in a design.
d. It advocates making higher level classes depend on lower level classes.

[W4.4] Some Other Principles

W4.4a

Principles → YAGNI principle

Can explain YAGNI principle

YAGNI (You Aren't Gonna Need It!) Principle: Do not add code simply because ‘you might need it in the future’.

The principle says that some capability you presume your software needs in the future should not be built now because chances are "you aren't gonna need it". The rationale is that you do not have perfect information about the future and therefore some of the extra work you do to fulfill a potential future need might go to waste when some of your predictions fail to materialize.

Yagni -- A detailed article explaining YAGNI, written by Martin Fowler.

W4.4b

Principles → DRY principle

Can explain DRY principle

DRY (Don't Repeat Yourself) principle: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. _{-- The Pragmatic Programmer, by Andy Hunt and Dave Thomas}

This principle guards against the duplication of information.

A functionality being implemented twice is a violation of the DRY principle even if the two implementations are different.

The value of a system-wide timeout being defined in multiple places is a violation of DRY.

W4.4c

Principles → Brooks' law

Can explain Brooks' law

Brooks' law: Adding people to a late project will make it later. -- Fred Brooks (author of The Mythical Man-Month)

Explanation: The additional communication overhead will outweigh the benefit of adding extra manpower, especially if done near a deadline.

Does the Brook’s Law apply to a school project? Justify.

Yes. Adding a new student to a project team can result in a slow-down of the project for a short period. This is because the new member needs time to learn the project and existing members will have to spend time helping the new member get up to speed. If the project is already behind schedule and near a deadline, this could delay the delivery even further.

Which one of these (all attributed to Fred Brooks, the author of the famous SE book The Mythical Man-Month), is called the Brook’s law?

a. All programmers are optimists.
b. Good judgement comes from experience, and experience comes from bad judgement.
c. The bearing of a child takes nine months, no matter how many women are assigned.
d. Adding more manpower to an already late project makes it even later.

(d)