Project Synopsis: Integrated Modeling Framework For Enterprise Systems

Vishwakarma Institute of Technology-37
Integrated Modeling Framework for Enterprise

systems
Project Synopsis
1
Department of Computer Engineering
Context
The principles to formulate enterprise are based on aspects of systems engineering. In

addition, it is a mistake to confine the integration discussions to information and control systems
alone. Often there are problems within the mission system (customer product and service
operations) whose solution would greatly ease the overall system problem.
No enterprise can long exist without a business or mission i.e. it must produce product(s)
or service(s) desired by a customer(s). It usually must also produce these products or services in
competition with other enterprises also vying for this same business.
The development of enterprise integration systems important due to:
1.The development environment is extremely competitive.

2.Development must adjust to contemporary standards of quality, reliability, higher
productivity, lower delivered cost and improved market responsiveness.
3. The integration of all development functions is required to optimize Life Cycle activities.
4. To make forward engineering dynamic in nature.
Problem
There are only two basic classes of functions involved in operating any enterprise:
1. Those involved in operating the processes which result in producing the “product” which
fulfills the enterprise’s mission.
2. Those involved in the “control” of the mission in an “optimal” manner to achieve the
necessary economic or other gains that assure the viability or continued successful
existence of the enterprise. These comprise the collection, storage and use of information
concerning the business processes in order to control them.
Thus it includes all management, planning, and scheduling, control, and data
management functions. Information or data will undergo multiple transformations i.e. many
separate task in fulfilling the information-handling requirements for an enterprise system. These
transformations or tasks are usually successive operations forming sets of sequential and parallel
networks.
All enterprises, of whatever type, follow a “life cycle” from their initial concept in the
mind of an entrepreneur through a series of stages or phases comprising their development,
design, construction, operation and maintenance, refurbishment or obsolescence, and eventually
to their final disposal.
2
To provide customer with desired products and services we require to do:
1. BPD: System developer will develop the BPDs according to the need that are captured from
the customer that will identify the implicit and explicit requirements.
2. BPMN: It provides business with capability of defining and understanding their internal
and external business procedures through BPD that will give organizations the ability to
communicate these procedures in a standard manner. Without business process modeling,
you might pick wrong piece of business to automate & implicit requirements may not be
captured.
3. RE: In Software Engineering, Requirement Analysis encompasses all of the tasks that go
into the instigation, scoping and definition of a new or altered system. Requirement
engineers and business analysts, along with software developers, identify the needs or
requirements of a customer.
4. UML: A notation that allow developer to specify, visualize and construct artifacts of
software system.
A complete workflow specification requires careful integration of many different process

characteristics. Decisions must be made as to the definitions of individual activities, their scope,
the order of execution that maintains the overall business process logic, the rules governing the
discipline of work list scheduling to performers, identification of time constraints and more.
The goal of this project is to address important issues in workflow modeling and its validation.
There are a number of approaches to making workflow management systems more flexible. Most
follow conventional notions of workflow models as formally complete and consistent, and look
at how change can be handled by migrating instances from one stable state to another. It is
required that interaction should be pursued more rigorously as an approach to enactment.
Involving users in situated model interpretation, interactive enactment allows inconsistent and
incomplete models to emerge, better matching the contingencies of real work.
Process-oriented workflow management means that processes are modeled and that the resulting
process models are used to govern these processes in the real world.
In governing processes on the basis of models it is ensured that real-world processes behave as
specified in their models. In most existing workflow management approaches only unstructured
pieces of information, like documents and images, can be managed. That means, processes that
create and manipulate structured pieces of information cannot be supported properly.
Solution
Once the integration of all of the informational and customer product and service
functions of an enterprise has been well-planned, the actual implementation of such integration
may be broken into a series of coordinated projects. All tasks will be defined in a modular
fashion, along with their required interconnections. These tasks will be implemented in a
3
modular fashion, again permitting their later substitution by other different methods of carrying
out the same function.
Tasks in the System Architecture are as follows:

1. Communications: the transmission of information between the elements (modules) of the
Information Architecture (either human workers or components of the Information Systems
Architecture) in the form of messages adhering to a pre-established protocol.
Messages may be verbal (agreed upon language), visual (agreed upon non-verbal actions or
symbols) or written (agreed upon language and format).
2. Information Storage - the retention of information and data for periods of time (specified or
indeterminate) for use in later actions of the Information Architecture components. Storage may
be in human-readable form (written - libraries, etc.) or machine-readable (databases or related
depositories).
3. Mission Fulfillment - Guidance (control) of the components of the Development (or

Customer Products and Services in general) elements of the Development Architecture in
carrying out their assigned tasks to assure an optimal completion of the assigned mission of the
enterprise.
As a part of Process Capture and Modeling three models are considered as follows:
 Activity models: They describe which activities have to be executed within processes,
which restrictions concerning the order of these activities have to be respected, and how
these activities are implemented.
 Object models: They describe the types of objects created and manipulated within
processes.
 Organization models: They describe, in which organizational context a process is
supposed to take place (including roles).
Development of a formal Plan involves:

1. Identify the implicit and explicit requirements from the BPDs developed by the developer.
2. According the customer needs, prepare RE.
3. Now cross match the requirements under BPD and RE.
4. Integrate requirements under both.
5. Develop UML diagrams that follow forward engineering.
Development of Domain Model:
A Context Level Domain Model can describe related systems in a domain. This can reduce
the time needed for developers to learn the modeling language, since it can use familiar terms
and concepts. The Context Level Domain Model can cover a range of abstraction levels for a
particular domain.
4
The proposed methodology integrates the Business Process Modeling, Systems

Engineering and UML capabilities to realize the transformations from real world to a well
designed and implemental solution.
REQUIREMENT MODELER PROCESS MODELER
INTERACTION FRAMEWORK
UML MODELER
Figure Abbreviations:
BPD : Business Process Diagram
BPMN: Business Process Modeling
Notation
BI : Business Intelligence
NM : Notation Manager
RG : Requirement Gathering
RC 5
: Requirement Collection
RM : Requirement Manager Department of Computer Engineering
Benefits
1. Improved responsiveness to technical and environmental changes.

2. Business strategies provide the focus, direction and priorities for enterprise integration
planning. Enterprise integration’s focus is sharing information to eliminate steps in the
processing of products that do not add value.
3. Due to the comprehensiveness of the WFM approach it will be possible to implement
multi-step, multi-user business processes with having examined them and with it having
checked their consistency against the actual way of conducting business.
4. The UML 2.0 notational compliance will allow the modeler to make a fully described and
realizable model that can be used as a fundamental unit in application development
6

systems
Feasibility Study Report
7
INTRODUCTION
A feasibility study is defined as an evaluation or analysis of the potential impact of a

proposed project. The feasibility study is based on extensive research on both the current
practices and the proposed project and its impact on the software industry. The feasibility study
will include advantages and disadvantages of both the existing situation and the proposed plan.
This document provides the purpose of the feasibility study, the background of the
proposed project, the methodology used for performing the study, and any reference materials
used in conducting the feasibility study for the project titled “Integrated Modeling Framework
for Enterprise System”.
Integrated Modeling Framework for Enterprise System is a CASE tool that supports a
Software Architecture, Enterprise Framework (EF). Such frameworks expose a rich set of
semantics and modeling paradigms for developing and extending enterprise applications.
Integrated Modeling Framework for Enterprise System uses a Meta Model Driven approach to
model engineering. The model captures the business logic and lifecycle semantics of the
component. This approach truly facilitates the "model once run anywhere" paradigm.
Purpose
The principles to formulate enterprise are based on aspects of systems engineering. In

addition, it is a mistake to confine the integration discussions to information and control systems
alone. Often there are problems within the mission system (customer product and service
operations) whose solution would greatly ease the overall system problem.
or service(s) desired by a customer(s). It usually must also produce these products or services in
competition with other enterprises also vying for this same business.
The development of enterprise integration systems important due to:
1. The development environment is extremely competitive.

2. Development must adjust to contemporary standards of quality, reliability, higher
productivity, lower delivered cost and improved market responsiveness.
3. The integration of all development functions is required to optimize Life cycle
activities.
4. To make forward engineering dynamic in nature.
8
Methodology
The following methodologies were used to conduct the feasibility study for this system
includes the study of the feasibility of implementation of the new features that are going to be
incorporated in the system. Below are some of the Features and the methodologies used for these
features implementation in the current systems:
1. WFM: System will perform workflow checking according to the workflow

traceability. System administrator will schedule the workflow. A workflow consists
of a sequence of connected steps. It is a depiction of a sequence of operations,
declared as work of a person, a group of persons, an organization of staff, or one or
more simple or complex mechanisms.
2. BPMN: It provides business with capability of defining and understanding their

internal and external business procedures through BPD that will give organizations
the ability to communicate these procedures in a standard manner. Without business
process modeling, you might pick wrong piece of business to automate & implicit
requirements may not be captured.
3. RE: In Software Engineering, Requirement Analysis encompasses all of the tasks

that go into the instigation, scoping and definition of a new or altered system.
Requirement engineers and business analysts, along with software developers,
identify the needs or requirements of a customer.
software system.
5. DOMAIN: Domain performs the task of building domain modeler and structuring
of domain information. It also includes building a task of domain vocabulary and
provide domain model notation. It performs task association of domain models.
A complete workflow specification requires careful integration of many different process

characteristics. Decisions must be made as to the definitions of individual activities, their scope,
the order of execution that maintains the overall business process logic, the rules governing the
discipline of work list scheduling to performers, identification of time constraints and more.
The goal of this project is to address important issues in workflow modeling and its
validation. There are a number of approaches to making workflow management systems more
flexible. Most follow conventional notions of workflow models as formally complete and
consistent, and look at how change can be handled by migrating instances from one stable state
to another. It is required that interaction should be pursued more rigorously as an approach to
enactment. Involving users in situated model interpretation, interactive enactment allows
inconsistent and incomplete models to emerge, better matching the contingencies of real work.
Process-oriented workflow management means that processes are modeled and that the
resulting process models are used to govern these processes in the real world.
9
In governing processes on the basis of models it is ensured that real-world processes behave as
specified in their models. In most existing workflow management approaches only unstructured
pieces of information, like documents and images, can be managed. That means, processes that
create and manipulate structured pieces of information cannot be supported properly.
General Information
Current Systems and Processes
The various UML CASE tools available like Enterprise Architect, Vp_Uml Suite,
Rational Rose etc. provide support for the functionality of the UML model of a system, which
captures aspects from requirements to deployment in varying degrees. These CASE tools aid
UML diagramming within a development process.
Rational Rose doesn’t support features of UML 2.0 which are provided in the case tools
like Enterprise Architect, Vp_Uml suite. Requirement Modeling is done using Use Case
mapping in all the above Tools. Features of Use case Mapping, NFR Mapping is not provided by
any of these tools. Enterprise Architect and Rational Rose generate code using Class Diagrams
while Vp_Uml generated it using State Chart Diagram. Diagram mapping to images in BMP,
WFM is supported by Enterprise Architect and Rational Rose. Vp_uml suite along with these
supports JPG, JPEG formats. The CRC card support is not available in Rational Rose and
Enterprise Architect while is there in Vp_Uml Suite.
System Objective
The main objective of Integrated Modeling Framework for Enterprise System is to

provide a framework on which models will be generated, resulting in improved design and in
turn improved productivity in an Enterprise. The software industry is trying to fully understand
the modern "Enterprise" in an attempt to automate its day to day operations and to provide
crucial decision support capabilities.
Integrated Modeling Framework for Enterprise System is a Framework which helps in

overall development of an integrated code for a project from the problem statement entered by
the end users and facilitates reuse throughout the software lifecycle process. Its basic objectives
are:
Requirements are indicated for workflow languages through workflow patterns. Patterns
address requirements in an imperative workflow style expression, but are removed from specific
workflow languages. The primary task of a workflow management system is to enact case-driven
processes by allowing workflow models to be specified, executed, and monitored. Workflow
process definitions are defined to specify which activities need to be executed and in what order.
10
An elementary activity is an atomic piece of work. Workflow process definitions are instantiated
for specific cases (i.e. workflow instances). Activities are connected through transitions and we
use the notion of a thread of execution control for concurrent executions in a workflow context.
Further mapping the activity diagrams to workflow modeling and then use Petri nets to analyze
the workflow so modeled. Then UML Modeler with the help of the notation manager models the
diagrams namely, Use Case, State Chart, Activity and Class Diagram and creates a workspace
for the same. The Notational Compliance will be for UML 2.0.
ISSUES
Workflow Specification:
Workflow specifications in a broad sense have number of different perspectives. The
workflow perspective describes activities and their execution ordering through different
constructors, which permit flow of execution control, e.g. sequence, splits, parallelism and join
synchronization. Activities in elementary form are atomic units of work, and in compound form
modularize an execution order of a set of activities. The resource perspective provides an
organizational structure anchor to the workflow in the form of human and device roles
responsible for executing activities.
Specification language:
All WFMS’s of which we are aware provide graphical workflow specification languages.
In addition, many WFMS’s provide rule-based or constrained workflow specification languages.
These languages are higher-level languages than standard programming languages such as C and
C++. They support the specification of the following:
• Task structure (control flow) and information exchange between tasks (dataflow) in a
workflow, e.g., specifying that tasks can be executed in parallel, or that a task needs to wait for
data from other tasks).
• Exception handling, e.g., specifying what actions are necessary if a task fails or a workflow
cannot be completed.
• Task duration, e.g., specifying initiation and completion time of a task
• Priority attributes, e.g., specifying priorities for task scheduling
Assumptions and Constraints
Availability of Information and Resources

An explicitly incorporated library stores reusable elements of both the analysis and the
design phase.
Financial considerations including development and operational costs

When a number of users across the world would like to work on a single project, the
organization will have to incur the costs involved in setting up and maintaining the server at
some centralized location.
11
Changing Operating environments

The system will be developed in a platform independent language (java) and no system
dependent components will be used for its development. But for different environments the user
needs to make sure that it has the JVM installed on it for the functioning of software.
Alternatives
A brief comparison between these available tools and Integrated Modeling Framework for
Enterprise System is mapped into the table given below:
Features Enterprise Rational Rose Vp_UML Integrated Modeling
Architect Framework for
Enterprise System
UML 2.0 Yes No Yes Yes
Documentation Html, RTF Html, RTF Html, RTF, Html, RTF, PDF
PDF, MsWord
Use Case No No No Yes
Mapping
NFR Mapping No No No Yes
Diagrams as BMP, WMF BMP, WMF JPG, JPEG, JPG, JPEG, BMP
Images BMP
Modeling Using Use Using Use Using Use Using Requirement
Requirements Cases Cases Cases Diagram
Code Using Class Using Class Using State Using Activity
Generation Diagram Diagram Machine Diagram
12
CRC Cards No No Yes Yes
Comparisons of alternatives
1. Programming Language
The comparison for programming language was done among Microsoft Visual
Basic 6.0, Microsoft .NET Framework, and Java 2 Second Edition.
Microsoft Visual Basic and Microsoft .NET framework are not free to use while
Sun Java is a free offering from Sun CORP. Ltd. Also Sun Java consists of a set of API’s that
can be used for the development of any application. Besides its own API’s there are several
open source organizations that develop API’s for Java. The integration of these interfaces is
fairly simple and the most striking feature of this language was that it allowed portability of
applications developed in Java while the other two did not support platform independency.
2. Java Integrated Development Environment

Taking into consideration the above factors Java was chosen over the other
choices for Programming language. A number of IDE were considered for development such
as Borland JBuilder, Sun Java Studio and Eclipse.
Sun Java Studio is based on NetBeans, the open source platform that competes with Eclipse.
NetBeans is a worthy platform, capable of doing most everything Eclipse can do. And like
Eclipse, NetBeans enjoys the support of numerous plug-in developers. It provides striking
features the other packages lack, and it lacks some tools that all the other packages offer. Its
two unique and truly meritorious features are collaboration and execution profiling.
For Borland’s JBuilder Personal Edition, basic IDE plus a few additional tools such as a GUI
designer, integrated JUnit framework, and some other items required for application
development comes at a cost. Eclipse is a free, open-source IDE. The most popular of all the
Java IDE, but harder to set up and configure than the commercial ones. Eclipse is the base
IDE, but there are many Java-related plug-in for Eclipse, and several commercial IDE built
on top of Eclipse.
Hence, Sun Java Studio was finalized over the other two.
3. Databases
The databases that were considered for the system are Oracle, MySQL, Microsoft
Access and XML database. Oracle is the industry preferred database and contains everything
an application needs. But it has a lot of dependencies, is too heavy to be used in this
application. MySQL is a free open source database, is very light, fast and efficient and a
worthy candidate to be considered for this application. Microsoft Access feature wise not
much different from either Oracle or MySQL, comparatively lighter than Oracle. But its only
disadvantage is that it is a proprietary and its usage requires heavy licensing fees.
Another tool considered data storage is to use XML databases. XML can be
extended to be used as databases. The primary advantage of using XML as database is that it
13
does not require any system specific configuration which supports the cause of the system to
be platform independent. Another, it can modified in the way we need it. It is also extremely
light. The only disadvantage of using XML as database is that, if the number of entries in the
database increases, it tends to slow down.
Recommendations and Conclusion
To support that the entire system is feasible from the point of view of
development, the following recommendations and conclusion has been chalked out. The
Platform Independency of Java made it a preferable choice over all the other considerations
as the language of implementation. The free availability of Sun Java Studio to the members
of Sun Microsystems along with no plug-ins required made it a preferred choice.
For the Database selection though MySQL had better features than XML,
but the fact that XML does not require any configuration and MySQL needs to be
configured differently for different platforms, favored XML.
Thus all the recommended tools are platform independent and are free of
cost. Thus to conclude the above, this report has examined the feasibility of the system
“Integrated Modeling Framework for Enterprise System”.
14

System
Software Project Plan
15
OVERVIEW
The objective of Integrated Modeling Framework for Enterprise System is to provide a

framework on which models will be generated, which will result in improved design and in turn
improved productivity in an Enterprise
Due to rapid changing business requirements the complexity in developing enterprise-

spanning applications is necessary. There is a relationship between business model and the
component. The business model captures common business logic and makes it available to the
systems analyst and software architect for reuse. The component is an implementation of some
business model for a given architecture. As such, the model driven approach facilitates the reuse
of the common logic across different implementation environments thus realizing the "model
once deploy anywhere" paradigm.
Various tools are available in market but none are as useful as Integrated Modeling
Framework for Enterprise System uses a Meta model driven approach to model engineering it
separates the definition of the business logic from implementation. The model captures the
business logic and lifecycle semantics of the component. As such, this approach truly facilitates
the "model once run anywhere" paradigm.
It is necessary to integrate applications on the business and conceptual level as well as

using business models, business process models, product, interface models, interaction model
etc.
The users for the system will be every Enterprise or an organization that follows the
UML standard. The system is being developed independently by four students as Final Year
Project in Computer Engineering for University of Pune. The expected time required for the
completion of this system is one year.
GOALS AND SCOPE
Project Goals
Project Goal Priority Comment/Description/Reference

Functional Goals:
Generate UML profile High The UML modeler analyzes requirements
and generates a framework for UML diagram
on which the user can work around adding
additional information. This will give idea
how to organize various notations profiles as
well as how to incorporate meta models and
their behavior.
Metamodel High This includes metamodel creation, metamodel
16
Project Goal Priority Comment/Description/Reference

