Methodology Of Scenario Based Integration And Testing

Published Date: 02 Nov 2017

"The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system" (Booch, 1994).

History of OOP and UML

The creation of UML was a result of the collaborative efforts of computer scientists Jim Rumbaugh, Ivar Jacobson and Grady Booch. Prior to its existence, each gentleman had developed a design method of his own. Collectively, those methods were referred to as the ‘Big Three’:

 The Object Modeling Technique (OMT) / Jim Rumbaugh

 The Object-Oriented Software Engineering Method (OOSE) / Ivar Jacobson

 Object-Oriented Analysis & Design (OOAD) / Grady Brooch

In 1994, the three men sought out to unify their modeling languages, intent on creating a standardized, general-purpose modeling language for object-oriented software developers. The first version of UML was officially released in 1996 (Quatrani, 2003).

UML Diagrams

UML diagrams provide software developers with a means by which to analyze a system from different perspectives such as organization, behavior and chronology of system events. This in turn enables them to design detailed software applications. There are currently 14 different UML diagrams, each of which lies in one of two categories:

 Structural UML Diagrams define the static structure of a system; they depict those components of a system that are irrespective of time such as physical infrastructure and how they are wired.

 Behavioral UML Diagrams emphasize on the mode of a system’s functions. It relates the behavioral criteria necessary in order for a system to function in a particular way or to meet a certain objective.

STRUCTURAL UML DIAGRAMS

Class Diagram - A class represents a set of objects that have common state and behavior. A class diagram is a depiction of the

INTRODUCTION CHAPTER ABOUT UML3

relationships between the classes of a system.

Usage – This diagram is used in the construction of executable code. It also serves as the foundation for component and deployment diagrams.

Advantages – Business analysts can use class diagrams to create models of systems from a business point of view.

Limitations – It is difficult to establish what a system may be lacking on the class level and its overall capabilities.

Component Diagram - A component is a replaceable, executable piece of a larger system. A component diagram models the physical aspect of arbitrarily complex object-oriented software systems, such as libraries, files, packages, etc. It shows the architecture of individual components within the system and the dependencies between them.

Composite Structure Diagram - This diagram shows the internal structure of a class and how this structure makes possible the interactions between this class and others.

Usage – It is used to provide concise definitions for the basic behavior of the system.

Advantages – Since a component is an executable part of a program, it is easy to find out whether or not it fulfills its intended purpose.

Limitations –

Deployment Diagram - A deployment diagram provides a model for the mapping of artifacts to nodes in a software system; it shows existing hardware and software components and how these elements relate. While component diagrams describe the components of a system, deployment diagrams describe how these components are deployed in hardware.

Usage – This diagram is used to manipulate the performance, scalability, maintainability and portability of a system.

Advantages – It is an in depth view of exactly how the system works since it incorporates both the software and hardware aspects of the application.

Limitations – Because of the

INTRODUCTION CHAPTER ABOUT UML4

complexity of this diagram, it is difficult to interpret.

Object Diagram - An object diagram illustrates the relationship between objects of a class at a particular instant in time.

Usage – Used to provide snapshots of the system during the design process in order to assess whether the design of the system is going according to plan.

Advantages – A collection of object diagrams provide useful insight on how a certain aspect of the system is meant to evolve. They typically serve as examples for class diagrams; because objects are specific entities, object diagrams hold more information than class diagrams.

Limitations – Because objects are so basic, an object diagram cannot provide a generalized view of any particular aspect of the system.

Package Diagram - A package is a mechanism for grouping related modeling elements (classes, interfaces, diagrams etc.). A package diagram shows the organization of model elements and the relationship between packages in a system.

Usage – This diagram to is typically used in large-scale systems to capture the dependencies between major elements of those systems.

Advantages – Each package in a package diagram can be worked on by a different group of people. Subdividing work is a good way of ensuring the quality of the resulting application.

Limitations – The diagram operates on a very complex level and thus requires many analytical and design resources.

Profile Diagram - A model, in software engineering is a visual representation of phenomena in the real world. A meta-model is a model which represents properties of the model itself.

BEHAVIORAL UML DIAGRAMS

Use-Case Diagram - A use-case diagram is a visual representation of the functional requirements of a software system. It follows the different users in a system

INTRODUCTION CHAPTER ABOUT UML5

(actors), the various system functionalities (use-cases) and the elements responsible for implementing these functionalities.

Usage – This diagram is commonly used to explain the various working mechanisms of the system to non IT staff.

Advantages – Since use-cases focus on the actors of a system and how their decisions affect system output, the actual needs of the system are brought out early in the design phase. Furthermore the use of narrative text in a use-case diagram makes it easy for any user to understand; more input from stakeholders increases the quality of design.

