Export (0) Print
Expand All

Applying BSAL Concepts to Software Factories

Behzad Karim

December 2008

Applies to:
   Behavioral Software
   Software Factories

Summary: Behavioral Software Architecture Language (BSAL) is a stream of thought regarding the effectiveness and productiveness of software development that capitalizes on the behavioral aspects of software. This article briefly explains one possible application of behavioral software analysis and design, to the domain of software factories. [1] (14 printed pages)


Great Software Products
Naming Conventions in BSAL
Behavior Event Model
Input- and Output-Producing Classes and Others
Documenting System Behavior (BDDoc)


Software architects are responsible for clear and reliable designs, as well as conveying and enforcing their vision and logic to project stakeholders and actual implementation. The job of a software architect has become more challenging, as the level of complexity in IT solutions and services has risen. While the emergence of a commoditized approach to software development has increased the expectations in software projects, resulting in tighter schedules and demands for more features, a definite need to manage standards and architecture as the software evolves is eminent.

Another striking fact is that software lifetime has become very short. As the level of complexity of software products has risen, the life span of these systems has decreased tremendously. We often hear that a new version of a product has been coded from the ground up; where companies often use these kinds of announcement as a marketing tool, I often conclude that the previous versions were not built to compensate for change and further evolution.

It is evident that businesses must change and adapt more quickly to the dynamic market environments, and that they need digital solutions to implement and enforce these changes. It is no longer possible to apply changes to the business in a robust manner without intelligent software solutions that guide business decisions and processes, which in turn has brought up the need to have more frequent releases of software products. These factors have changed the software industry and architecture, and have placed the software architect in the glowing spotlight of both fame and suspicion. The software architect now has to build systems that are more complex; are developed faster (get to the market sooner); are easier to use and adjust, and are more reliable; and have frequent upgrades, updates, and patches.

In my previous article, I elaborated on the fact that the most differentiating factor in software design, besides implementing a clear “aim” and “purpose,” is the behavioral aspects of it. The behavioral aspects of a system ultimately are derived from the aims and purposes of the system, and they express the specific distinguishing quality of software.

If architects are required to design systems that provide a systematic set of behaviors reliably, the aim and purpose of the system have to be envisioned clearly and flawlessly by analysts, architects, designers, and developers.

In software projects that are based on the classical project-management methodologies, software architecture is not tackled until business analysis is nearly complete and signed-off on. My experience is that an earlier translation of business models into architectural design is actually more helpful in defining and shaping the business cases themselves—not to mention the benefits of giving architects a chance to get involved earlier and understand better the business logic and requirements. Hence, I would prefer the earliest possible transition of business models into architecture definitions. Involving the architect in the business-modeling and model-refinement phases is very crucial to the success of any project. It is important to promote the methodology of business analysis and architectural design as parallel activities, instead of the traditional counterpart of finishing business analysis, and then going into design.

The first step in understanding a business system is to conceptualize its aims and objectives. After initial aims and objectives have been grasped and the primary business models have been designed and agreed upon, work can be initiated on preliminary system requirements and the complementary architectural design. In fact, it would be much better to start defining the system architecture right after the first tour of business modeling has been completed—before business has solidified its process definitions—so that architectural design could continue forward as a parallel activity, alongside business modeling and business-process refinement.

This might sound a bit odd; but, in a world in which business models no longer can come to life without their complementary digital systems, it is inevitable. We are at a turning point in the software industry, at which modeling and shaping businesses (or even politics for that matter) is no longer possible without the proper IT infrastructure and aligned software systems to support and promote them. These facts bring a greater challenge, if not a burden, to the IT teams—requiring them to build truly robust solutions on tighter schedules.

The good news is that there is much that we can do today to confront these challenges. There is a lot of room for improvement. In this article, I will try to develop the idea of generic architectural models and how they are linked to the behavioral aspects of software products.

Great Software Products

Great software products are based upon great ideas. Although it could be said that great software is one that addresses a pressing need for end users, I would argue that, in today’s market, great software should go farther than addressing the needs; it should take the users at least one step beyond their expectations.

Where Do Great Ideas Come From?