organization generation, and maintenance and meta model
integration.
Requirement High Requirement Entry deals with reliable storing,
management retrieving, parsing of requirements and
extracting of information required for future
phases which will helpful to analyze the
ambiguity as well as to categorize the
requirements.
Business Goals:
Business process High Gives the implicit and explicit requirements
diagram management and these get added into requirement
database. It is useful to capture needs by
applying BI rules.
Perform model High This goal gives idea to transfer the models
transformation from source model to destination model.
Which will transfer model to meta model and
it is necessary to satisfy transformation rules.
Quality Goals:
Security Management High The Security Management provides services
to maintain profiles as well as to manage that
profiles. which are also helpful to create
workspace as well as to import workspace.
Checking of workflow Medium Workflow editor elects appropriate resources,
system monitors progress, carries out ordered
execution of WF tasks and also determine
changes. It is very useful to check relation
between every element.
Constraints:
Source Code Source code from the models will be
Generation generated in XML programming language
only. It only considers every notation of the
required diagrams, not all of them.
17
PROJECT SCOPE
Included
The system functionalities can be divided into five main categories

 Workflow modeling
 Requirement Engineering
 BPMN
 Domain modeling
 UML generator
The system does not guarantee that the framework generated shall be 100% accurate. The
system will provide a framework according to its semantics knowledge gathered from
requirements and some diagrams, for the user to build the system from that point onwards.
This project will include:
1. WFM: System will perform workflow checking according to the workflow traceability.
System administrator will schedule the workflow. A workflow consists of a sequence of
connected steps. It is a depiction of a sequence of operations, declared as work of a person, a
group of persons, an organization of staff, or one or more simple or complex mechanisms.
2. BPMN: It provides business with capability of defining and understanding their internal
and external business procedures through BPD that will give organizations the ability to
communicate these procedures in a standard manner. Without business process modeling, you
might pick wrong piece of business to automate & implicit requirements may not be
captured.
3. RE: In Software Engineering, Requirement Analysis encompasses all of the tasks that go
into the instigation, scoping and definition of a new or altered system. Requirement engineers
and business analysts, along with software developers, identify the needs or requirements of a
customer.
software system.
5. DOMAIN: Domain performs the task of building domain modeler and structuring of
domain information. It also includes building a task of domain vocabulary and provide domain
model notation. It performs task association of domain models.
18
Excluded
This project will exclude

1. Requirement capturing from external system .
2. Semantics checking of UML 2.0 diagram.
3. Reverse engineering.
Schedule and Milestones
Milestones Description Milestone Criteria Planned Date

M0 Start Project
SRS reviewed
Stakeholders
identified
Implement Proposal
reviewed
M1 Start Planning
Scope and concept
described
M2 Start Execution
Requirements
agreed, project plan
reviewed, resources
committed
M3 Start Introduction
Coding of new
functionality
finished,
Draft documentation
M4 Close Project
19
Deliverables
Identifier Deliverable Planned Receiver
Date
BPDM Business process diagram Manager System Developer
RM Requirement Manager Project Managers,
Requirement
Engineers
SM Security Manager Requirement
Engineer
UM UML Generator System Analysts,
System Developers
DM Domain Modeler System Developers
WFM Workflow Manager System Analysts,
System Developers
20

Systems
Software Requirements Specification
21
INTRODUCTION
It gives an idea to the developers and its user on what the system will shape up like and
the functions the system will perform. This document also introduces all the functionalities
that the system can perform and its effect on the users and the stakeholders. Survival for the
enterprise depends on the ability to continually refine and alter the elements of its business
and organization. Such changes may represent attempts to refine existing practices, or more
radical alterations to the mission of the enterprise.
The rationale of this document is to collect, analyze and define high-level needs and
features of the Integrated Modeling Framework for Enterprise Systems. It focuses on the
capabilities needed by the enterprise and customer, and why these needs exist. The details of
how the Integrated Modeling Framework for Enterprise Systems fulfils these needs are
detailed in the use-case and supplementary specifications.
The intended audiences for this SRS are requirement engineers, system
developers, system analysts and project managers. Requirement Engineers play a major role
in the system as everything they specify in the requirements, forms the base on which the rest
of system functionalities depends. The system uses these requirements to model various
UML diagrams. They form the core of the system. System Developers need to work around
with the requirement engineers and system analyst assisting them, so that when development
process begins it becomes easy for them to understand the system and perform their task in
an efficient manner.
Purpose
or service(s) desired by a customer(s).The purpose of this document is to introduce aspects
for developing an integrated framework for an enterprise systems.
Intended Audiences
 Enterprise:
 Customers:
This group is end user with restricted rights.
 Developer:
It is community which actually develops the framework
 Designer:
One whose design must meet the requirements specified in this SRS.
22
 Tester:
This community tests the system according to the test cases.
SCOPE
Database:
These comprise the collection, storage, manipulation and use of information
concerning the business processes in order to control them.
Framework:
 Software framework: A reusable set of libraries or classes for a software system
(or subsystem).
 Application framework: A software framework used to implement the standard
structure of an application for a specific operating system
 Web application framework: A software framework for development of dynamic
websites, web applications and web services
It provides tools for developing enterprise system.
Workflow Management
 Build workflow editor to perform abstraction of requirements
 Build workflow planner to select appropriate set of available resources
 Build workflow observer to monitor progress
 Build workflow engine to carry out ordered of workflow task.
Requirement Management
 Build requirement query system
 Perform traceability
 Build Change control system
 Conversion of requirements
 Requirement report generation
Organizing metamodel
 Meta model creation
 Metamodel generation
 Metamodel maintenance
 Metamodel integration
Document Linking
 Generation of XMI DTD
 Generate repository for model instances
 Generate grammar for models
 XMI documentation
23
Realization of CBD
 Build concurrency adaptor
 Solve concurrency interface conflict
 Carry out component based development.
 Code assembly.
Benefits
1. Improved responsiveness to technical and environmental changes.

2. Business strategies provide the focus, direction and priorities for enterprise integration
planning. Enterprise integration’s focus is sharing information to eliminate steps in the
processing of products that do not add value.
3. Due to the comprehensiveness of the WFM approach it will be possible to implement
multi-step, multi-user business processes with having examined them and with it having
checked their consistency against the actual way of conducting business.
4. The UML 2.0 notational compliance will allow the modeler to make a fully described and
realizable model that can be used as a fundamental unit in application development
5. ERP systems connect to real-time data and transaction data (data accumulated into
collections to deliver sets of information) in a variety of ways. These systems are
typically configured by System Integrators, able to bring their unique knowledge on
process, equipment and vendor solutions.
Definitions, acronyms and abbreviations

Term or Acronym Definition
BI Business Intelligence.
BPD Business Process Diagram
BPMN Business Process Modeling Notations.
NM Notation Manager.
RC Requirement Collection.
RE Requirement Engineering.
RG Requirement Gathering.
RM Requirement Manager.
UML Unified Modeling Language.
WFM Workflow Modeling.
JVM Java Virtual Machine.
JDK Java Development Kit.
CBD Component Based Design.
Table x. Definitions and Acronyms
24
References
1.A New Approach to Version Control, 3rd March 1993, IEEE Software Transactions
1. Mapping User Requirements to Implementations, January 1995, IEEE Software Journal
2. Software Reflexion Models - Bridging the Gap between Design and Implementation, 4th
April 2001, IEEE Transactions on Software Engineering
3. Reviewing Software Diagrams - A Cognitive Study, 2nd February 2004, IEEE
Transactions on Software Engineering
4. Guided Development with Multiple Domain-Specific Languages, Anders
5. Hessellund, Andrez Wasowski, IT University of Copenhagen, Denmark.
6. An eXecutable Metamodelling Facility for Domain Specific Language Design,
7. Tony Clark, Andy Evans, Paul Sammut, James Willians.
8. Domain Specific Models, Model Analysis, Model Transformation, Tivadar
9. Szemethy, August 2006, Nashville, Tennesse.
10. Visualizing Model Mapping in UML. Jan Hendrik Hausmann and Stuart Kent
11. A Model Transformation Framework for the Automated Building of Performance Models
from UML Models_ Andrea D’Ambrogio
12. MOF QVT final adapted Specification by OMG
13. Jean-Jacques Dubray, “A Novel Approach for Modeling Business Process Definitions,”
2002
14. BPMN Adopted Specification 3
15. http://www.ebpml.org/ebpml2.2.doc
16. Response to OMG BPD RFP, OMG, Sept. 2003, bei/03-08-02
17. http://www.omg.org
25
Overview
The document is divided into three Sections.
Section 1
Introduces you to the system as a whole, its capabilities and how it is different from other tools.
It describes the scope of the system being developed and the references that were needed to give
a shape to this system.
Section 2
It Describes the Product’s Perspective, the various Interfaces of the system, its functions, user
characteristics, constraints, assumptions and dependencies.
Section 3
This section describes external interfaces to the system, performance requirements, design
constraints, system attributes and system specific requirements.
Section 4
The supporting information makes the SRS easier to use. It includes: Table of Contents at the
front of the document Index Appendices.
Overall Description
Integrated Modeling Framework for Enterprise System is a CASE tool. Its main intention
is to provide a framework on which models will be generated, which will result in enhanced
design and in turn improved productivity of the systems the end-users build.
This will be achieved by:
 Providing the framework to develop BPD depending on user needs.
 Providing a strong and reliable base to the models in the form of requirements.
 Interweaving between RE and BPD.
 Integrating WFM and BPMN.
 To generate the workflow models using BPMN.
 Linking gap between requirement engineering and Use case modeling.
26
Problem Statement
The problem of 1. Retrieving Requirements from BPD

2. Semantic Analysis of Requirements.
3. Linking gap between requirement
engineering and modeling.
4. Missing notations in UML.
Affects 1. Business Process Organization.
2. System Analyst
3. Solution Developers
4. Customers, Stakeholders
5. Requirement Engineers
The impact of which is 1. Overlapping and Loss of Requirements

2. Delayed and Unscheduled
3. Incorrect Hierarchy Mapping
4. Wrong Product Development
Product Perspective
The entire system in divided into various sub-systems:
1. Requirement Engineering
Systematic requirements analysis is also known as requirements engineering. It is

sometimes referred to loosely by names such as requirements gathering, requirements
capture, or requirements specification. The term requirements analysis can also be
applied specifically to the analysis proper, as opposed to elicitation or documentation of
the requirements, for instance. Requirements engineering can be divided into discrete
chronological steps:
 Requirements elicitation,
 Requirements analysis and negotiation,
 Requirements specification,
 System modeling,
 Requirements validation,
 Requirements management.
27
2. UML
Unified Modeling Language is popular for its diagrammatic notations. We all know
that UML is for visualizing, specifying, constructing and documenting the components of
software and non software systems. Block of the system provides the user with the
facility to model diagrams and provides with the notations for various UML diagrams
such as Use Case, State Chart, Activity and Class Diagram, etc
3. WFM
A workflow consists of a sequence of connected steps. It is a depiction of a sequence

of operations, declared as work of a person, a group of persons, an organization of staff,
or one or more simple or complex mechanisms. Workflow may be seen as any
abstraction of real work, segregated in work share, work split or other types of ordering.
For control purposes, workflow may be a view on real work under a chosen aspect, thus
serving as a virtual representation of actual work.
4. BPMN
This block performs the task of interweaving the requirements from both RE and BPD
and analyzing the requirements for identifying probable Use Cases and Actors. It then
generates the SCD and RCD based on its analysis.
5. Domain
A domain model is a model of domain within which an Enterprise conducts its

business. The domain model for one enterprise should be the same as that for any other
enterprise conducting business in same domain. Domain modeling should be of interest
of both to the system modelers and Business modelers.
Domain performs the task of building domain modeler and structuring of domain
information. It also includes building a task of domain vocabulary and provide domain
model notation. It performs task association of domain models.
A domain model, or Domain Object Model (DOM) in problem solving and

software engineering can be thought of as a conceptual model of a domain of interest
(often referred to as a problem domain) which describes the various entities, their
attributes and relationships, plus the constraints that govern the integrity of the model
elements comprising that problem domain.
28
REQUIREMENT MODELER PROCESS MODELER
INTERACTION FRAMEWORK
UML MODELER
Figure Abbreviations:
BPD : Business Process Diagram
BPMN: Business Process Modeling
Notation
BI : Business Intelligence
NM : Notation Manager
RG : Requirement Gathering
RC : Requirement Collection
RM : Requirement Manager
29
Product Position Statement
For 1. System Analyst

2. Solution Developers
3. Customers, Stakeholders
4. Requirement Engineers
Who designs various types of models

Integrated Is a CASE tool
Modeling
Framework For
Enterprise System.
That 1. It supports more notations.
2. More extensible.
3. Platform independent.
Unlike Rational rose.
Our product 1. It supports more notations.

2. More extensible.
3. Platform independent
System Interfaces
This section describes the various system interfaces required for realization of this CASE tool.
Common Language Runtime

The system development environment is JAVA programming language and XML as justified in
the Feasibility Study Report. The system will depend on the CLR which is available for the
Windows platform that will provide the required resources for successful execution.
Java Virtual Machine

The system development environment is Java programming language as justified in the
Feasibility Study Report. The system will depend on the JVM which is available for all the major
platforms that will provide the required resources for successful execution.
Java Integrated Development Environment

Java is used as the language of implementation for the system. It allows use of a simple text
editor to code an application in Java. Java consists of a set of APIs that can be used in application
development. It allows portability of applications produced in Java. For complex applications a
number of IDE were considered which are mentioned below..
30
Borland’s JBuilder Personal Edition

It provides few additional tools such as a GUI designer, integrated JUnit framework, and some
other items. It is freely downloadable.
User Interfaces
User Interfaces defines the various interfaces available for the end-user to interact with the
system.
Help System
A complete detailed Help system made available to the end-user of the system will contain all
the support information the end-user requires in case of some difficulties in using the system
arises. Help allows the user to walk through pictorial presentation of all the functionalities of the
system. Some of the highlights of the help system are as follows:
 Pictorial Presentation
 Search
Additions
1. This tool will allow user to add notes, search, add project packages.
2. Diagrams can be embedded in Document. Supporting formats are: GIF, BITMAP.
3. Tools and notational help will be provided to the user.
Software Interfaces
The development of the system on the Java platform gives an added advantage of having the
support of large number of Open Source Libraries to be used within the system. These libraries
are tried and tested and will help in quick development of the system.
JFreeReport
This library supports exporting of reports in tabled format to various file formats such as PDF,
XLS, etc. Report generation activity will use this library.
JavaHelp
JavaHelp library API’s are intended for generating help for authors, information architects, and
software developers who need a framework for delivering online help and documentation.
The xmlenc library is a stream-based XML output library for the Java programming
language, Microsoft XML Core Services (MSXML) is a set of services. XSD (XML Schema
Definition) XSDs are far more powerful than DTDs in describing XML languages. They use a
rich data typing system and allow for more detailed constraints on an XML document's logical
structure. XSDs also use an XML-based format, which makes it possible to use ordinary XML
tools to help process them.
31
Hardware Constraints
Hardware Interfaces Requirement Specification

Processor Pentium III,IV,V/Laptop/palmtop/pocket PC
RAM 256 MB
HDD 10 GB
VGA Display device
Operating System Windows XP/2000/2003
Memory Constraints
The application being developed in Java has the following memory constraints
1. Java application tends to run slightly slow because they run inside the JVM. This lag can be
reduced by efficient coding and avoiding use of heavy components.
2. The product development on the latest beta version of the Java Development Kit Version 6
Codenamed Mustang. At the time of writing, this beta release is more memory demanding
and is expected to cool down by the time its final version is released.
Considering the above factors the memory requirements for the product is as follows:
Minimum -- 128 MB Memory

Recommended – 512 MB Memory
Operations
Workflow Management
Workflow Management (WFM) promises to provide a suitable infrastructure for the execution of
business processes in a distributed environment. WFM aims at the automation of business
processes. Workflows can be characterized as executable images of business processes. Business
processes describe and explain how a business is conducted; therefore, more business related
terms are used in their definitions. Workflows are executable objects. Workflow management
promises to cope with this requirement by providing a highly dynamic execution platform for
multi-faceted business processes.
32
This includes:
1. Specification of the activity meta model

2. Definition of the meta models for business processes and workflows
3. Specification of business processes
4. Transformation of business processes into workflow.
Requirement Management
Adding requirement, validating them, if required, making changes, updating requirements are
some of the major activities here. Besides, various traceability options and version viewing
facilitates the requirement engineers. Comparing requirements for ambiguity and analyzing the
impact of the requirements on the system are the other major activities supported in the
Requirement management.
Requirement management allows user to
1. Capture and document requirements.

2. Develop requirements in an iterative process.
3. Describe a documentation hierarchy and standards for defining levels of requirements for a
product.
4. Use requirement attributes and traceability to help manage scope and change throughout
product lifecycle.
5. Use requirements to drive ongoing design, test, and user documentation activities.
Organizing metamodel
The metamodel driven architecture joins together the business model and the metadata captured
in the "meta" levels of the business model to bring about new levels of abstraction,
personalization, and extensibility of these business models – essential ingredients to manage
business information (content) and application/business processes that use this content. This
includes metamodel creation, metamodel generation, maintenance and meta model integration.
Site Adaptation Requirements
Java Runtime Environment

The system development is on the Java Programming Language. It becomes easier to port the
system on to various platforms with very less to no change in the code. The only thing the
system is dependent upon is the Java Runtime Environment (JRE) for its execution. JRE’s are
available for various platforms. Only thing is that they need to be installed on the target machine.
33
Product Functions
Goals Objectives Tasks

Organize meta model Provide Meta-Model 1. Extract meta model
2. Retrieve notations
Model diagram
1. Deliver diagram controls
2. Generate diagram profiles
Manage security Maintain Profiles 1. Maintain login
2. Manage profile right
Allocate workspace 1. Create workspace

2. Import workspace
Perform model transformation Extract metamodel 1. Associate meta model
2. Integrate model
Transform meta model 1. Transformation rule
2. Implement Transformation
Perform workflow checking Schedule workflow 1. Check element flow
2. Check element relation
Build workflow traceability 1. Determine changes
2. Accommodated changes
Manage BPD Develop BPD 1. Capture needs
2. Provide notations
3. Apply BI rules
Process BPD 1. Accept explicit requirements
2. Notify implicit requirements
Generate UML profile Organize notation profile 1. Categorize notations
2. Associate notations
34
Incorporate meta model 1. Extract behavior model

element
2. Build model elements
Manage requirement Capture requirement 1.Acquire requirement definition

2.Categorize requirement
Trace requirement 1.Analyze ambiguity

2.Determine requirement overlap
Build domain modeler Build domain 1. Structure domain information

2. Build domain vocabulary
Provide domain model 1. Associate domain model

notation 2. Provide domain notations
User Characteristics
System Analyst
Systems analysts apply mathematical methodology to the analysis of the systems involved
trying to form a detailed overall picture. Here Petri nets mathematics is used to convert the
activity diagrams into systematic code generation via workflow design.
Requirement Engineers
The requirement engineers are expected to determine whether or not the new system is feasible,
schedulable, affordable, legal and ethical. In Enterprise Modeling tool requirements are gathered
via textual analysis. This allows requirement engineers to understand needs efficiently. It also
provides support for accommodating changing requirements via iterative modeling approach.
Logical Database Requirements
Requirements Log
Requirements log holds the Requirement generation pattern. This are transferred to requirement
overview diagram and given as input to use case profile will be stored in the XML database in
35
the form of .rqs file. Every project will have one requirement file physically, but logically there
will one requirement file for every requirement.
Data catalog vocabulary

For natural language processing data is retrieved from data catalog vocabulary. It stores data in
terms of files, links, attributes. This helps in resolving vocabulary ambiguities.
Notation information for UML Modeling

UML Modeling Diagram will be stored in the database in the form of their extension being first
three letters of the diagram name. Eg. Every model will be identified by UML extension.
User Information
User Information will be stored in the database in two levels of hierarchy.

 System Level Login
 Project Level Login