Limitations – This diagram does not accurately reflect every function of the system. It can only work as a guideline for the system’s overall purpose

Activity Diagram - An activity model emphasizes on execution and flow of control of a system. While interaction diagrams show the flow of messages from one object to another, activity diagrams focus on the message flow between activities.

Usage – This diagram is commonly used with interaction and state diagrams in order to analyze a use-case and identify the actions that need to take place and when they should occur.

Advantages – Since it is so understandable, this diagram is a useful tool in analytical reports.

Limitations – A model including an activity diagram tends to become very complex because the user-friendliness of the diagram may lend itself to all-inclusive descriptions.

Interaction Diagram - An interaction diagram focuses on how the different objects of a system communicate.

There are 4 types of interaction diagrams, namely: Sequence Diagram, Communication Diagram, Timing Diagram and Interaction Overview Diagram

Sequence Diagram - This is a visual representation of the chronology of message passing between the objects of a system and its

INTRODUCTION CHAPTER ABOUT UML6

actors. It shows the existing classes in a particular use-case scenario and the sequence in which messages between them are exchanged over a given time period.

Advantages – Because it provides a snapshot of what happens within a given time frame, this diagram enables a designer to identify common interactions as well as elements that may be missing in a system.

Limitations – A single diagram on its own is inconclusive and there is no definite number of diagrams that comprise a design; the number is determined by the experience of the designer. Moreover, sequence diagrams do not accurately depict loops or conditional processes.

Communication Diagram - This model also represents the sequence in which messages between objects are exchanged. The difference however, lies in the presentation. Communication diagrams emphasize the nature of the interaction between elements, while sequence diagrams show better the order in which the interactions take place.

Advantages – This diagram helps to assess whether the resources enabling message passing are efficient.

Timing Diagram - A timing diagram represents the behavior of a set of objects within a given time constraint. It can be used to view the change of state of a set of elements over a given time period as well as the interaction between a given set of timed events.

State Machine Diagram - This is a chart which can be used to depict various types of systems, whether computer or business related. It depicts the life-cycle of a given object, describes the different states that object assumes during its life-time, the cause of transition between states and the resultant actions of this transition.

Advantages – It facilitates troubleshooting of the system. If an object behaves

INTRODUCTION CHAPTER ABOUT UML7

in an undesirable way, the cause of this behavior is easily traceable.

Limitations - UML state machines are not purely diagrammatical; a typical state machine requires a large amount of written information and thus depends heavily on the programming language used to build the software application under design.

Integrating UML Diagrams with other Diagram Techniques to Model Systems in Industrial

Engineering

Object-oriented languages such as UML can be used to model very complex software applications. However, UML emphasizes the preliminary phases of software development and is typically used to describe the ideal functionality of a system. Software developer as the basis for their designs and implementation is continually using it (Wu, 2003). Systems integration is the building of end-to-end solutions comprising prebuilt components integrated together to form a whole system that functions independently. They are made up of many subparts purchased from different vendors and brought together using special software techniques (Clements, 2003). System integration may be applied in industrial engineering in the development of EPOS terminals that are integrated with stock control systems to be able to management systems to have an overall view of the activities in the production lines. Different computer systems and software applications may also be linked up to coordinate the activities of the organization

Methodology of Scenario-Based Integration and Testing

The purpose of scenario-based integration is to create an outline of requirements by gathering all the information about a system that lies in the various models that have been constructed.

In order to conceptualize and build a test scenario, a number of factors should be considered including the choice of system scenario upon which the test scenario will be based, an outline of the infrastructure onto

INTRODUCTION CHAPTER ABOUT UML8

which the test case will be executed,  a list of system requirements and how they map onto the test case, a map of the test case onto the technical infrastructure and finally the definition of what the test is meant to accomplish (Clements, 2003).

In order to meet the above objectives, the following steps must be taken:

Inventory Deployment Model

The main objective of this model is to illustrate the number of nodes within the system and the software artifacts for each node. It serves as an inventory of the entire system’s various hardware and software components (Strembeck, 2004).

Deployment Model with Low-Level Communication Paths

Because a deployment diagram is an illustration of the functional nodes within a system, it should allow the developer to identify the communication paths between nodes at the physical level. This is vital as it helps to correctly configure the test scenario and thus eliminate any faults or discrepancies that may be present in the system.

Deployment Model with Layer 3 Communication Paths

It is important for this model to illustrate the protocols that govern the test scenario. In so doing, each package can be linked to a specific protocol and target destinations can be identified. Proper deployment of communication paths ensures that system integration is completed with minimal resources.

