Questions about analysis and structured and Object-Oriented design

Software process, involves several activities, among them, Analysis and design. Among the options of methods to carry out these activities, we have the structured and object-oriented. Regarding both, I have some doubts:

  • What's the main difference?
  • What are the advantages and disadvantages of using each?
  • Why is the object-oriented method used in most cases?
Author: renanvm, 2019-03-15

1 answers

What's the main difference?

  • in structured analysis (we will call it AE), the focus is mainly on the process and procedures. The main techniques used are DFD( data flow diagram), flow charts, decision table/tree and Entity-Relationship analysis. It is an old practice and not currently recommended.
  • in Object-Oriented Analysis (we'll call it AOO), the focus is on capturing real-world objects contextualizing them in a problem-relevant scenario (broadly, reproduce some real-world characteristics in a software environment). The detailing is larger for Data Structures and smaller (less imperative/specific) for procedure and method structure. Modeling techniques use UML (which can present both structural and behavioral/procedural aspects of the system).

Particularly I relate, so coarse, that structured analysis is for structured and procedural programming just as Object-Oriented Analysis is for Object-Oriented Programming; where AOO represents the interactions between objects of a system at the concept level, and AE the interactions between parts of the system at a function/method level.

What are the advantages and disadvantages of using each?

  • AOO uses UML, which is more reusable and easy to maintain, when compared to AE digrams;
  • AE has a focus on the functionality of the program, resulting in an imperative language, clearer to the programmer. AOO, being more declarative, may not be as clear / specific in some specifications;
  • AE uses process-oriented modeling, which makes it easier to understand the movement of data - whether by the developer or customer;
  • AOO is more efficient in large projects and with high risk of change in system requirements, whereas EA is efficient for well-defined projects with stable requirements;
  • AOO was developed in order to minimize the problems faced in the creation of complex software, allowing the use of object orientation-inheritance, polymorphism, composition, encapsulation, among others -, which is not available in AE;
  • AOO is more widely used today, which implies greater availability of documentation and general information;
  • AOO requires more effort in modeling the system when compared to AE, but also less coding effort-here we have a feature that moves the complexity of development to analysis, which is quite debatable in the context of being an advantage or disadvantage;
  • AOO have a greater tendency to face modeling problems due to their greater complexity. A practical example, caused by the lack of knowledge of abstraction, would be the creating a modeling that leads to the creation of separate similar implementations, contained in different non-reusable classes;
  • AOO can introduce greater verbosity than AE in small projects: in some cases the use of the OO paradigm can generate more lines of code than the structured implementation. This disadvantage disappears as use cases that benefit from oop are added;
  • AOO offers, through OO, an extension facility higher than AE, because the creation of new models that communicate with existing ones does not oblige the developer to know the inner workings of the latter.

Why is the object-oriented method used in most cases?

I believe the main reason is due to its similarity to the real world (objects have characteristics and can perform/undergo procedures), which makes it easier to represent it in a natural way. In addition object orientation allows for very large code reuse, especially in large projects.

The moment you define, for example, a Class Usuário for your system, it can be imported/required into any other module that has access to the class. Complex use cases that require inheritance or composition can be implemented simply with OO. This implies simplified development and maintenance processes , since there is just one file to change-besides following an important development rule, the DRY - don't Repeat yourself.

Another relevant aspect is greater security, where OO offers visibility control (public and private methods, for example), which implies allowing or preventing the use of system features in a development context. Applying this practice also simplifies the software API, which is especially useful in the creation of libraries and exports of the code, since the programmer who develops the client software only has knowledge and access to public methods.


Sources:

 14
Author: Mathias Berwig, 2019-07-15 12:49:40