D-FOM, Another Model for System Analysis & Design with Object Orientation

Introduction

OOAD is not a new concept in the field of Software Designing. Booch, Rum Baugh & Jackabson had given great concepts in this field to help the designing of a system. They proposed good approachs towards class identification & their modeling in terms of packages & relations.

Although, a beginner of object oriented approach has enough number of case studies & examples of already developed systems on these concepts on internet and other sources of information , yet they seem to be facing a lot of confusions in identifying classes & attributes with relationships & associations in them.

For last few months, different Software & Hardware Development Companies had approached me for that they have no efficient tool that may directly convert their VHDL-System designs to OOPS and vise versa. I gave some thoughts to the problem.

In these papers, I have tried to find & solve out most of those confusions & common problems with a proposal of another model for analyzing the system to give a clear view & easily acceptable approach for Object Oriented Analysis for a system.

Review of Traditional Object Oriented Approach

In the traditional object oriented approaches, we try to describe the system in terms of the discrete objects having their own identities, states behaviors. These approaches have been suggesting about analyzing the system not in terms of a set of functions but the Objects, Classes & Associations. (These terms have been discussed on various information sources and are not new to the IT-Professionals so need not to be re-discussed).

These approaches have been suggesting that software architecture and designing is not a one-dimensional thing but is made up of concurrent multiple views. [Refer �The 4+1 architecture�:Visual Modeling with Rational Rose2000-by Terry Quatrani].

Common Complexities in Traditional OO Approach

There are some soft points in these traditional approaches that frequently induce errors in the prepared designs and hence make system designing a complex task. Some of these complexities may be summarized as follows:

1. Class identification: The major complexity occurs in accurate class identification, without which, the design will not work as per specification and also it will create more complexities while implementation of the design. The traditional approaches have been suggesting collecting nouns from the problem statement and then classifying them in terms of relevant classes, irrelevant classes, attributes and relationships.

2. For a newly joined analyst, it is not possible to get a perfect (or good, nearly perfect) set of classes, use-cases, actors and associations. Sets of each of them have their own imperfections in them and when 4+1 view structure designs these views independently in parallel to each other, all these imperfections get added up and result in adding up more and more errors in the design.

3. As all the views are running under development in parallel, they all must be crosschecked for consistency of the system that different assumptions and decisions are not being made with different attitudes. This crosschecking in later phases (after analysis of all views separately) leads to a large number of iterations in the analysis and design phases.

4. No relation between OOPS (Object Oriented Programming Structure) & HDL (Hardware Description Language).

5. As Multiple Views are developed in parallel and finally they are combined together, they induce multiple inconsistencies and incompatibilities. To remove these inconsistencies and incompatibilities, we need to perform multiple iterations in SDLC. These iterations are time and resource consuming.

DFOM-The New Approach

For last few months, different Software & Harware Development Companies had approached me for that they have no efficient tool that may directly convert their VHDL-System designs to OOPS and vise versa. I gave some thoughts to the problem.

Now I will try to find out another approach, which must not leave the grounds of Objects & Object-Oriented-Systems but should give some reduction in number of iterations in the complete process and hence reduce the efforts & resources required to spend for a good design. Simultaneously, I will also try to cover the above mentioned problems in this approach so that we may covert our systems from VHDL-Models to OOPS & vise versa.

It is commonly found that when somebody looks into the system, he tries to directly look into the functionality of the system. Also when some customer asks for some system, he always tries to explain the required functionalities or the services of the system. It can even be the black box functionality of the system that states nothing more than what output is given for what input in the system. After identifying the behavior of the system for a given set of inputs, we can identify the different states of the system on an abstract level.

According to the behavior & environment of the system, we can define who are the users of the system & how they can use it. On the basis of these studies, we can prepare a use case analysis of the system with a number of users (Actor) and their interaction with the system (Use Case) that show how they use the system.

With a use case analysis result, called the Use Case Diagram, we may have a good understanding of how the system will be used in the environment.