Deployment Diagram on the Application Level

The purpose of this step is to show how this infrastructure is mapped onto the physical and logical network, given that there may be several distributed applications that can be represented by this model.

Physical Deployment Model for each Node

Each node in the system contains a number of applications communicating with each other from within the node. Furthermore, these processes were most likely developed

INTRODUCTION CHAPTER ABOUT UML9

by different organizations. Thus to correctly deploy a node, the developer must know the relationship between the application’s subsystems such as how they are interconnected, where inter-process collaboration takes place, and the order of these collaborations.

Node Behavior

To ensure the correctness of the test scenario, it is crucial for the integration to identify if subsystems follow the chosen scenario. The use of state-chart notation illustrates how each node reacts to a given set of stimuli and thus helps to identify any discrepancies in the system.

MSC

The MSCs developed in this step must reflect the overall structure of the system. In addition, they must be detailed enough to identify the nodes that take part in the different parts of the scenario, the processes involved in their communication, the data transferred between them, and all the protocols used during these processes.

Use-Case Map

Each MSC in the test case reflects only one aspect of the system’s various activities and the developer assumes that there are no outside influences from other scenarios. However, in application, this is not always true. Use-case maps help to identify the relationship between MSCs and other features of the system. They illustrate the possible outcomes when the test case scenario occurs directly on the system depending on which aspect of the system is under scrutiny (Miga, 2001).

 

Other Existing Diagramming Techniques

Diagramming Principles

There are to principles that are common to all diagramming techniques. Each diagram should be able to present a view of the entire system independent of other views and must be clear and fully understood. The context of the diagram must be understood from the viewpoint of its title, title block, a reference to a larger (smaller)

INTRODUCTION CHAPTER ABOUT UML10

context, or some combination thereof (Teory, 1990).

1. Logic Flow Charts

Refer to Appendix 1

Flowcharts place their focus on decisions which is a special process that is used in data-flow and object diagrams. The shapes are used to create conventional flowcharts. The techniques used in flowcharts include:

1. Functions, or processes, are represented by rectangles.

2. Decisions represented by diamonds.

3. Inputs represented by parallelograms.

4. Outputs represented by a hardcopy symbol (a rectangle with a wavy bottom edge).

Nassi-Schneiderman Diagrams also referred to as Chapin Charts, are a modern alternative to flowcharts. They can be drawn using text and lines showing processes by series, by selection or by iteration. They are read from top to bottom and are more structured than flowcharts

2. Entity Relationship Diagrams

Entity Relationship Diagrams are used to model the entities that a computer system records information about, and the relationships between those entities (Chen, 1976). They can be created from an existing database schema or they can be created from scratch. They begin with a user-readable form that allows validation of a design and progress into culminating in versions that are used by developers to validate a design (Chen, Peter, et. al., 1999).

3. Data Flow Diagrams

It is a formal, structured analysis approach that assists in the functional decomposition process. They are comprised of four components (Martin, James & O'Dell, 1998):

1. External interactors represented by a rectangle.

2. Data stores represented by an open rectangle (2 or 3 sides)

3. Processes represented by any rounded object (a circle, oval, or square with rounded corners).

4. Data flows represented by arrows, with labels indicating their content.

4. Object Oriented Diagrams

Object oriented diagrams made a great contribution to the development of UML (Martin, James &

INTRODUCTION CHAPTER ABOUT UML11

O'Dell, 1998). The Sally Shlaer and Stephen Mellor method is used on projects that have not adopted the UML. It major components are (Booch, 1994):

• Domain chart - used to partition the system into domains and subsystems.

• Information Model - used to build a static analysis model of a system, showing objects, relationships, and inheritance structures

• State model - used to analyze the object's behavior over time.

• Process Diagram, or Action Data Flow Diagram

• Object Communication Model (OCM) - summarizes the asynchronous event communication between state models in the system.

• Object Access Model (OAM) - summarizes the synchronous communication between state models and object instance data.

James Rumbaugh proposed an alternative methodology on Object Oriented Diagrams. His model defines class, object, state, and data-flow diagrams to model a system analysis and design (Rumbaugh, Blaha, Premlani, Eddy & Lorensen,1991). Some of the attributes of the object models include the object diagram, state-transition diagram (dynamic model) and data flow diagram (functional model). The advantage of the object modeling technique is that it allows for two different models of data to be displayed in the same diagram. Therefore, one diagram can show two different levels of association.

Grady Booch notation is the most complete method for representing the object-oriented systems (Coleman, 1999). It is however very complex and can lead to duplication and fragmentation of information across model diagrams. His model is made up of six diagrams: class, object, state transition, interaction, module, and process.