D-FOM: Yet Another Object Oriented Model

• Download PDF document containing complete details of D-FOM approach and a case study to build confidence in this approach - 175 Kb

Introduction

The concept of Object Oriented Analysis and Designing is not new in Software-Designing. Grady Booch, Rum Baugh, Jackabson and many more researchers have given great concepts in this field to help system designers. They proposed good approaches towards class identification and their modeling in terms of packages and relations. Although a beginner of object oriented approach, has enough number of case studies and examples of already developed systems to study and understand concepts of these approaches, yet they seem to be facing a lot of confusions in identifying classes and attributes with relationships and associations between them.

Also, these traditional OO approaches don�t come forward much efficiently for designing and implementation of hardware modules or systems. In today�s scenario, we used to be interested in a simulator-software of a hardware system to understand and feel the working on the actual system even if we don�t have a real one. These simulators have high importance in training organizations where a large number of candidates can be trained with the help of simulators because of their low space requirements and maintenance costs. Hence, the designers may also be interested in getting a simulator of the system with least efforts.

Involvement of automation in designing process may also be another objective of researchers of the field and a good attraction for designing teams. Error reduction and quick scanning of the design for some probable error in it is another high scale interest of the designers.

In these papers, I have tried to find and solve out some of those confusions and problems of common interests by proposing another acceptable approach for Object Oriented Analysis and implementation of any given system specifications. But to understand this new approach, one needs to be familiar with traditional Object Oriented Approaches suggested by Grady Booch, Rum Baugh and Jackabson.

Review of The Traditional Object Oriented Approach

In the traditional object oriented approaches, we have been trying to describe the system in terms of discrete objects having their own identities, states and behaviors. These approaches have been suggesting about analyzing the system not in terms of a set of functions but the Objects, Classes and Associations between them. These approaches have been suggesting that software architecture and designing is not a one-dimensional thing but is made up of concurrent multiple views. The 4+1 architecture [1] describes the system in five concurrent views in this regard. Each view is an abstraction with a definite focus area. The Use-Case view focuses on �analysis of usability� and �understandability� of the system. The Logical view focuses on �Functionality� of the system. Implementation view talks about �Software management� of the system. The Process view describes �performance, scalability and throughput� of the design, and the Deployment view talks abstraction for system topology, delivery, installation, and communication involved in the system [1]. All these views are prepared independent from each other.

Common Complexities in Traditional OO Approach

There are some soft points in these approaches that frequently induce errors in the prepared designs and hence make system-designing a complex task. It is not that these complexities are unavoidable or irremediable or something like that. Researches had been carried out for years to get the solutions for them. But understanding these complexities is of importance while proposing some new designing approach, and all these complexities must be discouraged in the new approach. 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 implementing 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. This tradition may also create confusion with a huge list of nouns.
2. For an inexperienced 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. For a new team member, who joined the project mid way, it is not easy to get the flow of the process and understand the complete design quickly as was analyzed by previous experts in iterations. It may take a long time, and hence joining of some team members mid way the project may delay the project from its due dates.
4. As all the views are running under development in parallel (4+1 architecture), 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. [1]
5. There is no direct relation or concept in these approaches for designing hardware and their implementation in HDL.

Determinant Functional-Object Modeling (DFOM)-The New Approach

For all above discussed complexities, we need to find out another approach, which must not leave the grounds of Objects and Object-Oriented-Designs but should give some reduction in number of iterations in the complete process and hence reduce the efforts and resources required to spend for a good design.

It is commonly found that when somebody looks into the system, it tries to directly look into the functionality of the system. Also, when some customer asks for some system, it 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 required for an applied 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 and environment of the system, we can define who are the users of the system and 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 (Actors) and their interaction with the system (Use Case) that shows 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.

The proposal is that, with some dependencies, this Use Case Analysis can directly 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, this 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 and 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 Object Oriented analysis of a system with this approach is to find out the actors and Use Cases for them in the system. For this, we need to be clear to the core of the concept of Actor and Use Case.

Actor: A user or any external system 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 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 representations of the business process of the system [2]. It is a model of a dialogue between an actor and the system. A Use-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?