Obviously, the people who drive businesses have the greatest role in creating new ideas and setting the general directions for upcoming products. Business departments are the driving power behind new ideas, while software architects and development teams are the ones that ensure that those ideas truly come to life.

The success of a software product is linked directly to its ability to deliver business ideas and project aims with all honesty—not to mention reliability and the capacity to expand and change in the future. Upon these factors, software architects play a decisive and dominating role: They have the greatest influence in delivering a product that is fit for use, as outlined in the original business requirements. If we accept this as fact, we can agree easily that every effort to streamline and simplify the job of the architect eventually would help to build a better product. Otherwise, by raising the level of abstraction, we can facilitate the software architect to put more effort in implementation of the business objectives in accordance with technical requirements. [1]

Critical issues of software development today include:

  • The gap between the business requirements and the finished IT solution. Although a certain amount of gap might be acceptable, excessive amounts often have been one of the major causes of project failure.
  • The software-production process is expensive. Experienced and disciplined software developers are hard to find. Both discipline and creativity are required in this profession, and these traits usually do not come plenty in one package.
  • The software-production process is very sensitive. The slightest miscalculation could send the project off into the outer rim.
  • The final product has a relatively short life span.
  • The product can degenerate quickly as enhancements and/or revisions (additions) are made to it. Hence, the common decision to rewrite the project completely.

As architects and developers of software products, we must:

  • Close the gap (towards zero) between business analysis and product development.
  • Focus on defining the behavior of our product by working closely with the business team. In order to bring in the business knowledge clearly, a Behavior Definition Document can be developed and signed-off on by all project stakeholders.
  • Make every effort to shorten the development and test phases of the product.
  • Facilitate tools for high-level design in order to produce more with less effort.
  • In terms of architecture, strive for the simplest design that will get the job done and work in production. By “work in production,” I mean to take into account the context of the solution and the load that is impaired upon, when it is rolled out.
  • Monitor the development process. Identify our bottlenecks, deficiencies, and weak steps, and try to resolve, enhance, and streamline these points in the process.
  • Enhance communication and understanding inside of the development team. Ensure a common understanding of the Behavior Definition Document. Link each item in this document with systems and classes in the proposed design.
  • Design and use a generic core architecture model for software behavior to use as a starting point for every architecture work, and gradually build additional modules around that core design. Always use the core design for behavior architecture definition, but be keen to modify it as knowledge ripens.
Generic Design for Implementation of Behavior

Can we create a generic design for implementation of behavioral aspects in the solution? How can we devote more time to implementation of business objectives and requirements?

Project teams need two-way channels of communication between business drivers of software products and technical teams. This has to be accomplished easily and effectively, and the results of this communication must be projected into design easily as code adjustments.

Reusable Business Models

In the software-development business, we are quite familiar with the concept of reusable object models. Although we could use a better utilization of this concept in our production, the basic concept is very well-defined and well-supported with different tools, techniques, notations, and even code. We already possess the necessary machinery to produce reusable object models. However, would it be possible to extend the idea of reusable object models to businesses? Can we build upon the idea of reusable business models? Can businesses be modeled in a reusable way?

My experience tells that, in fact, business models can be reusable. The catch, however, is to model businesses with a systematic approach, and this requires a significant amount of experience in the field of process management (both human-based and systems-based).

Systems Approach to Modeling Business

As I have stated, this article is an effort to shape a generic structure for defining software behavior. The ideas that are presented here are based loosely upon the concept of a systematic approach to business.

The systematic approach to business is a theory that states that, in order to understand and analyze the existence or operation of a business entity, the entity must be perceived as a system. However, what is a system?

Defining a System

A system is composed of one or more interdependent parts that function as a whole for a certain purpose. Most systems contain nested systems; that is, there might be one or more subsystems within a system. Similarly, many systems are subsystems of even larger systems. Systems can and usually do interact with other systems. These interactions have two distinct components: input and output. The system is a living organism that receives input from the environment and other systems, and produces certain output, too.

The nucleus of a system is where all of the specific processing takes place. The system is affected directly or indirectly by the input from the environment and produces some kind of output in relation to (although not necessarily) this input, as well as its own behavior patterns. The input to a system might be produced by the environment or other systems (sometimes called ecosystems). Naturally, the output of one system might serve as input for other systems. [2]

