Answer Happy

Question1/ Consider the following figure represents a concurrency design model of a real-time system using UML. Based on the design answer the following questions: i. ii. iii. computeAverageValue() int getAverageValue() int its SensorManager SensorManager its Sensor Sensor value int getValue(int itsFan Fan setAirFlow(int) int) itaHeater Heater itsCloseLoopControlThread CloseLoopControlThread setTemptint) int) Discuss the two natures of current system from the design. Draw a concurrency design model for the article Reference 2 case study using the following diagram notation. itsDataAcoThread DataAceThread itsValve Vahe Discuss your design model in bji, as compared to the existing design presented in the article. setFlow(fint) int) itsFilter Filter highPassFilterFreqint BlowPassFilterFreqint filter(s int) int 1 its Closed LoopController.Closedlos tempControlPoint int flowControlPoint int BairflowControlPoint int control Devices():void pData H AveragedData (D) period (100, 'ms) priority=20 // "medium" pData pControl averageValue:int AveragedData itsASD AverageSensedData getAverageValue in setAverageValue(int) void 2 period (10, ms) priority 5 // "high" Interface. AveragedData getAverageValue@int setAvageValue(int):void Averaged Data pData (0) period (30, 'second) priority 100 // "low its OveniewThread Overview Thread itsController Controller tempSetPoint int updateControlPonts():void its Controller Control pControl Question2/ What is deadlock problem in concurrency design? From your concurrency design model in b.ii. answer, discuss and give an illustration example how the problem might happen in the design. Suggest a mechanism to prevent deadlocks in your design.
484 H. Marouane et al./Journal of King Saud University - Computer and Information Sciences 30 (2018) 478-497 following tagged value (patternName, className.role) to indicate that the attribute or the operation is associated with the class whose name is className in the pattern. The information class- Name allows eliminating the ambiguity when two different oper- ation or attribute roles of different class roles have the same name. We proposed to extend the class, the sequence and the use case meta-models by the above described stereotypes as shown in Fig. 1 (for structural view), Fig. 2 (for behavioral view) and Fig. 3 (for functional view). These figures depict the relationships between the UML meta-classes in order to facilitate the under- standing of OCL rules explained in the next section. In fact, Fig. 1 illustrates the UML class diagram meta-model. The latter provides the essential elements (class, classifier, attribute, opera- tion and association) linked through the associations and the inheritance relationships. The structural elements are described by properties (defined with the Property meta-class). The concept of Property has two object properties with cardinality 1. At the instance layer, it is determined if an instance of the class Prop- erty is representing an attribute (contained by a class) or at non-attribute (contained by an association). Besides, the meta- model supports the definition of operations (the Operation meta-class) representing the functions and the methods of a class. Fig. 2 displays the UML sequence diagram meta-model. The Life- line meta-class represents a specific object. Lifelines communicate with each other through messages (Message meta-class). Each mes- sage triggers two events: send event and receive event. The Inter- action meta-class refers to the unit of behavior that focuses on the exchanges of information between a set of objects in the dia- gram. InteractionFragment is a piece of an interaction. The aggrega- tion between the Interaction and the InteractionFragment specifies composite interaction, in the sense that an interaction can enclose other sub-interactions. <<stereotype>> PatternOperation [Operation +patternName: String +className: String +role: String <<meta class>> Operation +owned Operation <<Stereotype>> periodic Operation] +deadine: Date +period: Integer +policy: String +priorby: Integer <<Stereotype>> sporadio [Operation] +triggred Time: Date +deadline: Date +poley: String +priority: Integer <<stereotype>> variation Point [Class] <<Stereotype>> Application Operation [Operation] <<stereotype>> rtDatabase [Class] stereotype nfp [Property] <<meta class>> Classifier <<stereotype>> Pattern Attribute [Property] patternName: String +className: String +role: String +ownedAtt bute Fig. 3 shows the UML use case diagram meta-model. This meta- model covers the basic elements of a use case diagram: Actor, Use- Case, Extend and Include. The Actor meta-class denotes the roles adopted by external entities that interact with the system directly. The UseCase meta-class refers to a set of actions representing the behavior of the system. The use cases can have relationships between them. Basically, a use case can include (or may be included in) other use cases and can extend (or may be extended by) other use cases. These meta-models contain concepts that suffer from a lack of a precise semantics. Therefore, we extended the UML concepts by the above described stereotypes. These stereotypes enhance con- ceptual semantics onto the various UML concepts. In other word, we added the stereotypes to the UML elements in order to assist the designer in differentiating between (i) the fundamental ele- ments and optional elements, (ii) the pattern elements and the specific elements and (iii) the RT concepts and the non-RT concepts. 3.4. Definition of OCL constraints The introduction of variability using stereotypes makes easier the understanding of patterns, but, it can generate some inconsis- tencies. For example, if a mandatory class inherits from an optional class, the resulting model is incoherent. Thus, we proposed to define constraints expressed in OCL in order to reduce the impact of variable elements, ensuring then the consistency and the cor- rectness of patterns diagrams. In fact, these constraints can be applied to ensure the consistency between the (i) elements of the static view, (ii) the elements of the functional view and (iii) the ele- ments of the behavioral view of design patterns. The expression of these constraints is based on the auxiliary operation (isStereotyped (S)) which indicates whether or not an element is stereotyped by a string S. It is formalized in Ziadi et al. (2003) using OCL as follows: +specific 1 general <<Stereotype>> derived [Class] <<metaclass>> Class cemetaclass>>L Property <<meta class>>> Generalization superclass +ownedEnd towningassociation <<metaclass>> Association <<Stereotype>> optional [Association, Class, Operation, Property] <<Stereotype>> sensor [Class] <<stereotype>> Pater PatternClass Class] +patternName: String +role: String <<Stereotype>> Application Attribute <<Stereotype>> variant [Class] Fig. 1. Stereotypes for extension of class meta-model. [Property] cestereotype>>> Application Class [Class] <<Stereotype>> mandatory [Association, Class. Operation Property)
H. Marouane et al./Journal of King Saud University - Computer and Information Sciences 30 (2018) 478-497 <<<Stereotype>> derived Lifeline] <<Stereotype>> sensor Lifeline] eestereotype>> rtDatabase Lifeline] eestereotype>> PatternLifeline [Lifeline] patternName: String role: String <<stereotype>> mandatory [Actor, UseCase] <<stereotype>>> optional [Actor, UseCase) 7777 metacias seine Lifeline <<stereotype>> ApplicationActor [Actor] <<stereotype>> mandatory InteractionFragment, Lifeline, Message) <<<<Stereotype>>> Application Lifeline [Lifeline] <<stereotype>> variant [UseCase] eestereotype>>> periodic [Message] +deadline: Integer period: Integer policy: String +priority: Integer <<stereotype>> sporadic [Message] +deadine: Integer triggredTime: Integer policy: String priority: Integer <<metaclass>>> Actor <<stereotype>>> optional InteractionFragment, Lifeline, Message] met aclass>> Message <<Stereotype>>> PatternActor [Acto] +patternName: String +role: String Context Construct::Class::isStereotyped (S:string):Boolean isStereotyped = self.extensions -> exists(E | E. ownedEnd.type.name = S) <<Stereotype>> Pattern Message Message] patternName: String +role: String <<stereotype>>> variationPoint [UseCase] <<metaclagg>> Interaction +extend +message Fig. 2. Stereotypes for extension of sequence meta-model. In order to ensure the consistency of the static view of design patterns, we applied only the following constraints defined in Rekhis et al. (2013): Constraint CC1: Each association related to an optional class must be stereotyped <optional>>>. 0..1 0..1 <<metaclass>>> UseCase endosinginteraction 0..1 <<metaclass>> Extend <<metaclass>>> fragment InteractionFragment <<Stereotype>> Application Message Message) extension 1 +extendedCase receiveEvent 0.1 0..1 sendEvent <<metaclass>>> MessageEnd <<Stereotype>> alternative InteractionFragment, Message] <<stereotype>> ApplicationUseCase [UseCase] <<stereotype>>> PatternFragment InteractionFragment] <<stereotype>>> PatternUseCae [UseCase] +patternName: String +role: String 11 Fig. 3. Stereotypes for extension of use case meta-model. includingCase inchide <<metaclass>> Include 485 Context Class inv: self.isStereotyped ('optional') implies self.ownedAttribute > forAll(a. a.owingAssociation.isStereotyped ('optional')). In the UML 2.2 meta-model, an inheritance relationship is mod- eled by the Generalization meta-class related to the Classifier meta- class by two associations representing the generic class and the specialized class. Thus, the second constraint is written as follow:
486 H. Marouane et al./Journal of King Saud University - Computer and Information Sciences 30 (2018) 478-497 Constraint CC2: Each class which inherits the feature of an optional super class must be stereotyped <optional>>. Context Classifier inv: self.generalization > forAll (cc.general.isStereotyped ('optional')). implies self.isStereotyped ('optional'). In addition to the two previously-mentioned constraints, we proposed the following: Constraint CC3: Each class, which inherits the feature of a super class defined with the variationPoint> stereotype, must be stereotyped <variant>>>. Context Classifier inv: self.generalization -> forAll (c| c.general.isStereotyped ('variationPoint')) implies self.isStereotyped ('variant'). Constraint CC4: Each attribute and each operation associated with an optional class must be stereotyped <<optional>>. Context Class inv: self.isStereotyped ('optional') implies self.ownedAttribute -> forAll (p p.isStereotyped ('optional')) and self.owned Operation -> forAll (op op.isStereotyped ('optional')). In addition to the static view, the functional and behavioral views represent a part of the pattern solution. Thus, it is necessary to verify the consistency and the correctness of the UML diagrams representing these views. Therefore, we proposed to define OCL constraints for the UML use case diagram and for the UML sequence diagram. For the functional view, we defined the following OCL: Constraint CU1: If an included use case is mandatory, the including use case must be mandatory, too. Context UseCase inv: self.isStereotyped ('mandatory') implies self.including Case.isStereotyped ('mandatory'). Constraint CU2: If a use case is stereotyped <variant», it should have one extended use case stereotyped <variationPoint>>. Context UseCase inv: self.isStereotyped ('variant') implies self.extendedCase.is Stereotyped ('variationPoint'). Constraint CU3: each use case which inherits an optional super use case must be stereotyped <optional>>>. Context redefinableElement inv: self.isStereotyped ('optional) implies self.redefinedEle ment.isStereotyped ('optional'). For the behavioral view, we proposed the following constraints: Constraint CS1: Messages which are associated to an optional lifeline must be optional. Context Lifeline inv: self.isStereotyped ('optional') implies self.interaction. message -> forAll(m | m.isStereotyped ('optional')). Constraint CS2: Messages related to an optional combined frag- ment must be optional. Context Interaction Fragment inv: self.isStereotyped ('optional') implies self.EnclosingInter action.message -> forAll(m | m.isStereotyped ('optional')). Constraint CS3: If a message is mandatory, then the sender and the receiver lifelines must be mandatory. In addition, if this mes- sage is related to a combined fragment, the latter must be mandatory. Context Message inv: self.isStereotyped ('mandatory') implies. self.sendEvent.Message.Interaction.lifeline -> forAll(I | I. isStereotyped. ('mandatory')) and self.receiveEvent.Message.Interaction. lifeline -> forAll(11 | 11.isStereotyped ('mandatory')) and. self.Interaction.InteractionFragment -> forAll(ff. isStereotyped ('mandatory')). 3.5. Evaluation of the DP-RTDB profile Our DP-RTDB profile is evaluated with regard to the design pat- tern specification and instantiation criteria. In Table 3, we com- pared this profile with the already-studied UML profiles. This table shows that none of the UML profiles, presented in Section 2.1, satisfies all these criteria. In fact, some studied profiles proposed extensions that allow covering either the patterns specification cri- teria (e.g. the profile proposed by Arnaud et al. (2008)) or the pat- terns instantiation criteria (e.g. the profile proposed by Dong et al. (2007)). Furthermore, previous works focused mainly on modeling the pattern structure and the pattern behavior. However, they have. some limitations related to expressing variability and representing pattern participant roles, essentially in the functional view. Obvi- ously, the ADOM-UML approach is the only one that expresses cor- rectly the variability criterion since it proposes extensions distinguishing all fundamental and optional elements in the static, functional and behavioral views. In addition, this approach repre- sents the unique profile that satisfies the traceability criterion because it defines extensions to retrieve all pattern elements (i.e.. actors, use cases, classes, attributes, operations, lifelines, messages and interaction fragments). However, this profile fails to satisfy the composition criterion since it does not trace the name of the pat- tern when the latter is instantiated. Besides, the profiles studied in Section 2.1 have limits in ensur- ing the variation point consistency. They do not enable the designer to verify the correctness of each pattern diagram. The ADOM-UML approach, the profile proposed in Park et al. (2013)
Table 3 Comparative analysis of the UML profiles. Arnaud Variability Expressivity Consistency Completeness Traceability Composition H. Marouane et al./Journal of King Saud University - Computer and Information Sciences 30 (2018) 478-497 1 Partially verified. 2 Not verified. 3 Verified. Dong et al. Loo et al. and the UML-RTDP profile are the only ones that define constraints to validate the models. The first approach verifies that the domain constraints are satisfied to validate the application model. But, these constraints do not deal with the dependence of the variable participants in a model. The ADOM-UML approach defines OCL constraints to check the conformance of design patterns instances to patterns. However, these constraints do not allow ensuring the consistency of UML class diagrams of patterns. The UML-RTDP pro- file defines constraints to ensure the consistency in the static view of patterns. However, these constraints are not validated. In addi- tion, the UML-RTDP profile does not define constraints to deal with the dependencies between the variable elements of the use case diagram, and those between the variable elements of the sequence diagram of the considered pattern. These weaknesses can generate some inconsistencies that may be propagated directly into imple- mentation errors. Besides, inconsistencies can result in incorrect pattern instance. Thus, it is necessary to give great importance to define constraints that enable the verification of consistencies of UML patterns diagrams. Unlike the profiles proposed in literature, our DP-RTDB pro- file satisfies conveniently all the pattern specification and instantiation criteria. In fact, it provides expressive extensions based on UML to specify all participants of the class diagram, all participants of the use case diagram and all participants of the sequence diagram. These extensions deal with design pat- terns representation at the specification and the instantiation levels. At the specification level, the DP-RTDB profile has to show clearly the variable participants through the <optional>> and <al- ternative stereotypes. It has also to indicate the fundamental participants through the <mandatory» stereotype. Expressing explicitly the variable elements and the fundamental elements helps the designer choosing the adapted variation in a pattern instantiation. Moreover, this profile defines a set of well-formed rules written in OCL language in order to verify the patterns consis- tency and correctness. These rules allow constraining dependen- cies between pattern variable elements in three views (class diagram, use case diagram and sequence diagram). They allow val- idating the consistency and the correctness of each diagram (see Section 6). At the instantiation level, our DP-RTDB profile allows easily identifying design patterns when they are instantiated by using extensions (e.g., <PatternClass> and <PatternLifeline>>) for explicit representation of patterns participants in software designs. These extensions allow tracing back the patterns par- ticipants (e.g., classes, attributes and methods in the class dia- gram) from a complex design diagram. Besides, the DP-RTDB profile supports the composition of patterns. Indeed, it proposes extensions showing the pattern name and the role names of each participant (classes, uses cases, lifelines, attributes, etc.) which makes easier to recognize the pattern instance when it is composed or integrated with other patterns in a particular design diagram. Reinhartz-Berger et al. ++ ++ Rekhis et al. Park et al. DP-RTDB ++ ++ ++ ++ 487 ++ 4. Case study methodology for UML profile evaluation To evaluate the effects of using pattern annotated with UML profile design method, we present the case study research method proposed by Yin et al. (2014). 4.1. Determining and elaborating the research questions In this case study, the main question to be answered in order to support or reject the main proposition of the case study is as follows: • Is the UML profile an improved method ensuring structural con- formance of UML pattern to the corresponding applications Go to page 20 The following sub-questions are issued from the main preceed- ing question: • How UML profile can improve the design patterns? • Does the UML profile design method result in fewer design defects than the conventional UML design method without profile? • How UML profile can facilitate the pattern instantiation? • Does the design patterns with UML profile result in fewer design defects than the design patterns without UML profile? 4.2. Conducting the case study The researcher collects the requirement specification of each application and some unification rules. An expert designer con- ducts this case study and produces the UML diagrams annotated with UML profile. 4.2.1. The analysis unit The analysis unit in the case study is the requirements specifi- cation documents of each application and some unification rules defined in Marouane et al. (2012). These documents are provided by contacting the organizations and the companies. 4.2.2. Questionnaire The case study researcher asks each designer about his/her background related to their experience in information system, especially in design patterns. In Table 4, there are two different types of questions given in this case study questionnaire: (1) yes- or-no questions, and (2) short-descriptive-answer questions. The results of questionnaire are collected from a group of ten professors on software engineering. These participants had sub- stantial software development experience ranging from 8 to 12 years. In fact, from the answers of question 1 (Q1), the designers agreed that the applications models resulting from the pattern instantiation with the respect to the UML profile are conform to