The system level login will contain all the users who belong to that organization. The user won’t
be able to login to a project unless and until he is given permission to do so. All the users
working on a particular project are stored in the .prj file.
Software System Attributes

Security
Login
At the most basic level login based security will be provided. An authenticated user can login to
the system and thus access the projects assigned to that user. To get a login id and password, the
user should contact the central administrator, who has the rights to assign new users to the
system and also remove the users from the system.
Digital Signatures
At file level, Digital Signature security will be provided. If any file that has been tampered in any
way outside the system’s environment the digital signature check will be failed. This will prevent
errors in the project from external sources
36

System
Use Case Analysis Document
37
System Context Diagram
38
39
USE CASE 1 Generate UML Profile.

Goal The goal of this use case is to organize UML profile and incorporate
meta model.
Purpose 1. Generate UML profile.
2. Organize UML profile.
3. Incorporate meta model.
Preconditions Administrator will request a model.

Success Condition Model elements extracted and build successfully.
Failed Condition Profile created unsuccessfully, display a message.
Post conditions Model will be retrieved from model db.
Primary Actors Administrator, Super user, Modular.
Secondary Actors Model db, UML profile db, UML db, Meta model db.
Trigger User requests for model.
DESCRIPTION Step Basic Course of Action
1 User will request a profile.
2 Requested profile is verified by the controller.
3 The Profile db extracts requested profile.
4 System will generate requested profile.
1. Process explicit requirements
5 GUI editor will display generated profile.
1.2. Validate explicit requirements
DESCRIPTION Step Alternate Course of Action
2.3. Store database
1 User will send request of edit (model).
3.4. Check
Display messageflow
sequence to user
2 System will accept the model request.
3 System will generate model elements.
4. Model db will store the model elements.
5 GUI will display the model elements.
6. System will give acknowledgement to user.
DESCRIPTION Step Error Scenario
If profile creation failed, model buildings failed then show an error
message.
Super ordinates Not applicable.
Subordinates Organize notation profile, Incorporate meta model.
40
USE CASE 1.1# Organize Notation Profile.

Goal The goal of this use case is to organize UML profile.
Purpose 1. Generate UML profile.
2. Organize UML profile.
Preconditions Administrator requests a Profile.
Success Condition Profile found successfully.
Failed Condition Profile created unsuccessfully.
Post conditions Notations have to be categorized, demonstrate a message.
Trigger User requests for profile.
1 User will request a profile (profile name).
2 System will verify the requested profile.
3 Profile notations will be extracted from db.
4 System will categorize the notations.

5 4.6. Validate
Notation explicit
db will store requirements
the notations.
5.7. Store
6. System
database
will exhibit notation to the user.
6.8. Check
Display messageflow
sequence to user
1 User will demand for a new profile (profile name).
2 Controller will accept request and will verify profile.
3 Profile db will create a new requested profile.
4. System will display message to interface.
5 System will display an acknowledgement to the user.

If profile creation failed and notation not categorized show error
message.
Super ordinates Generate UML Profile.
Subordinates Categorize notation, associate notation.
41
USE CASE 1.2# Incorporate Meta Model.

Goal The goal of this use case is to incorporate meta model.
Purpose 1. Extract behavior model element.
2. Build model elements.
Preconditions Administrator requests a model.
Success Condition Meta model generated successfully.
Failed Condition Meta model created unsuccessfully.
Post conditions Categorize notations, display a message.
1 User will send request for a model (name).
2 UML controller will generate model elements.
3 Model db will extract a model from db.
4 System will display model to an interface.

5 System will illustrate an acknowledgement to user.
7.10. Validate explicit requirements
DESCRIPTION Step 11. Store database Alternate Course of Action
8.
1 User will sendmessage
12. Display request to
to user
edit model (model name).
9. Check sequence flow
2 System will generate model elements.
3 Model db will store the model elements.
4. System GUI will display extracted model elements.
5 System will send an acknowledgement to user.

If building of a new model element failed, then display an error
message.
Super ordinates Generate UML Profile.
Subordinates Extract behavior model element, Build model element.
42
43
USE CASE 2 Manage security.

Goal The goal of this use case is to manage security.
Purpose 1. To Maintain profiles.
2. To Allocate workspace.
Preconditions Administrator requests a workspace.
Success Condition Maintain profile and allocate workspace to valid user successfully.
Failed Condition Allocation of workspace unsuccessful.

Post conditions Check profile status and display message.
Primary Actors Administrator.
Secondary Actors Login db, Profile db.
Trigger User requests (manage profile).
1 Administrator will request for a workspace (workspace name).
2 System will authenticate user.
3 GUI controller will check login status in login db.
4 Interface will display a message to user.
5 System will send acknowledgement to user.

14. Validate
User explicit
will request requirements
to manage profiles.
1
10.
15. Store database
2 System will verify user type.
11.
16. Display message to user
3 System willsequence
12. Check extract data
flowfrom db for valid user.
4. System will send display message at GUI.
5 GUI will generate an acknowledgement to user.

The requested workspace is allocated to an invalid user.
Super ordinates Not Applicable.
Subordinates Maintain Profile, Allocate Workspace.
44
USE CASE 2.1# Maintain profile.

Goal The goal of this use case is to Maintain profile.
Purpose 1. To Maintain profiles.
2. To maintain user login.
3. To manage profile rights.
Preconditions User requests a profile.
Success Condition Maintain profile successfully.
Failed Condition System failed at maintaining profiles.
Post conditions Check profile status and display message.
Secondary Actors Login db, UML Profile db.
Trigger User requests (manage profile).
1 System administrator will request Profile (profile name).
2 System will authenticate user by extracting authentication details.
3 System will check login status of user.
4 GUI will display a memo to user.
DESCRIPTION Step 17. Process explicitAlternate

requirements
Course of Action
18. Validate
13.
User explicit
to manage profiles.
1
19.
14. Store database
2 System will verify user type.
20. Check
15. Display messageflow
sequence to user
3 System will authenticate the user.
4. System will authenticate requested profile.
5 GUI will display profile to the user.

The requested profile is allocated to an invalid user.
Super ordinates Manage security.
Subordinates Maintain Login, manage profile rights.
45
USE CASE 2.2# Allocate workspace.

Goal The goal of this use case is to allocate workspace to an user.
Purpose 1. To create workspace.
2. To import workspace.
Preconditions Request is sent by an administrator.
Success Condition Allocation of workspace failed.
Failed Condition Invalid user gets workspace.
Post conditions Store created workspace.
Secondary Actors Login db, UML Profile db.
Trigger User requests workspace.
1 User will request for workspace (workspace name).
2 System will get workspace details from the user.
3 System will search workspace in db.
4 21. Process
System explicit
will create requirements
a new workspace.
22. Validate explicit requirements
16.
5 New workspace will be store workspace to db.
23. Store database
17.
6. System
24. Display
will generate
messageantoacknowledgement
user for a user.
1 System user will request for workspace.
2 System will get workspace details from the user.
3 System will create existing workspace.
4. System will store existing workspace to db.
5 Acknowledgement system will exhibit workspace to user.

If the creation of workspace failed then display error message.
Super ordinates Manage security.
Subordinates Create workspace, Import workspace.
46
47
USE CASE 3 Organize Meta Model.

Goal The goal of this use case is to provide meta model.
Purpose 1. Provide meta model.
2. Model diagram.
Preconditions Administrator requests a model.
Success Condition Meta model generated successfully.
Secondary Actors Model db, UML profile db, Meta model db, BPD notation db.
1 User will request notation (notation name).
2 System will retrieve notation from db.
3 System will generate diagram controllers.
4 GUI will exhibit diagram controllers.

5 System will illustrate an acknowledgement to user.
19.
20.
1 User will sendmessage
28. Check
Display request to
foruser
profile.
21. sequence flow
2 System will spawn diagram profile.
3 Method will exhibit diagram profile.
4. System will search (meta model) to db.
5 Meta-model db will extract meta model from db.
6. System GUI will display meta model to user.

Generating diagram controller failed extraction of model failed display
error message.
Subordinates Provide meta model, model diagram.
48
USE CASE 3.1# Provide meta model.

Goal The goal of this use case is to provide meta model.
Purpose 1. Provide meta model.
2. Extract meta model.
3. Provide notations.
Preconditions Administrator requests a notation.

Success Condition Notation extracted, Meta model generated successfully.
Trigger User requests for notation.
1 User will requests notation to system.
2 System regulator will retrieve notation from db.
3 System will return extracted notation.
4 GUI will exhibit (model) at user interface.

5 System will display meta model to user.
22.
23.
1 User will request
32. Check
Display to search
message notations (notation name).
to user
24. sequence flow
2 System will retrieve model from db.
3 GUI will present model to interface.
4. System will search meta model to db.
5 System will display meta model to user.

If retrieving meta model failed, then display error message.
Super ordinates Organize meta model.
Subordinates Extract meta model, retrieve notation.
49
USE CASE 3.2# Model diagram.

Goal The goal of this use case is to model diagram.
Purpose 1. Generate diagram profile.
2. Deliver diagram control.
Preconditions Administrator will request a diagram.
Success Condition Diagram controllers generated successfully.
Failed Condition Diagram controllers generated unsuccessfully.
Post conditions System will accumulate models.
Trigger User requests for diagram.
1 User will send request for diagram.
2 System will mine profile from db.
3 System will generate diagram controllers.
4 GUI will exhibit diagram controllers.
5 System will confirm concede to user.

DESCRIPTION Step 34. Validate explicitAlternate Course of Action
requirements
25.
1 User will propel
35. Store profile (profile name).
database
26.
2 36. Check
Display
System
27. messageflow
willsequence
generate to user profile.
diagram
3 System will save profile to UML profile db.
4. System GUI will display diagram profile.
5 System will save model to model db.
6. GUI will drive an acknowledgement to user.

If generating diagram in controller failed then display error message.
Super ordinates Organize meta model.

Subordinates Deliver diagram controls, generate diagram profile.
50
51
USE CASE 4 Manage Requirement.

Goal The goal of this use case is to capture requirements and trace requirements.
Purpose 1. Capture requirements.

2. Trace requirements.
3. Categorize requirements.
Preconditions Request will be sent by an administrator.

Success Condition Requirement captured and categorize correctly.
Failed Condition Requirement does not exist, send discard acknowledgement.
Post conditions Requirements are well categorized and commented.
Primary Actors Administrator, Super user, user.

Secondary Actors Requirement db.
Trigger User requests for requirement.
1 Administrator will request for release (project).
2 System will access existing requirements.
3 System will send (abridged and tokenized requirements).
4 37. Process
System explicit requirements
will determine requirement overlaps.
28.
5 System willdatabase
39. Store save requirements to requirement db.
29.
DESCRIPTION 40. Display message Alternate
Step 30. to user Course of Action
Check sequence flow
1 User will propel requirements.
2 System will search requirements in requirement db.
3 GUI will display resultant message.
4. System propels edit requirement.
5 System will demonstrate modified requirement.

Requirement not found, show error message.
Subordinates Capture requirement, Trace requirement.
52
USE CASE 4.1# Capture Requirement.

Goal The goal of this use case is to capture requirements.
Purpose 1. Capture requirements.
2 .Categorize requirements.
3. Modify requirements.

Success Condition Requirement captured and modified show acknowledgment.
Failed Condition Requirement does not exist, send discard acknowledgement.
Post conditions Requirements must be well categorized.
Trigger User requests for requirement.
1 User will send demand for requirements.
2 Requirement manager will admit requested requirement definitions.
3 Requirement manager will drive edited and tokenize requirements.

4 Requirement manager will extract subject verb and object.
31.
5 System willdatabase
43. Store Save it to requirement db.
32.
44. Check
sequence to user
1 User will request to modify requirements.
2 Requirement manager will search requested requirements.
3 Requirement manager will present message accordingly.
4. Requirement manager will update requirement db.
5 GUI will illustrate an acknowledgement to user.

The requested requirements were not found then show an error message.
Super ordinates Manage requirement.

Subordinates Acquire requirement definition, Categorize requirements.
53
USE CASE 4.2# Trace Requirement.

Goal The goal of this use case is to trace requirements and analyze ambiguity.
Purpose 1. Trace requirements.
2. Analyze ambiguity.
3. Determiner requirement overlap.
Preconditions Request will be sent by an administrator.

Success Condition Requirement captured and analyzed correctly.
Failed Condition Requirement overlapped, send discard acknowledgement.
Post conditions A requirement has to be well categorized and resolved.

Trigger User requests for open project.
1 User will open project.
2 System will reclaim requirements.
3 Requirement manager will resolve ambiguity.
4 45. Process manager

Requirement explicit requirements
will determine requirements overlap.
34.
5 GUI will present requirements to user.
47. Store database
35.
DESCRIPTION 48. Display message Alternate
Step 36. to user Course of Action
Check sequence flow
1 User will request requirements.
2 System will accept request.
3 Requirement manager will fetch requirements from db.
4. System will seek out requirement db.
5 System will exhibit message to user.

If the requested requirements overlapped then illustrate an error message
to user.
Subordinates Capture requirement, Trace requirement.
54
55
USE CASE 5 Manage BPD.

Goal The goal of this use case is to manage BPD (Business Process Diagrams).
Purpose 1. Validate Requirements.

2. Manage meta models.
3. Store BPD to db.
Preconditions User should be administrator.

Success Condition BPD stored to database successfully.
Failed Condition Discarded requirements and displayed error message.
Post conditions BPD diagram modeled correctly with their syntax.
Secondary Actors BPD db, Notation db, Database db.
Trigger User will request.

1 System will accept request from user.
2 1. Process
BPD_ managerexplicit requirements
will Process explicit requirements.
3 BPD_ manager validate explicit requirements.
3. Store database
4 BPD _ db willmessage
4. Display store profile to db.
to user
5 System will display a message to user.

2 BPD _ manager will accept implicit requirements.
3 BPD _ manager will process requirement.
4. BPD _ db will store profile to db.
5 System will display BPD to user.

The system will show an error message if user is not an administrator.

Subordinates Accept explicit requirements, Notify implicit requirements.
56
USE CASE 5.1# Develop BPD.

Goal The goal of this use case is to develop BPD (Business Process Diagrams) to
capture needs, provide notations and apply BI rules.
Purpose 1. Capture needs.
2. Provide notations.
3. Apply BI (Business Intelligence Rules).
Preconditions BPD notations are correct.
Success Condition BPD created successfully and stored to BPD manager.
Failed Condition Incorrect sequence flow of BPD and show error message.
Post conditions BPD diagram created correctly with their syntax.
Primary Actors Administrator, Super user.
Secondary Actors BPD db, BPD Notation db, BPD requirement db.
Trigger User request for open new project.
1 User will send request for new project.
2 49. Process
BPD_ explicit
manager requirements
retrieve notations from db.
37.
3 BPD_ manager will check sequence flow.
51. Store database
38.
4 BPD _ manager
52. Check
Display will apply
message BI_ rules.
to user
39. sequence flow
5 System will store project to BPD db.
6. System will propel user acknowledgement.

1 User will enter (BPD name).
2 System will search BPD _ db.
3 BPD _ manager will return condensed BPD.
4. System will accumulate it to BPD _ db.
5 GUI will display BPD to the user.

If BPD (Business process diagram) is not found then display an error
message to user.
Super ordinates Manage BPD.
Subordinates Capture needs, Provide notations, and Apply BI rules.
57
USE CASE 5.2# Process BPD (Business process diagrams).

Goal The goal of this use case is to Process BPD (Business Process Diagrams),
Accept explicit requirements and notifies implicit requirements.
Purpose 1. Accept explicit requirements.

2. Notify implicit requirements.
Preconditions Developed BPD should be correct.
Success Condition BPD processed successfully and stored to BPD db.
Failed Condition Invalid explicit requirement, discard BPD.
Post conditions BPD processed correctly.
Secondary Actors BPD db, BPD Notation db, BPD requirement db.
Trigger User requests for process BPD.

1 User will send explicit requirements.
2 BPD_ manager validate explicit requirements.
3 System will generate the implicit requirements.

40.
4 System will store
54. Validate the requirements
explicit requirementsto requirement_ db.
41.
55. Check
42. Store
System willdatabase
sequence
display aflow
message to user.
5
2 BPD_ manager will accept implicit requirements.
3 BPD_ manager will process requirements.
4. System will store the requirements to requirement_ db.
5 System will display BPD to the user.

6. System will show an acknowledgement to user.
If there is an invalid explicit requirement then display error message to
user.
Super ordinates Manage BPD.
Subordinates Accept explicit requirements, Notify implicit requirements.
58
59
USE CASE 6 Built domain modeler.

Goal The goal of this use case is to build a domain and provide domain model
notations.
Purpose 1. Structure domain information.
2. Build domain vocabulary.
3. Provide domain.
Success Condition Domain built successfully and provided correct notations then saved
to db.
Failed Condition Invalid domain details, incorrect domain vocabulary.
Post conditions
Secondary Actors Model db, domain notation db, domain db.
Trigger User requests for build and provide domain notations.
1 User will request to build domain (domain name).
2 Domain_ manager will build domain vocabulary.
3 Domain _manager will edit domain.
4 System will fetch vocabulary from vocabulary_ db.

43.
5 GUI_ editor will
58. Validate
44. display
explicit the domain.
requirements
6. 59. Check
System
45. Store
willdatabase
show an acknowledgement
sequence flow to user.
DESCRIPTION Step 60. Display messageAlternate

to user Course of Action
1 User will send a request to edit (notations).

2 Domain _ manager will fetch model from notation _db.
3 Domain_ manager will Build domain vocabulary.
4. System will store notations to notation_ db.
5 GUI will display notations to the user.

If building of domain vocabulary failed or association of domain
model failed then system will show an error message.
Subordinates Build domain, provide domain model notation.
60
USE CASE 6.1 Build domain.

Goal The goal of this use case is to build a domain vocabulary and structure
information.
Purpose 1. Structure information.
2. Build domain vocabulary.
Success Condition Domain built successfully.
Post conditions Build domain vocabulary successfully.
Trigger User requests for build and provide domain notations.
1 User will request to build domain (domain name).
2 Domain_ manager will get domain details from user.
3 System will search domain vocabulary in db.
4 System will build a domain vocabulary.

5 62. Validate
System
46. explicit
will store requirements
domain in domain_ db.
63. Store database
47.
6. System will send an acknowledgement to the user.
64. Check
sequence to user
1 User will send request to modify domain.
2 Domain_ manager will fetch domain from domain_ db.
3 System will build domain vocabulary.
4. System will store notations to notation_ db.
5 GUI will display notations to the user.
6. System will show an acknowledgement to the user.

If building of domain vocabulary failed or association of domain model
failed then display error message to the user.
Super ordinates Built domain modeler.
Subordinates Structure domain information, Build domain vocabulary.
61
USE CASE 6.2 Provide domain model notation.

Goal The goal of this use case is to associate domain model and provide domain
notations.
Purpose 1. Associate domain model.
2. Provide domain model notations.
Preconditions Notation Notation request is sent by an administrator.
Success Condition Notation generated successfully.
Post conditions Build domain vocabulary successfully.
Primary Actors Administrator, Super user
Trigger User requests for notation.
1 User will request notation (notation name).
2 System will extract notation from domain _notation db.
3 Domain organizer will display notation to interface.
4 System will store notations to notation_ db.
5 65. Process
System explicitdomain
will display requirements
model notations to user.
DESCRIPTION Step 49. Alternate Course of Action
1 67. Store database
50. will request for edit notations (notation name).
User
68. Check
sequence to user
2 Domain _manager will accept user request.
3 System will fetch notations from domain notation_ db.
4. System will display notations to GUI.