The system must be viewed as a whole and modified only through applying changes to its parts. Before modifications can be made to the system, a thorough knowledge of each part and the interrelationships among the parts must be available. After changes are made to a system, the relationship and interaction of the system with the environment can evolve. This, in turn, requires a thorough understanding of the relationship between the system and the environment.

In order to analyze and understand a system, we must:

  • Define the boundaries and clearly distinguish the system and the encompassing environment. In living organisms, this would be the skin.
  • Understand the internal components or the subsystems of the system. In living organisms, this would be any one of the internal systems—for example, the cardiovascular system.
  • Understand the inputs that the system can receive from the outside environment or other systems, and the effect that these inputs can bear on the system. For living organisms, this could be the temperature, humidity, interaction with other beings, and many more.
  • Understand the outputs of the system, how and why they are produced, and what the destinations of these outputs are.
  • Understand the changes and states that the system undergoes as the result of input, passage of time, output generation, and evolution.
Generic Architecture Definition for Systems

In the remainder of this article, I will try to convey the ideas for a generic architecture definition by using an example design.

The top-most structural component for a software system is the main “system” object.

The main system can be composed of one or more subsystems. The subsystem objects can be derived from the “system” object itself. Generally speaking, there is not the slightest difference between a system and a subsystem.

In order to understand and interpret a generic architecture easily, a logical and simple naming convention is needed.

Naming Conventions in BSAL

In order to identify effectively the nature and/or purpose of each class in our design, we can make use of a simple and intuitive naming convention.

I will try to explain a possible naming convention that you can use as a starting point for a behavioral architectural design.

System and Subsystem Classes

As discussed earlier, subsystems generally are systems inside of other systems. I will not go through the actual detailed design in this article. The system class can be based on an interface and/or an abstract class that would define the minimum set of required fields and methods. The system classes can be identified easily by having a _sys extension added to the end of the class name. As an example, if our system-class name is being, we could define the top-most class name in our design as being_sys (in this article, I deliberately use the term “being” instead of the term “entity”). This allows easy identification of the top-most system class.

The reason that I did not put the _sys extension before the name is that the name of the class itself is more important in terms of defining the system; and, besides, it resembles the natural language usage. In English, we would say “the bus system” or “the accounting system.” Saying “system accounting” or “system bus” would have a totally different meaning.

System classes may contain a minimum set of required attributes/fields, such as:

  • System ID—A unique ID for the system
  • Company ID—The ID of the company that is building the system

The system class contains the public attributes and methods of the system. This class defines all of the inputs to the system. Otherwise, the system object will be the only object that is approached by other systems from outside of the system boundaries. Internally, however, system class passes all behavior-related incoming requests to the behavior class.

Behavior Class

Each system object will have also at least one member object that would encapsulate the behavior of the class: Yes, I am separating the behavior of a system in a special class. The behavior object ideally is a private member, responsible for defining the behavior of the system and “initiating” all of the processing that runs inside the system. Otherwise, this object contains the code that produces the dynamic behavior of the system. Likewise, if some kind of output is supposed to be produced from the system, the behavior class must initiate such behavior.

This does not mean that all of this processing or interaction actually is carried out inside of this object. It would mean merely that the behavior object is the first place in which we would look to begin to understand the what, when, and how of a given behavior in our system. A good design would be to create supporting classes for separate categories of processing. However, the starting and returning points of analyzing any behavior in a given system must be the main behavior class.

The behavior classes can be identified by having a _bhvr extension added to the end of the class name. This allows us to identify easily the behavior class inside of the solution. So, for our being class, the behavior class can be named being_bhvr. Note that the name to the left of the underscore is the name of the system class.

The behavior object would best be defined as a private object inside of the system class and accessed only through the methods of the system object.

The behavior class itself can be derived from the system class and will have one additional attribute:

  • Current Behavior State—Attribute that determines the current mode of class behavior. It can be used to tone all system behavior.

A behavior-state list can be implemented as an enumeration list of all possible states through which the behavior of the system can go.

