Welcome to Eminent Infosystems Pvt. Ltd.

We take great pleasure to introduce ourselves as the pioneers in the area of IT solutions and services. Our initiatives and efforts take recognition under the name of Eminent Infosystems Pvt. Ltd. 


Eminent Infosystems, began producing commercial websites in 2006. Word of mouth recommendations and a good visibility on the key search engines led to the expansion of the business and the Private Limited company was formed in 2010.


Eminent Infosystems, is professional web development, Customised Software Development and offshore outsourcing company based in India. We offer a wide range of services to reach your targeted audience and share your valuable information focusing on retaining your customers.  

Are Programmers Engineers?

In yet another attempt to drive their ad impressions, Slashdot asks an old but still controversial question:  Are Programmers Engineers?


 Certainly not.


I used to think otherwise.  I graduated from the University of Illinois at Urbana-Champaign where the Computer Science department is part of the College of Engineering.  For a couple of years I took the same classes as the engineers.  I still have the T-square to prove it. 


Because CS gets lumped in with engineering at many schools, graduating programmers often think of themselves as engineers.  But the distinctions start appearing very quickly.


Engineers are required.  Programmers are optional. 


To be an engineer, you have to be licensed.  You have to pass the Professional Engineer exam.  Engineering is one of those fields where you have to have a license to know the right answer.  Law is like this too.  I'm quite certain I know more about copyright law than most small town attorneys.  Nevertheless, they are allowed to render their opinion on the subject whereas I am not.  Engineering is similar.  Some things can only be legally done by a licensed engineer. 


Anybody is allowed to write code.


Engineers work for a living.  Programmers do what they love to do.


Engineers are generally marked by a higher degree of professionalism than programmers.  Some people think this is because of the certification, but I think it comes simply from the origins of career choice.  Many programmers started coding as a hobby and gradually made it their profession.  I did.  I was writing code years before I could drive a car.  Sometimes we make stupid choices because the distinction between hobby and profession gets blurry.


Engineers generally don't do that.  Teenagers don't design bridges in their spare time and then decide to pursue civil engineering as a career.  Engineers always think of their job as their profession, because that's all it has ever been.


Engineering is well-understood.  Programmers have no idea what they're doing.


In general, engineers can predict their workflow.  They don't get into very many arguments about widely divergent ways of managing a project.  Ask them to estimate a project and they'll probably get it darn close. 


So far, there are no universally accepted methods for management of software projects.  We all do it differently.  Some of us get amazing results with virtually no process at all.  Some of us have formal methodologies and still can't finish anything on time.


Engineering is real.  Programming is abstract.


Engineers work with physical things like electricity, mechanics and heat.  When engineers design and build something, it is usually a tangible item which must be manufactured.  You can touch it, maybe even hold it in your hand.  In some cases it will retain its value for centuries.


Programming is the manipulation of complex abstractions.  We invent abstractions and give them names.  We manipulate them and use them to build things.  When our finally product is built, it requires no manufacturing.  It is merely a string of bytes.  Theoretically, a monkey sitting at the keyboard might accidentally of typed the same string.  The product we build cannot be touched or held.  It will be worthless in just a few years.


Am I saying that engineers are more valuable than programmers?  Certainly not.  Could I design a bridge, a TV, or a concrete canoe?  Nope, but I defy any engineer to design and ship a good version control system.  Programmers solve really hard problems too.


Our universities call us engineers because there is no college where we fit.  I don't blame them for that, but I have no desire to borrow the word engineer as an attempt to make myself sound more credible. 


Why not just admit that software development is unique?  No other field is like ours.  Engineering looks really dull to me.  I love being a programmer.

.NET Application Modeling Language

Introduction

nAML (.NET Application Modeling Language, pronounced as “namel”) is a visual modeling semantics to model .net applications with wide range of specific details. It contains extremely powerful visual notations and semantics to illustrate complex application components, processes and operations easily. It overcomes the limitation of traditional modeling languages by providing a single space to describe an application system with its structural and behavioral, as well as physical and logical components. One of it’s the most powerful objectives is nAML requires near to zero knowledge on notation semantics to understand an application system from readers perspective.

Example: Using nAML, for instance, a software architect can model a whole or part of a web application in a single visual diagram with respect to interaction, communication and structure between end user, web interface, .net classes, database objects, physical tiers (web server, business logic server, database server etc) and so on.

The primary objectives of nAML can be considered as follows:

• Provides a single space to visually describe one or more application systems with structural and behavioral components.
• Provides a single space to visually describe one or more application systems with logical and physical components.
• Provides a single space to visually describe one or more application systems from top to low level.
• Provides a single space to visually describe a part or whole of one or more application systems.
• Extremely simple and easy understand and learn from readers and designers perspective.
• Concentrates on .NET applications, with its related logical and physical entities (user interface, application logic, business logic, database etc).

Terms and Definitions

Element:

Definition

An Element is a structural notation that is the physical or logical object that holds one or more physical and/or logical objects.

Notation

Example

In an ASP.NET web application, an ASP.NET page can be an Element, having controls embedded within it as sub-Element and the event handler methods as defined Operation within it. For a .net class, the member Elements are the properties, data fields etc. For a physical database, its member Elements is the tables.

Operation:

Definition

An Operation is a behavioral notation that is the set of one or more actions to be performed that are defined in an Element.

Notation

or

Example

For instance, an ASP.NET page code behind class, as an Element, can have controls event handlers (click event handler of button etc) as Operation. For a .net class, the members Elements are the methods etc. For a physical database, its “Operation” can be defined within the stored procedure, functions.

Association:

Definition

Association is a structural notation that illustrates how the Elements or Operations are connected to other Elements or Operations.

Notation

Attribute:

Definition

Attribute is a structural notation that is the Meta data information that describes an Element, Operation or Association.

Notation

The notation of attribute can be simple text of an Element, Operation to be expressed as characteristics of another Element or Operation.

Example

For a .NET class “Employee” can have an Attribute as, Class Name: Employee

Element Lifeline:

Definition

An Element lifeline is a behavioral notation which is the time span within which all activities related to the corresponding Element is illustrated. The life line also shows the active and inactive state of the Element. Each lifeline for a given Element applies to only one instance of that Element.

Notation

Example

If an instance of a .net class is being created, then its activation will be illustrated from the moment it created.

Common Semantic Guideline

• To distinguish structural and behavioral components of system, consider solid line diagrams as the behavioral component and dashed line diagrams as the structural component.
• Element Lifeline reflects the time span for behavioral components only, rather structural components

The Hello World! Sample

The sample illustrated below shows the “Hello World” message in an ASP.NET Label server control, when a user clicks on a ASP.NET Button server control.

Now let’s see the corresponding nAML notations implemented in this example.