How to identify classes in an object-oriented system?

Asked

Viewed 5,026 times

18

When we work with object orientation we need to know how to identify which classes are necessary for a certain application. Some classes are usually "obvious" in a sense: in a product management system it is intuitively clear that we will need classes Produto, Fornecedor, etc..

Even to "detect" these more "obvious" classes I even heard of a technique: write use cases and then look at the nouns in these use cases. After that then we filter this list of nouns that we get to see which really should be classes, that is, which really represent important concepts of the problem treated.

But there are classes that are not so obvious and that I believe do not appear in the use cases. For example, considering ASP.NET Webapi, when we create the default project in VS 2013 we have the class ApplicationOAuthProvider, the class ChallengeResult and in addition we have to create the controllers.

What I said is just an example, because I really don’t know a better way to express it. The main fact is that all these classes nay seem obvious to me, and it seems to me very unlikely that they appear in the use cases.

In this way, how can we identify the necessary classes in an object-oriented system? Besides the technique of analyzing use cases, how can we find these classes "less obvious"? I know this subject is much extensive, so if possible I ask for references to study more on this.

oop software-engineering
  • 3

    I won’t answer because an answer is too difficult. The problem is because the market thinks that the programmer should understand of all possible domains whose law does not require a professional own certificate in any way. Most programmers don’t know as much about business rules as companies would like, so the organization of a system, those obvious classes, doesn’t end up being so obvious. The programmer does a lot of things without thinking correctly. And in cases involving technology directly? No one is expert at all.

  • 1

    Most people don’t understand security, competition, a specific API. Even learning to use ready-made things for these things is part of the programmer’s obligation. But only an expert will understand the subject in the depth that is required. More so. He will not dominate alone, he needs an extensive team, need to have other people to consult. In short, a specialist programmer has a great chance to choose the correct way to create these classes, but can still make mistakes. Imagine what is not an expert on the subject he is creating the class.

3 answers

20


TL;DR

Do not mix the Analysis of the problem with the Design (project) of the solution, nor with the Technological Implementation.

Analyzing

An analyst is the professional responsible for identifying a problem to be solved or need to be met and eliciting the requirements for creating a solution.

The set of requirements defines what the system should do to meet the identified needs.

Based on the requirements, the analyst continues the Analysis process identifying at a high level what functionalities the system should have to meet the requirements.

A common solution to map each functionality is through Use Cases (not to be confused with the UML Use Case Diagram). A use case is in general a kind of step-by-step interaction between user and system, although this concept may vary. In addition, it usually describes the necessary preconditions for the correct execution of that use case and the post-conditions, which are the results of the action performed.

Note that we are still at a high level and nothing here has to do with the technological solution involved.

Continuing, if the analyst is trained in object orientation and UML, he can choose to model this knowledge of the domain and problem using the appropriate diagrams, which are usually: Use Case Diagram, Activity Diagram, Class Diagram and State Diagram.

The Case Diagram of Use is a simple visual representation of the system’s interactions with the external world. The actors that interact with the system are representations of users, other systems or any entity external to the system that communicates with it. This diagram does not exclude the need to map use cases as described above.

The Diagram of Activities represents the case steps of use in a kind of flowchart, including forks with alternative scenarios, error scenarios, etc. Not all scenarios need to be represented in the same diagram.

The Class diagram, at this stage of a project, should include only domain classes, not including specific classes of frameworks, libraries, nor any reference to the technology that will be used for implementation. We could call this diagram Diagram of Domain Classes. The function of the diagram is to represent the necessary entities and the relationship between them. In short, it is the modern object-oriented form of the Entity-Relationship Diagram (ERI), although both can be used. ERI is usually associated with structured modeling.

The State diagram is used for system entities that follow a stream of states. For example, a portion may be "open", "settled", "in arrears", "at a loss". This diagram represents the states and how transitions occur between them.

