Design Patterns

--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,

16458561251_b34f988cb6_h.jpg
Continue reading "Design Patterns"

Modeling Languages and Tools

--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.

10510618765_c04b35bfda_k.jpg

Photo by William Warby

 

Unified Software Process

--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

3472308107_f54cddff29_o
Continue reading "Unified Software Process"

CHAPTER 10 – The OOA&D Lifecycle

--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

end.
Continue reading "CHAPTER 10 – The OOA&D Lifecycle"

CHAPTER 9 – Iterating and Testing

--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

2878528492_aff110ca2e_o.jpg
Continue reading "CHAPTER 9 – Iterating and Testing"

System Development Life Cycle

--Originally published at Newbie Programmer

The development of software has life cycles, because you need to follow a series of steps to do a good software you can’t only do one thing and its done, this is why we need cycles and strategies for doing application, this particular life cycle its consisted of seven steps or phases that helps to define our goals, the advantage of this is that you can go back to previous steps if you need to modify them. So, i am gonna explain this 7 steps.

Planning, it’s where you begin describing the cost and benefits of the project, the time you have, available resources, the people needed and their motivation, and other things that should be considered.

Analysis, this can be related of the requirements a theme that is very used in the object oriented analysis to know what the software (project)  must do, and what my customer wants to do with the application, and to do that, we need to hear our customer about what they want and how we can improve this things into a real thing, for this important to have an requirements list to understand what the project really needs to do.

Design, in this step is when you describe the things you need to supply the requirements you have from the analysis phase, things like the use of diagrams, samples of code, use cases, an another stuff that helps to satisfy the requirements.

Development, this phase is the beginning of the production of the application, this phase is where you put the things together and made in a real thing, like in software processes this phase can be described as the coding phase, where you can see if the things that you designed works.

Testing, you have the product finished, Continue reading "System Development Life Cycle"

Use Cases

--Originally published at Newbie Programmer

The use cases help us to describe what our products must have to do to achieve our customer goals, for this we need to separate the main goal into something like can be defined as user stories that are specific goals for the clients, for this we can use modeling languages like UML (Unified Modeling Language), where you use things like an a diagram when you have an actor, actions, and the relationship between them.

The actor is a person, organization, systems, everything that can be played as a role and can interact with our application, the associations are indicated by lines and the things they want to do its in the ovals.

For explaining this i think its more easily to see an actual use case diagram, because if you understand how the diagram work is easy to know what is the deal with an use case.

Screenshot_2018-10-01 Diagrama en blanco Lucidchart

I made this diagram for doing the use cases of a warehouse, you can see the actors, the Distributor and the Attendant (the actors), for explaining an use cause i can choose one of the actions (one of the ovals), for example when the Attendant needs to know how much products have in stock, we can make an use case.

  1. Attendant want to know how much products the warehouse have.
  2. Attendant search into the system or count the products available.
  3. If the warehouse don’t have the product required, the Attendant search for the days and hour of supply.
  4. The Attendant calls the Distributor, and the Distributor come to the warehouse.
  5.  The Distributor sells the number of products needed, and the Attendant buys them.
  6. The Attendant update the system with the new quantity of products, and closes the system.

In this case we achieved the goal for check the availability of a product, Continue reading "Use Cases"

CHAPTER 8 – Design Principles

--Originally published at Newbie Programmer

The design principles are basic tools or techniques that can we apply to design our code, and make it maintainable, flexible or extensive as we seen in the first chapters with the object-oriented principles like encapsulation, implementation, behavior, interfaces, and in this chapter, we can find these four new design principles to improve the code.

First principle, The open-closed principle, this principle explain that we can made our code closed for modification but open for extension, because we don’t want to make modifications from other people because its working well, but we can open it for extension and the people who need this can make subclasses or override the methods.

Second principle, The don’t repeat yourself principle, this is helpful to make the things without redundancy or to write the same thing two times, and this help to maintain the code and reusable, for example if we have the method of a class that does the same thing that we want to do in another class can we make a reference to this method instead of making that again, and this maintains each functionality in a place.

Third principle, The single responsibility principle,  each object of the design only have a responsibility, and for example to know if we have more than one responsibility we can check with the name of the class, and if the name make sense with the responsibility assigned, for example in a car, we have the class Automobile that is responsible for start the engine, stop and to check that we have oil, but the responsibility for driving is part of the driver, in this case we need to make two classes Automobile and Driver.

Fourth principle, The liskov substitution principle, is to design a well inheritance, this means that we Continue reading "CHAPTER 8 – Design Principles"

CHAPTER 7 – ARCHITECTURE

--Originally published at Newbie Programmer

In the chapter 6 we analyze the big problems, and we learned that we can make the big problem into small pieces, but we need to know how these pieces fit together, and more important how to begin with this, and that’s why we need architecture
The architecture is a design structure that show us the most important parts of the project, and the relationship between the parts, that we already know because we used use case diagram, but it’s not clear how they interact.

To begin with the architecture, we need to retake the three concepts of making a good software from the first chapter. First, make sure your application does what the customer wants to do, second, apply the principles of object oriented, and third, make and maintainable reusable software.

First, we have feature list of what the system is suppose to do, but we need to choose what are the most important or architecturally significant, because those are the pieces we need to do first, and to know what are the pieces we need to do first we need to ask the there questions of architecture, first, if it is part of the essence of the system, the essence is those parts that we can’t imagine the product without them, second , if we don’t know what this feature means we need to pay attention to make sure its clear what is it about, and third, how do I do it, this are features that are hard or new programming tasks, we need to make sure we can deal with the problem and spend time with this features to not create problems in the future.

We know if we choose the right the important features if they create risk, because if we can’t finish one of these

43330060684_fcd3d03022_k
Continue reading "CHAPTER 7 – ARCHITECTURE"

The Cathedral and the Bazaar

--Originally published at Newbie Programmer

This essay contrast two types of software development models that are show in the title, one named The Cathedral model, and the second The Bazaar model, is an interesting essay because its explain two different ways to do the things, and the kind of things that the author made in relation with the bazaar model, and this help us to understand how the open software works, and he give us various attributes of open source software, such as use others solutions, the interest of you, to have testers, users as developers, to make stable and early versions of software, to hear the customers, use ideas and solutions from the people, and this opens you a different perspective about the open software, because if you don’t know much about this you think is worse than things like Mac OS or Windows, or like its insecure, they have a lot of problems.

So, The Cathedral it’s a model where the source code is only available for exclusive groups of developers that oversee making new functions, solving problems, testing, but the releases are not frequently, and this will make the people angry because there its not a lot of improvements in a huge time. In the other hand, The Bazaar model, the source code is public for every person, that can be modified and published by everyone, its particularity is that the updates, the new features, the solve of bugs, new implementations are made by a lot of persons around the world and in less time.

6153470638_a251d2854b_o.png

Photo by Matt Lucht