Now this Use Case Analysis can be used to develop a class diagram of the system that provide a skeleton for programming codes for the system in any object oriented language.

Further the Use case analysis can be supported with a sequence diagram for each of its use case wherever required that provides you a dynamic behavioral view of the system while passing through the execution of that use case.

This dynamics of the system can then be converted to the codes in a programming language if the use cases are properly managed & analyzed. A use case can also be further analyzed individually into a number of use cases, wherever required.

First Step towards analysis:

The first step towards the Object Oriented analysis of a system with this approach is to find out the actors & uses cases for them in the system. For this, we need to be clear to the core of the concept of Actor & Use Case.

Actor: A user or any external system or entity or a part of the system itself (that is to be analyzed) that uses the system or triggers any activity in it can be taken as an actor for the system. In other words, an Actor is something external to the system that must interact with the system.

For an example, a customer is an actor for a Bank System; a request-sender is an actor for a �Music On Demand� system, a subscriber is an actor for a library, a driver and lender are the actors for a taxi.

Use Case: We can say that use cases are the representation of the business process of the system. It is a model of a dialogue between an actor and the system. A Uses Case may be some functionality or the service that the system provides to an Actor. In other words, it may be the way; an actor uses the system or takes its services. For example, for a customer of Bank, Form filling, Deposit, Withdraw, Balance Query etc are Use Cases. Similarly, for some request-sender to a MOD system, "Calling the system", "Selecting song of interest", "Submitting the request" etc. are the use cases.

What's New?

This analysis of the system in the terms of an Actor & the Use cases was similar to that in the case of a normal Object Oriented Approach as given by Booch & Ram Baugh. In these traditional approaches, we used to prepare use-case-diagrams, class-diagrams, sequence-diagrams, collaboration-diagrams, package diagrams etc. for analysis & designing of the system. We used to keep them independent of each other.

In DFOM, we add a few more concepts & members in design. In DFOM approach, two new terms are introduced as follows:

Unified Actors: These may also be called Internal Actors of the system. These may be defined as the Actors inside the system. These are supposed to be a part of the system itself. It may be noted that the previously defined actors were some members of the environment outside the system. But the Internal actors are the part of the same system only. It may be observed that these actors generally are the sub-modules or functional parts of the system that use the other sub-modules of the system for some services. In this way they use the system but on the same time, they themselves are the part of the system.

For example: "Display" in a Personal Computer System, uses the graphic card for its function. Hence, in this case, "Display/Monitor" is a Unified Actor.

The reason of calling them Unified Actors is that they contain a use of the system as well as a functionality of the system in a unified manner. It means that they use the system in one way and also provide some of its functionality in other way.

Unified Use Cases: We may also call them Internal Use Cases. These can easily be found out as the use cases for the functional actors in the system i.e. the something that the Internal Actor does with the system or the way it uses the system or some of its part. It may be easily observed with some example of any system that the Internal-Uses Cases may be the functionality or the service provided to the system or some of its part.

Taking from the last example: "Display" is the Unified Actor of PC System and "Conversion of Signals" in a displayable form (compatible to the monitor) is the functionality of the graphic card. It is also the Unified-Use-Case for the "Display".

We can also conclude that "Display" is an Actor for Graphic Card but a Unified-Actor for the PC, "Getting converted compatible signals" is its use case for Graphic Card and same is the Unified-Use-Case for PC system and "Displaying" is its functionality.

Now with these four components "Actor, Unified Actor, Use Case and Unified Use Case", we prepare a Functional Use Case model representing interaction between them.

Here the conclusion comes that if we define a Functional Actor (FA) as something, which is either an actor or a unified-actor then Functional-Actors are the units using or providing the Functionalities/Services to the system. Similarly another term may be called as Functional Use Case (FUA) that may be defined as something that is either a Use Case or an Internal Use Case. Hence the Functional Use Cases are either the functionalities/services that the system gives to its users or the services coming out of its sub-modules that the system uses for its internal works, the outcome of whose integration come as the functionality of the system. Analyzing the system in terms of Functional-Actors and Functional-Use-Cases is termed as Functional-Uses-Case-Analysis (FUCA) of the system outcome of what comes as Functional Use Case Model (FUCM).

