Concepts and Events

An important starting point for building an object oriented system is thus to look at the real world and see what objects there are. From these objects we try to find out what common types they belong to (I will refrain from an excursion to Plato and his idea-world). Those are the Concepts that we should model.

We then look for relations between the concepts and describe them as clearly as we can. These relations will help us later on when we see how concepts (or objects) interact with each other to solve a particular task. This also helps when we decide on the scope of the product, i.e. when we decide what is within what the system should do, and what is outside of what the system should do.

Concepts may have attributes, or properties. For example a Person may have a name, and an address. We add those too.

Concepts are similar to Classes as you are used to them in programming, but they are not the same! As stated earlier, a class contains all sorts of methods and attributes that have to do with being a software entity (such as a print() method, well defined types of all the attributes, collections of relations to other classes, etc. A Concept, on the other hand, should focus solely on the concepts, attributes, and relations that exist in the real world.

Similarly to classes, a concept can be seen as the archetype of a set of objects. For example, if you have a Volvo 244, a Ford Fiesta, and a Wolkswagen Golf, these are examples of the concept Car. If you construct software to, say, keep track of these cars, you may also have a class Car, with the instances Volvo244:Car, FordFiesta:Car, and VWGolf:Car. Of course it will be impractical to keep track of the instances, or objects, like this so you may instead have a carArray:Car[] or a std::set<car> to maintain your collection of cars. This would also mean that the car brands will need to be represented as attributes of the car instead of encoded in the name of the software variable:

std::set<Car*> myCars;
myCars.insert(new Car("Volvo 244"));
myCars.insert(new Car("Ford Fiesta"));
myCars.insert(new Car("VolksWagen Golf"));

Because of the similarities to classes there is no need to invent a new type of diagram for the conceptual model. Instead, you will re-use the notation for a Class Diagram to model your concepts, their relations, and their attributes.

As you continue with your analysis, you will learn more about the domain and the concepts in the domain, and will be adding this new knowledge into your conceptual model so that you eventually have a head start on creating your class diagram (but I get ahead of myself: We’re not there yet).

Remember that this is still early days. You have just started coming to grips with what you should be doing and, above all, you have not produced a single thing which has any value to the customer yet! Therefore you should not try to model the whole world and all the concepts in the world. You should stick to the immediate problem domain (which is why we also refer to the conceptual model as a Domain Model).

What’s more, your requirements will change, you will change how you perceive the domain, and you will learn and want to add more as you go along. Even worse, if you try to model everything and everything perfectly, you will be bogged down in this step forever in a form of writers’ block, which does not deliver value to the customer.

The solution and the agile way is thus to only model what is immediately useful for you. This sounds like simple advice, but what is immediately useful?

A good starting point is your UML use cases. The use cases you have selected for the current iteration represent a subset of the complete domain, and are a reasonaby good place to start. The use cases contains plenty of information about different domain concepts and how users interact with them, and so will give you a good starting point. Going through category lists of common types of concepts you can also easily find such concepts from your use cases.

Personally, I would also suggest that you look ahead a little so that you are at least aware of what you are going to do in the coming iterations as well, so that you don’t paint yourself into a corner. But that’s probably just me being stuck in a plan-driven design philosophy.

Another thing which we get from the use cases is our API endpoints. Of all the things that a user may do around the system, what does actually the system have to react to? We call those things System Events. Since they may come in a particular order, we can view them as a sequence of system events, and this we model in a System Sequence Diagram.

Consider the following course of events from a UML use case:

The system events we may generate from this are:

• initiateTransaction()
• orderBeverage(“Tea”)
• setFlavour(“Earl Grey”)
• setTemperature(“Hot!”)

Notice that we express these events as method calls. Also note that the order matters. “Hot Earl Grey Tea” will, in this system, not work.

Expressing this in a system sequence diagram:

We will come back to Sequence Diagrams later, where we use the same notation to express what’s going on inside the system.

So what’s the point of expressing this as method calls? We’re still just doing analysis, aren’t we?

First, there is no clear-cut line where we can say “this is analysis and that is design”. As you learn more about the problem and the problem domain you begin to realise not only what you should build but also how to build it, and so you will be moving into a design space. But you will just as quickly realise that you need more information, and will go back to analysing the problem. Object-oriented software design is very much this movement back and forth between problem analysis and solution design, made easy in particular because of the intentional similarity between the real world and the paradigm of modelling the objects in the real world.

Second, by modelling the system events as method calls we are creating a powerful entry point for our system. I will need to diverge a bit into software architecture in order to explain this further. Please bear with me. Almost all applications with some form of user interaction can be split into three parts, or layers:

Each layer has an API, a set of methods which we can call to access it. In the case of the user interface, this may consist of buttons and text boxes, but if you are creating a web application, it may also include the API endpoints such as https://www.your.server/User/userid to access the User profile for userid, as well as landing pages for your AJAX calls. The point is that you only focus on the interface of the layer you are going to connect to. So if you are an end-user, you only need to worry about the user interface. If you “are” a user interface, you only need to worry about the API for the Application Logic Layer.

This is what makes it so useful that you have already modelled them as method calls. You have now also documented your API; the methods you may call, the system responses, and the order (if any) that the methods must be called.

Moreover, you have done this without having decided how you are going to build your user interface. You are still free to write a desktop GUI application, a mobile phone app (where you have still left the choice open between IOS and Android – at least in theory), or a web application. You may even write your GUI in something esoteric like Unity, and your system sequence diagrams would still look the same.

In this sprint, we have introduced two new models; domain models and system sequence diagrams. Both of these are useful for testing purposes. The domain model shows you how you think the problem domain functions. When constructing your tests, this is a better starting point than what you eventually end up implementing. More importantly, the domain model divides your problem domain into smaller entities, concepts, that are possible to unit test. Later on, you can combine your already tested units and run integration tests to make sure the units work together.

Your system sequence diagrams tell you what API endpoints you have in the system. These are an excellent starting point for writing your regression tests. Consider the Layered architecture model in Figure 4 once more. Remember that we specified the API for the Application Logic in the System Sequence Diagram? So why not just “push” the user interface to one side and attach a testing interface there instead? Why not indeed.

In one go you have enabled automated testing of your application. Technically, you can (and should) do this on top of the user interface too, but this is easier to get in place.

We are thus able to start building a chain of analysis efforts and UML diagrams, where what we learn in one diagram is put to use when creating the next one, as illustrated in Figure 6. Of course, this chain is equally valuable going backwards: In order to find out more about a particular test case and why it is written the way it is, you go back to the UML use case. If this is not enough, you look at the involved requirements, or – via the requirements – contact the original source of the requirement to ask further questions.

• C. Larman, Applying UML and Patterns, 3rd Edition, Chapters:
  8. Iteration 1 – Basics
  9. Domain Models
  10. System Sequence Diagrams

• Concepts and Classes
• System Sequence Diagrams

• Execution in the Kingdom of Nouns (Steve Yegge)

Go through the user stories for this sprint and make sure you have a clear understanding of how to solve each of them.

Revisit and update your risks and contingencies section.

Add and/or revise the following items to your glossary:

• Concept
• Class
• Instance
• Object
• Object state
• Class Diagram
• Domain Model (Also: Conceptual Model)
• System Sequence Diagram
• System Event
• Black Box
• Software Architecture
  • Layered Software Architecture
  • Model-View-Controller Software Architecture
  • Pipes-and-Filters Software Architecture
• Unit Testing
• Regression Testing
• Integration Testing

Make sure you understand what each item is, the notation for them, and how to use them either in isolation or together with the other concepts.

What’s the next step? What do you need to do in order to understand how to implement the system based on your system sequence diagrams?

Are there any other questions that you want answered? Add them, along with a brief strategy for how to find an answer.