How To Make Goal Centric Software Design Minnesota

So in the world of objects, abstraction helps us to focus on the role that each object plays within the software application. Let us take the example of an ERP system. Suppose I am the person who is developing payroll and marketing modules. In the organization lets say that there is an employee named S and he is the marketing manager of the organization. When working on the payroll module I will only concentrate on S’s salary structure, attendance, leave, medical facility etc whereas at the time of development of marketing module I will concentrate on the targets, achievements, client handling, team performance etc of S. So if S is an object of the system it has two different goals and that leads to two completely different abstractions.

So here specific objects, like Employee object or Marketing Manager object, represent abstractions in the application. But definition and usage of appropriate objects is important. So in the requirement analysis phase of the application it is important to identify goals and requirement of each object. In this stage certain objects become redundant too.

Thus Goal-centric design is the first step in the methodology for object-oriented architecture. The objective of a goal-centric design is to examine the goals as well as the requirements of the application and develop the appropriate abstractions. These steps are not concerned with the physical design of the application hence sometimes they are called the logical design steps.

Goal-centric design involves the following steps:

a) Describe the objects

b) Define relationship between objects

c) Validate each object with respect using scenarios.

Professionals with proper domain knowledge should be appointed at this stage. The design team should have prolonged sessions with these professionals. Because these experts have in-depth knowledge of the application domain and can help the design team to develop appropriate abstractions and thus identifying appropriate objects. One should not distract these experts with too many technical concepts or jargons. It is better to understand the requirement in a simple language. All interactions should be properly documented so that none of the team’s abstraction is lost. Once this phase is over the design team will have the complete document that fully describes the probable objects, which need to be used in the application with their associated scenario. In a later stage at the time of implementation the objects may be combined, split or modified.

About the Author:

Article Source:

thePhantomWriters Article Submission Service