Week 12

CST 338 - Week 4

This week was the fourth week is CST 338, also known as Software Engineering. In this week we began to learn about android development.

Project 1 Review

This week we finished a large project in CST 338. We have been asked to work with one or more classmates, and answer some questions about the project.

With whom did you work?

• I worked with Nasser.

What was your strategy for solving the assignments?

• My strategy was to read all of the method descriptions before I wrote any code. As I read them I created method stubs, and detailed TODO comments for each method. Afterwards, I started writing the methods from top to bottom in the assignment prompt. If a method called another method that I had not written yet, I would go ahead and write that method first so I better understood how they interacted.

What was their strategy for solving the assignments?

• Their strategy was to follow the instructions closely as is, by following the UML diagrams and prompt as closely as possible.

How would you change your strategy having worked on the assignment?

• I think the TODO comments I wrote for each method were too detailed, and ultimately slowed me down. Instead I would have simply written the Java Doc comments for each method and followed the prompt.

According to your classmate(s): How well does your code follow the Google Java Style Guide?

• My code appears to follow the style guide well.

What was the most challenging part?

• I had never used with abstract classes or overridden methods before this project. I think learning about these was the most challenging aspect of it.

What was the most interesting?

• For me, the most interesting aspect of the assignment was analyzing the code specifications, and trying to predict how the game would feel to play if it was a fully-implemented game.

What are you the most proud of?

• I was able to complete the project in a very short amount of time, given the size of the assignment. I only had a small number of bugs to fix with my code as well, which meant I had a good understanding of the code specifications.

How did you celebrate completing the assignment? 

• I finished the project towards the end of the day, so I took a break from schoolwork and engaged in some of my hobbies and relaxed for the rest of the day.

SOLID

This week we discussed SOLID, which is a set of principles for software engineering and development. 

Single Responsibility Principle

"Each module should do one thing and do it well."

Code should not mix multiple roles or purposes, but should instead separate each into a separate class or service. Doing so decreases the likelihood of a change to one class or feature breaking another feature.

Open-Closed Principle

"You should be able to use and add to a module without rewriting it."

Many languages, such as Java, allow you to extend and create classes, but not modify the original class. One reason for this is to limit the dependency on the original class, thus limiting the need to ask the original author for changes, or having to change the class yourself. This also helps prevent code from being changed to handle multiple roles, which would break the Single Responsibility principle.

Liskov Substitution Principle

"You should be able to substitute one thing for another if those things are declared to behave the same way."

In object-oriented programming, you should be able to use any subclass in place of their parent class. In other words, a class that is type A will continue to act that way. 

Another way to interpret this principle is that if your code promises to do something, then it should keep that promise and not surprise anybody.

Interface Segregation Principle

"Don't show your clients more than they need to see."

 It is best to hide or keep private code that your client won't interact with. This helps ensure that a client doesn't become dependent on more code than they need to, and helps lower coupling between systems.

Some ways to do this are to only give clients limited implementation through interfaces or documentation that only shows public functions.

Dependency Inversion Principle

"Depend upon abstractions, not concretions."

Clients should rely on interfaces rather than concrete classes. This ensures that code is relying on a smaller surface area, and reduces the risk of a break causing another break somewhere else.

Use Case Modeling

This week we discussed Use Case Modeling in software development. A use case is a typical sequence of actions that an end-user performs in order to complete a given task. In other words, a use case is an example of what using a piece of software will normally look like. A use case should:

• Cover the full sequence of steps from the beginning of a task until the end.
• Describe the user's interaction with the system. Not any of the system's computations.
• Only include actions in which a user interacts with the system or software.

When designing a use case model, it is important to consider who will use the system, and what interactions they will make with the system.

 In use case modeling, Actors are outside entities that interact with the system:

• An actor can be an individual (human actor) or another system (system actor).
• An actor is often outside of the system, and usually outside the control of the system.
• The details of an actor impose requirements on what the system should or must do.