UML component diagrams are concerned with the components of a system. Components are defined as independent, encapsulated units of the system. Each component provides an interface for other components to interact with it.

The Component Diagram are used to visualize how a system’s pieces interact and and what relationships they have among them. This is high-level diagram, and shouldn’t considered to have details.

Continue reading “UML Component Diagram” →

It’s a difficult to capture the complete behavior of a system with a single perspective. Hence we have to observe it from 4 views.

1 – Logical View

Focuses on the functionality of a system and the objects found within it. The context is the services that should be provided to the end users. From the found objects you can create a UML class diagram that illustrates the logical view.

The class diagram has several purposes such as establishing the vocabulary of the problem and resulting system by defining all of the classes, their attributes and behaviors. It becomes easy to understand the key abstraction and terminology. The Logical View is also useful when specifying database schemes.

2 – Process View

It presents the processes implemented by the objects in the logical view. Focusing on non functional requirements which specify the desired qualities for the system. It includes quality attributes such as Performance and Availability.

Also helps to show the execution order of your different objects. It would show the calls to methods by the logical view in the correct order. Behaviors that asynchronous or concurrent are also described.

A UML sequence diagram would be helpful for illustrating the methods.

A UML activity diagram can illustrate the processes or activities for a system.

Continue reading ““4+1” Model View” →

The principle states that classes should achieve code reuse through aggregation rather than inheritance. For example the Composite design pattern and the Decorator design pattern use this approach.

The idea here that concrete classes can delegate tasks for other concrete classes. Delegation will provide loser level coupling then inheritance. Hence, provide your system more flexibility.

Disadvantages of Composition:

The biggest drawback of composition is that you must provide implementations for all behavior without the benefit of inheritance to share code. This means that you might have very similar implementations across the classes.

To manage complexity, one idea is that a class should be designed so that it does not need to know about and depend upon almost every other class in the system. By limiting which classes communicate with each other, you can enforce the principle of Least Knowledge. This principle is also realized in a rule known as The Law of Demeter.

The underlying idea of this Law is that classes should know about and interact with as few other classes as possible. This means that any class should only communicate with its “immediate friends”. These “friends” would be other classes that one class should only know about. It helps to reduce coupling and provide stability to a system.

• A method, M, is an object, O, can call on any other method within O itself (encapsulated within the same object).
• A method M, can call the methods of any parameter P (encapsulated within an object that is in the parameters of M).
• A method M, can call a method, N, of an object, I, if I is instantiated within M (encapsulated within an object that is instantiated inside of M).
• Any method, M, in object O, can invoke methods of any type of object that is a direct component of O (encapsulated within an object that is referenced in an instance variable of the class for M).

To summarize the rules, a method should not invoke methods of any object that is not local.

Classes should know as little as possible about your system as a whole, this will help to reduce amount of coupling and prevent unwanted effects from cascading through your entire system.

The Interface Segregation principle states that a class should not be forced to depend on methods it does not use. This means that any classes that implement an interface, should not have “dummy” implementations of any methods defined in the interface. Instead, you should split large interfaces into smaller generalizations.

The example before applying the Interface Segregation principle:

The best way is to apply Interface Segregation principle applying splitting the ICashier interface into 2 smaller. This will allow each interface to be more accurate with its description of expected behaviors, and it will allow you to pick and choose which correct combinations of interfaces a concrete class should implement.

Continue reading “SOLID (I) – Interface Segregation Principle” →

Classes should be open for extensions but closed for change.

You should consider a class as being “closed” to editing once it has been:

• Testing to be functioning properly.
• All the attributes and behavior are encapsulated.
• Proved to be stable within your system.

Once you’ve reached a point in development where you’ve already finalized most of your design decisions, and have implemented the most of your system, then you should consider “closing” your classes. It’s needed to avoid introducing undesirable side effects (of course it’s still acceptable to modify the code if need to fix bugs).

Continue reading “SOLID (O) – Open/Closed Principle” →

Dependency is an important topic, because it will determine how easily you can make changes to your system. The Dependency Inversion principle help to make a system more robust and flexible.

The principle states that high level modules should depend on high level generalizations, and not on low level details. This means that the client classes should depend on an interface or abstract class instead of referencing to concrete resources.

High level resources: interfaces and abstract classes.

Low level resources: concrete class.

Class diagram comparison between the low and high level resources:

Continue reading “SOLID (D) – Dependency Inversion Principle” →

In simple words: the subclass should be able to substitute a base class when needed and don’t lost sense/don’t change behavior after substitution.

As inheritance allows the subclass to become polymorphic, because inheritance lets the subclass become a subtype of the base class.

Subtyping also allows subclasses to be used as substitutes for their base class. Substitution states that:

Any class, S, can be used to replace a class, B, if and only if, S is a subtype of B.

Simply put, any subclass can stand in for its base class. Because of inheritance, a subclass is expected to have the same characteristics and behave in the same way.

The base class is the more generalized class, and therefore, its attributes and behaviors should reflect it. The names given to the attributes and methods, as well as the implementation of each method must be broad enough that all subclasses can use them.

If inheritance is not used correctly, it can lead to a violation of the “Liskov Substitution Principle”. This principle uses substitution to determine whether or not inheritance has been properly used. The Liskov Substitution Principle states that:

If a class, S, is a subtype of a class, B, then S can be used to replace all instances of B without changing the behaviors of a program.

Continue reading “SOLID (L) – Liskov Substitution Principle” →