Through all this, the analyst can validate the solution, not considering the technological part, but checking if the classes and use cases meet the requirements. For example, if there is a requirement that "the manager can extract a report with the total of products sold in the month", then the analyst should look at whether the class Produto has a "navigable" relationship with Venda and ItemVenda. It can also add to the classes some most important methods and attributes to meet these requirements.

Design

Based on all this information, architects and developers take action to propose a technological solution to the problem. This does not necessarily come in sequence, but much can occur in parallel.

Technical designers will be able to create several other diagrams to represent what will be implemented, but will hardly reach the level of detail of placing classes in a framework.

The most relevant and commonly used diagrams are:

  • Diagram of Components: represents the high-level division of the main components of the system. The split does not represent the folder structure of the project files, but is a logical division of responsibilities.
  • Deployment diagram: a representation of the environment where the system will be executed.
  • Sequence Diagram: for a given action in the system, this diagram represents the interaction between several objects through the calls executed and the return, allowing to visualize the sequence of calls to methods in time.

Design can also be done agnostically, that is, without considering what technologies, frameworks and libraries will be used. However, I believe that it is more productive to model the division of components and classes already thinking about the implementation, so as not to generate another gap information.

Note that each of these diagrams can be made for several different cases. When we speak of Class Diagram or Component Diagram, we do not speak of a single diagram that represents the system as a whole. The representation can be made in different levels, for example, one showing the general system components and other diagrams showing the internal structure of each component individually. The representation can also be done in different contexts, for example, several diagrams can be made to represent only what is necessary for an important functionality, ignoring classes and packages not relevant in this context.

Implementation

The implementation must follow what has been defined in the design, but this does not mean that each method, class, package and component must be mapped one-to-one in the "physical" project, its files and directory structure.

The programmer should have the freedom to find the best solution to meet what was requested with the structure he wants. It would be bad from the point of view of good practice to impose every detail of what should be implemented. If that were possible, we wouldn’t need programmers, but a code generator.

Building the bridge

When studying carefully the "phases" (in quotes because they are not a linear sequence) of a software development project, it is possible to notice that there is a big leap (gap). An analogy commonly used in Software Engineering books is to build a bridge between what the customer needs and the technological solution.

Even today, Software Engineering is a somewhat immature discipline, we do not have a standardized form as the Civil or Electrical to work. The validity of an Analysis Model, a Design Model or the solution implemented depends almost exclusively on human factors, such as the communication capacity and understanding of analysts.

There is no formal rule for data modeling. UML was a major breakthrough, but the various diagrams in general vary in detail, comprehensiveness and many other design factors for design, from team to team and from individual to individual.

Final considerations

Even with the last statements above, I do not want to be pessimistic. Although there is no definitive answer to the modeling of systems, there are some principles that can guide us:

  • Put the communication first. The purpose of a diagram is to communicate information and not simply to mirror the code. If a diagram does not communicate something useful, do not waste time with it. Consider your team and your project and make diagrams that are relevant with the relevant details so that people know what they’re doing. Your team can gather at a table and discuss a diagram, scribbling it and using it as a basis for conversation?
  • Do not diagram specific technologies. If someone wants to know how Servlets, Rails or Django work, they better buy a book. You’ll just confuse people. I’ve seen many diagrams out there that are nothing more than the MVC model with different names.
  • Make sure the diagram meets the requirements. Your diagram should be useful not only to understand what needs to be done, but also to validate whether your solution meets what the customer needs. Do logical mind tests, looking at classes, methods and relationships, checking if they have a reason to be there, whether for a certain scenario you can extract the necessary data, etc.

As I mentioned a few times, Analysis, Design and Implementation will probably be done many times during the development cycle. Don’t expect to have everything right in the beginning. Investing too much time in detail is bad, according to several authors.

This method of identifying classes through nouns can be useful when you have no idea what you’re doing, but it’s bad because it’s an attempt to create a "dumb" way of extracting information without critical analysis.

In fact, the word "extract" is often misused. When we create a system, no extract the requirements and the necessary classes as if they already existed there, hidden in some way. As for the classes, we simply set in a spurious way which classes a system will have in order to meet the needs. It is a creative process and not an extraction process as with raw material. By "creative", don’t think of post-modern art, but something more methodical.

