Use Case Digram - What is it?

The first step is to identify What needs to be built. At the end of this phase, an artifact called Usecase diagram is created. The Use case diagram identifies what needs to be built and who will use the system. The use case depicts, how a user of the system is going to use and how the system will respond. By definition Use cases treat the system as a black box, and the interactions with the system, including system responses, are perceived as from outside the system. This is a deliberate policy, because it forces the author to focus on what the system must do, not how it is to be done, and avoids the trap of making assumptions about how the functionality will be accomplished.

At a minimum, the use case consists of an actor (user of the system) and a sequence of how the system will respond to the different requests that the actor forces on the system. The Usecase also depicts how the system will respond, when the user makes requests on the system. Each of the request reply can be organized, into more modular request reply sequences by an modular construct call Use cases

OO Construction methodology and its significance.

A Business information system built as a bespoke system will fit the environment and hence can deliver a higher user satisfaction. A bespoke system is built by modeling how the user will use the system, realized by building artifacts called usecases. The usecase depicts the user experience of the completed system. We will explore how a system is built and see how the artifacts created add value to the overall development and see how these artifacts can be significantly simplified or totally eliminated and see how we can make the system building process more simple. We will be using the Object oriented use case methodology to illustrate this.

One of the hallmarks of a successful projects are its process discipline. Use case methodology like RUP is recommended practice which has delivered successful projects. These software methodologies, recommend a discipline of software development and they have different artifacts. In each of these phases, different artifacts are created. A typical Use case methodology like Unified Markup Language has few significant artifacts, they are a) Use case diagram, b) Class diagram, c) Sequence diagram, d) State Transition diagram and e) Collaboration diagram.

The use case diagram, depicts the system to be built. The other artifacts like Class diagram, Sequence diagram, Transition diagram and Collaboration diagram depicts the design view of the software

Each of these diagrams/artifacts have a purpose, to give clarity to the next phase of development. These complicated artifacts have to be built, to bring a business world that is concurrent into a sequential world of computers. In the next few posts, i will explore each one of these and understand its fundamental purpose. With the understanding of the fundamental purpose, then each of these artifacts can be explored, enhanced or removed from the development purpose by appropriate changes in the computing fundamentals (making computers understand concurrency directly, by providing communication primitives than sequential primitives). This i believe will bring significant benefits to software development productivity and usefullness

Adaptive Business Information System.

A typical business system, is used to record and organize work. The work and work products are organized into a system and it is called a business information system. The environment in which a business resides, brings with it specific constraints on the system. This happens due to the different stakeholders that put constraints on the business. The different stakeholders are Government (affects business through statutes and reporting requirements), employees (by thier roles and responsiblities), vendors(by owing them monies), physical environment (as in roads, access to infrastructure, etc) and customers (by providing monies, which is the life blood of the business). These constraints placed on business are collectively identified as business rules. Most of the effort to build software systems are spend in building these business rules into the business information system. In the interests of project completion some of these rules are sacrificed at the alter of dead lines leading to user unhappiness and frustration

There are two ways in which information systems can be built. One way is to either build a bespoke system (i.e. build the system to meet the local cultural and other environments) or the other way is to buy a pre-packaged software which have most of the functionalities and adapt the organization to that system. Both are not very good approaches, as first one involves high cost to build a new system and the other pushes you into a cookie cutter system,significantly reducing the businesses capabilities to serve the business stakeholders.

In further blog entries, i will explore how these new minituarization technologies (amplified as PDA's, mobile phones and mobile music players), networking (Internet) and new software architectures (like REST) can be used to reduce work in creating new information system architectures which will reduce cost at the same time produce systems which adapt to the organization dynamically. Towards this end we will identify how systems are built and see how these processes can be short circuited with these new technologies and network architectures.