Here i leartnt principally of how to use OO in an Agile methodology, cause a good OO is necesarry if we want a true agility.

There are two main camps when it comes to defining OO: structural (if it uses polymorphism and inheritance, it’s object oriented) and architectural (OO systems are models of real or imaginary things and of the way that these things interact as they perform some useful activity). I fall firmly in the second camp; structure is an important implementation detail, but doesn’t affect the object-oriented nature of the system one iota. I’ve even programmed what I think of as object-oriented systems in assembly language, with nary a class definition or virtual method in sight.

The objections to OO come largely from people so entrenched in the first camp that they don’t know that the second camp exists. For example, they say that Java is too complicated and wordy — which is certainly true — therefore OO is bad — which is not. They say that Java is too hard to deploy — also true — therefore OO is bad. They say that design patterns can add too much complexity to what should be a simple system — again, true, but that’s a good-versus-bad design argument, not a critique of OO. They say that it’s sometimes best to program with functional-programming techniques instead of inheritance — also true, but functional programming in no way renders the system less object oriented.

In an Agile world, following HSP gives you the freedom of changing implementation without the effects of that change rippling out to the rest of the program, and this property is, again, essential when constant change is in the picture.

Bibliography

https://www.coursehero.com/file/p1791rv/What-are-the-main-differences-between-structured-analysis-O-O-and-agile/

http://www.drdobbs.com/architecture-and-design/oo-as-a-prerequisite-to-agile/240164883

Test driven development has become popular over the last few years.

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. This is opposed to software development that allows software to be added that is not proven to meet requirements.

Programmers also apply the concept to improving and debugging legacy code developed with older techniques. Some programmers think that, in theory, it is a good practice, but that there is never enough time to really use TDD. And others think that it is basically a waste of time.

If you feel this way, I think you might not understand what TDD really is. There is a very good book on TDD, Test Driven Development: By Example, by Kent Beck. In this blog I will go through the fundamentals of Test Driven Development, addressing common misconceptions about the TDD technique.

Why use TDD?
There are studies, papers, and discussions about how effective TDD is. Even though it is definitely useful to have some numbers, I don’t think they answer the question of why we should use TDD in the first place.

Say that you are a web developer. You have just finished a small feature. Do you consider it enough to test this feature just by interacting manually with the browser? I don’t think it’s enough to rely just on tests done by developers manually. Unfortunately this means that part of the code is not good enough.

But the consideration above is about testing, not TDD itself. So why TDD? The short answer is “because it is the simplest way to achieve both good quality code and good test coverage”.

The longer answer comes from what TDD really is… Let’s start with the rules.

Rules of the game
Uncle Bob describes TDD with three rules:

• You are not allowed to write any production code unless it is to make a failing unit test pass.
• You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
• You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
  I also like a shorter version, which I found here:
• Write only enough of a unit test to fail.
• Write only enough production code to make the failing unit test pass.
  These rules are simple, but people approaching TDD often violate one or more of them. I challenge you: can you write a small project following strictly these rules? By small project I mean something real, not just an example that requires like 50 lines of code.

Bibliography

https://sg.com.mx/revista/46/test-driven-development

https://medium.freecodecamp.org/test-driven-development-what-it-is-and-what-it-is-not-41fa6bca02a2

https://en.wikipedia.org/wiki/Test-driven_development

In chapters 1-9 we have been learning variious parts of what makes a complete OO system, this chapter was about putting it all together so instead of having many little OO ingredients we have a full OO cake. Here we learned that everything that we have seen are not indivual things, but part of a whole process we use to have great software. A little list of things we have seen is the following:

1. Feature list, what the software is supposed to do.
2. Use Case Diagrams, how will the software be used
3. Break up the Problem, make smaller problems with easier solutions
4. Requirements Domain Analysis, what is it reach and what it needs to get there
5. Preliminary Desing, How will it be implemented
6. Implementation, the coding

Doing all of this in an Iterative way, to have a great delivery when done, whitout forgetting to apply the basic principles to add flexibility and to strive for a maintainable reusable desing

I only gave a quick explanation of the list because we have seen all of them before, but now we are seeing it as a proyect in which you do first iteration, and then second and so on, whitout forgetting to rest beetween iterations. Every time you Iterarate you have to make sure that all of your steps are followed correctly.

After the chapter i also read the 10 topics which we didn´t cover

1. IS-A and HAS-A refer to inheritance and composition/aggregation respectively
2. Use case Formats this mainly refers to the interaction
3. Anti Patterns is about recognizing and avoiding bad solutions
4. CRC cards that stand for Class Responsibility Collaborator which hel implement the Single Respomsibility Principle
5. Metrics, numbers to show your mistakes or just other info
6. Sequence diagrams , another kind of UML diagrams which document actions with its respective actors
7. State diagrams are used in state machines to represent where are you in the process and according to this you know what to do
8. Unit Testing is a way of automated testing
9. Coding Standars and readable code, this are all good practices
10. Refactoring, modify the softwares structure without modifying how it works

Testing is a thing you have to do in all ypur proyects, but especifically OO testing can be a little different and in many cases easier, this because when large scale systems are designed, object oriented testing is usedrather than using the conventional testing strategies as the concepts of object oriented programming is way different from that of conventional ones.

With the help of “class” concept, larger systems can be divided into small well defined units which may then be implemented separately.

The object oriented testing can be classified as like conventional systems. These are called as the levels for testing. that can be broadly classified in three categories:

1. Class Testing

Class testing is also known as unit testing.

