|
In order to face the changing business demands, Zensar focuses on use of Solution BluePrint. Zensar’s Solution BluePrint (SBP) Framework addresses business level requirements analysis with business process modeling and use cases modeling. It addresses, modeling of the system with UML sequence, collaboration, and state diagrams. Analysis and design of the static structure of the system is covered with the UML class, component and deployment diagrams.
The core idea behind MDA approach is to construct Platform Independent Model (PIM) of system/requirements, transform PIM into Platform Specific Model (PSM) using Profiles, and then transform PSM into Platform Specific Code (PSC) for different platforms/architecture. The BluePrint Foundry (BPF) tool developed by Zensar is based on the OMG UML 1.4 Metamodel. The crux of SBP is a Model Driven Architecture (MDA) Approach. SBP also lends itself to Agile approaches to MDA.
It also addresses the capturing of functionality using ADDL scripting (which is an implementation of OMG’s Action Semantic Specification), design patterns and UML extensions; and also the implementation through automatic generation of source codes in various languages. SBP Framework uses BluePrint Foundry tool (BPF) which adheres to UML 1.4 standard. Following are the four major phases which are considered in the SBP framework:
1. Business Process Analysis
2. Modeling of Business Objects
3. Automating Application Generation
4. Iterative Quality Verification
| 
| Click on image to enlarge |
I. Business Process Analysis
Business Process analysis involves first understanding the Business Process, followed by Identifying Business Objects from Business Process followed by Deriving Business Use cases from Business Objects.
Following are the deliverables of this phase:
Business Process Model, Business Use cases, Business Objects.
BPF uses BPMN (Business Process Management Notation) diagrams for depicting Business Process Model. The BPMN is a standard notation which has been standardized by BPMI (Business Process Management Initiative) organization. It provides more expressiveness in representing complex business process graphically than the Activity Diagram which is one of the standard artifacts of UML for depicting business processes.
For modeling Use Cases and Business Objects, BPF provides the facility for drawing Use case diagram and Class Diagram which are standard UML artifacts.
II. Modeling of Business Objects
This consists of the following tasks:
- Identifying Application Use Cases from Business Use Cases
- Performing Object-Relational Mapping between Identified Classes
- Incorporating Third Party Controllers in the Models
- Depicting business logic through UML Extensions and ADDL
- Defining System Boundaries
This phase provides the following deliverables:
i. Use Case Model
Use-case represents the functionality provided by the system. Each individual functionality provided by a system is captured as a use-case.
A use diagram is a graphical view of some or all of the actors, use cases, and their interactions identified for a system.
ii. State Chart Diagram
A state chart diagram is drawn to illustrate the life cycle of an object. It shows the various states that an object can be present in, and the events that cause a transition from one state to another.
iii. Class Diagram
(with relationships between classes such as Association, Generalization and realization)
The class design consists of the stricture of the classes, including the class name, their attributes, operations, as well as representation of various relationships that exist between classes and objects.
iv. Boundary Diagrams
Boundary classes represent the interactions between the system and its actors. They insulate the system from changes in the surroundings of the system, such as user interfaces, and interfaces to other systems.
v. Sequence Diagrams
A sequence diagram shows a pattern of interaction among objects, emphasizing the sequencing of messages. A message is the mechanism by which an object asks another object to execute a certain responsibility.
vi. Collaboration Diagram
A collaboration diagram is an alternative way if displaying the pattern of interaction between various objects and actors in a use case. While a sequence diagram emphasizes the sequencing of communication between objects, a collaboration diagram emphasizes the organization of the objects participating in an interaction.
vii. Implementation Diagram
(Consisting of Deployment and Component Diagram)
This diagram shows a set of software components of a system, and their relationships. The software components may be executable files, source files, database, tables etc.
A deployment diagram shows the configuration of the components that exist on system. It typically involves modeling the topology of the hardware on which a system would execute.
All the above diagrams are standard UML artifacts. BPF provides facility to develop and deliver these design artifacts to the user. These artifacts adhere to the UML 1.4 standard.
Over and above these standard UML artifacts provided as deliverables by BPF, it also provides facility to write your business logic in ADDL (Activity Diagram Description Language). Hence it provides a centralized location for documenting all your business logic in a platform independent manner. This ADDL can then be easily converted into C++, C#, Java, VB and VB.net by BPF inbuilt parser.
III. Automating Application Generation
It consists of the following steps:
- Selecting Customer Specific Deployment Environment from the Framework
- Generating Platform Specific Source Code from Platform Agnostic Models
- Generating Wrapper Code for Legacy Application as Third Party Controllers
This phase outputs the following deliverables:
- System Generated Class.
- Database components
- Controller Code
- Build Files
IV. Iterative Quality Verification
It consists of the following parts:
- Verifying Quality at Each Stage of the Development Process
- Automating Testing Process through Use of Tools
- Tinkering of Models Becomes Easy
- Implementing, Testing and Changing the Design Turns into a Real Maintenance Asset
Note:
Since SBP adheres to the UML Standard 1.4, it delivers all the UML artifacts during the analysis and design phase of the software development life cycle. It also adheres in part with MDA (Model Driven Architecture) which is open standard documented by OMG (Object Management Group) as it generates the application code in various platform selected by the user.
| 
| Click on image to enlarge |
SBP Persistence Framework
Zensar’s SBP Persistence Framework and our expertise in creating reusable & scalable enterprise applications:
The SBP persistence framework is built on some of the most commonly used application and design patterns that are prevalent today. The most important aspect of the framework is that it provides a platform agnostic and yet platform configurable implementation thus making it an ideal choice in a variety of situations. The framework leverages the latest industry standards to build performance oriented and easily manageable applications. Moreover, the complete framework is available in UML thus making its modification and understanding universal.
Some of the common patterns used in the SBP framework are given below. It is worthwhile to note that mutually exclusive behavioral patterns can be implemented by the same object giving composite functionality at a relatively lesser cost of implementation.
aspects of a query from its identity.
| 
| Click on image to enlarge |
1. Active Record
Although Active Records are used for pure persistent data wrapping or representation, sometimes it becomes essential to function-enable the wrappers themselves to prevent dissipation of ‘owned’ functionality within the different layers of an application. Mostly, we would have Domain Objects which are Active Records in applications.
2. Class Table Inheritance
There are several advantages to having a direct mapping between classes and their representations as tables. Although people do debate on the effectiveness of such a mapping (E.g. the non appealing representation of abstract classes as tables), it is found to be more fit in solving a wider range of problems in the real world in contrast to a horizontal OO-R map or a concrete-vertical map. A direct consequence of such a mapping would in theory be the large number of joins of hop-queries that need to be created to extract data. However, in practice, if a disciplined approach to identifying domain objects is followed, one can definitely eliminate the possibility of such a scenario.
3. Data Transfer Object
Data transfer objects tend to be widely misused, if ever used! Most designs tend to generalize data transfer objects in one way or another making them cumbersome for usage and thereby minimizing the advantages of such an approach. In our framework, all objects can be serialized to XML making the creation & usage of domain objects easy while retaining the intention of creating the same.
4. Lazy Load
Within the SBP persistence framework, it is easy to make an object a Lazy Loader. Objects can be made to behave in such a manner by controlling its functionality using external context controllers.
5. Unit of Work
Perhaps one of the most important aspects of a transaction heavy application, this pattern is implemented within the SBP framework as a context controller object. More than just behaving as a pure UOW facilitator, the context controller also acts as a lazy load enabler.
6. Query Object
One of the most important classes within the SBP framework are the QueryElement and QueryController classes which are built upon the Query Object pattern with some slight modifications. In functional terms they behave exactly as a Query Object when used together. They are designed as separate classes to separate behavioral aspects of a query from its identity.
|
