Object oriented design

Object oriented design

Implementation of an application might appear as the primary task of a programmer. From a technical side, this is true. The applications’ design, however, which precedes the implementation, is a task, which deserves at least as much attention, because it forms the backbone of the application and helps to view the application from a birds perspective (e.g. looking at the class diagram).

So let’s see which steps are necessary to arrive at the class diagram.

Use cases

Assuming that we have decided that an app has to be developped, we need a description of domain, which is to be modelled by the app. This can be a description of a business owner or employer about the work flow or common activities. These need to be brought down to a couple of use cases. Use cases are kind of goals a user wants to achive.

In an early stage the software architect needs to describe informally the use case. The description contains a detailed description of the user, his behavior and the behavior of the machine/app.

Then, the formal use case description can take place. In this description a primary actor is defined, the goal, and the main succes scenario, the interactive procedure that leads to achievement of the goal. The scenario should not involve more than 10 steps..

This formal description then can be extended by alternative steps that we be walked through when a interim step was not successful or a predicted problem occurred.

The formal use case can be used to crate a user system interaction sequence diagram showing user requests to the user and the systems response to these requests.

For every action request the system has to undertake a certain procedure. This can already be visualized using a Use case sequence diagram