The current behavior-state attribute can be used to reflect the current stage of system behavior. Practically any kind of event that could have an effect on the system could change the behavior state of the class. When the system object is initialized, the behavior object instance is created and set to the initial behavior state. As the system object lives through different situations, the behavior object sets the state according to behavior patterns that are needed.

Although the behavior states and the conditions that might cause a change to the state in a behavior class are unique to each system, the basic event model of a behavior change can be standard.

Behavior Event Model

What I mean by behavior event model is the set of events that always take effect when a behavior pattern is about to happen. This event model consists of one or more pre-conditions and checks, which might or might not result in some actions and/or output to other systems; the behavior pattern itself; and some post-conditions and checks that might or might not result in some actions and/or output to other systems.

The “pre” and “post” conditionals have a very special role in this model, and they tend to partialize the complexity of behavior. It would be good practice to place “pre-behavior,” the behavior code itself, and the “post-behavior” code in separate methods. In the “pre-behavior” method, the following conditions can be checked:

  • Prerequisites for the reference behavior of the system—If the conditions do not return the desired results, the behavior execution can be terminated totally; otherwise, a behavior can happen only if certain conditions hold true.
  • Encompassing environment—That is, other systems and/or attributes of the reference system that could be influenced by invocation of the behavior can be notified before the behavior is carried out. As a result, any other parallel or future sequential activity can be triggered or terminated. Likewise, other systems can be contacted, activated, or shut down.

The behavior pattern itself is implemented in a separate method and called only after the pre-conditions have been satisfied.

Finally, the “post-conditions” and related actions can be placed in a separate method. The “post-behavior” method is invoked after the behavior method has completed its execution. In this method, the following can be checked:

  • Encompassing environment—That is, other systems and/or attributes of the reference system that could be influenced by invocation of the behavior can be notified before the behavior is carried out. As a result, any other parallel or future sequential activity can be triggered or terminated. Likewise, other systems can be contacted, activated, or shut down. This is where the “after-glow” of the behavior pattern on the environment or other systems is implemented.

As a simple example, let us assume that we are developing an Inventory System, and that we are working particularly on the behavior of the system, when an inventory item deletion is requested. I realize that the behavior event model might be overkill for such a task, but bear with me; by using this simple example, I will be able to better concentrate on conveying the ideas that I want to explain, instead of on the example itself.

According to the behavior event model, before actually deleting an item from the inventory, the sequence of processing would be to invoke the delete “pre-behavior” method. This method would be responsible for performing all of the pre-conditional checks. The “pre-behavior” method would determine if the delete behavior is going to be carried out or not. For the sake of keeping the example simple, the following rules will suffice:

  • Rule 1: If the quantity on hand for an item is anything but zero, the item cannot be deleted. Only items with zero quantity can be deleted.
  • Rule 2: If there are any existing transactions (invoices, orders, and so on) for an item, the item cannot be deleted (whether or not the quantity on hand is zero).
  • Rule 3: When an item is going to be deleted, any further purchase transaction should be forbidden. However, sales transactions can continue until the quantity of the item is down to zero.
  • Rule 4: When an item is going to be deleted, any further orders for such an item should be forbidden; however, current pending orders should be allowed to complete.
  • Rule 5: Item definitions should remain in the database for the future reference of transactions; however, if no transaction exists for an item and the quantity on hand is zero, item definition can be deleted physically.

Let us analyze these rules thoroughly and add precautionary measures to our business requirements:

i. If the quantity on hand is greater than zero, we obviously cannot delete the item (Rule 1). We must allow sales transactions for this item, until the quantity on hand becomes zero (Rule 3). In this case, we can mark this inventory item as “obsolete.” An obsolete item cannot have any new purchases; however, it can have sales transactions. In this way, the inventory system would be able only to carry out sales transactions on the item; when the quantity eventually becomes zero, the item can be marked as “deleted.” Note that we cannot delete physically such an item, because it would have one or more transactions. According to Rule 2, it is forbidden to delete such an item.

ii. If the quantity on hand is less than zero, it would mean that there is a pending order on this item. We have to wait until the quantity becomes equal to zero (Rule 1) and all of the orders on the item are fulfilled (Rule 4) before we delete it. We can mark this item as “to-be-deleted.” When an item is marked as “to-be-deleted,” it can have purchase transactions, but it cannot receive further orders.

