Menu ▾ ▴

Introduction

Nghia Do
Attachments

Introduction

This article is a 5 parts to present a system which to keep all business rules and information for a software product.

As we work in software development either in Development team or Quality Control team or Business Team, we often want to know things like

  1. What are business rules behind a field on a screen?

  2. What are validations the system executes when a button is clicked?

  3. When we make code changes on a screen, what test cases we have to execute to make sure our new code is good to check-in.

  4. What are navigations flows of a field? How many ways end-user can go to this screen? What many test cases we have to execute if we change a screen?

  5. If we change a message, what screens or fields are using this message?

  6. Or we may ask what different between 2 versions of a product. When this business rule is introduced? What version is that?

  7. And more questions … to find out what dependencies or relationship of fields, screens in a software product are.

All of above questions are simply to help developers understand more and clear about a system before they can deliver code changes and have better maintenance for it. New developers or quality assurances to the product also need to learn things too.

Of courses, we are able to answer questions by many ways, such as go through numbers of existing documents, ask experience persons or research by yourself.

And I come up with a though, why don’t we have a system to help all teams in development with those questions and give them answers as much as possible. Somehow like if anyone wants to learn about a screen, they come to that system and search for a screen, click on a control on it, and then the system will give them all information relating to that control.

That is why Field Catalog is built.

Who end-user(s) for this product are

The targets for this product are persons who are working in IT department(s) such as

Developers, Quality Controls, Business Analyst And More ..

Five-part articles will cover
1. Introduction

2.Architecture

3.Database Design

4.High Level design

5.Low level design

for this open-source system.

What Field Catalog system does

The system is built base on 4 main objects

  1. Product

  2. Product Version

  3. Screen

  4. Field

Base on naming of 4 objects, I think you can guess what Field Catalog can do.

I would like to introduce main features of the product.

Define Software Product

For example, you can define Microsoft Word as a software product.

Define Software Product Version

For example, you can define 01.00.010 as a version of Microsoft Word.

Define Screen

For example, you can define New, Open, Print, Page Setup as screens of Microsoft Word version 01.00.010

Define Fields

For example, you can define OK, Options or Cancel as Fields of Print screen of Microsoft Word version 01.00.010

When I say ‘Define’, it means we are able to create or edit or maintain them with many items or information linked to them such as business rules, code, messages, tags, permission, events, custom fields …

Define Relationships between Product/Version/Screen and Fields

For example, Microsoft Word version 01.00.010 has 27 screens and 539 fields

Define Relationships between Screen and Screen

For example, the ‘Print’ screen is a child of Main screen and it is also a parent screen of ‘Page Setup ‘ screen.

Define Relationships between Field and Field

For example, ‘Page Range’ field can change behavior of ‘Manual Duplex’ checkbox on ‘Print’ screen of Microsoft Word.

Define Relationships between Screen and Field by Graphic mode

For example, you can open a screen which has screen-shot, and then you can tag Fields directly on that image

Beside 4 above main objects, the system also provide supporting objects
1. Event
2. Custom Field
3. Tag
4. Group
5. Message

And Field Catalog can provide more features

Define Dynamic Event for Screen and Field

For example, you can create events such as Click, Mouse Over for a Print button. Or you can define a event Page Load for Open dialog.

Define Dynamic Custom Fields for Product, Screen and Field

For example, you can create a custom field Technical Notes for ‘Page Setup’ dialog to put notes you would like to share with developers

Define as much as possible Tag across the system.

For example, you can tag ‘print’, ‘setup’ for Print screen.

Define Group which allow to control View/Edit permission

For example, you can create Developer and QC groups and assign View permission for both group in Microsoft Word versions 01.00.010

Define Message for entire Product.

Provide Search engine.

For example, you can put any keyword and search; the system will search on every single fields in system to find out information relating to that keyword including Tag, Events, Custom Fields …

Quick Tour

To recapture what I say above, please try to have a quick tour to understand what Field Catalog does before we can go to Part II with more technical stuff including Architecture, Database design and High and Low level design

The initial version of Field Catalog is deployed on OpenShift by RedHat.

http://fieldcatalog-itservicesdepot.rhcloud.com/pages/unsecure/login.xhtml

  1. Admin role: admin@itservicesdepot.com/tryme123

  2. Viewer Role: guest@itservicesdepot.com/tryme123

Try with Admin role to see all features/permissions.