Scenario Definition & Visualization Tool Architecture & Design in Practice Abhilash Gopalakrishnan Power Technologies, ABB Global Industries & Services Ltd, Bangalore, 919901001609
[email protected] ABSTRACT Software has evolved from smaller components to a major contributor in systems engineering, leading to a discipline of software-intensive systems. Software architecture and design plays a significant role in these systems than ever. In this context, some of the major challenges faced by today’s architects/designers that of the quality of requirements, the influence of stakeholders on every stage of software life cycle and the agility required. This paper walks through an experience of developing a scenario visualization tool following a feature driven software chain approach where requirements are further developed, technical decision making based on careful evaluation and analysis of the characteristics.
Categories and Subject Descriptors D2.10 [Design]: Methodologies, Representation D.2.11 [Software Architecture]: Domain-specific architectures, Patterns. D.2.13 [Reusable Software]: Domain Engineering, Reusable libraries, Reuse models, D.2.m [Miscellaneous]: Rapid Prototyping.
General Terms Design, Experimentation and Verification are the general terms involved.
leadership therefore is way bigger. The team looks forward to technical leader to steer the ship to safe seas. Technology leadership is often a technical lead who also plays the software architect role. Let us look at the context of software-intensive systems in some more detail. A software-intensive system is any system where software contributes essential influences to the design, construction, deployment, and evolution of the system as a whole [2][3]. Software comprises of 40% of features of a rapidly growing range of products and services from all sectors of economic activity. The examples for software intensive systems are vehicular systems, industrial control systems and telecommunication systems, the quality attributes of these can be found in Table 1. Table 1: Characteristics of Software Intensive Systems [3] Attribute Name
Industrial System
Reliability
High Reliability – Probably of failure is 10-9
High Reliability – Probably of failure is 10-
Safety
Safety important and applies more to certain types of Process - IEC 61508 SIL /ANSI/ISA84.01-199
ISO 26262 Safety Integrity level for Automobiles
Availability
High Availability and Only Planned Shutdown. Redundancy used
Redundancy used both as node as well as communication paths. Based on application
High Security needs based on zones
Security capabilities exist. Used or not used.
Keywords Software frameworks; software-intensive systems; software architecture; design.
1. INTRODUCTION Software has evolved from smaller components to a major contributor in systems engineering, leading to a discipline of software-intensive systems. The time-to-market i.e., the speed at which solutions are delivered has significantly reduced event in systems. At the same time quality is not to be compromised to ensure the end users trust these systems. Software programming languages are increasingly becoming abstract [1]. A typical example of increasing abstraction is the case of File Transfer Protocol (FTP) client. Six years back, for supporting FTP, it would be required to develop an entire stack, whereas today most of the frameworks come with the support as framework classes. Another noticeable change is the fact that most general purpose software is available either as Commercial Off The Shelf (COTS) or Open Source libraries. The emerging technologies and methods contribute to the confusion. The designer or architect is caught in this confusion when there is lot of expectations on understanding requirements in the domain front in these systems. The role and significance of technical
Security
Control
Vehicular Systems
9
The engineering disciplines involved here are Systems Engineering, Control Engineering and Software Engineering. Systems Engineering is an interdisciplinary approach to enable the realization of successful systems. It focuses on defining customer needs and functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the lifecycle of these systems from engineering, operations, evaluation, training and supporting, testing, disposal and manufacturing [4]. Not only that these systems differ in characteristics, but also involve a trust factor with the people operating them. Thy should strictly operate in a timely manner and take actions protecting people and equipment, like an Operator Training Station , where the need is to replicate the characteristics close to real system behavior.
front with guidance prototypes, or else developers tend to deviate from guidelines described in architecture documents. While making technical decisions it is important as well to make judgments listening to the stakeholders as well as the development team for the decisions to be successful. Once candidate architecture is selected, communicating the architecture with both stakeholders and development team stays as one of the biggest challenges. Furthermore, throughout the lifecycle it is to be ensured that architectural guidelines are followed throughout. Let us go through these challenges in more detail.
Figure 1: Architecture Model from IEEE 1471 Std.
2. CHALLENGES IN ARCHITECTURE AND DESIGN OF SYSTEMS Architecture plays the multiple roles as; a vehicle for communication among stakeholders, manifestation of earliest design decisions about a system and transferable, reusable abstraction of a system. As in Figure 1, the architecture and design activity involves identifying the needs of the system, identifying the architectural elements and their interrelationships, and communicating the architecture which includes documenting as well as demonstrations and presentation meetings [5]. In short this is bridging the gap between problem space and solution space. The activity spans throughout the lifecycle of the software development project. A typical case of architect’s involvement in project can be found in Figure 2. It is important to notice that the involvement is high in the beginning especially requirements, design and reduces slightly in construction and then again ramps up towards test, integration and acceptance phases. During lifecycle, the key challenges faced by an architect therefore spans both problem space and solution space. For example the challenges in problems space include lack of a good description of requirements and scope creep for existing requirements. Within the solution space it is required for the architect to demonstrate the leadership by leading from the
Figure 2: Involvement of Architect in Software Lifecycle
Lack of good description of requirements is a general problem. However best a requirement is described, it is always possible that the description needs to be supplemented with information like the quality attributes attached to, for example, like the graphics need to be loaded and playing in 5 seconds time. This is required for verifying and validating the architecture and its capabilities. Often the real requirement is revealed when the acceptance phase and customer involvement begins. The architect in fact plays a role in bridging this gap in the problem space by asking questions leading to clearer description of the system thus ensuring the success of the proposed candidate architecture. To summarize at a very high level the architect’s role is about identifying the environments, the goals and system objectives and proposing and demonstrating a solution that can satisfy the goals and system objectives. As in Figure 3, there are several factors influencing the architect/architecture team which includes the stakeholders, the development organization, the technical environment and their experience. The challenge lies in the fact that the architect needs to weigh these and decide on the right parameters of tradeoff. Often it is important to note that the architect is as much a representative of the stakeholder/end user as much as is a representative of the builder/organization. We present the journey of architecture and design for a tool development, which summarizes how the architecture team approached it and how they dealt with the challenges of developing an architecture which met the expectations of stakeholders including end users. The discussion also focuses on the methods followed to communicate the architecture and demonstrations done for building the confidence of the team and stakeholders and making sure the development team can follow and verifying at intermediate steps if this is followed as expected.
Figure 3: Factors influencing the architect
3. ARCHITECTURE & DESIGN FOR SCENARIO DEFINITION AND EVALUATION It is important to notice what Simon Brown means when he states ‘Software development is not a relay sport’ [6]. Software architecture is often misunderstood for being more on consulting mode or a part-time activity. The involvement of an architect might increase or reduce during the lifecycle, but it is most important to understand that architecture plays the pivotal role of bringing the system components and making them work together and therefore architect as well plays a pivotal role of bringing the stakeholders and developing team on a common understanding and making the organization work together towards success. Architecture activity revolves around these steps; 1.
User Story/Feature Analysis,
2.
Requirements Elicitation,
3.
Technology/Framework selection,
4.
Candidate Architecture selection,
5.
The Architecture Feedback Loop,
6.
Preparing Logical Architecture,
7.
Preparing Physical Architecture,
8.
Evaluating Architecture,
9.
Communicating Architecture,
10. Enforcing Architecture. Each of these steps is important in the walkthrough since these represent essential aspects to building successful architectures.
Narrative
Acceptance Criteria
The user should be able to define the connections between these elements using easy connectors. The user should be able to define the sequence of actions in the workflow. These aspects need to be stored file format 1. Elements HMI, Controller, Process Model are available and visible for instantiation 2. Elements can be dropped into editor pane and positioned 3. Elements can be connected together using communication elements 4. The topology and messages and their sequences can be described 5. The contents of the editor can be saved as a file and stored. 6. The contents are loaded and checked if they contain the full description and elements, connections and sequences.
3.2 Requirements Elicitation As in Figure 4, the requirements fall under varied categories and it is important to understand that stakeholders providing inputs include the architect as well. If the required details are not found as described, it is important for architect to discuss with the counterparts and make sure the clarity of requirements exists and quality attribute values are available so that we can verify architecture as well. The architecturally significant use cases/user stories with their quality attributes involved after discussion with stakeholders and reference systems revealed the following quality attributes:
3.1 User Story/Feature Analysis
1.
The Scenario Definition & Visualization Tool feature is described as presented in Table 2.
A Scenario with 50 types/objects should be easy to be prepared within 10 seconds.
2.
Loading and Starting the Scenario Player for a scenario with 50 types or objects and 10 transitions should happen within 5 Seconds.
3.
Ability to extend the types so as to support various domains like electric and general process control .
4.
Ability to interface and sent commands to existing simulation tools.
Table 2: User Story for Feature User Profile Background
Objective
User is product manager (Advanced knowledge of industrial automation components.) The user is familiar of objects like HMI, Controller, and Process Model. The user tries to document a requirement. The user would need this information be stored, shareable and executable by some other colleagues. Able to position, instantiate the elements in a visual pane, connect them and define the sequence.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee, provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Conference’14, Month 10, 2014, Hyderabad, Andhra Pradesh, India. Copyright 2013 ACM 1-58113-000-0/00/0010 …$15.00.
Figure 4: Categories of requirements
5.
The Type and Scenario data models and graphical elements should be technology independent, so that newer graphical engines can be easily integrated.
6.
The system should be able to behave as close to the real scenarios in plant to be giving a realistic experience.
3.3 Technology/Framework Selection The technology or framework selection involved an evaluation phase where the various alternatives would be evaluated against the requirements for the tool as the technology maturity aspects to be considered. The results can be found in Table 3. Table 3: Technology Evaluation
Figure 5: Architecture Feedback Loop of the prototype. The feature based software chain approach often allows us to validate performance calculation at component levels thereby able to arrive at a value of total chain working together from which signals whether we can really satisfy the quality attribute/non-functional requirements by using this architecture approach.
Qt
Microsoft .NET
HTML5
Platform Independence
YES
NO
YES
3.6 Preparing Logical Architecture
Animation Supported
YES
YES
YES
Ease of Use
Medium
High
High
The architecture decomposition is done into four parts which include;
Maturity
High
Medium
Low
Technology Expertise in Organization
High
Medium
Low
Technology/ Criteria
Technology Level
The rationale for selection of Qt as technology mainly depended on Platform Independence, Animation Support the maturity level and the expertise on the technology within the organization.
3.4 Candidate Architecture Selection Candidate Architecture and Selection Process involved the steps including relevant reference architectures, the architecture proposal and verification/evaluation of architecture to make sure it can meet the goals. 1. Search for Reference Architectures from within or known from architect’s experience or open source. 2. Propose candidate architecture based on the references and existing problem solution pairs like the Design Pattern Framework from dofactory, an architecture pattern score card and design pattern score card. 3. Evaluating the architecture based on prototypes thereby clearly making sure that the principles can satisfy the quality attribute performance criteria.
1.
Object Model & Toolbox
2.
Engineering scenario definition and view
3.
Animation Framework for scene play
4.
Communication engine interface for simulation.
Based on the decomposition of the tool, the analysis of the decomposed features is performed and the analysis led to the artifacts. The extensibility aspect is realized using the reflection pattern and the layers architectural patterns, the design patterns identified to include factory and singleton, the frameworks included Qt and Adaptive Communication Framework (ACE) Frameworks[7][11].
The Search for reference architectures resulted in Table 4. Table 4: Reference Architectures Scenario Editor QT Creator IDE & SharpDevelop IDE (Open Source)
Scenario Playing
Type Loader
Simulation Interoperability Standards
Engineering Libraries& Simulation Interoperability Standards
3.5 The Architecture Feedback Loop The architecturally significant scenarios/use cases are the basis on which architecture team prepared guidance prototypes. The deviation of prototypes with respect to quality attribute values defined, was fed back to be taken care in the next evolution
Figure 6: Tools for Solution Space
Table 5: Inputs to Candidate Architecture Artifact
As Applied
ARCHITECTURE PATTERN
REFLECTION, LAYERS
ARCHITECTURE TACTICS
USABILITY
DESIGN PATTERNS
FACTORY SINGLETON
DATA STRUCTURES ALGORITHMS
&
METHOD,
XML PARSING
OPEN SOURCE
QT FRAMEWORK
REFERENCE ARCHITECTURE
Adaptive Communication Environment (ACE) FRAMEWORK
Based on the decomposition and details arrived at in Table 5, , the logical architecture was arrived at as in Figure 7 with a toolbox, graphical view, animation framework and communication engine to interface with external simulation platforms.
3.7 Preparing Physical Architecture The logical architecture, once realized the Object Model uses C++, the Graphical Libraries a mix of Qt and C++, the editor itself realized using Qt Graphical View and the animation engine based on Qt Animation Framework.
3.7.1 Data Model The data model for the type information is based on Simulation Interoperability Standards Organization (SISO) standard called Base Object Model. Based on this model the Type data is available as file in XML format as shown in Figure 8. The data model for scenarios are as well uses XML, but a more simplified model where we have identifiers for the types, the topological information, action sequence and the communication sequence.
Figure 8: Type Data and Scenario Definitions The XML based samples depicting Type of Boiler and the usage of a boiler in a scenario is depicted in Figure 8. Each type comes with an xml file based on Base Object Model [12].
3.7.2 Object Model The object model involves Model Identification, the conceptual model. The model mapping and object model definition as in SISO Standard is not implemented in the solution as of now as in Figure 9. The Scenario definition follows a simpler model containing the scene topology items, scene actions and communication actions as defined and referenced from the available types.
Figure 7: Logical Architecture
Figure 9: Base Object Model
3.7.3 Feature Driven approach with Software Chains
within 10 seconds.
In the beginning we followed an approach where we have been focused on a more feature driven and software chain approach and the software focusing on these features; 1.
Engineering Scenario Definition and View,
2.
Animation Framework for scene play.
Loading and Starting the Scenario Player for a scenario with fifty types or objects and ten transitions should happen within 5 Seconds.
This includes a.
Loading scenario with five types/objects -2 seconds
b.
Start Playing loaded -1 second
once
With fifty types loading the xml file could take 10 seconds
Figure 10: Software Chain: Scenario Definition & View The feature of scenario definition is broken into elements in the chain like 1.
Type XML for BOILER, TURBINE, GENERATOR and CONTROL,
2.
Load and Display Types in Tool Box,
3.
Drag and Drop and create the scenario of Boiler Control,
4.
Save Scenario in file.
Similarly a chain was created for animation play using the same scenario file created from scenario definition feature and software developed to perform animation using these elements.
3.8 Evaluating the Architecture For the first iterations, the architecture fared against the defined scenarios and demonstrated the values for quality attributes as shown in Table 6. [13]. Table 6: Evaluating against scenarios for Quality attributes Scenario
Performance Chain
From
A Scenario with fifty types/objects should be easy to be prepared within 10 seconds.
For five objects dragging dropping and creating a scene it tool
Ability to extend the types so as to support various domains like power system.
Factory Method and XML Type including SISO BOM Standards allowed these extensions.
Ability to interface and sent commands to existing simulation tools.
Communication Actions and the communication engine integrated allowed communication with simulation tools.
The Type and Scenario data models and graphical elements should be technology independent, so that newer graphical engines can be easily integrated.
The usage of XML as the data format leaves the ability to use the multiple graphic engines. It is also possible that the scenario file created using Qt based approach be made use for scenario playing in HTML based user interface.
From Table 6, it is clear that the second scenario and the quality attributes are not satisfied. This invites the need of an architecture feedback loop where we redo the elements of the software chain and reassess the scenario. In order to make sure this would be satisfied the XML reader was modified and seen how much this incremental addition of types affect the performance. By making these modifications in the scenario readers, a bigger set of types were created i.e., 20 and then on evaluation it was found that loading scenario was still happening in 2 seconds. Following this approach we could make sure that the fifty objects in 5 seconds could still be met using our architecture.
3.9 Communicating the Architecture The Architecture Description consists of a system context, goals and system objectives, development and target environments and finally the solution and how it achieves goals and system objectives.
Software
a.
Create Topology seconds
b.
Connect seconds
c.
Define three Scene Actions -20 seconds
elements
-20 -5
Most of this gets done in one second. Therefore on an average fifty Objects this should be well
. Figure 11: Architecture Description
4. LEARNING From the observations and experience on the software development, following points could be considered as major learning:
Figure 12: Scenario Editor & Boiler Control in Action Architecture Description (AD) acted as the platform for communication. AD also included viewpoints catering to various stakeholders for example like Layered View, Runtime View, Deployment View and Development View. AD is supplemented by the demonstrator and demonstration sessions, that the architect invited the team and stakeholders. The meeting involved presenting the architecture to the stakeholders and development teams, providing chances of question answer sessions and discussions, thereby convincing the teams and the stakeholders how well the architecture fits the requirements. As in Figure 12, the demonstrator performing one sample scenario creation and playing and demonstrating it helped the stakeholders to provide better feedback and thereby we arrived at more clear quality attributes and behavioral aspects were improved based on these inputs. The improvement was evident from the number of defects detected reducing towards the phases later to requirements from 71 to 15.
3.10 Enforcing the Architecture Architecture evolves over a period of time and stabilizes. It is important that architect makes sure via review process that during the entire development and even later during the maintenance the guidelines described in architecture are followed religiously. This is enforced by following approaches: 1.
Building interfaces between modules to make sure the system is well organized and the separation is clear,
2.
Intermediate technical reviews by reverse engineering code into modeling tools like enterprise architect and checking if the guidelines are followed,
3.
Review results posted for action/tasks to the teams thereby making sure that they are resolved over time.
a.
An evolutionary prototyping approach based on a sample scenario for a feature termed ‘Feature Oriented Software Chain’, when developed, demonstrated and improved on stakeholder feedback tend to succeed better in today’s business environments. This reduced lot of rework hereby ensuring improved productivity. Agreeing on acceptance criteria for each feature provides the baseline for better communication on requirements.
b.
An efficient reuse of existing knowledge artifacts like reference architectures, standards, architecture, design patterns and domain models can significantly help deliver quality software as well as reduce time and effort. These serve as requirements model as well.
c.
In context of Systems Engineering, Operational Scenarios are more significant and these serve as a platform for better communication between stakeholders and development team. Capturing these operational scenarios as part of feature oriented chain aligns itself with agile approaches, still underlines the fact that clarity or granularity of requirements is essential for success.
5. ACKNOWLEDGMENTS I thank Power Technologies R&D, ABB Global Industries and Services Limited, for the kind support extended for this work.
6. REFERENCES [1] Jack Greenfield and Keith Short, with contributions by Steve Cook and Stuart Kent “Software Factories: Assembling Applications with Patterns, Frameworks, Models & Tools". ISBN 0471202843. [2] Nick Rozanski and Eóin Woods “Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives (2nd Edition)”, Nov 4, 2011. [3] IEEE Computer Magazine, “NextGen Vehicular Systems”, June 2012. [4] European Commission & US National Science Foundation "Workshop Report and Recommendations - Engineering Software -Intensive Systems”, 22-23 May, 2004. [5] IEEE-Std-1471-2000: IEEE Recommended Practice for Architectural Description for Software-Intensive Systems. [6] Simon Brown “Software Architecture for Developers” https://leanpub.com/software-architecture-for-developers [7] Pattern Oriented Software Architecture, Volume 1 and 2 (POSA). [8] Len Bass, Paul Clements and Rick Kazman, “Software Architecture In Practice” – Second Edition Apr 19, 2003. [9] Erich Gamma, Richard Helm, Ralph Johnsonand John Vlissides, “Design Patterns: Elements of Reusable ObjectOriented Software” November 10, 1994, ISBN9780201633610.
[10] Mark Nelson,"C++ Programmer's Guide to the Standard Template Library", December 1995.
http://www.sisostds.org/ProductsPublications/Standards/SIS OStandards.aspx
[11] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides “Design Patterns: Elements of Reusable ObjectOriented Software” November 10, 1994 ,ISBN9780201633610
[13] Requirements Engineering Visualization PlatformArchitecture and Experiences – Abhilash Gopalakrishnan, Abhinna Biswal, Ashoka Shyamaprasad 2012.
[12] Simulation Interoperability Standards:
