Software Design & Architecture

Software Design looks at the lower-level aspects of a system. Example – Interior Designer
Software Architecture looks at the higher-level aspects of a system. Example – Building Architect

Object Oriented Design

Object Oriented Modeling – it keeps your code organized, flexible, and reusable.
When solving a problem, object-oriented modeling involves the practice of representing key concepts through objects in your software. Depending on the problem, many concepts, even instances of people, places, or things, become distinct objects in the software.
Object have specifications and responsibilities (behaviors).
1. Form initial requirements and come up with an initial design.
2. Elicit new requirements by asking probing questions.
3. Conceptual Design Mockups – defines major components and connections. Each component has tasks that it needs to perform, known as responsibilities.
4. Technical Design Diagrams – defines how the responsibilities identified in the conceptual design are met.

Components turn into collections of functions, classes, or other components. These pieces then represent a much simpler problem that the developers can individually implement.


Categories of Objects in Design:-
1. Entity Objects correspond to some real world entity in the problem space.
2. Control Objects are responsible for coordination.
3. Boundary Objects sit at the boundary between the systems.


Some software design decisions will involve trade-offs in different quality attributes, such as performance, convenience, scalability, time to market, and security.

Functional Requirements describe what the system or application is expected to do.
Non-Functional Requirements specify how well the system or application does what it does.

CRC Cards to represent the identified components, connections, and responsibilities during conceptual design. CRC stands for Class, Responsibilities, and Collaborators.

Screen Shot 2018-04-02 at 1.02.21 PM.png

Collaborators are other classes that the class interacts with to fulfill its responsibilities.


Four Design Principles:-
1. Abstraction – simplifying a concept in a problem domain to to its essentials within some context, and abstracting the unnecessary complexity from the outside world.
2. Encapsulation – Three things: 1) bundle attributes values, data, behaviors, functions, 2) expose certain data and functions, and 3) restrict access to certain data and functions.
3. Decomposition – taking a whole thing and dividing it up into different parts OR taking a bunch of separate parts and combining them to form a whole.
4. Generalization – helps to reduce the amount of redundancy when solving problems. It is achieved by inheritance.


UML Class Diagram
UML stands for Unified Modeling Language


CRC to UMLScreen Shot 2018-04-03 at 10.14.22 AM.png


UML to Java codeScreen Shot 2018-04-03 at 10.14.48 AM.png



Screen Shot 2018-04-03 at 11.24.14 AM.png

Getter Methods are to retrieve data. The method name typically begins with get and ends with the attribute to be returned. Getters often retrieve a private piece of data.
Setter Methods are to set or change data. The method name typically begins with set and ends with the attribute being set. Setters often set values for a private variable.

Screen Shot 2018-04-03 at 11.30.18 AM.png



Association: a loose relationship between two objects.
Screen Shot 2018-04-03 at 11.49.27 AM.png

Screen Shot 2018-04-03 at 11.50.04 AM.png

Aggregation: multiple parts are combined to make a whole. The whole “has a” relationship with parts is considered a weak relationship. Although the parts belong to a whole, there could be sharing of parts among wholes, and parts can also exist independently. Screen Shot 2018-04-03 at 11.55.02 AM.png
The empty diamond in the UML diagram represents the whole in this relationship. It shows that its an aggregation.
Screen Shot 2018-04-03 at 11.58.33 AM.png

Screen Shot 2018-04-03 at 11.58.48 AM.png
Composition: an exclusive containment of parts, otherwise known as a strong “has a” relationship. The whole cannot exist without its parts. If the whole loses any of its parts, it ceases to exist. If the whole is destroyed, all of its parts are also destroyed. Contained parts are exclusive to the whole. Usually, you can access the parts only through the whole.
Screen Shot 2018-04-03 at 12.03.04 PM.png
The filled diamond represents the whole, and shows that its a strong “has a” relationship, which means its a composition relationship.
Screen Shot 2018-04-03 at 12.04.33 PM.pngScreen Shot 2018-04-03 at 12.04.50 PM.png



Screen Shot 2018-04-03 at 2.01.56 PM.png

Screen Shot 2018-04-03 at 2.02.56 PM.png

Inheritance is shown by the arrow, the superclass is at the top and the subclasses are at the bottom, showing inheritance. The # represents that the variables are protected. In Java, a protected attribute or method can only be accessed by 1) the encapsulating class, 2) all subclasses, and 3) all classes within in the same package.

We use the word abstract to create a general class, which means the class cannot be instantiated. The subclass of an abstract class will have all of its attributes and behaviors.

Screen Shot 2018-04-03 at 3.25.54 PM.png

A subclass constructor must call its super class constructor if it has an explicit constructor using the keyword super.


An interface only declares method signatures, and no constructors, attributes, or method bodies. Interfaces are not classes.

Screen Shot 2018-04-03 at 3.37.09 PM.png

A class can inherit an interface using the keyword implements. The class must implement all the methods declared in the interface.

Screen Shot 2018-04-03 at 3.40.45 PM.png

Abstract classes and Interfaces can be used to implement Polymorphism. Interfaces can inherit from other interfaces. A class can implement multiple interfaces.

Screen Shot 2018-04-03 at 4.52.18 PM.png

Screen Shot 2018-04-03 at 4.53.23 PM.png

Two metrics to evaluate design complexity:-
1. Coupling
2. Cohesion
Screen Shot 2018-04-03 at 6.18.02 PM.png


Screen Shot 2018-04-03 at 6.19.07 PM.png

Screen Shot 2018-04-03 at 6.19.44 PM.png

We want our design to be loosely coupled so pieces can fit together with each other easily.

Three things to consider when evaluating coupling of a module:-
1. Degree – number of connections between the module and others. Fewer parameters or narrow interfaces means degree is small and coupling is loose.
2. Ease – the connections between the module and others should be obvious, and should not require understanding of implementation of other modules.
3. Flexibility – interchangeability of other modules for this module. The other modules should be easily replaceable for something better in the future.

COHESION – the clarity of the responsibilities of a module.

If a module has one task or is clear about its responsibility, it has high cohesion.
If a module has more than one purpose or an unclear purpose, it has low cohesion.

We want high cohesion. If a module has low cohesion, you should probably split your module.

Our goal is to create flexible, reusable and maintainable code. Separation of concerns creates more cohesive classes using abstraction, encapsulation, decomposition, and generalization. This creates a system that easier to maintain because each class is organized so that it only contains the code that it needs to do its job. Modularity is increased in turn, which allows developers to reuse and build up individual classes without affecting others.


Information Hiding
Four different access specifiers in Java:-
1. Public – accessible from any class in the system; doesn’t allow other classes to change the implementation.
2. Protected – only accessible to the encapsulating class itself, all sub-classes, and classes within the same package.
3. Default – only accessible to the classes in the same package; not accessible to classes, even sub-classes in other packages.
4. Private – only accessible to the encapsulating class.


Generalization and inheritance are some of the most difficult topics to master in pbject oriented programming and modeling.
If we are using inheritance to simply share attributes or behavior without further adding anything special in our subclasses, we are misusing inheritance. There is no point for the subclasses to exists since the superclass already is enough.
The Liskov Substitution Principle states that a subclass can replace a superclass, if and only if, the subclass does not change the functionality of the superclass.
The subclass must have more functionality than the superclass. If there is no specialized behavior, we can just use the superclass directly.
Subclasses provide and share attributes and behaviors from the same superclass, but each subclass has its own distinct functions.


UML Sequence Diagram
Screen Shot 2018-04-13 at 12.09.07 PM.png

Create a UML sequence diagram that will show your clients how the system’s classes will interact when customers are buying their flight tickets on the booking website.
The system should allow the customer to search available flights from the database by inputting their desired location and departure/arrival date. The website will search the database and return the available flights to display. Once the customer has chosen the flight, they will add the flight to their cart and checkout. They will also then input their payment information and once everything is complete, the website should confirm the flight, empty cart and lastly display a confirmation of the ticket for the flight.

Screen Shot 2018-04-13 at 12.12.05 PM.png

UML State Diagram – Vending Machine
Screen Shot 2018-04-13 at 12.20.16 PM.png

During your two previous assignments you created a UML class diagram and sequence diagram to display your new system for North American airports. You are now required to create a UML state diagram to communicate the state of the planes in the airports.
The airplanes should go through multiple different states. When planes are not in use for a flight they are usually waiting to be assigned. Once a plane is chosen to be used for a flight, they are assigned to that flight until the airplane is ready for take-off. While the plane is in the air and flying the state is termed ‘en route’. Once the plane has reached its destination, the plane has to change into a state of landing for the airport to prepare for its arrival. Finally, once the plane has successfully landed, the plane is checked to see if it is ready to be assigned to a new flight or if maintenance is required. If maintenance is required the plane is unusable and if a mechanic decides that the plane cannot be repaired it is removed from the airport and disposed.

Screen Shot 2018-04-13 at 12.21.34 PM.png


Model Checking is a systematic check of your system’s state model in all its possible states. Basically, you check all the various states of your software and find that there are any errors by simulating different events that would change the states and variables of your software. So you check if the state model of your software contains some flaw. These checks are done using model checking software. Model checkers generate a State Model from your code. A state model is an abstract state machine that can be in one of various states. The model checker then checks that the state model conforms to certain behavioral properties.

There are three different phases to performing model checking,

1. the modeling phase
2. the running phase
3. and the analysis phase


The modeling phase comes first. This is where you enter the model description. This will be provided in whatever programming language your system uses. You also describe the desired properties. During the modeling phase, you can perform some Saturday checks. These are quick checks that should be easy to do because they usually come from very clear and simple logic. It’s like testing if a light bulb is working by flipping a switch on and off. It’s clear to see when the light bulb is malfunctioning. It’s beneficial to get rid of these simpler errors before using any model checkers so that you can focus on specifying the more complex properties to check. The second phase is the running phase, this is when you run the model checker to see how your model conforms to the desired properties that you’ve wrote in the modeling phase. The last phase is the analysis phase. This is where you check if all the desired properties are satisfied and if any are violated. Violations are called counterexamples. Your model checker will provide descriptions of violations in your system so that you can analyze how it got to that state.