iii. If the quantity on hand is zero, we can delete the item physically after checking the following conditions:

  1. There are no previous records of any transactions for the item, so that we can “physically delete” it. Note that this is the only case in which the item actually can be deleted.
  2.  There are records of one or more transactions for the item, so that we set the item attribute to “deleted.” An item that is marked as “deleted” will not be allowed to have any further transactions. We must keep the item definition for reference (Rule 5).

Please note that there are four different outcome settings for any given item, when a delete request is received:

  1. Marking the item as “obsolete”
  2. Marking the item as “to-be-deleted”
  3. Marking the item as “deleted”
  4. Deleting the item physically

All of the preceding conditions can be checked in the delete pre_behavior method, and only the fourth case—that is, deleting the item physically—is carried out in the delete behavior method.

After the delete behavior method has completed execution, the post_behavior method would be called to provide output regarding the behavior of the system to other systems and/or the environment. In the case of our example, we might have to send a message to each of our suppliers in order to signify that we will not order any further quantities of this item in cases 1, 3, and 4. If the outcome of the behavior is “to-be-deleted,” no action is required with regard to suppliers.

Naming Convention for Behavior Event Model

Many different naming conventions can be used, as long as the rules are simple and straightforward and they fulfill the purpose. The aim of any naming convention is to explain easily—or rather reveal intuitively—the purpose of the named object.

One possible and logical naming convention is presented here. The behavior methods can best be named by using “simple present” verbs. In our example, if the name of our system is “inventory,” the behavior class that is related to this system can be named inventory_bhvr, and the name of the delete behavior method can be simply delete. The name of the “pre” and “post” behavior methods can be pre_delete and post_delete.

As a useful exercise for the behavior event model, the reader might explore and contemplate the following case:

A robot is to be designed that is capable of moving in a two-dimensional plane. As the robot moves about randomly in the surroundings, it will collect temperature readings from the environment. The objective of the robot is to mark the coordinates with exceedingly low or high temperatures, and to save the results in its memory. The robot can cope with any temperature, as long as it is between a certain range of degrees. When the temperature reading for a spot is above or below a certain level, the robot simply records the coordinates and the temperature reading, and randomly changes direction to move to a new area. Note that the robot should not move over previously recorded coordinates.

Input- and Output-Producing Classes and Others

The input-producing and output-producing and other special-purpose classes can be created under the hierarchy of the main behavior class. This would reinforce the position of the behavior class as the initial point of reference for analyzing the dynamic behavior of the system, as well as keep the classes grouped according to their general characters.

By definition, in digital systems, business logic is a set of related actions that are carried out according to certain rules and exceptions. In business applications, there is always a set of standard business-logic rules that are utilized throughout and across systems and business processes. In fact, the toughest part of a system-analysis task is to identify these common sets of business rules and define them clearly, so that they can be understood thoroughly by the project team and implemented correctly. In a sense, it would be safe to say that business rules define the behavior of the system.

As a simple example, we can look at a purchase system, which is an integral part of any Enterprise Resource Planning (ERP) system. When a purchase order that contains inventory items is entered into the system, a number of logical transactions take place for each inventory item.

A minimum set of rules might be the following:

  1. Insert a record for the purchased inventory item.
  2. Accordingly increase the quantity field of the master record for the inventory item.
  3. Calculate the average price, sales price, and best-offer price for the inventory item, according to company policies, and update the related fields in the master record.

These three transactions must be atomic, and they must be carried out any time that a new inventory item is bought. In our design, this behavior must be implemented in a special method with standard transaction logic and referenced through the behavior class of the system.

Likewise, input- and output-producing classes for a system can be encapsulated in separate classes and instantiated, as needed, inside of a behavior class or a business process.

Naming Convention for Input and Output Classes

For input-producing and output-producing classes, we can use the name of the system, followed by an identifier for the output destination (or the input source) and then by either _out or _in. The output-destination or input-source identifiers could be just names that resemble those systems or objects.

As an example, if we are going to produce output to a database from our system, we might create a class that is named being_db_out or being_db_in and encapsulate all database-destined output inside of it. Note that this is not the low-level database-interaction class that commonly is used in the n-tier architecture. This class should encapsulate only the output-generating code from the system at hand. It is good design practice to encapsulate the actual database interaction in a common data-tier class.

