Home‎ > ‎

Design


Subscribe to posts

Software design: Basics are important

posted May 31, 2020, 2:29 PM by Jageshwar Tripathi

{
"Basics are important": [{
"Perceptions in software development": [
"We have to do Microservices using SpringBoot",
"We have to learn these two"
],

"Reality": [
"We have to implement solution of a requirement",
"Requirements are complex as a whole",
"Finding solution of a requirement as a whole is difficult",
"If somehow we implement a system, it becomes complex, difficult to change and                 maintain",
"Knowledge of NodeJS, SpringBoot doesn't help us"
],

"Result": "We fail a project",

"Why": [
"Because requirement is a complexity and",
"We have to reduce this complexity by dividing it in to smaller parts",
"We have to analyse the requirement"
],

"Our perception of the solution": [
"Design",
"Class"
],

"What are we missing?": [
"We can't jump to the design before analysis",
"We can't find out classes from the air",
"We can't solve this complexity without taking a step by step computational                   thinking"
]

},

{
"What is the right approach": {
"Use cases or scenarios": "Helps finding what a user requires or does with the                                         system. This will help finding responsibilities                                             later",
"Domain Objects": "Real world entities, vocabulary of the domain, nouns or                                     noun phrases. These objects will take responsibility of                                     achieving what user wants",
"CRC Card": "A good technique to find out responsibilities of Domain classes                             and any other class they will collaborate to achieve the                                     scenarios",
"Object responsibility assignment principles": "Certain principles help us                                                                     assigning right                                                                         responsibility to the right                                                                     object",
"Collaboration diagram": "For more complex scenarios to showcase collaboration                                            of more than two objects",
"Software classes": "Applying patters which are solution of recurring                                             problems, we add more classes which are not domain                                         objects but are software classes",
"Class diagram": "Now you can have static view of the classes and their                                         association without their properties and behaviors                                         (responsibilities) in a model",
"Iterate": "This is not a one time activity, in agile world you may have to                             iterate your model, starting with a small slice"
}

}
]
}

What users want in design?

posted Sep 14, 2014, 12:45 PM by Jageshwar Tripathi   [ updated Oct 31, 2018, 12:30 AM ]

It is not about object oriented design, database design or design of software. It is about how users see the design (comfortable or not comfortable with it). Mostly users interact with an interface and in modern applications, websites and software, that interface is UI (user interface). Very good looking, bright and full of images/animation is not what is most important for the users. There are few principles of design from user point of view and they are mainly on usability. Here are some basic things which most of the users want in an application:

Self explanatory or intuitive: 

If your application or website requires training, a user guide to use it or steps to remember the things on how to use it, you have missed the plot. The features, commands and menus of the website or application should be self explanatory, well known and obvious to the user. 

Maximum default values: 

If there can be a default value it should be provided. A user is filling out a form but why he should enter date of filling out the form. There may be an option to change it but why not provide a default value. If a user is filling out a form why should he enter his country, why not the default selection of country based on his locale or history of use? If a department user has to make entries or post often, why should he selects his department? His profile should have his association with a department and that should be auto-filled. 

One stop shop: 

Asking user to do multiple things on multiple pages or applications is a big no. Whatever user has to do to get something done should be available on single place (may be on a single page too  that's why RIA or Ajaxified apps came to the picture).

Minimum steps: 

There should be minimum steps, as minimum as possible. Only one step is the best. Confusing multiple options or ways to do the same thing confuse users, provide them one consistent way of using the application. Minimum choices are the best for users. It doesn't mean user should not have choice for his product but here we are talking about what he has to do to get his needs fulfilled should not require him to deal with multiple choices big and detailed form and many steps.

No repetition:

Don't ask users to provide same information which they have already provided. 

Be a guide:

Users want suggestion on how to do, what to do not "you made a mistake", "there is an error" statements. Provide them as much as possible hints, help and message (but avoid unwanted popup messages, they are killers). What you assume about user knowledge is certainly not true. They don't know how to write(right) "click" (now decide how will you ask them to click right mouse button after pointing the mouse pointer over an option or icon on the computer screen)

At the right time & quick:

There is a right time to everything. If you provide lots of information (you try to do this but they wont listen/read/understand) very early before time when that information is needed or if you provide them information too late, both are not going to be liked by users. Response time of a request should be minimum, no one wants to wait. Would you like an application which asks you to fill a form and get the report tomorrow or get the information you need after few hours? No, never.

No partial functionality:

If you go to a restaurant and order food, restaurant says we can serve meal but not water, you will have to arrange it on your own from outside, will you go to that retardant again? User has to do something and you give him only half of the functionality, for another part of the same requirement he has to use another application or do it manually, such application is not going to be helpful for the user.



Object oriented analysis & design

posted Feb 8, 2011, 8:53 PM by Jageshwar Tripathi   [ updated Jun 3, 2020, 1:42 PM ]

You can use a case tool or you can create UML diagrams in a white board and then take a picture of it or just draw them in a white sheet of paper. Case tool is not mandatory for good design.

Object oriented analysis and design is not about creating UML diagrams. Diagrams are a way to write your design decisions and give you a canvas to draw while you are thinking. I used them like mind maps. If you don't want to use UML to write and convey your design decisions for review and to be followed by programmers or your team, you can use other means of presenting your design. 

A) Managers are comfortable in power point and spread sheets and they would always prefer to show everything with spreadsheet. If you and your team is convinced, you can use spread sheet.