Error will occur if providing domain model notation failed and
generation of model failed.
Super ordinates Built domain modeler.
Subordinates Associate domain model, provide domain notations.
62
63
USE CASE 7 Perform model transformation

Goal The goal of this use case is to Perform transformation of model
Purpose 1. Extract mete model.
2. Transform meta model.
Preconditions User should have a model.
Success Condition Meta model extracted successfully.
Failed Condition System failed at extracting and transforming a model.
Post conditions Store extracted model to db.
Primary Actors Super user.
Secondary Actors Model db, meta model db.
Trigger System accept requested model (model).

1 User will send request for model (model name).
3 Meta-model controller will transform model to required model.
4 System will extract meta-model from meta-model db.
5 System will show an acknowledgement to user.
DESCRIPTION Step 69. Process explicit Alternate Course of Action

requirements
1 User
70. Validate
will request
explicit
for search
requirements
model (model name).
52.
71. Store database
2 53.
Meta-model controller will authenticate user.
3 System will transform model to required model.
4. Meta-model controller will store result to model db.

If the profile allocated to invalid user then error message will be
displayed.
Subordinates Extract meta model, Transform meta model.
64
USE CASE 7.1# Extract meta model.

Goal The goal of this use case is to Extract meta model.
Purpose 1. Associate meta model.
2. Integrate model.
Preconditions User should have a model.
Success Condition Meta model extracted successfully.
Failed Condition System failed at extracting a model.
Primary Actors Super user.

1 User will send request for model (model name).
3 Meta model manager will extract requested meta model from meta-model
db.
4 System will associate meta-model.

55. will request for (search
1 User model).
75. Store database
56.
76. Check
sequence to user
3 Meta- model controller will extract requested meta model.
4. System will associate meta-model model.

If meta model extracted partially then error message will be displayed at
GUI.
Super ordinates Perform model transformation.
Subordinates Associate meta model, integrate meta model.
65
USE CASE 7.2# Transform Meta-model.

Goal The goal of this use case is to Transform Meta-model.
Purpose 1. Acquire Transformation rules.
2. Implement Transformation.
Preconditions User should have a meta model.
Success Condition Meta model transformed successfully.
Failed Condition System failed in transforming a meta model.
Post conditions Store Transformed meta model to db.
Primary Actors Super user

1 User will send meta model (meta-model name).
2 System will validate user.
3 Meta-model organizer will acquire transformation rules.
4 System will perform meta-model transformation.
DESCRIPTION Step 58. Alternate Course of Action

1 78. Validate
User explicit
for (search meta model).
59.
79. Store database
2 60. Check
System willsequence flowuser.
authenticate
3 Meta-model controller will acquire transformation rules.
4. System will employ meta-model transformation.
5 System will store result to meta-model db.

The fatal error could be of meta model transformed partially; this will
display an error message to user.
Super ordinates Perform model transformation.
Subordinates Acquire Transformation rules, Implement Transformation.
66
67
USE CASE 8 Perform workflow checking.

Goal The goal of this use case is to check workflow.
Purpose 1. Schedule workflow.
2. Build workflow traceability.
Preconditions Workflow should be available at system.
Success Condition Workflow elements checked thoroughly.
Failed Condition System failed at checking workflow.
Secondary Actors Notation db, model db, domain db.
Trigger System accepts requested model.
1 Administrator will send model.
2 System will check workspace elements.
3 System will determine changes.
4 System will save changes to domain db.
5 System will show an acknowledgement to administrator.
DESCRIPTION Step 81. Process explicit Alternate Course of Action

requirements
61.
1 User will request
82. Validate search
explicit model (model name).
requirements
62.
2 83. Store
System database
manager will flow
authenticate user.
63. Check sequence
3 System will accommodate changes.
4. System will perform workflow check on model.

If workflow model checking performed partially then system will
display error message.
Subordinates Schedule workflow, Build workflow traceability.
68
USE CASE 8.1# Schedule Workflow.

Goal The goal of this use case is to schedule workflow.
Purpose 1. Check flow of elements.
2. Check element relation.
Success Condition Workflow elements scheduled properly.
Failed Condition System failed at scheduling workflow model.
Post conditions Forward scheduled workflow for further element checking and
accommodation of changes.
Trigger System accepts requested model workflow.

1 Administrator will send workflow model (model name).
3 System manager will ensure workflow elements relationships.
4 System will check flow of elements in workflow.
DESCRIPTION Step 85. Process explicit requirements

Alternate Course of Action
64.
1 Administrator will search
86. Validate explicit workflow model.
requirements
65.
2 87. Check
Store
System
66. willdatabase
authenticate
sequence flowuser.
3 System will accommodate changes manually.
4. Perform workflow check on workflow model by user itself.
5 Administrator will stores result to model db.

If there is wrong relationship in workflow elements then error will be
generated by system.
Super ordinates Perform workflow checking.
Subordinates Check flow of elements, Check element relation.
69
USE CASE 8.2# Build workflow traceability.

Goal The goal of this use case is to build traceability of workflow.
Purpose 1. Determine changes.
2. Accommodate changes.
Success Condition Changes in workflow elements done successfully.
Failed Condition Changes done in workflow model are not satisfactory.
Post conditions Store the changes to db done in workflow model.
Trigger System accepts requested model workflow.

3 System manager will determine changes to elements.
4 System will accommodate changes.
DESCRIPTION Step 89. Process explicit requirements

67.
1 User will request
90. Validate search
explicit workflow model.
requirements
68.
2 91. Check
69. Store
System willdatabase
check workspace
sequence flow elements.
3 System will determine and accommodate changes.
4. System will store changes to model db.

If unexpected changes done in workflow elements then error will occur.
Super ordinates Perform workflow checking.

Subordinates Determine changes, accommodate changes.
70

System
Behavior: Sequence Diagram
71
Goal 1: Generate UML Profile

1.1 Organize Notation Profile.
Basic Course of Action
72

1.1 Organize Notation Profile
73
Scenario Description
Informational Item Information

Use Case 1.1# Generate UML Profile.
Scenario Name Organize Notation Profiles.
Basic Course of 1. User will request profile (profile name).
Action [BCA]
2. System will accept request.
3. System will verify profile.
4. If profile not found to system.
5. Then display an error message at GUI.
6. If system finds profile successfully.
7. Then display profile at GUI.
8. System manager will request notations (name).
9. System will accept requested notations.
10. System will extract notations from notation db.
11. System will categorize notations.
12. GUI will display notations.
Alternate Course of 1. User will request for create (new_ profile).

Action [ ACA ]
2. System will create new profile.
3. If profile created fruitlessly.
4. Then System will Display message at GUI.
6. If profile created successfully.
7. Then System will fetch notations from notation db.
8. System will verify notations.
9. System will return notation.
74

1.2 Incorporate Meta-Model.
75

1.2 Incorporate Meta-Model.
76

Use Case 1.2# Generate UML Profile.
Scenario Name Incorporate meta model.
Basic Course of Action 1. User will request model (model name).
[BCA]
2. System will extract model elements from model db.
3. System will return model elements.
4. GUI will display model elements.
5. System will send (model elements).
6. System will build meta-model.
7. System will retrieve meta-model from model db.
8. System will send (meta-model).
9. System will build models.
10. System will return meta-model elements.
11. GUI will display generated meta-models.
Alternate Course of 1. User will request for edit (model).

Action [ ACA ]
2. System will extract model elements from model db.
3. GUI will display extracted models.
4. System manager will get (meta-model).
5. System will build meta-model elements.
6. System will build model elements.
7. GUI will display new models.
8. System will send an acknowledgement to user.
77
Goal 2 Manage Security
2.1 Maintain Profile.

78

2.1 Maintain Profile
79
Use Case 2.1# Manage Security.
Scenario Name Maintain profiles.
Basic Course of Action 1. User will request for (manage profile).

[BCA]
2. System will verify user type.
3. System will maintain (profile).
4. System will maintain login.
5. System will maintain profile rights.
6. System will check login status.
7. System will display message to interface.
8. System will display user acknowledgment.
Alternate Course of 1. User will request (manage profiles).

Action [ ACA ]
2. System will verify user type.
3. System will maintain (Profile).
4. System will maintain profile db.
5. System manager will check profile status.
6. System will display message at GUI.
7. System will send user acknowledgement.
80
Goal 2 Manage Security.

2.2 Allocate Workspace
81

82
Use Case 2.2# Manage security
Scenario Name Allocate Workspace
Basic Course of Action 1. User will request workspace(workspace name)

[BCA]
2. System will accept details
3. System will authenticate user.
4. System manager will create workspace.
5. System will allocate workspace.
6. System will check user validation.
7. System GUI will display workspace.
Alternate Course of 1. User will request workspace.

Action [ ACA ]
2. System will accept details.
3. System manager will authenticate workspace.
4. System will search existing workspace.
5. System will update UML profile db.
6. GUI will display workspace to user.
83
Goal 3 Organize Meta –model

3.1 Provide meta-model.
84

3.1 Provide meta-model
85

Use Case 3.1# Provide meta model.
Scenario Name Organize meta model.
Basic Course of Action 1. User will request (notation).
[BCA]
2. System will accept request from user.
3. System will retrieve notation from db.
4. Return extracted notation to meta-model manager.
5. System will send notation.
6. Meta-model manager will extract model from db.
7. System will display (model) at user interface.
8. System will accept requested model.
9. System will retrieve meta model.
10. GUI will display meta model.
Alternate Course of 1. User will request to Search (notations).

Action [ ACA ]
2. System will retrieve notations from notation db.
3. System will send (notation).
4. System will retrieve model from db.
5. System will return model to GUI.
6. GUI will display model to interface.
7. System will search (meta model).
8. System will retrieve meta model.
9. GUI will display meta model to user.
86

3.2Model Diagram
87

3.2 Model Diagram
88
Use Case 3.2# Organize meta model.
Scenario Name Model diagram.
Basic Course of Action 1. User will request diagram.

[BCA]
3. System will extract profile from profile db.
4. System will retrieve diagram profile from profile db.
5. System will retrieve requested model.
6. System will produce diagram controllers.
7. GUI will display diagram controllers.
8. Interface will show an acknowledgement to user.
Alternate Course of 1. User will send Profile.

Action [ ACA ]
2. System will spawn diagram profile.
3. System will save profile to profile db.
4. System will return Profile to GUI.
5. GUI will display diagram profile.
6. User will send model (model name).
7. System will generate diagram controller.
8. System will save model to model db.
9. System will return diagram controller.
10. GUI will display diagram controllers.
89
Goal 4 Manage Requirement

4.1 Capture Requirements
90

4.1 Capture Requirements
91
Use Case 4.1# Manage Requirement.
Scenario Name Capture requirement.

[BCA]
1. User will send demand for requirements.
2. Requirement manager will admit requested requirement definitions.
3. Requirement does not exist, send discard acknowledgement.
4. Requirement manager will drive edited and tokenize requirements.
5. Requirement manager will extract subject verb and object.
6. System will save it to requirement db.
Alternate Course of 1. User will request to modify requirements.

Action [ ACA ]
2. Requirement manager will search requested requirements.
3. Requirement manager will present message accordingly.
4. Requirement manager will update requirement db.
5. System will return requirements to GUI.
6. GUI will illustrate an acknowledgement to user.
92

4.2 Trace Requirements.
93

4.2 Trace Requirements
94
Use case 4.2# Manage Requirement
Scenario Name Trace Requirements
Basic Course of 1. User will open project.

Action [BCA]
2. System will reclaim requirements.
3. Requirement manager will resolve ambiguity.
4. System will return message to GUI.
5. Requirement manager will determine requirements overlap.
7. GUI will present requirements to user.
Alternate Course of 1. User will request requirements.

Action [ ACA ]
3. Requirement manager will fetch requirements from db.
5. System will seek out requirement db.
6. System will exhibit message to user.
95
Goal 5 Manage BPD

5.1 Develop BPD
96
Goal 5 Manage BPD

5.1 Develop BPD
97

Use Case 5.1# Manage BPD
Scenario Name Develop BPD
Basic Course of 1. User will Open(new project)

Action [BCA]
2. System will capture needs
3. System will accept BPD names
4. BPD_ manager will create BPD
5. System will request notations
6. BPD_ manager will retrieve notations from db
7. System will associate notations
8. System will check sequence flow
9. If sequence is correct
10. Then system will apply BI_ rules
11. System will store BPD to db
12. System will display BPD to user
Alternate Course of 1. User will open(existing projects)

Action [ ACA ]
2. User will enter( BPD name)
3. System will search db
4. If BPD not found then
5. System will display an error message to user
6. If BPD is found then
7. System will return edited BPD
8. System will apply BI rules
9. System will save it to db
10. System will display BPD to user
98
Goal 5 Manage BPD

5.2 Process BPD
99
Goal 5 Manage BPD

5.2 Process BPD
100
Use Case 5.2# Manage BPD
Scenario Name Process BPD
Basic Course of Action 5. System will accept request from user.

[BCA]
6. System will accept explicit requirements.
7. BPD_ manager will process explicit requirements.
8. System will validate explicit requirements.
9. If requirement not valid then discard requirements.
10. System will display error message.
11. System will store requirements to requirements db.
12. System will generate implicit requirements.
13. System will save to database.
14. System will display message to user.
Alternate Course of 1. System will accept request from user.

Action [ ACA ]
2. System will accept explicit requirements.
3. System will accept implicit requirements.
4. BPD_ manager will process requirements.
5. System will validate requirement.
6. System will save it to db.
7. System GUI will display BPD to user.
101
Goal 6 Build Domain Modeler

6.1 Build Domain
102

6.1 Build Domain.
103

Use Case 6.1# Build Domain Modeler
Scenario Name Build Domain
Basic Course of 1. User will request to build(domain)
Action [BCA]
2. System will accept request from user
3. System will get domain details from user
4. System will enter (domain details)
5. Domain organizer will retrieve domain vocabulary from db
6. System will search domain vocabulary in db
7. System will build domain
8. System will build domain vocabulary
9. System will Store it to domain db
10. GUI will display domain to user
Alternate Course of 1. User will request to edit domain

Action [ ACA ]
2. System will fetch domain from domain db
3. System will extract domain
4. GUI will display domain to user
5. System will request to edit
6. Domain organizer will request vocabulary from db
7. System fetch vocabulary
8. System manager will edit domain
9. System will build domain vocabulary
10. System will store it db
11. System will return updated domain
12. GUI will display information to user
104

6.2 Provide Domain Model Notations
105

6.2 Provide Domain Model Notations
106
Use Case 6.2# Build Domain Modeler.
Scenario Name Provide Domain Model Notations.
Basic Course of Action 1. User will request (notation).

[BCA]
2. System will accept request from user.
3. System will extract notation from db.
4. GUI will display notation to interface.
5. System will request (models).
6. Domain organizer will retrieve models.
7. System will generate domain model notations.
8. System will store it to db.
9. System GUI will display domain model notations.
Alternate Course of 1. User requests for edit (notations).

Action [ ACA ]
2. System will extract notations from db.
3. System will send (models).
4. Domain organizer will fetch model from db.
5. System will generate domain model notation.
6. System will display notation to user.
107
Goal 7 Model Transformation

7.1 Extract Meta-model
.
108

7.1 Extract Meta-model.
109
Use Case 7.1# Perform Model Transformation.
Scenario Name Extract meta-model.

[BCA]
1. User will send request for model (model name).
3. Meta model manager will extract requested meta model from meta- model
db.
4. System will associate meta-model.
Alternate Course of
Action [ ACA ]
1. User will request for (search model).
3. Meta- model controller will extract requested meta model.
4. System will associate meta-model model.
5. System will return message to GUI.
6. GUI will display model.
110

7.2 Transform Meta-model.
111

7.2 Transform Meta-model
112
Use Case 7.2# Perform Model Transformation.
Scenario Name Transform meta-model.

[BCA]
1. User will send meta model (meta-model name).
2. System will validate user.
3. Meta-model organizer will acquire transformation rules.
4. System will perform meta-model transformation.
5. System will return to GUI.
Alternate Course of
Action [ ACA ]
1. User will request for (search meta model).
3. Meta-model controller will acquire transformation rules.
4. System will employ meta-model transformation.
5. System will store result to meta-model db.
6. System will return message to user.
113
Goal 8 Perform Workflow Checking

8.1 Schedule Workflow
114

115
Use Case 8.1# Perform Workflow Checking.
Scenario Name Schedule Workflow.

[BCA]
1. Administrator will send workflow model (model name).
2. System will accept model.
3. System will check workspace elements.
4. System manager will ensure workflow elements relationships.
5. System will check flow of elements in workflow.
6. Reply workflow model to GUI.
7. System will show an acknowledgement to administrator.
Alternate Course of
Action [ ACA ]
1 Administrator will search workflow model.
3. System will accommodate changes manually.
4. Perform workflow check on workflow model by user itself.
5. Reply model to GUI.
6. Administrator will stores result to model db.
116

8.2 Build Workflow Traceability
117

8.2Build Workflow Traceability
118
Use Case 8.2# Perform Workflow Checking.
Scenario Name Build workflow Traceability.

[BCA]
3. System will forward elements.
4. System manager will determine changes to elements.
5. System will accommodate changes.
6. System will show an acknowledgement to administrator.
Alternate Course of
Action [ ACA ]
1. User will request search workflow model.
3. System will forward elements.
4. System will determine and accommodate changes.
5. System will store changes to model db.
6. Workflow db will reply to GUI.
7. System GUI will send an acknowledgement to user.
119

System
Behavior: State Chart Diagram
120
Goal 1 Generate UML profile.
1.1 Organize Notation Profile.
121
1.2 Incorporate Meta-model
122
123
124
Goal 3 Organize Meta-model
3.1 Provide Meta-model
125
3.2 Model Diagram
126
4.1 Capture Requirement
127
4.2 Trace Requirement
128
Goal 5 Manage BPD
5.1 Develop BPD
129
5.2 Process BPD
130
6.1 Build Domain
131
6.2 Provide Domain Model Notation
132
Goal 7 Perform Model Transformation
7.1 Extract Meta-model
133
7.2 Transform Meta-model
134
135
8.2 Built Workflow Traceability
136

System
Behavior: Activity Diagram
137
Goal 1 Generate UML Profile
1.1Organize Notation Profile
138
1.2 Incorporate Meta-model
139
140
2.2 Allocate Workspace.
141
Goal 3 Organize Meta-model
3.1 Provide Meta-model
142
3.2 Model Diagram
143

.
4.1 Capture Requirement
144
4.2 Trace Requirement.
145
Goal 5 Manage BPD
5.1 Develop BPD
146
5.2 Process BPD
147
Goal 6 Build Domain Modeler.
6.1 Build Domain.
148
6.2 Provide Domain Model Notation.
149
7.1 Extract Meta-model.
150
7.2 Transform Meta-model.
151
152
8.2 Built workflow
153

System
System Design Document
154
CLASS DIAGRAM
155
1. CRC TEMPLATE #1
Class Name Generate UML Profile.

Class Type Control object.
Characteristics Tangible.
Super class NONE.
Subclass 1) Organize Notation Profile.
2) Incorporate Meta-model.
Variables 1) Model details: string.
2) Profile details: string.
3) Notation details: string.
Services 1) Accept request from user.
2) Verify request.
3) Process request.
4) Generate model elements.
5) Extract model elements.
6) Accept model elements.
7) Process model elements.
8) Generate meta-model.
9) Extract meta-model.
10) Store models.
11) Check models.
12) Store meta-model elements.
13) Extract profile.
14) Verify notation request.
15) Extract notation.
16) Categorize notation.
17) Store notation.
18) Store profile.
Responsibilities Collaborators
1)Manage Meta-model() Model db.