Simple Design for “being” System and Delete Behavior


Figure 1. Static structure representation for BSAL

Sample Code for “being” System and Delete Behavior
namespace being
    public enum being_type {notset, person, role, group, department, company, robot};

    public class being_sys : sys
        private string beingId;
        private string beingName;
        private being_type beingType;
        private being_bhvr bhvrObj = new being_bhvr();

        public being_sys()
            beingId = "notset";
            beingName = "notset";
            beingType = being_type.notset;

        public being_sys(string newBeingId, string newBeingName, being_type newBeingType)
            beingId = newBeingId;
            beingName = newBeingName;
            beingType = newBeingType;

        // “being” object deletion requested here
        public gen_parameters.states deleteBeing(string delBeingId)
            return bhvrObj.delete(delBeingId);

namespace being
    // This is the main behavior class that would be the initial point of reference
    // for looking up behavior of “being_sys”
    class being_bhvr : sys

        private gen_parameters.states bhvrState;
        private being_db_out dbObj = new being_db_out();

        public being_bhvr()
            bhvrState = gen_parameters.states.active;

        public gen_parameters.states delete(string beingId)
            // pre_behavior method performs checks,
            // may get input, set output, change state or changes attributes
            if (bhvrState == gen_parameters.states.canbedeleted)
            {   // actual deletion can be carried out.
                if (dbObj.deleteBeing(beingId)) bhvrState = gen_parameters.states.deleted;
            // post_behavior method performs checks,
            // may get input, set output, change state or changes attributes

            return bhvrState;

        // pre_behavior method performs checks,
        // may get input, set output, change state or changes attributes
        private void pre_delete(string beingId)
            // perform pre-conditional checks here

        // post_behavior method performs checks,
        // may get input, set output, change state or changes attributes
        private void post_delete(string beingId)
            // perform post-conditional checks


namespace being
    public static class gen_parameters

       // Different behavior states of being system
        public enum states { active, canbedeleted, deleted, obsolete, tobedeleted };

Documenting System Behavior (BDDoc)

One of the most important factors that can help in development of a good design is clear documentation of business rules and system behavior. System behavior is defined by business analysts. In order to guide business analysts in collecting the necessary and critical information and providing this information in a way that is easily understandable by the technical teams, we need a standard analysis-document format. This document should be geared toward accurate definition of system behavior. I would like to call it the Behavior Definition Document (BDDoc) and not the analysis document, as it would have a specific format to capture the behavioral aspects of the software systems. Obviously, we continue to need a business-analysis document, as before; however, we could refer the definition of behavioral aspects entirely to the BDDoc.

The format of the BDDoc should lead business analysts to collect the right information, in enough depth for development purposes. The right information resembles precise and clear definition of business rules and dynamic behavior of the system, and it should eliminate the need for further interpretation. During analysis sessions, this document would facilitate elicitation of business knowledge and (possibly) shorten the analysis phase. Format of the BDDoc should comply roughly with the “systems approach to business modeling” and “map” clearly to BSAL generic design.

Providing and explaining the BDDoc format here would make this article exhaustive. However, I do plan to share a draft format (in a follow-up article) for such a document, as I consider it essential for creating a good design and an efficient development process.


[1] For a more detailed analysis of the needs and challenges of software architects, please refer to the BSAL article in the Architecture Journal 6 (August 2006). Additional material can be found at http://www.bsal.org.

[2] For a more thorough description of the systems approach, please refer to General System Theory: Foundations, Development, Applications by Ludwig von Bertalanffy (Rev. ed. New York, G. Braziller, 2003).

About the author

Behzad Karim (MCSD.NET, MCT) is a software project manager at TEPUM SIGMA Consulting and Development Center (http://www.sigma.net.tr), which is based in Istanbul, Turkey. There, he has been leading project teams in delivering BPM, EDM, Interoperability, and SOA projects for banks, telecomunication firms, and government agencies. Prior to working as a software architect and project manager for nearly 9 years, Behzad worked as a solution developer for 14 years.


© 2015 Microsoft