In class testing, every individual classes are tested for errors or bugs.

Class testing ensures that the attributes of class are implemented as per the design and specifications. Also, it checks whether the interfaces and methods are error free of not,

2.Inter-Class Testing

It is also called as integration or subsystem testing.

Inter class testing involves the testing of modules or sub-systems and their coordination with other modules.

3.System Testing

In system testing, the system is tested as whole and primarily functional testing techniques are used to test the system. Non-functional requirements like performance, reliability, usability and test-ability are also tested.

There are two different strategies for integration testing of OO systems . The first, thread-based testing, integrates the set of classes required to respond to one input or event for the system. Each thread is integrated and tested individually. Regression testing is applied to ensure that no side effects occur. The second integration approach, use-based testing, begins the construction of the system by testing those classes (called independent classes) that use very few (if any) of server classes. After the independent classes are tested, the next layer of classes, called dependent classes, that use the independent classes are tested. This sequence of testing layers of dependent lasses continues until the entire system is constructed. Unlike conventional integration, the use of drivers and stubs as replacement operations is to be avoided, when possible.

Biliography

http://ecomputernotes.com/software-engineering/object-oriented-testing

http://www.ques10.com/p/8428/briefly-explain-unit-and-integration-testing-in-th/

https://www.minigranth.com/software-testing/object-oriented-testing/

In the process of making software we have seen many things about what it requires, how to do it, when to do it, among other things, but ww do, wwe must not forget that we are doing the product for our customer. The software is theirs and we need to act like it. You always need to keep them happy by having the software do what they want it to do.

One good way to do this is by working iteratively, and asking the client how does he like it in the middle, not at the end of the project, there are many ways to develop the software, we are gonna focus on a particular division which are the granurlar and the big-picture software, the first works well when you have a lot of differente features that don´t interconect a whole lot, it allows you to show the customer working code faster, it is very functionality-driven. you are not going to forget about any features using feature drive development, also it works particularly well on systems with lots of disconnected pieces funcionality.

The second one, big-picture software, works well when your app has lots of processes and scenarios rather than individuak pieces of functionality, it allows you to show the customer bigger pieces of functionality at each stage of development, it is very user-centric, meaning that you will code for all the different ways a user can use your system . Also it works particularly well on transactional systems, where the system is largely defined by lengthy, complicated processes.

To know if this is what the customer wants you need too learn what they do so you can «Be the customer», you need to act like him and make the uses cases and everything as if you were him

Imitation is the sincerest form of not being stupid, this is the phrase that the chapter starts with. This means sometimes its better just to use something thats already done, instead of trying to do it for yourself cause you will only lose time, its better to invest that time to upgrade or correct something that was done from before

One of the advemtages of OO Programming is thta it allows specifically to do this by making code more maintainable, flexible and extensible, and all of this so anyone else can make use of it too, not just the person who coded it.

For this we are going to review some OO principles which are the following:

First, the OCP principle, which means the open-closed principle, which means it will be open for extension, but closed for internal modification, an explame here are libraries, which you can use , but there is no way to modify some one elses library

Second, we have de DRY, which tells you not to repeat yourself, meaning, if you see some repeated code, it most likely means that you should create a method that does that.

Third, we saw the single responsibility principle meanind that an object methods should only modify itself, if you need to modify something else, make a method in that class that does that.

Fourth principle would be the Liskov Substitution Principle it states that you should be able to substitute your subclass for that base class and keep stuff working, if not, it means you inherited incorrectly.

Any software requires to be verified and validated before releasing it, for starters i wanna make a list of the most significant differences between this two.

Verification: -It finds bugs early in the development cycle – Whether the software conforms to specification is checked -Verification uses methods like reviews, walkthroughs, inspections, and desk- checking etc. -It does not involve executing the code -The verifying process includes checking documents, design, code, and program -Target is application and software architecture, specification, complete design, high level, and database design etc. -QA team does verification and make sure that the software is as per the requirement in the SRS document. -It comes before validation

Validation:
-It can find bugs that the verification process can not catch -It checks whether the software meets the requirements and expectations of a customer -It uses methods like Black Box Testing, White Box Testing, and non-functional testing -It always involves executing the code -It is a dynamic mechanism of testing and validating the actual product -Target is an actual product -With the involvement of testing team validation is executed on software code. -It comes after verification

Also they have different definition and objectives answering two different questions, while Verification answers if the producto is being built rigth, Validation checks if it acctualy is the rigth product

References

http://softwaretestingfundamentals.com/verification-vs-validation/

https://www.guru99.com/verification-v-s-validation-in-a-software-testing.html

https://en.wikipedia.org/wiki/Software_verification_and_validation

Blogging has been very hard for me, and i still think i am not doing it rigth, i usually dont tend to write about my life, i have really tried to keep journarls af what i do day to day but i just get distracted or forget what i did too easily.

For this course i have been writing lots of entries in my blog, mainly for mastery topics and chapter summaries but i still think i am missing what i am trying to do now, which is to have direct contact with the reader, not just putting text but expressing my ideas which i am not very goood at.

I know this post is too short but i only wanted to express what i feel about blogging and i hope i will get better with time.

Turning classes to code is one of the most basic stuff we need to learn when we want to code, classes can be a genric «pseudocode» not linked to any coding language. Turning classes to code is a processes that is in other words, to change documentation to code.

In this Mastery i will talk about how to change classes to code in java as of personal experience. Java can be used as an Object Oriented language , in which each class will be used as an object, each class will have methods, things it can do, and attributes, properties of the object.