B) Even if writing design in spread sheet looks too costly, go ancient way, write your design on walls and caves (obviously there are challenges while following this approach in office because there are limited walls in office).

C) And finally if you still see challenges writing your design somewhere, you can think about it and keep it in your mind. How to convey it to others?, how to refer to it later? Leave it to god. The almighty will help at the time when it will be required, right now we are living in an agile world so do whatever takes less time and don't take pain in thinking about reviewing and giving feedback.

D) There may be some one among us who may ask "why to do design at all?" 
Yes it is absolutely correct if your users or client asks what is needed (requirements are not written) and expectation is that programmers will write the code, client or users will see the output and if it is fine go ahead otherwise changes are suggested and programmers will write the code again. You may rely on programmers to think, understand and write code with best design decisions directly on IDE, nothing better than that. 

In any one of above cases, some one may be thinking about design even if directly writing the code. Good design skill is still required even if no design document is created. Good design principles are still applied. So let us see those principles and steps, which steps to follow and which one to escape depends upon team to team.

Here are some steps to follow in "usecase driven analysis and design" of object oriented system:

Object oriented analysis

Identify and describe your usecase

This is not the focus of this topic  hence not talking in detail but just to mention: for good object oriented design you should have your usecases identified. If in detail nothing like that. If usecases are not identified yet  you will have to do iterations to complete them. Usecase is going to define needs, actors involved and constraints, business rules, validation rules and non functional requirements (special requirements). Otherwise how will you be able to take care of all these aspects in your design?
In the name of Agile how much are you going to write your requirements and how formally are you going to define the business rules? It depends on different teams and set-up (people have defined their own methods to escape everything but to code so nothing is mandatory :) ).
Less documentation may be fine (less formal) but even if you are discussing about important topics/aspects and making important decisions, you will have to put them somewhere? 

Identify domain objects:

This is the place where you first introduce objects. Where do objects come from? How to identify objects? Answer is domain vocabulary. Objects should be representatives of the domain. Real world objects come to play role in the form of Java or .NET classes (class is not an object but a template to define them. Using a class you can create many objects). 
  • Read you requirement document or usecases carefully and see the nouns or noun-phrases. Yes believe me they come from there. 
  • They may also come from your historical knowledge of same domain and similar project/application
  • Remove duplicates: The nouns which may be same with little different name, eliminate the duplicates.
  • Identify attributes of the objects: Which information should they have? An employee should know about his name, age, department etc. These attributes may not be complete in one go but you may define few, high level first.
  • How are they (objects) related? Do they need help from each other or some how reference one another? If there are some who are related identify this relationship in a diagram called domain object model. 
  • Relationship may be association, aggregation or composition but don't stress too much very early about much detail and precision. Just define two objects are associated (association relationship). 
  • Sometimes people also define cardinality (one to one or one to many or many to many). Initially when you are doing analysis it is not mandatory. 

Refine domain objects

  • System sequence diagram: To refine this domain object model you can create a diagram which is called system sequence diagram. In this diagram an actor interacts with a context level object which is system. System here is represented as a blackbox and events starting from actor (user) to the system are drawn. It helps in understanding the usecase. It can be created  for main flow of a usecase and for those usecases which are complex. 
  • Note: For usecase estimation model analysis up to system sequence diagram is needed and I have seen use of system sequence diagram for this purpose in most of the cases where SSD were created. 
  • Analysis model: Defines how a usecase will be realised. It is logical structure of the usecase. Class diagram represent static structure and sequence diagram shows flow of event in a usecase. In theory you may define boundary, control and entity per usecase by doing SSD and model your domain objects better. When you have all the boundaries, control and entities known you can better know complexity of a usecase and size of the system. It is not a mandatory activity for estimation.that (in practice I have seen people guestimating without going to all this detail because they don't have opportunity to do it or may be there were some other limitations)  
  • Activity diagram: With activity diagram (which is kind of flowchart in UML) you are able to see how request will be processed. This may also help knowing behavior required by the user of a usecase and will help discovering complexity of a usecase. This is also not a mandatory thing to do (in practice I have seen very few people doing it). If you have to do it, it should be for complex usecases only. Why to waste time if things are clear :).