Above discussed analysis of the system in terms of Actors and the Use Cases is similar to the case of traditional Object Oriented Approaches given by Booch and Ram Baugh. In these traditional approaches, we used to prepare Use-Case-diagrams, class-diagrams, sequence-diagrams, collaboration-diagrams and package diagrams for analysis and design of the system. We used to prepare them in independent views of the model as described earlier (4+1 architecture) [1].

In DFOM, I want to introduce a couple of new concepts and members in design to make the process simpler. Here, two new terms are introduced as follows:

1. Unified Actors: These may also be called Internal Actors of the system. These may be defined as the Actors inside the system. It means that a unified actor is something that uses the system in some form but it itself is present inside the system. It takes the services from other parts of the system as well as itself is a part of the system. It triggers activities in the system whenever asked for some service for it. 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 later that unified 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 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 ways. In this way, they are unifying the concept of Actors and Functionality, so are called unified actors.

2. Unified Use Cases: Just like Unified Actors, these may also be called Internal Use Cases. These can easily be found out as the Use-Cases for the unified actors in the system, i.e. something that an Internal Actor does with the system or the way it uses the system or some of its part. A unified use case of some unified actors may be the activity it may trigger in the system. It may be easily observed with some example of any system that the Internal-Use Cases may be the functionalities or the services provided to the system or some of its parts. 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� (FUCM) 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 (FUC) 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 comes as the functionality of the system. Analyzing the system in terms of Functional-Actors and Functional-Use-Cases is termed as Functional-Use-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 externally for some function. As we start looking into the Microprocessor, in the first sight, on the basis of our first level experience and knowledge, we can see that the units that may be the Unified Actors here are:

1. Control Unit
2. Memory
3. Decoder
4. Arithmetic Logic Unit

These units provide the functional services to the Microprocessor internally.