2)Modify Meta-model() UML Profile db.
3)Add Meta-model() UML db.
4Build Model() Meta-model db.
5)Provide Notation()
6)Add Notation()
7)Retrieve Model()
8)Display Notation Profile()
156
2. CRC TEMPLATE #1.1
Class Name Organize Notation Profile.

Super class Generate UML profile.
Subclass NONE.
Variables 1) Profile details: string.

2) Verify request.
3) Process request.
4) Extract Profile.
5) Verify notation request.
6) Extract notation.
7) Categorize notations.
8) Store notation.
9) Store profile.
1)Accept Profile Details() Model db.

2)Display Messages() UML Profile db.
3)Display Profile() UML db.
4)Provide Notation() Meta-model db.
5)Create New Profile()
6)Add Notations()
7)Retrieve Notations()
8)Add model()
9)Retrieve Model()
10)Manage Meta-model ()
11)Display Notation Profile()
157
Class Name Incorporate Meta-model.

Super class Generate UML profile.
Subclass NONE.

2) Verify request.
3) Process request.
4) Generate model elements.
5) Extract model elements.
6) Accept model elements.
7) Process model elements.
8) Generate meta-model.
10) Store models.
11) Check models.
12) Store meta-model elements.
1)Accept Model Details() Model db.

2)Display Messages() UML Profile db.
3)Open Model Window() UML db.
4) Edit Model Window () Meta-model db.
5) Open Meta-model Window ()
6)Manage Meta-model()
7)Modify Meta-model()
8)Add Meta-model()
9)Build Model()
158
4. CRC TEMPLATE #2
Class Name Manage security.

Super class NONE.
Subclass 1) Maintain profile.
2) Allocate workspace.
Variables 1) User id: string.
2) Password: string.
Services 1) Accept details.

2) Authenticate user.
3) Create workspace.
5) Update db.
6) Existing workspace.
7) Verify user type.
8) Maintain login.
9) Maintain profile rights.
10) Maintain db.
1)Allocate New Workspace() Login db.

2)Allocate Existing Workspace() Profile db.
3)Display Workspace()
4)Auto Maintain()
5)Manage Profile()
6)Maintain Login()
7)Maintain Profile Rights()
159
Class Name Maintain profile.
Super class Manage security.
Subclass NONE.

Services 1) Verify user type.

2) Maintain login.
3) Maintain profile rights.
4) Maintain db.
1)Manage Profile() Login db.

2)Maintain Login() Profile db.
3)Maintain Profile Rights()
4)Auto Maintain()
160
Class Name Allocate workspace.

Super class Manage security.

Subclass NONE.

Services 1) Accept details.

2) Authenticate user.
3) Create workspace.
5) Update db.
6) Existing workspace.
1)Allocate New Workspace() Login db.

2)Allocate Existing Workspace() Profile db.
3)Display Workspace()
161
7. CRC TEMPLATE #3
Class Name Organize Meta-model.

Super class NONE.
Subclass 1) Provide Meta-model.
2) Model Diagram.

2) Check request.
3) Process request.
4) Retrieve notations.
5) Process notations.
6) Generate model.
7) Extract model.
8) Accept model.
9) Process model.
10) Generate meta-model element.
11) Retrieve meta-model.
12) Built notations.
13) Save in database.
14) Acquire meta-model.
15) Built diagram profile.
16) Generate diagram controllers.
17) Accept profile.
18) Process profile.
19) Save profile.
1)Modify Notation() Model db.

2) Retrieve Notation () UML Profile db.
3) Modify Model() BPD Notation db.
4) Retrieve Model () Meta-model db.
5)Display Meta-model()
6)Request Diagram()
7)Extract Profile()
8)Retrieve Diagram Profile()
9)Generate diagram Profile()
10)Display Diagram Controllers()
162
Class Name Provide Meta-model.

Super class Organize Meta-model.
Subclass NONE.

2) Check request.
3) Process request.
5) Process notations.
6) Generate model.
7) Extract model.
8) Accept model.
9) Process model.
10) Generate meta-model element.
11) Retrieve meta-model.
12) Built notations.
13) Save in database.
14) Acquire meta-model.
1)Modify Notation() Model db.

2) Retrieve Notation () UML Profile db.
3) Modify Model() BPD Notation db.
4) Retrieve Model () Meta-model db.
5)Display Meta-model()
163
Class Name Model Diagram.

Subclass NONE.
Variables 1) Diagram details: string.
2) Diagram Request: string.

2) Check request.
3) Process request.
4) Built diagram profile.
5) Generate model.
6) Retrieve model.
7) Generate diagram controllers.
8) Accept profile.
9) Process profile.
10) Save profile.
11) Accept model.
12) Save model.
1)Request diagram() Model db.

2) Extract Profile () UML Profile db.
3)Send Profile() BPD Notation db.
4) Retrieve Diagram Profile () Meta-model db.
5) Generate Diagram Profile ()
6)Display Diagram Controllers()
164
10. CRC TEMPLATE #4
Class Name Manage Requirements.

Super class NONE.
Subclass 1) Capture Requirements.
2) Trace Requirements.
Variables 1. Requirement name: string.
2. Need: string.

2) If requirement exits show
acknowledgement.
3) Enter new request.
4) Extract subject and verb and object.
5) Categorize requirements.
6) Save data to database.
7) Update database.
8) Search requirements.
9) Retrieve requirements.
10) Compare requirements.
11) Analyze ambiguity.
12) Resolve ambiguity.
13) Determine requirement overlap.
1)Accept Details() Requirement db.

2)Modify Requirements()
3)Acquire New Requirements()
4)Process Requirements ()
5)Edit Requirements()
6)Discard Requirements()
7)Categorize Requirements()
8)Analyze Requirements()
9)Retrieve Requirements()
10)Compare Requirements()
165
Class Name Capture Requirements.

Super class Manage Requirements.
Subclass NONE.
Variables 1) Requirement name: string.
2) Need: string

2) If requirement exits show
acknowledgement.
3) Enter new request.
4) Extract subject and verb and object.
6) Save data to database.
7) Update database.
8) Search Requirements.
1)Accept Details() Requirement db.

2)Modify Requirements()
3)Acquire New Requirements()
4)Process Requirements ()
5)Edit Requirements()
6)Discard Requirements()
7)Categorize Requirements()
166
Class Name Trace Requirements.

Super class Manage Requirements.
Subclass NONE.
Variables 1. Requirement name: string.

2) Retrieve requirements.
3) Compare requirements.
4) Save to database.
5) Update database.
1)Analyze Ambiguity() Requirement db.

2)Resolve Ambiguity()
3)Determine Requirement Overlap()
4)Retrieve Requirements()
5)Acquire Requirements()
6)Modify Requirements ()
7)Compare Requirements()
167
13. CRC TEMPLATE #5
Class Name Manage BPD.

Super class NONE.
Subclass 1) Develop BPD.
2) Process BPD.
Variables 1) Requirement: string.
2) Need: string.
3) BPD name: string.
Services 1) Capture needs.

2) Accept BPD name.
4) Associate notations.
5) Check sequence flow.
6) Store to BPD manager.
7) Update BPD manager.
8) Process explicit requirement.
9) Validate explicit requirement.
1)Create BPD() BPD db.

2)Open Existing BPD() BPD notation db.
3)Associate Notations() Requirement db.
4)Apply BI Rules()
5)Accept Explicit Requirement()
6)Accept Implicit Requirement()
7)Generate Implicit Requirement()
8)Process BPD
168
Class Name Develop BPD.

Super class Manage BPD.
Subclass NONE.
Variables 1) Needs: string.
2) BPD name: string.
Services 1) Capture needs.

2) Accept BPD name.
3) Create BPD.
5) Check sequence flow.
6) Sequence correct.
7) Store to BPD manager.
8) Update BPD db.
9) Search db.
1)Create BPD() BPD db.

2)Open Existing BPD() BPD notation db.
3)Associate Notations() Requirement db.
4)Apply BI Rules()
5)Store db()
169
Class Name Process BPD.

Super class Manage BPD.
Subclass NONE.
Services
1) Process explicit requirement.
2) Validate explicit requirement.
3) Store db.
4) Create BPD.
5) Forward to database.
6) Accept implicit requirement.
7) Process requirement.
8) Save requirement.
1)Accept Explicit Requirement() BPD db.

2)Process Explicit Requirement() BPD Notation db.
3)Generate Implicit Requirement() Requirement db.
4)Process BPD()
5)Save BPD()
170
16. CRC TEMPLATE #6
Class Name Build Domain modeler.

Super class NONE.
Subclass 1) Build Domain.
2) Provide Domain Model Notations.
Variables 1) Notation details: string.
2) Domain name: string.
3) Domain details: string.

2) Verify request.
3) Process request.
4) Extract notations.
5) Accept model.
6) Process model.
7) Store in database.
8) Perform modification.
9) Structure domain information.
10) Build domain.
11) Extract domain.
1)Get Notation() Model db.

2)Edit Notation() Domain notation db.
3)Create Notation() Domain db.
4)Retrieve Notation()
5)Add Notation()
6)Get Model()
7)Retrieve model()
8)Add model()
9)Generate Domain Model Notation()
11)Access Existing Domain()
12)Create New Domain()
13)Modify Domain()
171
Class Name Build Domain.
Super class Build Domain modeler.
Subclass NONE.
Variables 1) Domain name: string.

2) Domain details: string.

2) Structure domain information.
3) Search in database.
4) Build domain.
5) Extract domain.
1)Access Existing Domain() Model db.

2)Create New Domain() Domain notation db.
3)Modify Domain() Domain db.
4)Build Domain vocabulary()
172
Class Name Provide Domain Model Notation.

Super class Build Domain modeler.
Subclass NONE.
Variables 1) Notation details: string.

2) Verify request.
3) Process request.
4) Extract notations.
5) Accept model.
6) Process model.
8) Perform modification.
1)Get Notation() Model db.

2)Edit Notation() Domain notation db.
3)Create Notation() Domain db.
4)Retrieve Notation()
5)Add Notation()
6)Get Model()
7)Retrieve model()
8)Add model()
9)Generate Domain Model Notation()
173
19. CRC TEMPLATE #7
Class Name Perform Model Transformation.

Super class NONE.
Subclass 1) Extract meta-model.
2) Transform meta-model.
2) Meta-model details: string.
Services 1) Admit request.

2) Process request.
3) Identify meta-model.
4) Generate meta model details.
5) Initialize details.
7) Initialize process.
8) Evaluate transformation details.
9) Extract transformation.
10) Incorporate transformation rule.
12) Store meta-model.
13) Forward meta-model.
14) Generate transformation options.
15) Retrieve transformation details.
16) Integrate transformation rules.
18) Upload meta-model.
19) Formulate model details.
20) Integrate model.
1)Display Search Result()
2)Display Error message () Model db.
3)Get Model Details() Meta-model db.
4) Edit Model ()
5)Generate Meta-model()
6)Extract Meta-model()
7)Display Model()
8)Accept New Meta-model()
9) Built Meta-model()
174
Class Name Extract Meta-model.

Super class Perform model transformation.
Subclass NONE.
2) Meta-model details: string.
Services 1) Gather request from user.

2) Accept model.
3) Formulate model details.
5) Extract model.
6) Accept meta-model.
7) Evaluate meta- model details.
8) Extract meta- model.
9) Associate meta-model.
10) Verify model.
11) Process edit request.
12) Built model details.
13) Store model.
14) Perform operation.
15) Formulate model.
16) Integrate model.
1)Display Search Result() Model db.

2)Display Error message () Meta-model db.
3)Get Model Details()
4) Edit Model ()
5)Generate Meta-model()
7)Display Model()
175
Class Name Transform Meta-model.

Subclass NONE.
Services 1) Admit request.

2) Process request.
3) Identify meta-model.
4) Generate meta model details.
7) Initialize process.
8) Evaluate transformation details.
9) Extract transformation.
10) Incorporate transformation rule.
12) Store meta-model.
14) Generate transformation options.
15) Retrieve transformation details.
16) Integrate transformation rules.
18) Upload meta-model.
1)Display Search Results() Model db.

2) Display Error Message () UML Profile db.
3) Display Model() BPD Notation db.
4) Accept New Meta- model () Meta-model db.
5)Built Meta-model()
176
22. CRC TEMPLATE #8
Class Name Perform Workflow checking.

Superclass NONE.
Subclass 1) Schedule Workflow.
2) Build workflow traceability.
2) Workflows: string.
Services 1) Accept request.
2) Search domain.
3) Verify domain.
4) Get model.
5) Validate model.
7) Classify workflow elements.
8) Assemble Elements.
9) Validate element rules.
10) Integrate changes.
11) Apply relational rules.
12) Check element flow.
13) Store to db.
14) Inspect changes.
15) Accommodate changes.
16) Inspect traceability.
1) Acquire Workflow Details() Domain db.
2) Evaluate domain() Notation db.
3) Associate notations() Model db.
4) Perform workflow analysis()
5) Check element relationships()
6) Manage Workflow ()
7) Check Traceability()
8) Schedule workflow()
177
Class Name Schedule Workflow.
Superclass Perform Workflow Checking.
Subclass NONE.
Variables Workflow: string.
Services 1) Accept request.

2) Search domain.
3) Verify domain.
4) Get model.
5) Validate model.
7) Classify workflow elements.
2) Associate notations() Notation db.
3) Check element relationships() Model db.
4) Schedule Workflow
178
Class Name Build Workflow Traceability.

Superclass Perform workflow checking.
Subclass NONE.
Variables Requirements: string.
Services 1) Validate element rules.
2) Integrate changes.
4) Check element flow.
5) Store to db.
6) Inspect changes.
7) Accommodate changes.
8) Inspect traceability.
Notation db.
2) Manage Workflow () Model db.
3) Check Traceability()
4) Process Model()
5) Evaluate domain()
179

System
System Implementation Document
180
Component diagram description
181
Component Name Generate UML Profile

Kind of Component Module
Responsibilities To generate requested profile
Processing 1) User will request profile, profile is verified
by controller.
2) System will generate requested profile,GUI
editor will display generated profile.
Reference Refer PDL #1
Constraints Only administrator can access system.
Composition Store user details in the user database, store
profile details in Profile database.
Resources 1) User_db
2) UML_Profile_db
3) Model_db.
Interactions User authenticator
Interface/Exports Accept request from user
1)Login window
2)Registration window
182
Procedure Definition Language#1
Procedure Generate UML Profile
ACCEPT request from user

SYSTEM accepts request
VERIFY profile
IF profile=NOT found
THEN Display an error message
End if
IF profile=found
THEN display profile at GUI
End if
Terminate
ELSE
USER CREATES new profile

SYSTEM validates profile
IF profile=NOT Successful
THEN
Profile will display error message
End if
ELSE
IF profile=SUCCESSFUL
THEN
Fetch notations from notation db
End if
Terminate
ELSE
GET metamodel
SEARCH model and metamodel from model db
RETRIEVE model and metamodel
TRANSFORM metamodel and store changes
IF model=found
THEN Search model into model db
ADD model to model db
STORE model changes
DISPLAY notation
ADD notation to profile db
IF notation added successfully
THEN exit from profile
ELSE repeat
183
End if
IF build==Successful
DISPLAY confirmation done
ELSE
Show error message
Terminate
OPEN GUI editor and display models
DISPLAY new model
SEND Acknowledgement to user
End if
Terminate
184
Component Name Organize Notation Profile

Kind of Component Sub Module
Responsibilities 1) Organize UML profile
2) Categorize notations.
Processing 1) Opens login page, user enter username and

password
2) System validates the user details and
provides access to the user.
Reference Refer PDL #1.1
Constraints Cannot allow multiple login
Composition Access user details from the user database.
2) Notation_db
Interactions Login user
Interface/Exports 1)Accept request from user
185
Procedure Definition Language#1.1
Procedure Organize Notation Profile
REQUEST Profile
SYSTEM accepts notations request
IF profile==VALID
THEN
ENTER profile details
SEARCH profile in profile db
IF Profile=found
THEN display profile names to user
ELSE Display error message
End if
GOTO create_new_profile
RETRIEVE profile from UML profile db
MODIFY profile
ADD new notations
RETRIEVE notations from notation db

SAVE changes to notation db
GET metamodel
SEARCH model and metamodel from model db
RETRIEVE model and metamodel
TRANSFORM metamodel and store changes
IF model=found
THEN Search model into model db
ADD model to model db
STORE model changes
DISPLAY notation
ADD notation to profile db
IF notation added successfully
THEN exit from profile
ELSE repeat
End if
End if
186
Component Name Incorporate Metamodel

Responsibilities 1) To incorporate Metamodel.
2) Extract Behavioral model elements.
3) Build Model elements.
Processing 1) User will send request for model,
Controller will generate model elements.
2) Model will be extracted and viewed to an
interface.
Constraints Administrator requests a model.
Composition Meta model generated successfully.
2) Model_db
Interactions User requests for profile.
1) Generate metamodel
2) Display it to an interface.
187
Procedure generate Metamodel
USER will request model details

ENTER model details
SEARCH model into model db
IF model==found
THEN
GO to Open search window
DISPLAY search results
PROCESS model
ELSE IF model NOT found
THEN
DISPLAY error message
Go to search page
End if
OPEN model window
DISPLAY model name
EXTRACT models from model db
OPEN metamodel window
RETRIEVE metamodel from model db
ADD metamodel details
SAVE modifications
Go to build metamodel
DISPLAY added metamodel
IF build==Successful
DISPLAY confirmation done
ELSE
Show error message
Terminate
OPEN GUI editor and display models
DISPLAY new model
SEND Acknowledgement to user
End if
Terminate
188
Component Name Manage security

Responsibilities To manage security
Processing 1) Administrator will request for workspace.
System will authenticate user.
2) GUI controller will check LOGIN status in
LOGIN db. Interface will display message
to user.
3) System will send acknowledgement to user.
User will request for workspace. System
will get workspace details from user. Search
workspace in database. Create new
workspace.
4) Display message to user. Accept details.
Allocate workspace and Update db.

Constraints Only registered user can access system.
Administrator requests for a workspace.
Composition Store user details in the user database. Also
store profile details in profile database.
Resources 1) LOGIN db
2) PROFILE db
Interactions User authenticator
1)Login window
189
Procedure Manage security
Accept Login details from Administrator

CHECK details
VALIDATE details
IF request=Provide access
Get the profile details from the user.
IF Profile details =FOUND
MAINTAIN details in Profile db
IF profile exists
EXTRACT profile from the database
EDIT details
CHANGE profile definitions
APPLY changed definitions
UPDATE changes in profile db
SAVE changes in profile db
ELSE
Display profile not found
ELSE
Get the details from the user
PROCESS details
ASSOCIATE profile details
EXTRACT subject, verb, and object from the requirements
CATOGOREIZE Profiles
TOKENIZE Profiles
UPDATE changes in Profile db
SAVE changes in Profile db
DISPLAY the details
ENDIF
ELSE
CHECK details
VALIDATE details
IF request=Request for Workspace
SEARCH Workspace
IF workspace =FOUND
MAINTAIN details in UML db
IF Workspace exists
ALLOCATE Workspace
EDIT details
UPDATE changes in UML db
SAVE changes in UML db
190
ELSE
CREATE new Workspace
ELSE
PROCESS details
ASSOCIATE Workspace details
CATOGOREIZE details
TOKENIZE details
DISPLAY the details
ENDIF
191
Component Name Maintain profile

Responsibilities 1) Maintain login details
2) Maintain profile rights details
3) Save to database
Processing 1) Opens registration form, system gets user