Move towards Design

In DFOM technique, major iteration takes place in the Functional-Use-Case-Analysis phase only. Later the approach is as per the Top-Down-Analysis strategy. Each Functional Actor (FA) is taken as a separate module and each FA-FUC Set is analyzed deep into itself individually in order to design the module to its maximum details.

To explain this FUCA clearly, let's analyze a Microprocessor Chip with the same approach:

For a Microprocessor, the external users or the actors may be the "Command Generator" and the "Reset" signal generator. It is because of the fact that these are the only two ways; a microprocessor may be excited for some function. As we start looking into the Microprocessor, in the first sight, on the basis of our first level knowledge, we can see that the units that may be the Functional Actors here, are

• Control Unit

• Memory

• Arithmetic Logic Unit

These units provide the functional services to the Microprocessor internally.

A Functional Use Case Model contains the Functional Actors & Functional Use Cases in it. It means that it has Actors, Internal Actors, Use Cases and the Internal-Use-Cases in it. It should be noted here that this model may differ from person to person for a given system problem statement according to their own understanding and experience in the domain. But this difference is generally very minute and the final analysis model moves around a common line of view. These iterative analysis outcomes bring a FUCA model of the system under development.

Now, this is the point from where we move towards the designing phase of the system. This designing is not the same as the traditional approach. This is the point where DFOM takes a steep and shape turn from the traditional approaches. We move forward in a dependent & biased manner. Here the DFOM technique introduces some dependencies in the Component-View (that includes Class Analysis, Objects and Associations) over the pre-developed Functional Use Case Model. DFOM says that, in order to get a Class-Design for the system, we can directly take our Unified Actors as Classes and the corresponding Functional Use Cases (Unified and normal Use Cases) may directly be taken as the functions (or Methods) associated with the objects of the respective classes. Before implementation or formalization of this Class-Design, we may cut the irrelevant classes out of the model if needed, based on our experience & knowledge of the system.

This leads major reduction in requirements of big iterations in later phases for having a consistent 4+1 view. The major iterations are covered in FUCA phase only. Also in presence of the introduced dependencies, the further designing and implementation procedure for the system becomes very straight and simple. It gives fast and accurate results.

Now, for moving forward, with an implementation focus, develop sequence diagrams for each of the functional use-case included in the class-model. It gives a frame for implementation of all the methods included in the classes. Here the idea is that "Sequence diagrams represent the common boundary of design & implementation phases". Hence they must be able to show clearly how that method works and also explain how this process will be implemented in the chosen programming language. The sequence diagrams may also be said to represent some algorithm for the process to work.

After this, we can group the classes into packages as per their characteristics. Finally the system may be implemented iteratively as per the requirements.

It should be mentioned here that the approach does not eliminates the concept of iterations but it is only an effort to reduce the number of iterations required to get a good design. Also, as this approach focuses mainly on the FUCA and FUCM, once you get a good FUCM, the result of the process will itself be a good design.

Why named D-FOM?

A question may arise why I have named this proposed approach "D-FOM". There is no big story beginf this. Here 'D' stands just for my initial. 'FOM' stands for Functional Object Modeling. In fact this approach is working with Functional-Objects. The concept of Functional-Object state that here we are trying to analyze the functionality of the system and then trying to develop an Object model on its base. Finally, these Functions and these Objects are combined to get what we call Functional-Objects. A combining frame for these concepts and their applications here is named FO-Model and the result is the approach, 'D-FOM'.

Analyzing the D-FOM approach

The above-discussed D-FOM approach can be taken as an alternative over the other available approaches for software system designing approaches for some advantages in some case or other. But on the same side, with these advantages, the approach also has some limitations and also some disadvantages for some cases. These advantages and limitations need to be understood before using the approach to solve a particular problem. The nature of the problem and its environment makes big differences in results of modeling technique.