A Functional Use Case Model contains the Functional Actors and 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 Functional-Use-Case Model (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 sharp turn from the traditional approaches. We move forward in a dependent and biased manner. Here, the DFOM technique introduces some dependencies in the Implementation-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 only if needed, based on our experience and knowledge of the system.

This leads major reduction in long iterations in later phases for having a consistent 4+1 view. The major iterations are covered in Functional Use Case Analysis (FUCA) phase only. Also, in presence of the introduced dependencies, the further designing and implementation procedure for the system becomes very straight and simple and hence may also be made automated with development of some Automated-Tool. 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 and 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 is good to mention here that the approach does not eliminate the concept of iterations in the process but it serves just as 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 here why I named this proposed approach "D-FOM". There is no big story behind this. 'D-FOM' stands for Determinant Functional Object Modeling. In fact, this approach is working with Functional-Objects. The concept of Functional-Object states 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 Functional Object (FO)-Model. The approach is working neither purely on functions nor with objects, but is wondering somewhere in between the two concepts for a solution. As we saw, the approach has made the process quite rigid and determinant after Functional Use Case Analysis (FUCA), and for next steps of the process, we move in a quite rigid framed and determinant manner. Here, the approach orients around neither Objects nor functions but the �Functional Objects� and that too in a determinant manner, and the result is the approach Determinant Functional Object Modeling (D-FOM).

Evaluating the approach

All approaches have their own advantages as well as limitations (if not disadvantages). This makes none of the approaches as global that can be adopted without discussion, for any type of given project. We need to analyze the system on first level on some ad-hoc base, and then according to the nature of the project and experiences in the field, we opt for the available approaches. The same is also in the case of Determinant Functional Object Modeling (DFOM). Here also, we have limitations associated with its positive features. The technique gives its best results when applied to an appropriate project only. This is easy to understand just like if you need a project in a very short time period and also you have a team with sufficient experiences in the subject, yet if you have opted for �Prototyping� model of SDLC, quite natural that you may not receive the expected profits. Only a RAD model may make the things better and increase the profits. Similar things happen with designing techniques too. So we need a proper analysis before we decide for the SDLC model and the Analysis and Design approaches. Let�s now try to compare Determinant Functional Modeling approach (DFOM) with some other designing approaches with Object Orientation in their base.

Analyzing D-FOM approach

As we have discussed before, a number of approaches have been proposed and accepted for system analysis and designing with a base of orientation around the object concept. Yet researches are going forward on different aspects for making the System Analysis and Designing (SAD) process easier and smoother. These techniques may avoid the silly mistakes you often do while analyzing a system and during its development. But they can�t over-rule the probabilities of errors in the process at all. The approaches have their own advantages as well as limitations. This makes none of the approaches as global that can be adopted without discussion, for any type of given project. We need to analyze the system on first level on some ad-hoc base, and then according to the nature of the project and experiences in the field, we opt for the available approaches. The same is also the case of Determinant Functional Object Modeling (D-FOM) too. Here also, we have limitations associated with its positive features. The technique gives its best results when applied to an appropriate project only. This is easy to understand just like - if you need a project in a very short time period and also you have a team with sufficient experiences in the subject, yet if you have opted for �Prototyping� model of SDLC, quite natural that you may not receive the expected profits. Only a RAD model may make the things better and increase the profits. The similar things happen with designing techniques too. So, we need a proper analysis before we decide for the System Development Life Cycle (SDLC) model and Analysis and Designing approaches. Let�s now try to compare D-FOM design technique with some other traditional approaches with Object Orientation base.

The discussed approach �DFOM� can be taken as an alternative over the other available 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 the results of modeling technique.

Advantages:

1. Resource consumption and Consistency: If we do consistency checks in later phases (like in 4+1 architecture), and at that stage, if the system design is found to be inconsistent, we compulsorily need to iterate the complete design process again and again until a consistent design is made. Alternatively, in DFOM, we take consistency checks in earlier phase of "FUCA". By this, we need not iterate the complete process but only FUCA is required to be revised. It saves the resources and efforts with time.
2. Automation: The dependencies in different stages on DFOM make it a 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.
3. Concentrated and Determined Error-Prone Area: As "FUCA" is having the major manual decisions, it comes out as a main error-prone area for any system design. Other stages in DFOM are almost automated and 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 and simulators: For any hardware system, these days, companies try to build a simulator of the same for their future analysis and experiments with similar hardware. With DFOM, we can get a design that is equally suitable for OOPS as well as HDL for implementation. In this regards, I have discussed Mapping HDL to OOPS in another paper of mine.

Disadvantages

1. For its proper functioning, the model needs a proper and well-defined problem statement with clear statements for consistency criteria of the system. If we can't have a proper understanding of the system, probably this approach will not give efficient results. For the case where it is not possible to give a good problem statement because of lack of knowledge of the system and related fields, rather we should go for some prototyping with least functionalities that make base for system-understanding. In the later stages of prototype enhancement, when we have a proper system concept and a good problem statement, we may easily switch to DFOM. But for this, you should build the prototype with steps and dependencies of different analytic and design steps and diagrams as explained in the approach.
2. Another major limitation of the model is that it is made highly dependent on its functional 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 this step may lead to the same error in final design. It means the errors of FUCA are propagated to the design of the system unsolved. To get a good design with this approach, hence, we need to give our major focus on its FUCM preparation so that almost no error is left there. The major iterations will occur there only to make it more and more refined and error-free.

How the approach works (a practical experience: reference of HRD Department)

In the traditional OO approaches, we used to identify the objects and then assign the functionalities to them. On the other hand, in the new approach, we try to do it reverse. DFOM works as per the Human Resource Development department of some organization.

Suppose if you are a Project-Manager in a software development organization and have been assigned for a project in hand. Now, you look into the project and with your experience, you try to prepare a list of the skills required in the men-power you will be having for the problem in hand. Then you give this �Skills Requirement� to the HR department of the company. The HR department then looks for the appropriate workers within the organization, and if not available, new men-power is recruited with the required skills.

Here, what exactly we are doing is, we have first analyzed the functionality of the system and then created objects (men power) for these functions to be done. Now, how these functions are to be assigned to different objects? For this, again we take the example of HR department.

Suppose a team �T1� is recruited on the basis of their Logical and Analytical skills. And another team �T2� is recruited on the basis of their programming skills in language C++, then all the analysis, designing and algorithm writing functions can be assigned to team T1, and the work of implementation of these algorithms in C++ will be assigned to team T2.

In the same way, D-FOM approach also creates objects according to groups after grouping the similar functions as per requirements.

Rehash:

Components of D-FOM:

1. Actor: Something that uses the system.
2. Use Case: Tells how the system is used.
3. Unified Actor: Actor inside the system.
4. Unified Use Case: Use Case for unified Actor.
5. Functional Actor: An actor or unified actor.
6. Functional Use Case: A Use Case or Unified Use Case.

Steps in D-FOM:

1. First step towards analysis:
   1. Find Actors
   2. Find Use Cases
   3. Find Unified Actors
   4. Find Unified Use Cases
   5. FUCA
   6. Prepare FUCM
   7. Iterate FUCM
2. Where to end analysis: A rough idea for beginners
   • When you get no further module inside.
   • Experience may make an earlier end too.
3. Moving forward towards design: Implementation View (Involve Dependencies)
   • One level of tree at a time and integrate for one level up on the path (Bottom-Up)
   • Unified Actors->Class
   • Functional Use Case->Method
4. Iterate and get generalization
5. Get Packages for similar classes
6. Sequence Analysis and Sequence Diagrams
   • Bottom-Up Strategy: Sequence analysis for leaves (statements)->Sequence analysis of one level up (functions)->Sequence analysis for system (Process)
7. Implementation:
   1. Code for leaf-sequence diagram and make functions
   2. Integrate functions to get one level up in the tree
   3. Integrate to get the system-code
8. Deployment Analysis according to the problem in hand as per traditional approach (not really tough because of new systems, networking technologies, and database concepts).

Summarized list of Advantages:

1. Dependent Class identification reduces confusions.
2. New joining member is expected to start working quickly because it needs to study and understand FUCM only.
3. Concentrated error prone area.
4. Approach gives a design equally suitable to be implemented in OOPL and HDL. So is applicable to HDL also.
5. Parallel designing of H/W and its simulator made possible.
6. Automation made possible.
7. Reduced Effort and Resource consumption is expected.

Summarized list of limitations:

1. Need a proper FUCA. FUCM needs to be made with in depth knowledge of the system.
2. Over dependent on FUCM
3. Is not globally acceptable but depends on nature of problem. May not be good for highly complex architectures. (Complexity means to interdependencies of modules, which may create huge integration problems. But the same is the case in traditional approaches too, so nothing exceptional here.)
4. Experience in the field of the project gives better results.

Future Works:

D-FOM opens new fields in system designing by introducing new concepts in process. It is expected to reduce the efforts and resource consumption in SDLC. The demand of time is to explore the ways to optimize the code created by the approach according to an opted programming language because all languages have their own specific structure of code and they can be optimized in different ways. For HDL, we generally use an automated synthesizer. But for Object Oriented Programming Languages (OOPL), we need other means. Another corner where some more light is required is what types of projects are much suitable to be worked on with D-FOM preferred over other approaches. For this, we need to prepare some more case studies with which we may do some comparative studies of different approaches with D-FOM.

Foregoing Works:

In future works, I will add some case studies that support this model. These case studies will make clear the use and concept of application of Determinant Functional Object Modeling (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 we use the dependencies of different models (Analysis-Diagrams) in D-FOM with their corresponding dependencies.

• D-FOM Analysis of a Microcontroller System (MCU).
• D-FOM Analysis of components in MCU viz. internal Decoder, RAM, ROM, ALU, USART and Control Unit.
• A design life cycle of Microcontroller using D-FOM.
• Development of a tool based on D-FOM and concepts of mapping of HDL and OOPS for converting OOPL code to HDL and vise versa.

Reference:

1. Terry Quatrani, Visual Modeling with Rational Rose 2000 and UML, Addison Wesley.
2. James Rumbaugh, Object Oriented Analysis & Design, Prentice Hall, 2002.
3. Martin Fowler, What�s a Model for?
4. Martin Fowler, Who needs an Architect? IEEE Software July/August 2003.
5. Michael A. Ogush, Derek Coleman, Dorothea Beringer, A Template for Documenting Software and Firmware Architectures (Version 1.3, 15-Mar-00).
6. Rational Software, Unified Modeling Language, version 1.1, 1998.