details and registers the user and provides
access to the user.
2) Administrator will request for profile.
System will authenticate user.GUI controller
will check LOGIN status in LOGIN db.
Maintain profile rights and maintain db.
Interface will display message to user.
3) System will send acknowledgement to user.

Constraints Cannot create account for invalid user.
Composition Store user details in the user database and
UML profile details in UML profile db.
Resources User db , UML profile db
Interactions User register
192
Procedure Maintain profile

CHECK details
VALIDATE details
IF request=Provide access
Get the profile details from the user.
MAINTAIN details in Profile db
IF profile exists
EXTRACT profile from the database
EDIT details
CHANGE profile definitions
UPDATE changes in profile db
SAVE changes in profile db
ELSE
Display profile not found
ELSE
PROCESS details
ASSOCIATE profile details
CATOGOREIZE Profiles
TOKENIZE Profiles
UPDATE changes in Profile db
SAVE changes in Profile db
DISPLAY the details
ENDIF
193
Component Name Allocate workspace

Responsibilities 1) Create workspace
2) Import workspace
3) Save to database
Processing 1) Authenticate user. User will request for

workspace. System will get workspace
details from user.
2) Search workspace in database. Create new
workspace. Display message to user.
Accept details.
3) Allocate workspace and Update db.

Constraints Administrator can only create workspace.
Composition Store user details in the user database and
UML profile details in UML profile db.
Resources 1) User db
2) UML profile db
Interactions User register, allocate workspace
2)Error message window
194

CHECK details
VALIDATE details
IF request=Request for Workspace
SEARCH Workspace
IF workspace =FOUND
MAINTAIN details in UML db
IF Workspace exists
ALLOCATE Workspace
EDIT details
ELSE
CREATE new Workspace
ELSE
PROCESS details
ASSOCIATE Workspace details
CATOGOREIZE details
TOKENIZE details
DISPLAY the details
ENDIF
195
Component Name Organize Metamodel

Responsibilities 1) Provide Metamodel
2) Model diagram
Processing 1) User will request notations
2) System generates diagram controller
3) GUI will exhibit diagram controllers.
Constraints Administrator, super user requests a model.
2) UML_profile_db
3) metamodel_db
4) BPD_notation_db
2) Display metamadel to user
196
Procedure Organize metamodel

USER will request notations
SELECT notations from notation db
Go to next window
SEND notations
OPEN notation window and retrieve notation
IF notation NOT found
SEARCH notation in notation db
EXTRACT notations
PERFORM transformation
SAVE changes to db
ELSE
MODIFY notations
OPEN search tab and search notations to display
PERFORM modifications
SAVE changes
End if
DISPLAY model to an interface
PROVIDE metamodel
Terminate
ELSE
Terminate
ELSE
SEND diagram profile details
DISPLAY profile
IF Successful
ACCEPT profile
EXTRACT profile details
GENERATE diagram profiles
SAVE diagram profiles
ELSE
Terminate
GO to Diagram controller
GENERATE diagram controllers
SAVE diagram controller
RETURN profile to GUI
DISPLAY diagram profile
End if
197
Component Name Provide Metamodel

Responsibilities 1) Provide Meta-model
2) Model diagram
Processing 1) User will request notations
2) System generates diagram controller
3) GUI will exhibit diagram controllers.
Constraints Administrator, super user requests a model.
2) UML_profile_db
3) metamodel_db
4) BPD_notation_db
2) Display metamadel to user
198
Procedure provide metamodel

USER will request notations
SELECT notations from notation db
Go to next window
SEND notations
OPEN notation window and retrieve notation
IF notation NOT found
THEN
SEARCH notation in notation db
EXTRACT notations
PERFORM transformation
SAVE changes to db
ELSE
MODIFY notations
OPEN search tab and search notations to display
PERFORM modifications
SAVE changes
End if
GET metamodels
OPEN model database
Go to model details
RETRIEVE Meta model
IF Successful
THEN
OPEN GUI editor
DISPLAY metamodel
SAVE modifications
SHOW Acknowledgement to user
DISPLAY model to an interface
PROVIDE metamodel
Terminate
ELSE
Terminate
199
Component Name Model Diagram

Responsibilities 1)Generate diagram profile
2)Deliver diagram control
Processing Diagram controls generates successfully.
Constraints Administrator ,super user ,Modular
Composition Diagram profile generated successfully.
Resources 1) Model_db
2) UML_profile_db
3) Meta-model_db
4) BPD_notation_db
1) Generate diagram profile.
2) Deliver diagram control.
200
Procedure Model Diagram

USER requests diagram
IF user == VALID
THEN
ACCEPT request
ELSE
REJECT Request
FORWARD diagram name
PROVIDE notations
GET notations
SEARCH notations in notation db
EXTRACT notations
MODIFY notations
SEND diagram profile details
DISPLAY profile
IF Successful
THEN
ACCEPT profile
EXTRACT profile details
GENERATE diagram profiles
SAVE diagram profiles
ELSE
Terminate
GO to Diagram controller
Display controller
GENERATE diagram controllers
SAVE diagram controller
RETURN profile to GUI
DISPLAY diagram profile
SEND acknowledgement to an user
End if
End if
Terminate
201
Component Name Manage Requirements.

Kind of Component Module.
Responsibilities 1) Capture Requirements.
2) Trace Requirements.
3) Categorize Requirements.
4) Modify Requirements.
Processing 1) Get the requirements from the user.
2) Abridged and tokenized requirements,
resolve ambiguity.
3) Determine requirement overlap.
Constraints Request will be sent by an administrator.
Composition Store the requirements in the user database.
Resources 1) Requirements db
2) UML Profile db
3) Model db.
Interactions Requirements Manager.
Interface/Exports Accept requirements from User.
1) Requirement Editor.
2) Requirement Controller.
202
Procedure Manage Requirements

Accept Request from Administrator
CHECK request
VALIDATE request
IF request=CREATE Capture Requirements
Get the requirement definitions from the user.
IF requirement definition =FOUND
SEARCH requirements from requirements db
IF requirements exists
EXTRACT requirements from the database
EDIT requirements
CHANGE requirements definitions
UPDATE changes in requirements db
ELSE
Display requirements not found
ELSE
Get the requirements from the user
PROCESS requirements
ASSOCIATE requirements
CATOGOREIZE requirements
TOKENIZE requirements
ELSE IF request=TRACE Requirements
Go to requirements db
Go to Existing Projects
IF project exists =OPEN Existing Project.
IF requirements =AVAILABLE
ACCESS the requirements from the Project
MATCH the requirements in db.
DETERMINE requirement overlap.
IF requirement =OVERLAP
REMOVE the requirements.
ELSE
ANALYZE ambiguity
IF Requirements=Ambiguous
RESOLVE ambiguity
ELSE
Print requirements not available.
ELSE
Project not found.
ELSE
INVALID Request
Return to main window.
203
Component Name Capture Requirements.

Kind of Component Sub Module.
Responsibilities 1) Capture requirements.
3) Tokenize requirements.
4) Modify requirements.
Processing 1) Accept requirement definitions from the
user.
2) Abridged and tokenized requirements.
3) Modify the requirements, update and save
the changed requirements.
Constraints Requirements can be managed by
Administrator only.
Composition Capture and Store the requirements in the user
database.
Resources 1) Requirements db
2) UML Profile db
3) Model db.
Interactions Requirements Manager.
Interface/Exports Accept requirements from User.
2) Requirement Controller.
204
Procedure Capture Requirements

CHECK request
VALIDATE request
IF request=CREATE Capture Requirements
Get the requirement definitions from the user.
IF requirement definition =FOUND
SEARCH requirements from requirements db
IF requirements exists
EXTRACT requirements from the database
EDIT requirements
CHANGE requirements definitions
SAVE changes in requirements db
ELSE
Display requirements not found
ELSE
Get the requirements from the user
SSOCIATE requirements
CATOGOREIZE requirements
TOKENIZE requirements
SAVE changes in requirements db
DISPLAY the details
ENDIF
205
Component Name Trace Requirements.

Kind of Component Sub Module.
Responsibilities 1) Trace requirements.
2) Analyze ambiguity.
3) Resolve Ambiguity
4) Determiner requirement overlap.
Processing 1) Retrieve requirement from the user.
2) Analyze requirement ambiguity.
3) Resolve Ambiguity, Determine requirement
overlap.
Constraints Requirements cannot be traced by the user.
Composition Trace and Store the requirements in the user
database.
Resources Requirements db.
Interactions Requirements Controller.
Interface/Exports Regain requirements from the System.
2) Requirement Manager.
206
Procedure Trace Requirements

CHECK request
VALIDATE request
IF request=TRACE Requirements
Go to requirements db
Go to Existing Projects
IF project exists =OPEN Existing Project.
Go to requirement page
IF requirements =AVAILABLE
ACCESS the requirements from the Project
MATCH the requirements in db.
DETERMINE requirement overlap.
IF requirement =OVERLAP
REMOVE the requirements.
UPDATE Requirements db
SAVE to the Requirements db
ELSE
Continue
ANALYZE ambiguity
IF Requirements=Ambiguous
RESOLVE ambiguity
UPDATE Requirements db.
SAVE to Requirements db.
ELSE
Continue
ELSE
Print requirements not available.
ELSE
Project not found.
ELSE
INVALID Request
Return to main window.
ENDIF
207
Component Name Manage BPD

Kind of Component Module.
Responsibilities 1) Develop BPD.
2) Process BPD.
3) Apply BI Rules()
4) Accept Explicit Requirement()
5) Generate Implicit Requirement()
Processing 1) Capture needs, Accept BPD details from
the user.
2) Accept explicit as well as implicit
requirements, and Associate notations to it.
3) Apply BI rule, Create BPD.
Constraints User can be administrator or super user.
database.
Resources 1) BPD db
2) Notation db
3) Database db
4) Requirements db
Interactions BPD Manager
1) BPD Editor.
2) BPD Controller.
208
Procedure Manage BPD

ACCEPT Request from Administrator
CHECK request
VALIDATE request
IF request=DEVELOP BPD
REGISTER request
IF request = CREATE New BPD
CAPTURE Needs
ACCEPT BPD name
ACCEPT BPD details
ELSEIF request=MODIFY BPD
SEARCH BPD db
IF BPD = PRESENT
RETREIVE BPD from BPD db
MAKE changes to the BPD
CHANGE BPD details
ELSE
DISPLAY BPD not found
ELSE
Continue
FIND notations in Notation DB
RRETRIVE notations
ASSOCIATE Notations to BPD
APPLY BPD Notations
CHECK SEQUENCE FLOW
APPLY BI rules
CREATE FINAL BPD
STORE BPD in BPD db
UPDATE BPD db
END IF
ELSE
IF request= PROCESS BPD
REGISTER request
IF request = ACCEPT both the requirements
ACQUIRE explicit requirements
IF requirements = PRESENT
PRINT requirements already exists
ELSE
Continue
MAKE changes
ACCEPT implicit requirements
ELSE
209
Continue
Modify requirements
STORE the requirements in requirement db
UPDATE requirement db
ELSE
ACCEPT explicit requirements
ELSE
Continue
PROCESS explicit requirements
SAVE requirements
GENERATE implicit requirements
STORE implicit requirements
UPDATE requirements db
CREATE BPD
SAVE BPD in BPD db
UPDATE BPD db
DISPLAY BPD
ENDIF
210
Component Name Develop BPD

Kind of Component Sub-Module.
Responsibilities 1) Develop BPD.
2) Apply BI Rules()
3) Apply BPD notations()
Processing 1) Capture needs, Accept BPD details from the
user
2) Associate notations to it, Apply BI rule,
Create BPD.
database.
Resources 1) BPD db
2) Notation db
3) Requirements db
Interactions BPD Manager
1) BPD Editor.
2) BPD Controller.
211
Procedure Develop BPD

CHECK request
VALIDATE request
IF request=DEVELOP BPD
REGISTER request
IF request = CREATE New BPD
CAPTURE Needs
ACCEPT BPD name
ACCEPT BPD details
ELSE
IF request=MODIFY BPD
SEARCH BPD db
IF BPD = PRESENT
RETREIVE BPD from BPD db
MAKE changes to the BPD
CHANGE BPD details
ELSE
DISPLAY BPD not found
ELSE
Continue
FIND notations in Notation DB
RRETRIVE notations
ASSOCIATE Notations to BPD
APPLY BPD Notations
CHECK SEQUENCE FLOW
APPLY BI rules
CREATE FINAL BPD
STORE BPD in BPD db
UPDATE BPD db
DISPLAY BPD on request by admin
END IF
212
Component Name Process BPD

Kind of Component Sub-Module.
Responsibilities 1) Process BPD.
2) Accept Explicit Requirement()
3) Generate Implicit Requirement()
Processing 1) Accept explicit as well as implicit
requirements.
2) Associate notations to it.
3) Generate implicit requirements, Create
BPD.
database.
Resources BPD db, Notation db, Database db,
Requirements db
Interactions BPD Controller
1) BPD Editor.
2) BPD Manager.
213
Procedure Process BPD

CHECK request
VALIDATE request
IF request= PROCESS BPD
REGISTER request
IF request = ACCEPT both the requirements
ACQUIRE explicit requirements
ELSE
Continue
MAKE changes
ACCEPT implicit requirements
ELSE
Continue
Modify requirements
STORE the requirements in requirement db
UPDATE requirement db
ELSE
ACCEPT explicit requirements
ELSE
Continue
PROCESS explicit requirements
SAVE requirements
GENERATE implicit requirements
STORE implicit requirements
UPDATE requirements db
CREATE BPD
SAVE BPD in BPD db
UPDATE BPD db
DISPLAY BPD
ENDIF
214
Component Name Build Domain modeler

Responsibilities Build domain modeler
Processing 1) It generates the structure of domain
information and builds the vocabulary.
2) It not only provides the domain model
notations but also associates them.
Constraints Performs task of the domains.
Composition 1) Store domain information in the domain
database.
2) Stores the domain notations in domain
notation database.
3) Stores the domain models in model
database.
Resources 1) model_db
2) domain model_db
3) domain_db
Interactions Domain Modeler.
1) Model Window.
2) Notations window.
3) Domain vocabulary window.
215
Procedure build DOMIN MODELER

REQUEST domain details
ACCEPT request from USER
GENERATE domain model
IF request= EDIT DOMAIN

EXTRACT the domain details form domain_db
MODIFY the domain model
EDIT the structure domain information
EXTRACT the domain vocabulary
EDIT the domain vocabulary
GENERATE the domain model
APPLY the changes to domain
UPDATE the new generated domain in domain_db.
UPTADE the new generated domain vocabulary in vocabulary_db
UPDATE the model_db
DISPLAY the domain model
ELSE
DISPLAY domain not found
IF request= BUILD NEW DOMAIN

ACCOUIRE Request the domain details.
BUILD the domain model
ACCQUIRE the domain information
UPDATE the domain information
GENERATE the new domain vocabulary
ASSOCIATE the domain vocabulary
UPDATE the new generated vocabulary in vocabulary_db
UPDATE the new domain model in model_db
DISPLAY new generate domain model.
ELSE
DISPLAY invalid request
GENERATE domain notation
IF request= EDIT domain model

ACCEPT the domain model
EXTRACT the domain model form model_db
216
IF request=ADD new domain notation

DISPLAY domain notation
INCORPORATE new domain notation
ASSOCIATE domain notation.
UPDATE the domain notation in notation_db
ELSEIF request= EDIT domain model

EXTRACT domain model
MODIFY Domain notation
ASSOCITATE domain model
DIPLAY the domain model
UPDATE the model in model_db
ELSE
IF request= GENERATE NEW DOMAIN MODEL

ACCQUIRE the details
DISPLAY the Domain Model Notations
ADD notation to model
GENERATE the domain models
ASSOCIATE the domain notation
UPDATE Models to Model_db
ELSE
ENDIF
End build domain modeler
217
Component Name Build Domain

Responsibilities 1)Accept domain requests
2) Check Domain details
3) Generates new /edit domain model
4) Save to database
Processing 1) Generates the domain as per request.

2) It structures the domain information and
builds the domain vocabulary.
Constraints Generate the domain model only.
Composition Store domain vocabulary in domain database.
Resources 1) Domain_db
2) Model_db
Interactions Domain modeler
1) Domain vocabulary
2) Domain model.
218

Procedure Build Domain
ACCEPT requests from USER

CHECK domain details
VALIDATE domain details
IF details=FOUND
IF request= EDIT DOMAIN
EXTRACT the domain details form domain_db
MODIFY the domain model
EDIT the structure domain information
EXTRACT the domain vocabulary
EDIT the domain vocabulary
GENERATE the domain model
APPLY the changes to domain
UPTADE the new generated domain vocabulary in vocabulary_db
UPDATE the model_db
ELSE
DISPLAY domain not found
IF request= BUILD NEW DOMAIN

ACCOUIRE Request the domain details.
BUILD the domain model
ACCQUIRE the domain information
UPDATE the domain information
GENERATE the new domain vocabulary
ASSOCIATE the domain vocabulary
UPDATE the new generated vocabulary in vocabulary_db
UPDATE the new domain model in model_db
DISPLAY new generate domain model.
ELSE
ENDIF
END Build Domain
219
Component Name Provide Domain Model Notation

Responsibilities 1) Accept domain details
2) Generate the domain notations.
3) Associate the domain models.
4) Save domain models and Domain notations
Processing 1) Provides the domain notations.
2) Adds new notations.
3) Domain models can be structured using
these domain notations
Constraints Can generate only domain model.
Composition 1) Access Domain Notations from the
Domain Notations database.
2) Generate the Domain Models in Model
database.
Resources 1) Domain Notation_db
2) Model_db
Interactions 1) Domain Notations
2) Domain Models
1) Domain Notations window
2) 2. Domain Model window
220
Procedure Provide Domain Model Notation
ACCEPT request for Domain Model USER

CHECK Domain models
VALIDATE domain models
IF request=found
IF request= EDIT domain model
ACCEPT the domain model
EXTRACT the domain model form model_db
IF request=ADD new domain notation
DISPLAY domain notation
INCORPORATE new domain notation
ASSOCIATE domain notation.
UPDATE the domain notation in notation_db
ELSEIF request= EDIT domain model
EXTRACT domain model
MODIFY Domain notation
ASSOCITATE domain model
DIPLAY the domain model
ELSE
IF request= GENERATE NEW DOMAIN MODEL

ACCQUIRE the details
DISPLAY the Domain Model Notations
ADD notation to model
GENERATE the domain models
ASSOCIATE the domain notation
UPDATE Models to Model_db
ELSE
ENDIF
END Provide Domain Model Notation
221
Component Name Perform Model Transformation

Responsibilities 1) Accept the Model for transformation.
2) Extract the Meta-models.
3) Acquire the transformation rules
4) Transform the Meta-model.
5) Integrate model
4) Store Meta-model in the database.
5) Update Model in the database.
6) Display models details.
Processing 1) Extract the Meta-model.

2) Implements the Meta-model
transformation using transformation rules
3) Integrate models

Constraints Perform transformation of the models only.
Composition Access the Models and Meta-models form
model database and Meta-model database
respectively.
2) Meta-model_db
Interactions Extract and transform Model and Meta-model.
1) Model extraction window.
2) Meta-model transformation window.
222
Procedure Perform Model Transformation
ACCEPT Request from USER

CHECK request
VALIDATE request
Procedure Extract Meta-model
CHECK request
VALIDATE request
IF request=valid
IF request= EDIT META-MODEL
ACCQUIRE model
IF model=found
ACCQUIRE meta-model
. GENERATE the meta-model details
EXTRACT meta-model from database
MODIFY meta-model
ASSOCIATE the model
ELSE
DISPLAY model not found
DISPLAY the meta-model
UPDATE the meta-model_db
DISPLAY model
UPDATE the model_db
ELSE
DISPLAY request invalid
IF request= NEW meta-model
ACCEPT the model details
GENERATE the model details
ASSOCIATE the meta-model
ACCQUIRE the meta-model details
GENERATE the meta-model
UPDATE the meta-model in meta-model_db
DISPLAY model
ACCEPT Model from user
VALIDATE Model
IF model= FOUND
IF request= EDIT model
GOTO Model window
ACCQUIRE model details
223
EXTRACT the model form database