My recommendation is to identify through the requirements, what data is needed for the system to work and the relationship between them. The Dbas say so: data is the heart of the system. So we have the necessary entities.

Then, based on the functionalities the system should have, you can create classes that will be responsible for handling these functionalities.

Anyway, there is no absolute answer, but I hope to have well exemplified a path I learned over a few years studying and reflecting on how to develop software well, not only from a technical point of view.

  • Thank you so much for the reply @utluiz! You clarified many points that were confused in other readings that I did. There is one thing I still want to ask you: in some points of your answer you mentioned teams. In my case, I work alone. Could you recommend a reference on this subject to programmers who work alone? I think it doesn’t exist, but it doesn’t hurt to ask. Thank you again for your help!

  • @user1620696 I have no specific reference on the subject. I do several projects alone and what helps me is to read about personal organization and keep in mind that the documentation will be to communicate information with the "me of the future". I’ve tried detailed project documentation, but it didn’t work. What worked is simply to write down the important things for when you need to resume that point of work.

  • I wanted to ask you something else @utluiz. Today I found a book called "Use your head! Object-Oriented Analysis and Design". I took a look at the index and some pages and the book seemed good to those who are starting the subject. Do you know this book? Could you tell me if he’s good or not? Thank you very much!

  • 1

    @user1620696 Yes, I have read and recommend it. It’s a great introduction to the subject.

  • It’s a good answer but I disagree in degree and gender mainly with tl;dr. For many years I have observed that the nouns and verbs of a well-designed OOP code come from the jargon of business and that problem analysis and solution design are indeed closely linked. Such a bridge between the system and the business is no longer necessary if you follow these premises. Long after I started noticing this I became aware and deepened into DDD, and he strongly recommends and teaches us just how to do this: make the system speak the language of business.

  • As developers, we care too much about technology, but it’s customer concern that leads to expressive success. I have been repeating here at Sopt how important it is to direct each document, each diagram, each line of code... solely and exclusively to the customer and his needs, and the importance of the intimate connection of the code with the problem.

  • @Caffé Business jargon nouns are a bad example, because classes with certain names represent very erroneously real world concepts. People usually use the same term to refer to very different things or even different terms to refer to the same thing. This occurs with different professionals and companies in the same area or in different areas within a company or distinct companies. In a non-trivial project, different programmers will understand nouns differently and there is no data dictionary that can withstand an average or large project.

  • @Caffé What I wrote here is a summary of recognized techniques of software engineering. I know this goes very much against the approach ad hoc or Agile that is fashionable today, because they think that traditional development methodologies are plastered and unnecessary. However, every time someone tries to "climb" Agile or ad hoc ends up in the same problems that good software engineers have known for decades.

  • @Caffé The question of the "bridge" ceasing to exist is simply a utopia. I thought so too, but a graduate advisor, a doctor at USP in Software Engineering, who does research on this very subject, convinced me otherwise. A simple example is the emerging architecture concept of XP. This leads many to think that it is possible to program without fixing an architecture. In fact, the only difference is that in XP architecture is implicit and distributed in the minds of programmers. Anyway, the difference is that it becomes explicit in some document or remains understood.

  • @Caffé As for satisfying the client’s needs, while making the code closer to jargon can help us think (which reminds me of Dsls), this would still represent a very small part of the problem. If programming consisted only of representing the relevant elements of the domain, ok. Many systems designs like this and we see classes with similar names spread across all layers of the system. However, in any more complex system a large part of the effort will be spent on tasks that do not have to do directly with the domain.

  • @Caffé For example, any web system with a relevant number of users will have to worry about scalability. This brings to light the use of CDN, concurrent programming, optimized data structures, data decentralization, various types of cache, asynchronous persistence, user experience, monitoring, Profiling and... the list doesn’t end. All of this is somehow interconnected, even if the implementation is distributed between teams and different code bases and even micro services. The effort to satisfy the customer goes far beyond modeling classes.

  • I repeat that from the outset I am referring precisely and only to complex areas (as I said in my reply). I work in a global financial institution with more than 200,000 employees, of which 80,000 are IT (outside third-party) and where there is software development spread over more than 70 countries - and this is not the only experiment in complex systems that I observe during my responses. It seems to me that we have different experiences regarding success in "climbing" the agile (in quotes, as you also used, because we know that is not quite how you do).

  • Yes, the business vocabulary is misused by devs and the business experts themselves - a study of ubiquitous language (see DDD) helps us understand this. The same names being used for different things in different areas is also a known situation. "Situation" and not necessarily a problem because it might make sense for business to be like that - a study of bounded context (see DDD) helps us understand this. I agree that data dictionaries in these cases do not solve anything - as I already had commented here.

  • Yes, the effort to satisfy the customer goes beyond modeling the domain. But let me reiterate that modeling the domain is the most difficult and also the most important part. I can add many technologies and architectures to scale a well-modeled system, and to handle these technologies "hard" I can read manuals and hire consultants. But what about designing, refactoring and evolving the modeling of a complex domain? Manuals and trainings hired in the market cannot solve the problem of modeling the client’s business. I repeat: we need to focus more on business than technology.

  • @Caffé It seems that we could agree on 99%, except perhaps some personal preferences. I think it is important to emphasize to other users that at no time I defend that there is only one valid method to model a software. Unfortunately this is a problem far from being solved and even existing knowledge is most often misinterpreted and misused. If I have ardently defended a point of view, it is not because I believe I am absolutely right, but because I enjoy discussing the subject.

  • 1

    If you like my answer, this other is required reading.

