Project Topics
Get Complete Project Material File(s) Now! »
System Engineering vs. Software Engineering
In the light of above discussion comparison between two disciplines can be established. [14] [13]
• System engineering is comprised of well-organized process through which operational desires and specific requirements are transformed into system.
• Software engineering provides disciplined approach for developing software system by utilizing resources efficiently.
• System engineering hierarchy consist of four views i.e. world view, domain view, element view and detailed view. To established proper business or technology context entire domain will be examined. It is termed as world view, domain comes around when context have been established and engineers start focusing on particular domain of interest. When engineers narrow their focus by paying attention on each element of system individually i.e. elements view.
• According to Pressman [14] software engineering starts from element view, when software element is focused individually. After element view, implementation detail of each element is considered which relate to detailed view.
In light of above mentioned points, it can be easily observed that software engineering activities are conducted within context of system engineering. Actually software engineering and system engineering both are the processes used for the development of some kind of products that fulfils the need of the customers by designing, developing and documenting. Where software engineering is used to create those products only which can perform software intensive tasks. System engineering used to prepare the whole system which includes different parts like hardware, software, documents. In short, software engineering activities occur as a consequence of system engineering activities.
SYSMLARCHITECTURE
Actually SysML is evolved to provide simple and effective constructs to address modeling issues of complex system engineering problems. As SysML reuse subset of UML, it seems to be a good approach to describe its architecture with respect to UML as shown by Venn diagram in fig.2, where UML and SysML are represented by two intersecting circles.
Following three areas of concern can be easily extracted from fig.2. [1].
• UML reused by SysML.
• SysML extensions to UML.
• UML not required by SysML.
SysML is comprised of nine standard views/diagrams whereas UML consist of thirteen views/diagrams. Actually SysML retain some diagrams with out modification while a number of diagrams are adopted with modifications. Further more SysML also introduce several new diagrams which are not present in UML. These diagrams are actually considered as extensions made by SysML. SysML diagrams are generally divided into three categories as shown by Fig.3 by keeping in view three areas of concern given by Venn diagram in fig.2 [1].
1. Diagrams that are used same as UML 2.0.
2. Diagrams used with slight modification from UML 2.0.
3. New types of diagrams.
Cross-Cutting Constructs
Cross-cutting constructs play a significant role in SysML architecture. Actually these construct map one element to another. These constructs may take the form of allocations, requirements, and parametric. Most important cross-cutting construct is allocations which define a basic allocation relationship that will be used to allocate a set of model elements to another, such as allocation of model elements from behavior to structure constructs or allocating from logical to physical components or from software to hardware. Actually allocation relationship provides an effective way to navigate model by creating cross relationship. Further more it also ensures that various part of model are appropriately integrated. The major concern of cross-cutting constructs is to support activities that will be conducted across the different views, and may be addressed by all or disparate parts of the model.
UML VS SYSML
In recent time UML has become a de-facto standard of software industry. The language is widely adopted for analyzing and designing software. It is common thinking that UML is software centric and can not be used for system engineering but only suitable for software engineering. However UML has been used for system engineering for many years.
However it should be noted that UML is facing certain challenges relating to system engineering. These challenges include representation of inputs and out puts, continuous systems, physical structures and system characteristics like reliability, safety, performance and parametric relationships.
Further more, it is not appropriate to hold idea that UML and SysML are two separate languages. In fact SysML provides a set of useful extension to UML to support system engineering activities. Although OMG has made several enhancement in UML 2.0 to support system engineering like UML 2.0 has been improved for specifying large and complex architectures and it became easy to decompose complex architectures by applying UML 2.0 structured classifiers, activity diagram partitions is one of major enhancements. The capability of UML 2.0 to integrate structures has been enhanced by cross cutting functionalities. Actually through this functionality model and behaviors are integrated. Further more UML 2.0 also make enhancement in activity diagrams.
No doubt these developments makes UML quite suitable for system engineering but need for certain customize language is always there. For this purpose Systems Engineering Domain Special Interest Group (OMG SE DSIG) [22] and INCOSE[11] work together to customize UML for special needs of system engineers.
Elements Introduced by SysML
The major challenge faced by SysML group at OMG and INCOSE was to make changes in UML 2.0 but they had to make sure that only extremely necessary changes were made. They tried their best to use as much UML as they can. In the beginning lot of changes had been suggested but SysML group recommended following new concepts
Requirements Diagram
Requirements are foundation stone for every system development. In UML there is no direct support of requirement engineering to make-up this deficiency SysML introduced support of requirement engineering in a sense that engineer not only build requirement model but also relate requirement to actual design elements and test procedures. Use case model in UML can only develop an understanding of system but can not help greatly towards traceability of requirements because through use case, requirements are traced to use case only not to design elements. In UML note is used to write comments but it is not considered as model element i.e. designer may exclude these comments from model if they want and there is always a chance that some valuable comments may be lost. To avoid this difficulty SysML requirement diagram provides concept of rational, which is considered as model element. In fact rational provides space for writing comments against requirements, so that it becomes traceable to design element and test case. Rational information actually makes sure that design decisions should also become part of requirement diagram. The rational information may also be helpful for analyzing change impact on requirements. SysML requirement diagram provide a great support for traceability of requirements, and define a trace dependency for this purpose, through this relationship it is possible to relate derived requirements to source requirements. This diagram also play very significant role in solving different complexity problem in requirement, it is possible to decompose requirements through containment relationship just as we can develop containment relationship in UML class diagram. It is always a problem for modeler to link requirement with design elements; this difficulty is by providing satisfaction dependency. It is also possible to relate requirement with associated test cases by means of verification dependency.
According to Hause et al [29] one of the strengths of UML is that it is more than just a set of diagrams but there exit an underlying model, which supports the diagrams. In a similar manner requirement diagram also has requirement model behind it. The SysML proposal states “The requirements model describes the SysML support for describing textual requirements and relating them to the specification, analysis models, design models, etc. A requirement represents the behavior, structure, and other properties that a system, component, or other model element must satisfy”.
However it should be noted that SysML depicts requirement as requirement stereotype of UML class [7].In short, modeling of requirements specifications is very much possible in SysML by keeping in tact different aspects regarding requirements like priority, traceability. In fact only basic features of requirements can be modeled directly, for modeling certain specialized requirements like performance, storage, design constraints designer have to relay on stereotypes.
Parametric Diagram
One of the significant advancement made by SysML is inclusion of parametric diagram. Parametric diagram use constraints block as constraints properties. In fact a constraint blocks package expression of constraints. These constraints are packed up in such a way that they can be reusable for other constraints blocks.
Actually through constraints blocks SysML provide mechanism for conducting engineering analysis such as performance and reliability. With the help of constraints block it become possible to establish network of constraints along with their respective mathematical expressions. Parametric diagram also has capability to bind parameters of constraints actually all properties of constraints blocks are defined in term of its parameters. In short we can say that parametric diagram is a restricted form of internal block diagram that represent constraints block along with their respective constraints. The keyword <<constraints>> is used in block definition to show that it is a constraints block. Constraints compartment of block definition will contain expression that specify constraints. However it should be noted that SysML does not provide any particular language for writing Mathematical expressions.
IBM Rain Sensing Wiper (RSW); Case Study
At IMB research division Laurent.B considered an embedded system called Rain Sensing Wiper RSW [33] to demonstrate capabilities of SysML in product life cycle. The motivation for selecting this case study for analyzing SysML capabilities is that IBM playing pivotal in development of modeling tools. Further more case study is base on system through which hardware, software aspect can be considered comprehensively.
Actually RSW belongs to automobile industry. Important characteristic of RSW is that various engineering discipline have been involved in designing this system. The major objective of system is to clean windshield. When some liquid is detected on windshield, system starts working without any involvement of user.
System consists of three types of components;
1. Software i.e. algorithms, which controls activities of hardware.
2. Electronic control unit, which execute software.
3. Sensor, which detects droplets on screen.
Engineers will integrate these components to establish overall structure of system. The motivation for selecting RSW system is that verity of disciplines are involving in system structure, it can provide a good platform for analyzing capabilities of SysML for system engineering applications. Actually system is based on two parameters.
• Windshield optical and geometric specifications, specially its thickness and its optical indexes.
• Operational ranges of sensors.
To make system more flexible it is necessary to specify certain ranges for windshield and sensor. This feature permits engineers to make important design choices. However it should be noted that for best performance there should exit great compatibility between values of windshield properties and sensor.
Table of contents :
1 INTRODUCTION
1.1 BACKGROUND
1.2 AIMS AND OBJECTIVES
1.3 RESEARCH QUESTIONS
1.4 EXPECTED OUTCOME
1.5 ASSUMPTIONS
1.6 RESEARCH PLAN
1.7 THESIS OUTLINE
2 A COMPARATIVE STUDY; SYSTEM ENGINEERING VS SOFTWARE ENGINEERING
2.1 SYSTEM ENGINEERING
2.1.1 System Engineering Process
2.1.1.1 State the Problem:
2.1.1.2 Investigate Alternatives
2.1.1.3 Model the system
2.1.1.4 Integrate
2.1.1.5 Launch the system
2.1.1.6 Assess performance
2.1.1.7 Re-evaluate
2.2 SOFTWARE ENGINEERING
2.3 SYSTEM ENGINEERING VS. SOFTWARE ENGINEERING
2.4 WHY SYSML?
3 SYSML ARCHITECTURE
3.1 STRUCTURE
3.2 BEHAVIOR
3.3 REQUIREMENT
3.4 PARAMETRIC
3.5 CROSS-CUTTING CONSTRUCTS
4 UML VS SYSML
4.1 ELEMENTS INTRODUCED BY SYSML
4.1.1 Requirements Diagram
4.1.2 Parametric Diagram
4.1.3 Allocations
4.1.3.1 Behavioral Allocations
4.1.3.2 Flow Allocation
4.1.3.3 Structural allocations
4.2 EXTENSIONS
4.2.1 Activity Diagram
4.2.1.1 Probability:
4.2.1.2 Rate:
4.2.1.3 Optional:
4.2.1.4 Continuous:
4.2.1.5 Discrete:
4.2.1.6 Control Operator:
4.2.1.7 No Buffer:
4.2.1.8 Overwrite:
4.2.2 Block Diagrams
4.2.2.1 Labeled compartments
4.2.2.2 Constraints compartment
4.2.2.3 Namespace compartment
4.2.2.4 Structure compartment
4.2.3 Ports and Flows
4.2.3.1 Standard Ports
4.2.3.2 Flow Ports
4.2.3.3 Item Flows
4.2.3.4 Outcome
5 DEVELOPMENT OF EVALUATION CRITERION
5.1 EVALUATION CRITERIA FOR SYSML
5.2 IBM RAIN SENSING WIPER (RSW); CASE STUDY
6 APPLICATION OF CRITERIA ON SIMILAR
6.1 STATE THE PROBLEM
6.2 INVESTIGATE ALTERNATIVES
6.3 MODEL THE SYSTEM
6.4 INTEGRATIONS
6.5 LAUNCH THE SYSTEM
6.6 ASSESS PERFORMANCE
6.7 RE-EVALUATION
7 DISCUSSION AND FUTURE WORK
7.1 DISCUSSION
7.2 VALIDITY THREATS
7.2.1 Internal validity
7.2.1.1 Maturation threats
7.2.1.2 Testing threats
7.2.1.3 Selection threats
7.2.2 Construct Validity
7.2.3 External Validity
7.2.4 Conclusion Validity
7.3 FUTURE WORK
8 REFERENCE
