--Originally published at Newbie Programmer

As the name say Patterns, this are used in the software engineering as a solution in a common problem in the software design, these patterns are not a finished solution to the problem they are a template or an instruction of how to deal with the problem. These patterns can be helpful for solving problems more quickly, to apply some software techniques to our projects and to improve the scalability and robust between the parts of the design. This patterns are divided in three categories Creational, Structural and Behavioral, and this division was made in the book Design Patters written by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides in 1994.

Creational

This patterns are about the instantiation of a class, the patterns can be used for creating classes using inheritance and for object creation they use delegation, and the patters that we can find here are : abstract factory, builder, factory method, prototype, singleton, and my favorite for this type is the object pool, because we can recycle objects with no use, and make it useful instead of creating another object with the same functionality.

Structural

These patterns are used for the classes and objects composition, for the structure of the classes we use inheritance to compose interfaces and for objects how to define the objects to obtain new functionality. In this classification we have these patterns: adapter, bridge, composite, decorator, facade, flyweight, private class data and proxy, proxy it’s my favorite because it’s used in representation of another object, and its useful for security of the original object.

Behavioral

These patterns oversee the class communication, the communication between objects like passing requests, adding elements to a class, default values, encapsulation etc. We can found this patterns : chain of responsibility, command, interpreter, iterator, mediator, memento, observer, state,

--Originally published at Newbie Programmer

A modeling language it’s any language that we can use for making a model, this model can be an image, text, table, diagram, etc., this kind of languages are mainly used in the software engineering and computer science for designing software, patterns, equipment, implementations, relationships, code and its based in the requirements of the domain used for example object oriented, and there are a lot of types of modeling languages but the most typical ones are the graphical and textual ones.

Graphical

In this type we found one of the most used languages UML (Unified Model Language), that is used in the object-oriented design, and the main characteristic is the use of blueprint diagrams, and we have more languages like behavior trees and flowcharts to mention some examples.

Text

This are represented in natural languages, that is a language that we typically use that’s why is called natural we learned through the history, this type of modeling languages can be used to express knowledge like dictionaries, taxonomies, geographic, etc. This can be used to write code (pseudocode) and to make it understandable to implement in many programming languages.

There is more classification of the modeling languages like algebraic, behavioral, object oriented, for information and knowledge, but the mentioned before are the most used type and classification of modeling languages.

Photo by William Warby

--Originally published at Newbie Programmer

The Unified Software Process is an iterative process framework that can be suitable for many types of projects , this have some characteristics that defines this framework for example is an Iterative and incremental development framework that allow us to test, design and implement the product before its finished not like the waterfall model that you only can do one thing at time, second, is architecture centric that supports multiple architectural models and views and its risk focused, this means that we need to solve first the critical or greatest risks in the elaboration phase. To do the Unified Software Process we need to do four phases: Inception, Elaboration, Construction and Transitive.

Inception

In this phase it’s like understanding the project, because we need to establish what are supposed to do and the goals for the project, for this we can use a list of requirements and use cases, it’s important to have a schedule of time and the cost estimation for achieving the goals.

Elaboration

In this phase is where we do the risk focused part, where we need to know the critical problems and solve them first based in the requirements that we have, and it’s important to choose the architecture we are going to use considering that is useful for the project, that is good in terms of value, functionality and scalability, and to do an schedule for the Construction Phase.

Construction

This phase is where we begin with doing code and building the use cases diagram or class diagram and the implementation of each of the parts together to make sure the program its working well with making tests or changing aspects of the elaboration phase, because it’s an iterative process we can go back and solve the problem or to add things to make the

--Originally published at Newbie Programmer

The last chapter is important, because is about putting all the things together, all the things that we learned through the chapters are revisited and make sense when they are together, and this makes the Object-Oriented Analysis & Design Project Lifecycle that is an Iterative Development that is applied to each small problem and is iterating with every problem. And this chapter explains the seven phases and a final one of this development.

Feature List: This is necessary to do write the things that the applications need to do, when this is finished we can move to the use of case diagrams.

Use Case Diagrams: This phase helps us to thing about how the application will be used without unnecessary details. In the diagrams we are dealing with interactions between actors and the system, the features reflect functionality and use cases the usage.

Break Up the Problem: With the use case diagrams we can break this problem in smaller pieces, then we can start iterating with these pieces until the application is complete with every use case, int this phase is an extra step that is Understand the Problem before we begin with the Requirements phase because we need to understand well the problem.

Requirements: Are the specific things that the system must do to work correctly, and this help to see if the use case works.

Domain Analysis: In this phase we need to do a textual analysis on the use case and figure out the nouns (candidate classes) and verbs (candidate operations).

Preliminary Design: This phase is about making design decisions, that should be based on how the application will be used and to apply object-oriented principles.

Implementation: Here we begin with the creation and testing of the code, with doing this based in the analysis, and we

--Originally published at Newbie Programmer

Iterating and testing

This chapter introduces us to show the progress to a customer, and how to do it, because the customer don’t care about our diagrams, classes, or the object oriented tools we used, they only want to see a functional application that solves their problems and more important is doing what is suppose to do, and for this is important to choose  a way of development, Feature driven development or Use case driven development.

Feature driven development, you must look at the feature list and work on one single feature at a time, then iterate and doing all the features until the functionality of the application is finished, this works well when the features don’t interconnect a whole lot and systems with lots of disconnected pieces of functionality.

Use case driven development, here you work in a single scenario through a use case, and you work until all the scenarios are completed, this is useful when the application has a lot of scenarios than individual functionalities, you can show bigger pieces of the project to the customer and works well if the system have a large and complicated process.

To show the development of the application to the customer we need to write test scenarios, where is a way to show the customer that the functionality is working well, and is needed to be creative to test the software with every possible usage and for incorrect usage, because this way we can catch errors early, and this is only for one specific thing, a expected output according to the input, and more important to match with the design.

And the chapter concludes with an interesting contract between software and the people that use it for example the frameworks , this details how the software work when