Show 11 more comments

7

TL;DR

Problem analysis and solution design are deeply connected, speak the same language, and only this language (the language of business).

The technological implementation is disconnected from this language.

The answer of the utluiz delivers quite, but as I commented there, I see differently some important aspects of the question.

Design of the project

I’ll try to summarize my vision to the fullest.

Please bear in mind that I refer to minimally complex systems - I don’t mean web "sites", blog system, highly cadastral systems that only have CRUD...

I’m talking about systems that have business rules, and that these are complex (believe, even with the whole wave of startups, etc., it is still the complex systems that move the world).

Domain modeling

This part seeks to take care only of the business rule. It should focus to the maximum on the business.

Object names, attributes and behavior names, faithfully reproduce business nouns and verbs.

This part of the solution design, which is to write the business rules using the language of the business, is the most important part of the project. This is where we must make our biggest investments.

It is in this part of the design that you find the obvious classes you quoted (Product, Forncedor,...) and also others not so obvious but that surely one can find a suitable name from the conversation with the client or his experts in the business.

It is important to note that entities of equal names appear in different areas of the domain, with distinct purposes, characteristics, and behaviors. This can be natural and correct in the customer’s business and the modeling needs to respect. One approach to solving this is to use delimited contexts (or bounded context).

In addition, it is important that the project is able to change these names when other more appropriate names appear. This change of names we can call "refactoring of the modeling".

Application layer

This part of the design also matters to the business and she knows the modeling of the solution (although the modeling does not know it).

Here you can find a mix of technological terms and business terms.

For example, here you find a Productocontroller with a service Removerproduct, that handles the solution modeling components to meet a user request, and then navigates to a certain page as defined with the customer or business experts.

Many names in this part of the design are dependent on the selected technology and architecture, but those who manipulate solution modeling objects will allude to the names of these objects.

Presentation, infrastructure and solution technology layers

This part also requires good design and great care; but the most important part of design, which is the modeling of the solution, is completely disconnected from this part here of presentation, infrastructure and technologies.

It is in this part here of the design that you will most find and write classes without meaningful names for the business.

Words like "table", "Connection", "preview"... appear here.

In fact the names here are more related to technology and architecture, and this is not a problem.

Completion

The biggest investments of the project should occur in the modeling and implementation of the solution, and this should speak the language of the business, with its verbs and nouns.