Object oriented design

Object oriented design is about identifying the objects, assigning them responsibilities, identifying their attributes and identifying relationship among objects (how they interact). There may be different ways to do design, one of which is usecase driven or requirement driven design. Another way may be database driven design. Apart from defining responsibilities you may have to decide if a class is going to aggregate other class or there is a composition required or not. If there is an opportunity to extend the class from a super class or a new super class needs to be designed.  
Identifying objects

We have already seen above in analysis how we find domain objects. Other objects are also identified which help in making design better and these objects which are our of domain vocabulary but come from software engineering are called software objects or these classes are called software classes. When design patterns are applied or any framework is used these software classes come in to picture. Some software classes are introduced when we apply some OOD principles of best design. See OOD principles and Use patterns sections bellow.

Assigning responsibilities to objects

Assigning responsibilities means identifying which object will do what. In most of the cases it is identifying methods of a class or messages an object will receive from other objects or actors. Some times objects may have responsibility of doing something when an event is fired.   

Sequence diagrams

Sequence diagrams in design help identifying messages to an object. When events from an actor to system are drawn and some of the objects in the system collaborate to realise the usecase messages are passed between objects, these messages become operations or methods of the objects. In design phase sequence diagram shows how system works.

Collaboration diagram

Some times collaborations diagrams are also created (with case tools they can be automatically generated if you have created sequence diagram. Collaboration diagrams are another representation of how objects collaborate in a usecase.

Use OOD principles: 

Separation of concerns

Software should be divided according to different aspect of the system. All the classes related so specific aspect should be kept in a layer. These layers dealing with different things should interact with each other through predefined contract or protocol. A layer (objects in that layer) should only interact with layer adjacent to it (object in adjacent layer). This way impact of changes in one layer can be limited to calling layer and it doesn't spread all over the system. Making changes and maintenance is easy in this case.
Example of layers may be Presentation (view), Controller, Business Logic, Data Access, Database
Model View Controller is one of the pattern for separation of concerns.

Principle of least knowledge

While design one object interacting with other object (to get some work done it calls a method of other object) it should not know internal state of the other object. Objects should interact through a standard predefined contact. For this purpose attributes of the classes are made private and if there is any access needed it is given by getters or setters. Giving direct access to attribute of an object may lead to uncontrolled change of state of the object. For example public attribute age of an Employee class can be set to negative ( - value) which is not correct in any case. If age is private and setter is provided, it can be controlled by checking in setter whether value being set is greater than zero or not.

Principle of single responsibility

Cohesiveness is the desired characteristic of an object. If an object is doing or dealing with multiple things handling it will be difficult. Its impact will be on many objects and larger part of the system. If there is an object which is dealing with many different responsibilities it should be split in to two objects. 

Principle of don't repeat yourself

During processing of business logic many objects may deal with some common business logic or processing. If this is repeated in many objects it becomes source of maintainability challenge. Higher maintenance cost of duplicate code is always higher.  Such common functionality should be taken out in the form of common object or reusable components.

Low coupling

To reduce coupling between two different types of objects or layers, a de-coupling object should be introduced which can insulate caller from change impact of called object or layer. One of the example is Web layer or controllers need to call a remote EJB and hence they have to lookup it, they know about its (EJBs) specific nature. In future if services of EJB are provided by a web-service, there will be a change needed in controller classes. To insulate them from impact of such changes a Business Delegate can be introduced between web layer and business login layer so that Business Delegate can handle any changes and web layer always considers it is communicating to a local object. 

CRC cards

Classes, Responsibility & Collaborators. It is a method of identifying classes, assigning responsibilities and their collaborators. In this method Name of classes on cards is written and a team role plays and defines responsibilities of the  class and its collaborator or class which this class interact with. A card has three areas: On the top name of the class, on the left: responsibilities of the class and on the right: its collaborators are written.
There is one basic tool specially for CRC card: https://echeung.me/crcmaker/

ClassName
  • Responsibility 1
  • Responsibility 2

 
  • Collaborator class 1
  • Collaborator class 2

 

Use patterns

Solution to common problems. This will add software classes apart from domain classes you earlier identified in analysis. 
Who should be given responsibility of doing something? One who has the information. If you want to get age of an Employee, it is Employee class who has the information so you will have to call it for getting age.
Who creates the objects of similar types or category? Normally a Factory pattern is used where Factory is called to create the object. 
How to reduce network round trip or chatty  interfaces with remote objects? Use Facade or synthetic object at remote to take one message from client and Facade calls other objects locally. 
GoF or Gang of Four patterns are useful patterns to deal with commonly occurring problems and their solution through better design of objects. 

Interesting Resources




1-3 of 3