Advantages:

1. Resource consumption & Consistency: if we do consistency checks in later phases as in the traditional approaches and at that stage, if the system design is found to be inconsistent,, we compulsorily need to iterate the complete design process again & again until a consistent design if made. These itrations make the design process much time & resource consuming. Alternatively, in D-FOM, we take consistency checks in earlier phase of "FUCA". By this,, we need not to iterate the complete process but only FUCA is required to be revised. It saves the resources & efforts with time.

2. Automation: the dependencies in different stages on D-FOM make it more automated approach. We need to analyze "FUCA" and dynamics of functions only and most of the other parts are designed with the prescribed dependencies and hence are mostly confined to a rigid result according to the input. We may develop a tool that may take "FUCA" as input and give the complete design-skeleton as output in an automated way.

3. Concentrated & Determined Error-Porn Area: As "FUCA" is having the major manual decisions and analysis involved in it, it comes out as a main error-porn area for any system design error. Other stages in D-FOM are almost automated & dependent on FUCA. Hence for any error in the system, major probability occurs in FUCA only. It makes the model fast in error detection in the design

4. Parallel designing of the system & simulator: for any hardware system, these days, companies try to build a simulator of the same for their future analysis & experiments with the similar hardware. With D-FOM, we can get a design that is equally suitable for OOPS as well as HDL for implementation. In this regards, you may view my another paper "Mapping of HDL & OOPS".

Flaws in approach:

We may not directly call it flaw but obvious, just like any other approach, this approach also may face some constraints & limitations.

• For its proper functioning, the model need a proper and well defined problem statement with clear statements for consistency criteria of the system. Here the proper problem statement may not exactly mean to a rigid problem statement but it talks about a problem statement that gives at least a viewable requirement list and understandability for requester's expectations.

• If we can't have a proper understanding of the system, probably this approach will not give efficient results. Rather we should go for some prototyping with least functionalities that make base for system understanding. In the later stages of prototyping, when we have a proper system concept and a good problem statement, we may easily switch to the same model. But for this, you should build the prototype with steps and dependencies of different analytic and design steps & diagrams as explained in the approach.

• A major limitation of the model is that it is made highly dependent on its use case model. It means that only a perfect "Functional-Use-Case-Model" (FUCM) can give you a good design. Any error left there in that step may lead to the same error in final design. To get a good design with this approach, hence, we need to give our major focus on its FUCM analysis so that almost no error is left there. The major iterations will occur there only to make it more & more refined and error-free.

Future work on D-FOM:

In future works, I will add some case studies supporting this model. These case studies make clear the use of D-FOM. I will try to describe different steps and stages in D-FOM with practical examples of system designs. These case studies will show how do we use the dependencies of different models (Analysis-Diagrams) in D-FOM with their corresponding dependencies.

1. D-FOM Analysis of a Microcontroller System

2. D-FOM Analysis of internal RAM in Microcontroller

3. D-FOM Analysis of ALU in Microcontroller

4. D-Fom Analysis of internal Decoder in intel 8031-MCU

5. A Design life cycle of Microcontroller using D-FOM

References

1. Who needs methodologies? By David A Banks
2. Why Modeling? By Martin Fowler (Editor-IEEE)
3. �The 4+1 architecture�:Visual Modeling with Rational Rose2000-by Terry Quatrani
4. Dynamic Modeling in forward and reverse engineering of Object Oriented Software systems- by Tarja Systa-University of Tampere.
5. 4+1 Architecture: http://www.architecture.external.hp.com/Download/ arch_template_vers13_withexamples.pdf
6. Object Oriented Analysis & designing -by James Rumbaugh, Michael Blaha, William Premerlani.
7. Object Oriented Analysis & designing -by Gardy Booch
8. Software Engineering-A Practical Approach: By Reger S. Pressmen
9. VHDL: Analysis & Designing -by Navabi.