DISPLAY model
GENERATE meta-model details
EXTRACT the meta-model form database
IF request=EDIT meta-model
GET meta-model
BUILD transformation rules
EXECUTE transformation
ELSE
ACCEPT transformation rules
GENERATE meta-model
DISPLAY the new meta-model
ASSOCIATE the model
DISPLAY model
ELSE
IF request=NEW model
GENERATE the new model
INCORPORATE the meta-model
UPDATE model in model_db
IF request=MODIFY transformation rules
EXTRACT the transformation rules
ELSE`
ACCEPT the transformation rules
ASSOCIATE the transformation rules
UPDATE transformation rule_db
GENERATE the Meta model
UPDATE meta-model in meta-model_db
DISPLAY meta-model
DISPLAY model
ELSE
ENDIF
END Perform Model Transformation
224
Component Name Extract Meta-model

Responsibilities 1) Accept Model from the user
2) Get the Meta-model
3) Integrate the model
4) Display Model details.
Processing 1) Extract the model details and meta-model
for transformation.
2) Finally integrates the model after
transformation.
Constraints Only extraction of meta-model is performed.
Composition Access model and meta-model form database.
Resources 1) Meta-model_db
2) Model_db
Interactions Extract Meta-model form database
Interface/Exports 1) Model window.
2) Display Meta-model window
225
Procedure Extract Meta-model

CHECK request
VALIDATE request
IF request=valid
IF request= EDIT META-MODEL
ACCQUIRE model
IF model=found
ACCQUIRE meta-model
. GENERATE the meta-model details
EXTRACT meta-model from database
MODIFY meta-model
ASSOCIATE the model
ELSE
UPDATE the meta-model_db
DISPLAY model
UPDATE the model_db
ELSE
DISPLAY request invalid
IF request= NEW meta-model
GENERATE the model details
ASSOCIATE the meta-model
GENERATE the meta-model
DISPLAY model
ENDIF
END Extract Meta-model
226
Component Name Transformation Meta-model

Responsibilities 1) Get Meta-model from the user.
2) Acquire the transformation rules.
3) Implement the transformation.
4) Store Meta-model into the database.
1)
Processing Transformation of the Meta-model takes place
using transformation rules.
Constraints Transformation of Meta-model performed.
Composition Generate the model associated with it and store
to database.
2) Meta-model_db
Interactions Meta-model transformation
Interface/Exports 1) Model window.
2) Meta-model window
227
Procedure Transformation Meta-model

ACCEPT Model from user
VALIDATE Model
IF model= FOUND
IF request= EDIT model
ACCQUIRE model details
EXTRACT the model form database
DISPLAY model
GENERATE meta-model details
EXTRACT the meta-model form database
IF request=EDIT meta-model
GET meta-model
BUILD transformation rules
ELSE
ACCEPT transformation rules
GENERATE meta-model
DISPLAY the new meta-model
ASSOCIATE the model
DISPLAY model
ELSEIF request=NEW model
GENERATE the new model
INCORPORATE the meta-model
IF request=MODIFY transformation rules
EXTRACT the transformation rules
ELSE`
ACCEPT the transformation rules
ASSOCIATE the transformation rules
GENERATE the meta model
UPDATE meta-model in meta-model_db
DISPLAY meta-model
DISPLAY model
ENDIF
END Transformation Meta-model
228
Component Name Perform workflow checking

Responsibilities 1) To perform workflow checking
Processing 1) Administrator will send model. System will

check workspace elements.
2) System will determine changes. Save
changes in domain database. Show
acknowledgement to administrator.
Administrator will send model.
3) System will check workspace elements.
4) System manager will determine changes to
element.
Constraints Administrator can only perform workflow
checking.
Composition Store notation details in the notation database,
model details in model db and domain details
in domain db.
Resources Notation db ,Domain db, Model db
Interactions Schedule workflow, Build workflow
traceability
1) Registration window
2) Error message window
3) Notation window
229
Procedure Perform workflow checking

ACCEPT Login details from Administrator
CHECK details
VALIDATE details
IF request=Check workspace
Get the domain details from the user.
VERIFY details in domain db
IF domain exists
EXTRACT domain from the database
CLASSIFY notations
CHANGE notations definitions
UPDATE changes in notations db
ELSE
Display notations not found
ELSE
PROCESS details
ASSOCIATE notations details
EXTRACT subject, verb, and object from the notation relations
CATOGOREIZE models
TOKENIZE models
UPDATE changes in model db
DISPLAY the details
ELSE
CHECK details
VALIDATE details
IF request=Send model
Get the model details from the user.
IF model details =FOUND
VERIFY details in model db
IF model exists
EXTRACT notations from the database
CLASSIFY notations
ELSE
ELSE
Apply relational rules
PROCESS details
ENDIF
230
Component Name Schedule Workflow

Responsibilities 1) Check element flow
2) Check element relation
3) Save to database
Processing 1) System manager search domain in db.

2) After that system will retrieve notations and
according to that classify workflow
elements.
Constraints Administrator can only schedule workflow.
in domain db.
Resources Notation db ,Domain db, Model db
Interactions Maintain LOGIN, Manage profile rights
3) Notation relation window
231
Procedure Schedule Workflow

ACCEPT Login details from Administrator
CHECK details
VALIDATE details
IF request=Check workspace
Get the domain details from the user.
VERIFY details in domain db
IF domain exists
EXTRACT domain from the database
CLASSIFY notations
SAVE changes in notations db
ELSE
ELSE
PROCESS details
CATOGOREIZE models
TOKENIZE models
SAVE changes in model db
DISPLAY the details
ENDIF
232
Component Name Build workflow traceability

Responsibilities 1) Determine changes
2) Accommodate changes
3) Save to database
Processing 1) System will check workspace elements.

2) Validate element rules and integrate
changes.
3) Apply relational rules and check element
flow.
Constraints Administrator can only build workflow
traceably.
in domain db.
Resources Notation db, Domain db, Model db
Interactions Determine changes, accommodate changes
3) Notation relation window
233
Procedure Build workflow traceability

CHECK details
VALIDATE details
IF request=Send model
Get the model details from the user.
IF model details =FOUND
VERIFY details in model db
IF model exists
EXTRACT notations from the database
CLASSIFY notations
SAVE changes in notations db
ELSE
ELSE
Apply relational rules
PROCESS details
SAVE changes in model db
DISPLAY the details of traceability
ENDIF
234
Deployment diagram description
235
1. GENERATE UML PROFILE.
The main aim is to provide separate profile to user. The various UML profiles are
distinguished from each other and to maintain them precisely. The two objectives are:
i. Organize notations Profile.
ii. Incorporate Meta-model.
1.1 Organize Notation Profile: Various UML profile has different notation. This objective
performs the task of unraveling the notations as per the UML Profile. It takes care of
notations do not get combine with one another.
1.2 Incorporate Meta-model: The UML profile has diverse models and diagrams. Thus every
model has a meta-model. So newly generated models will have their Meta-model and it
needs to get added into the database.
2. MANAGE SECURITY
The authentication of the user is performed in manage security. Along with that, it also
maintains the user profile. So that the users work is safe. The two major objectives of it are:
i. Maintain Profile.
ii. Allocate Workspace.
1.1 Maintain Profile: To provide security to the user. It authenticates the user and provides it
workspace. Thus user can maintain it profile as per required and secure his work.
1.2 Allocate Workspace: To provide workspace to new user. To generate the necessary work
environment for user. So that the profile of does not get mix-up with other.
3. ORGANIZE META-MODEL.
The major job is to organize the Meta-model whenever they are modeled in the diagram
by the user. It not only organizes the meta-model but maintains them. The objectives are:
i. Provide Meta-model.
ii. Model diagram.
1.1 Provide Meta-model: The Meta-model of various models are associated with it as per the
diagrams. Also the notations required for generating the diagram are retrieved and
manipulated.
1.2 Model Diagrams: Modeling diagram perform the task of providing the diagram
controllers. It generates the notations that are must for the diagram profile selected.
236
4. MANAGE REQUIREMENT
This goal deals with requirement provided by user and analyze them. This will perform the
management of the requirement and also differentiating them. The two objectives to achieved
are:
i. Capture Requirement.
ii. Trace Requirement.
1.1 Capture Requirement: the requirements are provided by the user, these requirements are
acquired and stored. After that the requirements are categorized into respective classes.
1.2 Trace Requirement: An important operation of analyzing ambiguity i.e. determines if any
uncertain requirement is present or not, also it verify that requirement are present in
database are not.
5. MANAGE BPD
This goal is providing the Business Process Diagrams for developing the model. This
helps to provide the distinguishing notations required for generating the diagram or model.
The major two objectives are:
i. Develop BPD.
ii. Process BPD.
1.1 Develop BPD: The objective is providing the BPD notations as per the needs captured.
The diagrams will be formulated using the Business Intelligence rules provided by BPD.
1.2 Process BPD: The requirements will be classified into implicit and explicit. That is
helpful for providing the correct BPD for the respective requirement.
6. BUILD DOMAIN MODELER
This is one of the important goal of all as it is necessary for formulating of any domain. It
holds the necessary vocabulary and the structure information for developing the domain. The
objectives are as follows:
i. Build Domain.
ii. Provide Domain Model Notations.
1.1 Build Domain: It provides the foundations for formulating any domain. It supplies the
structure information required to develop a specified domain. It offers the necessary
domain vocabulary for the domain.
1.2 Provide Domain Model Notations: Its work is to provide the required notations that are
must for the generation of the domain model and associate the domain notations with
models.
237
7. PERFORM MODEL TRANSFORMATION
Model transformation involves the generation of the models or modification of any

existing model. Thus the new meta-model should also be formulated for it. It achieved using
two objectives they are:
i. Extract Meta-model.
ii. Transform Meta-model.
1.1 Extract Meta-Model: Every model has its own Meta-model, so when a new model is
build the meta-model is needed to be transformed. Thus the meta-Model are extracted
for same purpose.
1.2 Transform Meta-model: The extracted Meta-models are transformed into the new Meta-
model with the help of Transformation rules
.
8. Perform Workflow Checking
The goal deals with the verification of the workflow of diagram. The model should be
correctly associated with the elements. Its objectives are as follows:
i. Schedule Workflow.
ii. Build Workflow Traceability.
1.1 Schedule workflow: The check is performed the flow of elements is in correct sequence.
Also the relation associated with elements is valid or not.
1.2 Build Workflow Traceability: Trace the changes that occur during the workflow. It also
accommodates the changes in workflow.
238
Integrated Modeling Framework for Enterprise System
System Testing Document
239
TEST PLAN
1. PURPOSE
The purpose of this test plan is to describe the scope, features to be tested and not to be
tested, and items to be tested, criteria, approach, and deliverables included in testing activities for
this particular project. The aim of this document is to guide through the testing procedure.
Through unit testing, individual components of the system will be tested independently to
ensure their quality, and to uncover errors in data structures, program logic, program structure,
interfaces and functions and operations of a component.
Through integration testing, group of dependent components will be tested together to ensure
the quality of design and construction of software architecture, integrated functions or operations
at sub-system level and interfaces and interactions between them.
Through system testing software will be tested as a whole. It will test system functions,
performance and system reliability.
OUTLINE
The test plan has the following structure:

a) Test plan identifier
b) Introduction
c) Test items
d) Features to be tested
e) Features not to be tested
f) Item pass/fail criteria
g) Environmental needs
2. Introduction
Integrated Modeling Framework for Enterprise System is a CASE tool that supports a
Software Architecture, Enterprise Framework (EF). Such frameworks expose a rich set of
semantics and modeling paradigms for developing and extending enterprise applications.
Integrated Modeling Framework for Enterprise System uses a Meta Model Driven approach to
model engineering. The model captures the business logic and lifecycle semantics of the
component. This approach truly facilitates the "model once run anywhere" paradigm.
The main objective of Integrated Modeling Framework for Enterprise System is to
provide a framework on which models will be generated, resulting in improved design and in
turn improved productivity in an Enterprise. The software industry is trying to fully understand
the modern "Enterprise" in an attempt to automate its day to day operations and to provide
crucial decision support capabilities.
240
Test Items
 Generate UML Profile

 Organize Notation Profile
 Incorporate Meat-Model
 Manage Security
 Maintain Profile
 Allocate Workspace
 Organize Meta-Model
 Provide Meta-Model
 Model Diagram
 Manage Requirement
 Capture Requirement
 Trace Requirement
 Manage BPD
 Develop BPD
 Process BPD
 Built Domain Modeler
 Build Domain
 Provide Domain Model Notation
 Perform Model Transformation
 Extract Meta-Model
 Transform Meta-Model
 Perform Workflow Checking
 Schedule Workflow
 Build Workflow traceability
FEATURES TO BE TESTED
Following is list of functions that will be tested:
 Generate UML Profile

 Organize Notation Profile
 Incorporate Meat-Model
 Manage Security
 Maintain Profile
 Allocate Workspace
 Organize Meta-Model
 Provide Meta-Model
 Model Diagram
 Manage Requirement
 Capture Requirement
 Trace Requirement
 Manage BPD
 Develop BPD
 Process BPD
241
 Built Domain Modeler

 Build Domain
 Provide Domain Model Notation
 Perform Model Transformation
 Extract Meta-Model
 Transform Meta-Model
 Perform Workflow Checking
 Schedule Workflow
 Build Workflow traceability
FEATURES NOT TO BE TESTED

The following obvious features are not to be tested:
 Operating system environment
 Backend database
 Other hardware features
ENVIRONMENTAL NEEDS
The Environmental Needs of the testing phase are the same as specified in the software
requirement specification.
The hardware requirement includes a machine with these minimum requirements.
P3,P4 1.6 GHz or higher
512 MB RAM or higher
Software
Windows operating system XP or higher
Java enabled machine
242
ITEM PASS/FAIL CRITERIA:
Test Item 1 Generate UML Profile
Pass Criteria  Model elements extracted and build successfully.
 All the requirements must be present in the Requirement
database
 Model will be retrieved from model database.
 Categorized UML profile
 Included meta-model successfully.
Fail Criteria  Model elements are not present in database
 Cannot categorize UML profile.
 Display error message if profile created unsuccessfully.
Test Item 2 Organize notation profile
Pass Criteria  Requested profile found successfully.
 Profile notations extracted from profile database.
 System will exhibit notations to user.
 Acknowledgement to user.
Fail Criteria  Requested profile is not valid.
 Missing notations in notation database.
 Display error message if user request improper option for
profile.
243
Test Item 3 Incorporate meta-model
Pass Criteria  Metamodel are generated successfully.
 Model extracted effectively from model database.
 The system will display model to user interface.
 An acknowledgement is sent to user.
Fail Criteria  Metamodel generated unsuccessfully.
 If building of new model elements failed.
 Display error if user selects improper option.
 If there are missing notations in model database.
Test Item 4 Manage security
Pass Criteria  User must provide valid user name and password.
 System will authenticate user.
 GUI controller will check LOGIN status in LOGIN db.
 All the details present in the database.
 The profile details are separated from the other details.
 Maintain profile rights and maintain db.
 If user provided workspace details are valid.
 Allocate workspace if details are valid.
 If valid user create new workspace.
244
Fail Criteria  If provide incorrect user name and password give error
message.
 If profile detail input is not well defined.
 The workspace for given input are not available.
 The workspace details are not correctly provided.
Test Item 5 Maintain profile
 GUI controller will check LOGIN status in LOGIN db.
 Interface will display message to user.
 User must provide correct details of profile.
 User must have knowledge about diagram profile.
 All the details present in the database.
 The profile details are separated from the other details.
 Maintain profile rights and maintain db.
 Interface will display message to user.
245
message.
 If profile detail input is not well defined.
 If any profile details are not in database.
 Incorrect profile details provided.
 Missing particular details.
Test Item 6 Allocate workspace

 GUI controller will check LOGIN status in LOGIN
db.
 If user provided workspace details are valid.
 If details are present in database.
 Allocate workspace if details are valid.
 If valid user create new workspace.
246
Fail Criteria  If provide incorrect user name and password give
error message.
 The workspace for given input are not available.
 The workspace details are not correctly provided.
 Missing particular details
Test Item 7 Organize Meta-model
Pass Criteria  Generated meta-model are organized productively.
 Retrieve absolute meta-models from the model database.
 Notations retrieved effectively from notation database.
 Metamodel searched successfully.
 GUI has exhibited diagram controller successfully.
Fail Criteria  Requested meta-model File unavailable.
 The notation are not stored in the notation db
 Metamodel has not been displayed to user.
 Acknowledgement is not received to user.
247
Test Item 8 Provide Metamodel
Pass Criteria  Successful extraction of notations from notation
database.
 Metamodel generated successfully.
 Metamodel acquired successfully by database controller.
 Metamodel is displayed effectively to user.
Fail Criteria  Model is not retrieved from model database.
 Processing of notations at database controller failed.
 Metamodel has not been displayed to user.
 Database controller not forwarded model to model db.
Test Item 9 Model Diagram
Pass Criteria  Requested diagram verified successfully.
 Diagram controllers generated successfully.
 Diagram requested by user has been verified
successfully.
 GUI has exhibited diagram controller effectively.
Fail Criteria  Diagram controllers generated unsuccessfully.
 Processing of notations at database controller failed.
 Diagram profile has not been generated at UML profile
db.
 Diagram profile has not been displayed to GUI.
248
Test Item 10 Manage Requirement

Pass Criteria  Requirements captured successfully from the user.
 Captured requirements displayed successfully.
 Requirements traced successfully from the database.
 Requirements categorized successfully.
 Overlapped requirements determined correctly.
 Ambiguity in the requirements resolved successfully.
 Accepted Requirements tokenized correctly.
 Tokenized requirements displayed successfully.
 Requirement processed and modified successfully.
 Requested requirements retrieved successfully from the

database.
 Requirements in the database and entered requirements

are compared successfully.
Fail Criteria  Requested requirement does not exist in the database.
 Requirements cannot be categorized.
 Requirements overlapped, dispose the requirements.
 Too much ambiguity in the requirements, reject the

requirements.
 Requirements cannot be tokenized due to insufficient

data.
 Requirements cannot be compared.
 Requirements cannot be traced.
249
Test Item 11 Capture Requirement
Pass Criteria  Requirements captured successfully from the user.
 Requirements categorized successfully.
 Requirement processed and edited successfully.
 Captured requirements displayed successfully.
 Accepted Requirements tokenized correctly.
 Tokenized requirements displayed successfully.
 Requirement processed and modified successfully.
database.
Fail Criteria  Requested requirement does not exist in the database.
 Requirements cannot be categorized successfully.
 Requirements already exists, discard the requirements.
 Requirements cannot be tokenized due to insufficient
data.
250
Test Item 12 Trace Requirement
Pass Criteria  Requirements traced successfully from the user.
 Overlapped requirements determined successfully.
 Ambiguity in the requirements analyzed successfully.
 Ambiguity in the requirements resolved successfully.
 Requirements in the database and entered requirements
are compared successfully.
database.
 Requirements stored successfully in the database.
Fail Criteria  Requirements overlapped, dispose the requirements.
 Requirements cannot be categorized successfully.
 Too much ambiguity in the requirements, reject the
requirements.
251
Test Item 13 Manage BPD

