This is the first post on my new blog. I’m just getting started, so I’d like to introduce me.
My name is Oscar; i’m studying a BS in Computer science. I’m in love with music and the life! and I think that if you put enough effort on something, you always will get what you want. Also, I love photography, thats one of the things that I think makes this life better, because it gives me the opportunity to share with others how I can see the world, and sometimes, you can share emotions too. I have a meme page with over 70k followers, and yes, I do memes, but also i take it from other pages, the watermark is always there, so our followers can know where is the meme coming from. I have a little dog, his name is Pirata; he’s always making my days better and its more effective than a home alarm! For me, mathematics are present in everything, and if something has todo with numbers or patterns, i’m gonna be as focused as possible.
But let’s get back to the topic
I think that this kind of courses (the ones that use modern educative methods) are the greatest because education has evolved based on its reasons. This “connected courses” thing will let us learn in a different way by reading what our classmates have concluded, and by interchanging opinions and perspectives, making our criteria and concepts better. I’m Trying to connect my own website with this blog, but I think that will have to wait until the next week, because i have a lot of projects going on. I’m hoping to give the best of me in this course and to get the most knowledge that I can.
Object-Oriented Programming and the principles it promotes make a big difference in creating large scale, maintainable code. It allows developers to design and write code in more productive ways than were possible with procedural languages. The same happens with the agile methodologies; agile is a set of methodologies which share development values. Trying to be more specific, i’m going to focus on Scrum.
Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value, looking for effective team collaboration on complex products. A scrum team is divided into three roles:
Scrum Master: is a servant-leader for the Scrum Team. Is responsible for promoting and supporting Scrum. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
Product Owner: is responsible for maximizing the value of the product resulting from the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
Development Team: consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. A “Done” increment is required at the Sprint Review. Only members of the Development Team create the Increment.
Nice, nice, there are roles and good things but, How does exactly scrum works?
Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process. The Scrum Events are:
Sprint: is a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.
Sprint Planning: is the work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team. Usually is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
Daily Scrum: is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work.
Sprint Review: is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. There could have been a single deployment or many deployments during a Sprint which lead up to that Increment to be inspected. This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter.
Sprint Retrospective: is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. It occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter.
What is the backlog?
Is a breakdown of work to be done. Contains an ordered list of product requirements that a scrum team maintains for a product. Common formats include user stories and use cases. The requirements define features, bug fixes, non-functional requirements, etc.—whatever must be done to deliver a viable product.
As you could read, Scrum is always focused on the Done, which we are going to call MVP. This is because scrum looks to deliver a functioning viable product after each sprint. This helps with the client satisfaction and to the productivity of the team.
Finally, I hope that reading each scrum activity and with the help of the first image, you have a better idea of what Scrum is and of course, Agile came to revolutionize how the software is made.
Do you know what you get when you combine an iterative process, an incremental one and then add a pinch of testing? you come up with Test Driven Development. TDD is a software development process that relies on the repetition of a very short development cycle: first the developer writes an automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck stated that TDD encourages simple designs and inspires confidence. The concept is simple: write a test, write code, test it, do it again.
Here are the steps:
Write a test that defines a function or improvements of a function. this helps the developer to focus on the requirements before writing the code.
Run all tests and see if the new test fails. The new test should fail for the expected reason. This step increases the developer’s confidence in the new test.
Write the code that causes the test to pass. it doesn’t matter if it is the ugliest thing you have done, that is acceptable because it will be improved and honed in Step 5.
Run tests: If all test cases now pass, the programmer can be confident that the new code meets the test requirements, and does not break or degrade any existing features.
Refactor code: Now put the dressing on your code, make it look fancy and be sure its readability is good.
In a few words, TDD implies: write only enough of a unit test to fail and then write only enough production code to make the failing unit test pass. Basically, you are trying to do the most with the less effort possible, using an iterative method and going step by step. Besides this, using TDD meant writing more tests and, in turn, programmers who wrote more tests tended to be more productive; furthermore as they were tackling little problems at once, they found no need to invoke the debugger.
But, be careful…
Test-driven development does not perform sufficient testing in situations where full functional tests are required to determine success or failure, due to extensive use of unit tests. since the test are typically created by the developer who is writing the code to test, the test my have a blind spot and in consequence, the program will have it too.
As you would expect from this starting lines, I’m about to write about testing. Once you finish coding, you should test what you did in order to detect any error/failure so you can handle it. Also, you have to check if the software really does what it is meant to; how it fits it, defines the software quality.
This is an OO blog, so, let’s talk about Object-Oriented Systems Testing. This is a continuos activity during development. For the OO branch, testing includes three levels:
This is somehow an individual test. Typically, is an automated test with associated control data that simulates how the source code to check should behave. checks if the methods and interfaces are error-free and if the attributes are implemented. This kind of testing is the responsibility of the developer who implements the source code of the structure.
This is more complex than unit testing. It involves testing the associations and dependencies within a subsystem and how it interacts with the outside. this one is responsibility of the subsystem leader. This kind of test can be used as a regression for each newly released version of the subsystem.
This one involves testing everything as a whole. Often, this can be used as regression tests when a new release is assembled. This tests are responsibility of the quality-assurance team.
Grey Box Testing
The different types of test cases that can be designed for testing object-oriented programs are called grey box test cases. It is called gray box because the tester has a partial understanding of the internal structure in the system under test; also there is a black box and a white box technique, but this one is the most used. There are a lot of gray box tests, some of the most important are:
State model based testing − This encompasses state coverage, state transition coverage, and state transition path coverage.
Use case based testing − Each scenario in each use case is tested.
Class diagram based testing − Each class, derived class, associations, and aggregations are tested.
Sequence diagram based testing − The methods in the messages in the sequence diagrams are tested.
Techniques for Subsystem Testing
Thread based testing − All classes that are needed to realize a single use case in a subsystem are integrated and tested.
Use based testing − The interfaces and services of the modules at each level of hierarchy are tested. Testing starts from the individual classes to the small modules comprising of classes, gradually to larger modules, and finally all the major subsystems.
Categories/Stages of system testing
Alpha testing − This is carried out by the testing team within the organization that develops software.
Beta testing − This is carried out by select group of co-operating customers.
Acceptance testing − This is carried out by the customer before accepting the deliverables.
Let’s supuse you are about to deploy a new software system. Before you put in into production, you need to be sure that it is working, so, you should validate it. But, what exactly is validation? when i was learning programming, one of the very first concepts i have to catch up was validation. Back to those days, validation was only to assure the user input will not affect your program. However, things change.
Validation is the process of checking whether the software product is up to the mark or in other words product has high level requirements. It is the process of checking the validation of product. Validation is the dynamic testing.
Also, you need to verify your system. But, what is different from validation. Well, just as efficiency and effectiveness, they are similar, but not the same. Verification is the process of checking that a software achieves its goal without any bugs. It is the process to ensure whether the product that is developed is right or not. It verifies whether the developed product fulfills the requirements that we have. Verification is static testing.
So, in a few words, Verification is asking your team: Are we building the product right? and validation means: Are we building the right product?
In order to get a better understanding of this concepts, you can read its differences below:
It does not involve executing the code
It always involves executing the code
The verifying process includes checking documents, design, code, and program.
It is a dynamic mechanism of testing and validating the actual product
Methods used in verification are reviews, walkthroughs, inspections and desk-checking.
Methods used in validation are Black Box Testing, White Box Testing and non-functional testing.
It checks whether the software conforms to specifications or not.
It checks whether the software meets the requirements and expectations of a customer or not.
It finds bugs early in the development cycle
It can only find the bugs that could not be found by the verification process.
The goal of verification is application and software architecture and specification.
Target is an actual product
This is the first step
is the last step
Since the verification and validation are part of the quality control process, this activities are regulated by international standards, such as ISO 9000. Remember, Validation consist in the assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers, while verification is the evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition.
In a perfect world, verification should go before validation and the validation after the verification. Somehow validation is more related to the software engineering, where you check the system is been building right, and the validation, also related to the software engineering, because you have to check wether or not has all the requirements, it is also a developer’s and testers thing. If you wanna learn more about Testing, I recommend you to look for Kent Beck, He is an awesome engineer and he has made a lot of contributions to this beautiful software engineering world.
A code review is a process in which the dev team checks up an implementation to come up with ideas on how to enhance it, or maybe refactor it, discovering possible bugs, architecture errors, missing test cases and several things that may happen. Now, you should be wondering: why in the hell someone else has to check my code, I’m such a programming guru… Well, yes, but actually, no.
When you are working in an organization, you should know that you are not the only one working on a project. On this context, socialism actually works (excepting your paycheck) because you are writing code that will be on constant development, enhancement and will require maintenance, all of this given by a bunch of developers in the future. Actually there are a lot of benefits on doing this exercise.
Knowledge is shared
People can discover tools, API’s and different ways to solve a problem that they were not aware of.
Obtain global knowledge about the system (Not only the components you are working on).
When new members join the team, more experienced engineers mentor the newer members. Often, teams have hidden knowledge within the code that surfaces during code review. Newer members, with fresh eyes, discover areas of the code base that need a new perspective. So, code review also helps ensure new insight is tempered with existing knowledge.
Keep in mind, code review is not just a senior team member reviewing a junior team member’s code. Code review should happen across the team in every direction. Knowledge knows no bounds! Yes, code review can help newer engineers, but by no means should it be used solely as a mentoring exercise.
Code review pretends to
Contribute with different points of view and to fix something that the developer may have forgot.
Enhance the software quality and the code readability.
Get the desired “code collectivity “
Let’s say that the code you wrote is already into production. Unfortunately, there is a bug in some code you wrote. This Math formula is code review in a nutshell:
How to review code?
As a code reviewer, you should ask:
Are there any obvious logic errors in the code?
Looking at the requirements, are all cases fully implemented?
Are the new automated tests sufficient for the new code? Do existing automated tests need to be rewritten to account for changes in the code?
Does the new code conform to existing style guidelines?
As a developer, you should ask yourself:
Is my code easy to understand?
Do I will be able to understand this code in a couple of years?
Did I consider every factor that may affect to the system?
But code reviews take time!
Sure, it takes time. But that time isn’t wasted–far from it; when the code review its done right, it actually saves time in the long run.
As a photographer, I can tell you that working with models is way easier than shooting with normal people. Once, I had a shooting with two girls for some social media advertisement. The shoot was amazing, we were on an awesome location and the production team was just good vibes. However, one of those girls was indeed a model, and the other one not. Shooting the model was easy, we got a lot of pics in a very short amount of time; shooting with the other girl who was unfamiliar to this, was a little bit more difficult. We got the job done, but it was easier and quicker working with the model. Well, the same goes to the software: “Working with models is going to make your life easier and your productivity will increase”.
The software engineers were aware of this, but there was a little problem: with the born of the object oriented paradigm, a rush of new modeling languages came in, just like there were several network protocols. The world of computers needed a standardization so the developers could integrate with different teams and get a common language to communicate their ideas.
James Rumbaugh, Grady Booch and Ivar Jacobson decided to merge various existing modeling languages into one common standard; this way, UML was born. The Unified Modeling Language is a graphic language that is intended to represent this:
Individual objects (basic elements)
Classes (Combining elements with the same properties)
Object Relationships (Hierarchy and behaviors, communication between objects)
Activity (Complex combination of actions / behavior modules)
Interactions between objects and interfaces (even human interaction)
UML is a multimodeling Language, meaning that you can make different models from the same thing, it depends on which level of abstraction you want to represent something.
UML has 13 different types of diagrams. We are going to categorize them by their functions.
Structural diagrams: This type of diagram, makes emphasis on the elements that may exist into the modeled system.
Composite Structure diagram
Behavioural diagrams: Describes what has to happen into the modeled system.
Use Cases diagram
Interaction diagram: This are a subtype derived from the behavioural diagrams, centered into the control and data flow into the system.
I bet you are into this right now so, let me explain some diagrams.
This one is used to model the dynamic behavior of a class in response to time and changing external stimuli. We can say that each and every class has a state but we don’t model every class using State diagrams.
Initial state – Use a black filled circle represent the initial state of a System or a class
State – Use a rounded rectangle to represent a state. A state represents the conditions or circumstances of an object of a class at an instant of time.
Transition – Use a solid arrow to represent the transition or change of control from one state to another. The arrow is labelled with the event which causes the change in state.
Fork – Use a rounded solid rectangular bar to represent a Fork notation with incoming arrow from the parent state and outgoing arrows towards the newly created states. The fork notation is used to represent a state splitting into two or more concurrent states.
Join – Use a rounded solid rectangular bar to represent a Join notation with incoming arrows from the joining states and outgoing arrow towards the common goal state. use thise join notation when two or more states concurrently converge into one on the occurrence of an event or events.
Composite state – Use a rounded rectangle to represent a composite state. A composite state is a state which has an internal structure consisting of a set of states, transitions and other components.
Final state – Use a filled circle within a circle notation to represent the final state in a state machine diagram.
Self transition – Use a solid arrow pointing back to the state itself to represent a self transition. There might be scenarios when the state of the object does not change upon the occurrence of an event. Use self transitions to represent such cases.
Steps to draw a state diagram
Identify the initial state and the final terminating states.
Identify the possible states in which the object can exist (boundary values corresponding to different attributes guide us in identifying different states).
Label the events which trigger these transitions.
Package diagrams are used to simplify complex class diagrams, you can group classes into packages. A package is a collection of logically related UML elements.
Package diagram follows hierarchal structure of nested packages. Atomic module for nested package are usually class diagrams. There are few constraints while using package diagrams, they are as follows.
Package name should not be the same for a system, however classes inside different packages could have the same name.
Packages can include whole diagrams, name of components alone or no components at all.
Check the syntax
We need a way to represent code dependencies, this is what we have to do.
There are two sub-types involved in dependency. They are <<import>> & <<access>>. Though there are two stereotypes users can use their own stereotype to represent the type of dependency between two packages.
<<import>> – one package imports the functionality of other package
<<access>> – one package requires help from functions of other package.
Now that you know how this works, check this example:
This is a little overview on how UML is used to model the systems. This is a powerful tool for project development and of course, if you want to be a good software engineer, you must have to have understanding on this diagrams. If you want to learn more, there are always books and wonderful websites with tons of knowledge waiting to be read.
Have you ever wondered why is always the menu located in an upper corner from the most of apps ? well, if you did, you are at the right spot; but, if you didn’t, i recommend you to stay, because we are about to dig into some gold.
Humans, despite having the capability to adapt, can feel uncomfortable when ran into an unfamiliar situation or environment. The designers realized about this, and they started to create patterns to make our lives easier and a much pleasant experience. This concept, known as Design Patterns, is almost everywhere, from buildings to a web page, and it is one of the most useful guides in the development of any project.
Design patterns were not only intended for UX, in fact, the concept born in the building world, based on this idea:
“Each pattern describes a problem which occurs a lot of times in our environment, including the solution to it; so, this solution can be used forward without having to think it again.”
Kent Beck and Ward Cunningham realized how this concepts could be applied in the new OO paradigm, so they published an article entitled Using Pattern Languages for OO Programs. A couple years later, the gang of four wrote the book Design Patterns, which you can read if you want to learn more.
So, basically, design patterns are a set of reusable elements in the design of software systems that try to avoid the search of solutions to problems which are already solved. Somehow, dp create standards for the vocabulary of the designers and also, standardize the way in which things are created (a better UX). However, design patterns does not impose some alternatives to another, its just a guide; and, of course, this is not an attempt to eliminate creativity in the design process.
Have you ever heard about the concept “Modeling language”? If you have not, congratulations! You are at the right place. As I said on my previous post, we need to represent our projects in a way that can be understood by every involved person. Thus, we are going to use modeling languages; a modeling language provisions the design and construction of structures and models following a systematic set of rules and frameworks.
Modeling languages are mainly used in the field of computer science and engineering, intended for designing models of new software, systems, devices and equipment. This languages are primarily textual and graphical, but based on the requirements and specific domain in use, modeling languages fall into four categories:
System modeling language
Object modeling language
Virtual reality modeling language
Data modeling language
Let’s focus on system modeling languages. This languages will let us specify and design what we want to achieve on a software product. I am going to use a couple of them, but it will be just a sneak peak, in the future i’ll be blogging in deep about those.
It was developed by Grady Booch, Ivar Jacobson and James Rumbaugh at Rational Software. It is a pretty complete language because it has ways to represent the most important parts of a project, such as structure, behavior and interaction diagrams.
This family covers a wide range of uses, from functional modeling to data, simulation, object-oriented analysis/design and knowledge acquisition. This family were developed under funding from U.S. Air Force and although still most commonly used by them, as well as other military and United States Department of Defense (DoD) agencies; however, this are public domain.
The main goal of this modeling languages is to make the developers life easier and to create a software blueprint that will enhance productivity and clearness in the project.
The most difficult part of any software project is to get what the client wants. Every mind is a whole different world, and this could cause miscommunication problems or giving something by understood without having in mind the discrepancies between the developer and client ideas. Thus, the engineers had to manage to find some way in which the client requirements could be completely understood by the developer; mostly, to represent the software-human interaction, we use the “Use case” technique.
So, What are the use cases?
The use case is a paradigm which describes how a user uses a system to accomplish a particular goal. The goal is to create a model of the system based on the user interactions, in order to define the features to be implemented. You can find the use cases as plain text or a diagram, but the most common one is the diagram so let’s go deep into it.
Use case diagram
The use case diagram is composed by 3 or 4 elements: Actor, use case, system and package (this one is optional).
Any entity that performs a role in one given system. This could be a person, organization or an external system and is usually drawn like this.
Represents a function or an action within the system. It’s drawn as an oval and named with the function.
The system is used to define the scope of the use case and drawn as a rectangle.
The package is another optional element that is extremely useful in complex diagrams. Similar to class diagrams, packages are used to group together use cases.
Now that you know how to interprete the diagram, check out this example, is so simple that it needs no explanation.
At the beginning, when God brought software to the world, the IT crowd started to create big and complicated systems. But there was a problem; due to the lack of uniformity, the project in development could be compared to a tangled spaghetti because of every aspect but the code.
Thus, Some crazy computer people started to design a framework that allowed us as developers, to get productivity, an enhanced project structure and better results for the clients in the process. This people came out with the Unified Process. So, What is the unified process? Let’s talk about it.
First things first, the unified process is not a a software development process, it’s an extensible framework. This means that it should be customized for every project or organization, always having in mind the main characteristics of the UP, which i’m about to explain.
The Unified Process is a framework for an iterative and incremental software development process.
Iterative and incremental
The Unified Process is like an endless loop, until the project is finished; let’s go deep about it. The Elaboration, Construction and Transition phases are divided into a series of timed iterations. Each iteration results in an increment, which is a new release of the system that contains added or improved functionality.
Architecture sits at the heart of the project team’s efforts to shape the system.
The Unified Process requires the project team to focus on addressing the most critical risks early in the project life cycle.
Transition (final production release)
Inception is the smallest phase in the project, and ideally it should be quite short. You should develop an approximate vision of the system, make the business case, define the scope, and produce rough estimate for cost and schedule.
At this time, the project team is expected to capture the system requirements. However, the main goals of Elaboration are addressing known risk factors and to establish and validate the system architecture.
Construction is the largest phase of the project. In this phase, the remainder of the system is built on the foundation laid in Elaboration. System features are implemented in a series of short, time-boxed iterations. Each iteration results in an executable release of the software.
The final project phase is Transition. In this phase the system is deployed to the target users. Feedback received from an initial release may result in further refinements to be incorporated over the course of several Transition phase iterations. The transition phase also includes system conversions and user training.