There should be no need for a bridge between the most important part of design (modeling) and business - both should speak the same language.

The other parts of design will speak more the language of architecture and technology and less the language of business, and this is natural.

For modeling to speak the language of business it is not fundamental that programmers be experts in business - they can learn the necessary about business during design.

If you have developers with the right skills and can count on business experts on the customer side, the part of the design that modes the solution will speak the language the language of the business and will be quite disconnected from the technological language.

It was much bigger than I would like but I hope to have been able to express myself. Questions are welcome.

  • 1

    I agree that analysis and design are connected. In fact, if the whole process is not connected and follows a single logic or rule, there is something very wrong. Unfortunately, this is not uncommon in companies and billions are wasted every year because of it. However, joining analysis and design in a single step is not a silver bullet, it is simply trying to do two things at once. For noncomplex and nonchaotic problems, it can work well, just as when someone with mathematical ease writes directly the solution without developing the enunciation equation.

  • 1

    Another problem is the terms that at first may seem simple and straightforward, such as Supplier or Client. In each area of the company these terms may have different meanings, unless you are copying the terms already used in other systems, such as Erps or Crms. In this case it is a problem already solved. Even so, I’m tired of seeing systems that, as they evolve, have to change the terms used because at first it was thought that they were simple, but then it was found that there were many nuances. Then table names, classes and Labels become inconsistent, there is the "old" mode and the "new".

  • 1

    Another problem that is more conceptual than practical and the non-existence of a "bridge" from the real problem to the solution. Well, that is the same as saying that the classes of a system faithfully represent the problems of the customer. There is no such thing. What we program is an abstraction of the real problem, usually a subset of the problem containing the relevant features to solve a particular situation. Of course, the better the modeling represents the problem, the better. It’s like an equation of physics or chemistry. Anyway, the difference is the "bridge" become more implicit.

  • 1

    Apart from my criticisms, I would like to say that this is a very good answer, in the sense that a contrast to my initial response makes it possible to enrich the subject considerably, as well as clarifying that no one here is in favour of following a magic process or generating unnecessary bureaucracy. Something very important is that to the extent that we understand better how things work, we can "hack the system" rather than blindly following what others preach. I am sure that Caffé does this and so can speak with propriety on the subject.

  • Yes, I only refer to non-trivial domains (I wrote that in the original answer). Yes, business jargon is misused by devs and also in the business itself - and this is a known problem with available solution approaches. Yes, equal names have different meanings in different areas of the domain - and this is also a known situation with known solution approaches. Yes, the project needs to be able to have these names changed (I also wrote this in the original answer) and this is a relatively simple problem to solve.

  • And yes, we modeled only a "subset" of the customer problem, comfort me already I answered here. And I’m glad you realize that my intention in discussing is to give material to think about, because interesting problems are not solved with a simple answer in the OS, even if long. And I believe that honest, contradictory answers are great to help you think.

Show 1 more comment

5

Use cases are used to map the business, facilitate the analysis of the business rules that your system will have and start to map them into classes, activities, interfaces according to class diagrams, activity diagrams, sequential diagrams, etc. Sinking from business rule to technology, according to the level of detail you want.

With this first analysis (of the business rules) you will have the "obvious" classes of your system, the "less obvious" have no other way than to master the technology that you are using to make the system. So I guess a lot of people think that being a systems architect or analyst is a bigger job, or a next step, for an experienced developer/programmer (something I don’t believe, I don’t see any harm in a guy who likes to program/develop and evolve and stay in programming/development), because to make these diagrams, these analyses, the architect/analyst must know how the technology with which the system will be implemented works. Ex: If you are going to program in MVC . NET, you know that you will have the Model, View and Controller classes. If you are going to program in Web Form (.NET), how will you structure, will you follow the idea of MVC? You will use DDD (Domain Driven Design)?

SUMMING UP: It all depends on the level of detail you want to have in the analysis and diagrams, how much you understand about the business rule and how much you understand about the technology being used.

Browser other questions tagged oop software-engineering

You are not signed in. Login or sign up in order to post.