Pass Criteria  Needs are captured successfully.
 BPD details accepted from the user.
 Sequence flow in the BPD checked successfully.
 Requested notations are retrieved from the database.
 BI rules are applied to BPD successfully.
 Notations are correctly associated to the BPD.
 Explicit requirements are accepted successfully.
 Implicit requirements generated successfully.
 Explicit requirements are validated successfully.
 Retrieved BPD edited successfully.
Fail Criteria  BPD cannot be created if sequence flow is incorrect.
 BPD search fails if it is not present in the database.
 Requirements are not accepted if requirements definitions

and requirements details are insufficient.
 BPD does not get created if requested notations do not

matched with retrieved notations.
 BPD cannot be created without getting implicit

requirements.
 BPD cannot be stored in the database due to insufficient

space in the database.
 Explicit requirements cannot be validated, due to

incorrect data entered.
 Implicit requirements cannot be generated.
252
Test Item 14 Develop BPD
Pass Criteria  Needs are captured successfully.
 BPD details accepted from the user.
 Sequence flow in the BPD checked successfully.
 Requested notations are retrieved from the database.
 BI_rules are applied to BPD successfully.
 Notations are correctly associated to the BPD.
Fail Criteria  BPD cannot be created if sequence flow is incorrect.
 BPD search fails if it is not present in the database.
 BPD does not get created if requested notations do not
matched with retrieved notations.
253
Test Item 15 Process BPD
Pass Criteria  Explicit requirements are accepted successfully.
 Implicit requirements generated successfully.
 Explicit requirements are validated successfully.
 Retrieved BPD edited successfully.
Fail Criteria  BPD search fails if it is not present in the database.
 Requirements are not accepted if requirements definitions
and requirements details are insufficient.
 BPD cannot be created without getting implicit
requirements.
 Explicit requirements cannot be validated, due to
incorrect data entered.
 Implicit requirements cannot be generated.
254
Test Item 16 Build Domain Modeler.
Pass Criteria  Provide correct domain (domain name).
 Extract the domain.
 Associate the domain vocabulary.
 Provide valid notation.
 Fetch the notation form database.
 Display notation.
 Generate domain model notation.
 Incorporate domain model notations.
 Display domain model notations.
 Display acknowledgment.
Fail Criteria  False domain provided.
 Domain not available in database.
 Domain vocabulary not associated.
 Notation unable to generate.
 Domain model notations not generated.
255
Test Item 17 Built Domain.
Pass Criteria  User should provide valid domain (domain name).
 Domain generated correctly.
 Domain vocabulary should be generated.
 Domain vocabulary extracted from database.
 Domain vocabulary is associated with domain.
 Display the domain vocabulary.
 Display the association of domain and domain

vocabulary.
 Display domain.
Fail Criteria  Invalid domain provided.
 Domain is not present in database.
 Domain vocabulary is not generated.
 Improper association of domain vocabulary.
 Missing particular vocabulary or association.
256
Test Item 18 Provide Domain Model Notations.
Pass Criteria  User should request for valid notation.
 Notations extracted from database.
 Display notations.
 Provide valid domain model.
 Domain model should be generated.
 Domain model notation associated.
 Display domain model notations.
Fail Criteria  Incorrect notation provided.
 Notations missing in database.
 Domain model not generated.
 Domain model not associated.
257
Test Item 19 Perform Model Transformation
Pass Criteria  Valid model should be provided by user.
 Extract Model form database.
 Associate the meta-model.
 Display association of model and meta-model.
 Extraction of meta-model from database.
 Valid transformation rules provided.
 Display transformation.
 Transformation performed correctly.
 Display meta-model.
 Incorporate the model.
 Display model.
Fail Criteria  Invalid model provided.
 Model unable to extract from database.
 Meta-model missing.
 False transformation rules.
 Model not transformed.
258
Test Item 20 Extract Meta-model.
Pass Criteria  User should provide valid model (model name).
 Extract Model form database.
 Show retrieved model from the database.
 Associate meta-model.
 Generate meta-model.
 Display meta-model.
Fail Criteria  Invalid model provided.
 Model unavailable in database.
 Meta-model not generated.
 Meta-model not associated.
259
Test Item 21 Transform Meta-model.
Pass Criteria  Retrieve the meta-model form database.
 Provide correct transformation rules.
 Extract the transformation rules from database.
 Perform valid transformation.
 Generate the meta-model.
 Display transformed meta-model.
Fail Criteria  Meta-model unavailable in database.
 Invalid transformation rules provided.
 Transformation rules missing in database.
 Transformation not performed.
 Unable to generate meta-model.
260
Test Item 22 Perform workflow checking

Pass Criteria  Accept request from administrator is valid.
 Administrator will send model to user.
 If workspace elements are present in system.
 Search domain present in db.
 Verify the domain and get the model are verified.
 If domain is present retrieve notation from db.
 A workspace element is present.
 System manager will determine changes to element are
valid.
 System will accommodate changes.
 Validate element rules and integrate changes if allowed.
 Check element flows if user will apply correct rules.
 Save into the database and accommodate changes.
 Inspect traceability and show acknowledgement to
administrator.
Fail Criteria  If provide request is incorrect give error message to user.
 If workspace element is not present in db.
 Detail input is not well defined.
 If relational rules are not well applied on models.
 Determine changes of element are invalid.
 If apply incorrect relational rule.
 If changes not allowed to accommodate.
261
Test Item 23 Schedule Workflow
Pass Criteria  Accept request from administrator is valid.
 Administrator will send model to user.
 If workspace elements are present in system.
 Search domain present in db.
 Verify the domain and get the model as well as verify it.
 If domain is present retrieve notation from db.
 Work flow notation must be well separated
 Apply relational rules and Show acknowledgement to
administrator.
Fail Criteria  If provide request is incorrect give error message to user.
 If workspace element is not present in db.
 Detail input is not well defined.
 If any domain are not in database.
 Incorrect domain details provided.
 If relational rules are not well applied on models.
262
Test Item 24 Build workflow traceability

Pass Criteria  Input user is valid.
 Administrator will send model is present in db.
 A workspace element is present.
 System manager will determine changes to element are
valid.
 System will accommodate changes.
 Validate element rules and integrate changes if allowed.
 Check element flows if user will apply correct rules.
 Save into the database and accommodate changes.
 Inspect traceability and show acknowledgement to
administrator.
message.
 Administrator send model not available in db.
 Determine changes of element are invalid.
 If apply incorrect relational rule.
 If changes not allowed to accommodate.
263
3. TEST PROCEDURE
Test Item Check List UML 2.0 Activity Diagram

Test Procedure Specification ID #1
Purpose To test whether the Activity Diagram can be
drawn or not.
Specific Requirements Diagram Notations must be in presence.
Procedure Steps Setup/Startup User clicks on the
“Diagrams” tab and
then on “UML 2.0”
tab
Proceed Check for ease of
access of UML 2.0
Activity Diagrams.
Measure If Activity diagram is
easily reached it
opens its notations.
Pre-Condition User decide UML
diagram to be
drawn.
Post-Condition Page with notations
arise.
Shut Down/Restart Unable to load
Activity Diagram
notations.
Stop For invalid selection
of model/notations.
Wrap up Model checks
availability of
notations.
Contingencies In case of some
abnormal event.
264
265
Test Item Check List Domain Modeler.

Purpose To test Domain modeler notations are drawn or not.
Specific Requirements Notations must be in attendance
“Domain Modeler” tree
folder
Proceed Check for availability of
Domain modeler
models. Double click to
add notations on panel.
Measure If model is accessible its
notations are displayed.
Pre-Condition User decides Domain
Modeler diagram to be
drawn.
come up.
Shut Down/Restart Unable to load model
and its notations
Stop For invalid
model/notation.
Wrap up Model checks availability
of notations.
anomalous event.
266
267
Test Item Check List Domain Modeler.

Purpose To test whether the Database Engineering
are displayed and drawn or not.
Specific Requirements Models must be in presence.
“Domain Modeler”
tree folder
Proceed Check for
availability of
Database
Engineering.
Double click to
add Database
Engineering on
panel.
Measure If model is
available then
Database
Engineering are
displayed.
Pre-Condition User decides
Domain Modeler
diagram to be
drawn.
Post-Condition Page with Domain
Modeler notations
arise.
Domain modeler
notations.
Stop For invalid choice
of notation.
accessibility of
notations.
unusual event.
268
269
Test Item Check List Domain Modeler

Purpose To test whether the extended Network
Symbols notations are displayed and drawn or
not.
Specific Requirements Models must be in presence.
“Network Symbols”
tab
Proceed Check for
accessibility of any
model.
Measure If model tree is

easily reached it
opens its
description.

diagram to be
drawn.
Post-Condition Panel with

model/diagrams
occurs.

model/diagram
notations.

of model/diagram.
Wrap up Checks availability of

diagram/model.

unusual event.
270
271
Test Item Check List Domain Modeler

Purpose To test “Save” of the diagram
Specific Requirements Diagram notations must be obtainable.
Procedure Steps Setup/Startup User clicks on
IFMES. Clicks on
“save as”.
Proceed “Save as” window
appears.
Measure Saves the diagram
successfully.
Pre-Condition User decide to save
the diagram.
Post-Condition Save is successful.
Shut Down/Restart Unable to save
diagram.
Stop For invalid
selection of tab.
Wrap up Invalid name
inserted.
unusual event.
272
273
Test Item Check List Business Process Modeling Notations

Purpose To test whether the flow object model notations
are drawn or not.
Specific Requirements Notations must be in attendance
“BPMN” tree folder
Proceed Check for
availability of flow
object model.
Double click to add
notations on panel.
Measure If model is
accessible its
notations are
displayed.
Pre-Condition User decides BPMN
diagram to be drawn.
come up.
model and its
notations
Stop For invalid
model/notation.
availability of
notations.
anomalous event.
274
275

Purpose To test whether the swim lanes are displayed
and drawn or not.
Specific Requirements Model and notations must be in presence.
“BPMN” tree folder
Proceed Check for
availability of swim
lanes model. Double
click to add swim
lanes on panel.
Measure If model is available
then swim lanes are
displayed.
Post-Condition Page with swim
lanes notations arise.
BPMN model
notations.
Stop For invalid choice of
notation.
accessibility of
notations.
unusual event.
276
277

Purpose To test whether the extended model notations
are displayed and drawn or not.
Specific Requirements Model and notations must be in presence.
“BPMN” tree folder.
Proceed Check for

availability of
extended model.
Double click to add
notations on panel.
then extended model
notations are
displayed.

Post-Condition Panel with Extended

model/diagrams
notations occurs.

extended
model/diagram
notations.
of model/diagram
notations.
Wrap up Checks availability

of diagram/model.

atypical event.
278
279

Purpose To test whether the connecting objects model
notations are displayed and drawn or not.
Specific Requirements Model and notations must be in existence.
“BPMN” tree folder.
Proceed Check for
availability of
connecting objects.
Double click to add
notations on panel.
then connecting
model notations are
displayed.
Post-Condition Panel with
connecting object
model/diagrams
notations occurs.
connecting
object/diagram
notations.
of diagram notations.
Wrap up Checks availability
of diagram/model.
abnormal event.
280
281
Test Item Check List UML 2.0 Activity Diagram

Purpose To test whether the Activity Diagram can be
drawn or not.
tab
access of UML 2.0
Activity Diagrams.
Measure If Activity diagram
is easily reached it
arise.
Activity Diagram
notations.
of model/notations.
availability of
notations.
abnormal event.
282
283
Test Item Check List UML 2.0 Use Case Diagram

Purpose To test whether the Use Case Diagram can be
drawn or not.
tab
access of UML 2.0
Use Case Diagrams.
Measure If Use Case Diagram
arise.
Shut Down/Restart Unable to load Use
Case Diagram
notations.
of model/notations.
availability of
notations.
abnormal event.
284
285
Test Item Check List UML 2.0 Component Diagram

Purpose To test whether the Component Diagram can
be drawn or not.
tab
access of UML 2.0
Component
Diagrams.
Measure If Component
Diagram is easily
reached it opens its
notations.
arise.
Component Diagram
notations.
of model/notations.
availability of
notations.
abnormal event.
286
287
Test Item Check List UML 2.0 Sate Machine Diagram

Purpose To test whether the Sate Machine Diagram can
be drawn or not.
tab
access of UML 2.0
Sate Machine
Diagrams.
Measure If Sate Machine
Diagram is easily
reached it opens its
notations.
arise.
Shut Down/Restart Unable to load Sate
Machine Diagram
notations.
of model/notations.
availability of
notations.
abnormal event.
288
289
Test Item Check List UML 2.0 Sequence Diagram

Purpose To test whether the Sequence Diagram can be
drawn or not.
tab
access of UML 2.0
Sequence Diagrams.
Measure If Sequence Diagram
arise.
Sequence Diagram
notations.
of model/notations.
availability of
notations.
abnormal event.
290
291
Test Item Check List UML 2.0 Class Diagram

Purpose To test whether the Class Diagram can be
drawn or not.
tab
access of UML 2.0
Class Diagrams.
Measure If Class Diagram is
easily reached it
arise.
Shut Down/Restart Unable to load Class
Diagram notations.
of model/notations.
availability of
notations.
abnormal event.
292
293
Test Item Check List Functional Requirement

Purpose To test whether the functional requirement
of user are satisfied or not.
Specific Requirements Requirement must be valid.
“Requirement
view” on tool bar
Proceed Check for
requirement
validity object
model. Double
click to add
requirement on
panel.
Measure If requirement is
valid its notations
are displayed.
functional
requirement to be
drawn.
Post-Condition Functional
requirement
window come up.
requirement and
not present in
database.
Stop For invalid
requirements.
availability of
requirements.
abnormal event.
294
295
Test Item Check List Non Functional Requirement

Purpose To test whether the nonfunctional
requirement of user are satisfied or not.
Specific Requirements Requirement must be valid.
“Requirement
view” on tool bar
Proceed Check for
requirement
validity object
model. Double
click to add
requirement on
panel.
valid add
requirements into
it.
nonfunctional
requirement to be
drawn.
Post-Condition Non Functional
requirement
window come up.
nonfunctional
requirement.
Stop For invalid
requirements.
availability of
requirements.
anomalous event.
296
297
Test Item Check List Requirement lists

Purpose To test whether the requirement of user are
functional or nonfunctional.
Specific Requirements Input must be valid.
“Requirement list”
on tool bar.
Proceed Check for
requirement
validity object
model. Check
requirement is
functional or
nonfunctional.
valid its notations
are displayed.
Pre-Condition User decides to
check whether the
requirement is
functional or
nonfunctional
requirement.
Post-Condition Functional
requirement list
window come up.
requirement and
not present in
database.
Stop For invalid
requirements.
availability of
requirements.
anomalous event.
298
299

System.
Conclusion and References
300
CONCLUSION
The proposed system aims to address the issues related to all management, planning, and
scheduling, control, and data management functions. Information or data will undergo multiple
transformations i.e. many separate task in fulfilling the information-handling requirements for an
enterprise system. These transformations or tasks are usually successive operations forming sets
of sequential and parallel networks.
Once the integration of all of the informational and customer product and service
functions of an enterprise has been well-planned, the actual implementation of such integration
may be broken into a series of coordinated projects.
All tasks will be defined in a modular fashion, along with their required
interconnections. These tasks will be implemented in a modular fashion, again permitting their
later substitution by other different methods of carrying out the same function.
Apart from this, we have also provided basic modeling and editing tool to simplify the
modeling of UML diagrams namely Usecase diagram, Activity diagram, State chart diagram and
Class diagram etc.
This tool is very useful for efficient and effective Requirement Engineering and Usecase
development especially for enterprise. Because of the simplicity of Integrated modeling
Framework, there is no need to put in extra efforts in learning of this tool.
301
REFERENCES
Following is list of references:-
1. Booch, Grady Object-Oriented Analysis and Design with Applications. 2nd

Edition Redwood City, CA: Benjamin/Cummings, 1994.
2. Designing Tool support for Translating Use cases and UML 2.0 sequence diagrams into
CPN by Simon Tjell, Jens Baek Jorgensen ,Dept of Computer Science, University of
Aarhus.
3. http://www.objectime.com/otl/technical/content.html.
4. Domain Specific Models, Model Analysis, Model Transformation, Tivadar
Szemethy, August 2006, Nashville, Tennesse.
5. Domain- Specific Modeling”, Steven Kelly, Juha- Pekka Tolvanen.
6. http://www.omg.org.
7. Mapping User Requirements to Implementations, January 1995, IEEE Software Journal.
8. Software Reflexion Models - Bridging the Gap between Design and Implementation, 4th
April 2001, IEEE Transactions on Software Engineering.
9. Reviewing Software Diagrams - A Cognitive Study, 2nd February 2004, IEEE
Transactions on Software Engineering.
302

Project Synopsis: Integrated Modeling Framework For Enterprise Systems

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Project Synopsis: Integrated Modeling Framework For Enterprise Systems

Hochgeladen von

Copyright:

Verfügbare Formate

Vishwakarma Institute of Technology-37

Integrated Modeling Framework for Enterprise

The principles to formulate enterprise are based on aspects of systems engineering. In

The development of enterprise integration systems important due to:

1.The development environment is extremely competitive.

To provide customer with desired products and services we require to do:

A complete workflow specification requires careful integration of many different process

Tasks in the System Architecture are as follows:

3. Mission Fulfillment - Guidance (control) of the components of the Development (or

Development of a formal Plan involves:

Development of Domain Model:

The proposed methodology integrates the Business Process Modeling, Systems

REQUIREMENT MODELER PROCESS MODELER

1. Improved responsiveness to technical and environmental changes.

Integrated Modeling Framework for Enterprise

A feasibility study is defined as an evaluation or analysis of the potential impact of a

The principles to formulate enterprise are based on aspects of systems engineering. In

The development of enterprise integration systems important due to:

1. The development environment is extremely competitive.

1. WFM: System will perform workflow checking according to the workflow

2. BPMN: It provides business with capability of defining and understanding their

3. RE: In Software Engineering, Requirement Analysis encompasses all of the tasks

A complete workflow specification requires careful integration of many different process

Current Systems and Processes

The main objective of Integrated Modeling Framework for Enterprise System is to

Integrated Modeling Framework for Enterprise System is a Framework which helps in

Assumptions and Constraints

Availability of Information and Resources

Financial considerations including development and operational costs

Changing Operating environments

Enterprise System is mapped into the table given below:

Features Enterprise Rational Rose Vp_UML Integrated Modeling

Architect Framework for

UML 2.0 Yes No Yes Yes

Use Case No No No Yes

NFR Mapping No No No Yes

Modeling Using Use Using Use Using Use Using Requirement

Requirements Cases Cases Cases Diagram

Code Using Class Using Class Using State Using Activity

Generation Diagram Diagram Machine Diagram

CRC Cards No No Yes Yes

2. Java Integrated Development Environment

Recommendations and Conclusion

Integrated Modeling Framework for Enterprise

The objective of Integrated Modeling Framework for Enterprise System is to provide a

Due to rapid changing business requirements the complexity in developing enterprise-

It is necessary to integrate applications on the business and conceptual level as well as

GOALS AND SCOPE

Project Goal Priority Comment/Description/Reference

Project Goal Priority Comment/Description/Reference

The system functionalities can be divided into five main categories

This project will include:

This project will exclude

Schedule and Milestones

Milestones Description Milestone Criteria Planned Date

Integrated Modeling Framework for Enterprise

It provides tools for developing enterprise system.

1. Improved responsiveness to technical and environmental changes.

Definitions, acronyms and abbreviations

The document is divided into three Sections.

This will be achieved by:

 Providing the framework to develop BPD depending on user needs.

 Interweaving between RE and BPD.