A Multi-level Methodology for Developing UML Sequence Diagrams
Download as PPTX, PDF0 likes269 views
This document presents a multi-level methodology for developing UML sequence diagrams (SQDs) in a systematic way. The methodology has three levels - the object framework level, responsibility assignment level, and visual pattern level. Each level breaks the SQD development process into discrete stages and provides guidelines to help avoid common errors. The goal is to serve as an easy-to-use reference for novice SQD modelers to develop correct and consistent SQDs.
A Multi-level Methodology for Developing UML Sequence Diagrams
- 1. A Multi-level Methodology for Developing UML Sequence DiagramsIl-Yeol Song Ritu Khare Yuan An Margaret Hilsbos(Unites States of America)ER CONFERENCE 2008 1
- 2. Order of the Presentation SQD: BackgroundRelated ResearchSQD SemanticsDetecting ErrorsTranslating Use-case to SQDOthersNotations of SQDKey FeaturesMulti-levelCorrectnessConsistencyAssumptionsComponent DiagramStepsObject Framework LevelObject Assembly StageObject Rearrangement StageResponsibility Assignment LevelAction Message Mapping StageMessage Responsibility StageVisual Pattern LevelHigh Cohesion CheckLow Coupling CheckFork or Stair CheckCentral Class Check Conclusion Future Work2
- 3. 1. Sequence Diargams: BackgroundHelp in Object Oriented Programming by presenting a visual logic flow. Development Process is intricate. As new objects and messages are identified, the diagram gets more packed and complicated. At every step, multiple factors (which object to choose, which message to assign to what object) need to be taken care of simultaneously. Developer ends up making mistakes. Hence, we present an easy-to-use and practical method for SQD development. 3
- 4. 2. 1 Related Research: SQD Semantics4Xia and Kane (2003) present an excellent attribute grammar based approach on defining the semantics of UML SQD to make it easily convertible to code, and to make these formal methods more usable in the industry. Aredo (2000) prepares a framework for defining the semantics of an SQD to create a shared understanding across a design team. Research Gap: The problem of designing an SQD still remains unresolved especially for the novices who do not hail from computer science background. Hence novices continue to commit errors.
- 5. 2.2. Related Research: Detecting Errors5Baker et al (2005) address the problem of automatically detecting and resolving the semantic errors that occur in SQD scenarios. The tool proposed in this paper is successful in detecting semantic inconsistencies in industrial case studies.Research Gap: Our method takes a preventive action to deal with the semantic inconsistencies by basing itself on the commonly occurring valid patterns in SQD and avoiding the frequently committed mistakes by UML students.
- 6. 2.3 Related Research: Translate Use-case to SQD6Li (2000) presents a semi-automated approach to translate a use case to a sequence diagram. The work is based on syntactic structure of the sentences of use-case description. It presents a parser that makes a tabular analysis distinguishing between the static information (classes, objects attributes and operations) and the dynamic information (message sends from use case description). Research Gap: This motivated us to separate the static and the dynamic elements of an SQD, and deal with them at different levels of the process. Although this paper provides useful rules for novices, e.g. converting a use case to “message sends”, it does not avoid the common mistakes made by novices.
- 7. 2.4 Related Research: Others7Selonen et al (2001) present a method to generate implementation schemes (pseudo codes) using UML sequence diagrams. Both Rountev and Connell (2005), and Merdes and Dorsch (2006), present reverse engineering techniques to extract an SQD from a program. Another interesting work ‘REUSER’ by Robinson and Woo (2004) automatically retrieves reusable SQDs from UML artifacts. Research Gap: Research effort for developing an easy-to-use method for developing SQDs is still rare and far from satisfactory.
- 8. 3. Notation of SQD8UML 2.0
- 9. 4. Key Features 9Extend 10-step heuristics (Song,2001) using use-case and class diagrams. Purpose: To serve as a reference guide for novice SQD modelersKey features: Multi-levelGuidelines and PatternsConsistency checks
- 10. 4.1 Key Features: Multi-level10Re-organize the steps in Song (2001) into three levels and each level is further divided into several stages so that we can focus on one issue at a time. 4.2 Key Features: Guidelines and Patterns11Our subjects include students from different backgrounds including computer science, information science, psychology, biosciences, biomedical, and business. Correctness of the SQD by making use of certain rules and visual patterns.The guidelines were tested and examples were collected for the past five years of teaching SQDs in a graduate class. Warnings to stay away from frequently committed mistakes in drawing SQDs.Incorrect patterns have been found on the basis of our observation of the mistakes students make in SQD assignments to develop SQDs using use-case and class diagrams.
- 11. 4.3 Key Features: Consistency Checks12Provide consistency checks between an SQD and use cases and class diagrams. 5. Assumptions13The construction of SQDs begins the transition from analysis to design. Elaboration of the model is an iterative process, and the models will be updated several times to reflect learning as they become more detailed. For many projects, a complete set of sequence diagrams will not be created. (Ambler, 2008b;Ambler 2008a; and Chonoles and Schardt, 2003)There are other UML diagrams (State, Activity, and Communication) which may be involved, depending on the extent of modeling performed on a project. The consistency checks presented here are generally applicable to Communication diagrams, which are simply a different view of the same information presented in an SQD. The scope of the SQD has already been decided. More information on the definition of scope could be found in Song(2001).
- 13. 7. Method Steps151. Object Framework Level:Identify the building participants which constitute the basic framework of an SQD. 1.1 Object Assembly Stage: Identify the actor, primary BO, primary CO, secondary CO(s), secondary BO(s) for the SQD. 1.2 Object Rearrangement Stage: Rearrange the classes (and also the actor) in the following order: Actor, Primary BO, Primary CO, EOs (list in the order of access), and Secondary COs and Secondary BOs in the order of access. 2.Responsibility Assignment Level: Assign correct responsibilities to each object. 2.1 Action-Message Mapping Stage: Map every automated action in the use-case description to a message in the SQD. Each message would fall under one of the following categories: Instance creation and destruction, Association forming, Attribute modification, Attribute access, Input/Output/Interface, and Integrity-constraint checking. 2.2 Message Re-arrangement Stage: Perform arrangement checks such as: making sure that each message is traceable to the primary actor through activated objects, giving meaningful names to each message, checking consistency of SQD with class diagram, removing any unnecessary return messages, and checking for continuity of focus of control. 3.Visual Pattern Level: Apply final checks based on the visual patterns illustrated by the SQD. 3.1 High Cohesion Check: Make sure that the responsibilities assigned to a class are related, and there exists a high cohesion within a class. 3.2 Low Coupling Check: Re-arrange messages from one class to another class to reduce coupling. 3.3 Fork or Stair Check: Choose between the “fork” and the “stair” pattern depending on the relationship between classes, and taking into account the pros and cons of both patterns. 3.4 Central Class Check: It should be kept in mind that the class, which looks central in the class diagram, is likely to send most messages to other classes in the SQD.
- 14. 7.1 Object Framework Level16In this level, we identify the building blocks which constitute the basic framework of an SQD.
- 15. 7.1.1Object Assembly StageSelect the initiating actor and initiating event from the use case description.Identify the primary display screen needed for implementing the use case. Call it the primary boundary object. Create a primary control object to handle communication between the primary boundary object and domain objects. If the use case involves any included or extended use case, create one secondary CO for each of them. Identify the number of major screens necessary to implement the use case. From the class diagram, list all domainclasses participating in the use case by reviewing the use case description. 17
- 16. 7.1.2 Object Rearrangement Stage18Use the classes just identified as participant names in the SQD. In a logical sequence of actions, tasks begin with an actor interacting with an interface (BO). The BO then passes control to a CO that has resources to carry the required actions, which then passes control to relevant EOs, and so on. Hence, list the actor and the classes in the following order: Actor, Primary BO, Primary CO, EOs (list in the order of access), Secondary BOs, and Secondary COs in the order of access.
- 17. 7.2 Responsibility Assignment Level19Responsibility assignment refers to the determination of which class should implement a message (the target), and which class should send the message (the source).A segment of a SQD and the class in the design class diagram
- 18. 7.2.1 Action-Message Mapping Stage20The messages are identified through the following procedure: Identify verbs from the use-case description.Remove verbs that describe the problem. Select verbs that solve the problem and call them problem-solving verbs.From the problem-solving verbs (PSVs), select verbs that represent an automatic operation or a manual operation by the actor. We call these PSVs problem-solving operations (PSOs) and use them as messages in the SQD. Larman (2004) uses three types of postconditions: Instance creation and destruction, Association forming, and Attribute modification. In this paper, we treat them as PSO categories. Here, we add three more PSO categories: Attribute access, Input/Output/Interface, and Integrity-constraint checking. We use these six PSO categories to identify messages from a use case description. These six types of PSOs can also be used in identifying messages that are necessary but not explicit in the use case descriptions.
- 19. 7.2.1 Action-Message Mapping StageA. Instance Creation and DesctructionB should have the responsibility to send the create() message to A: B aggregates A objectsB contains A objects B records instances of A objectsB closely uses A objects B has the initializing data that will be passed to A when it is created.21X
- 20. 7.2.1 Action-Message Mapping StageB. Association FormingIf there is an association between two classes, then at least one of the SQDs must include a message that forms this association. If a depicted association is never supposed to be used at all, then there must be an error either in the class diagram or the SQD (Ambler, 2008b). Associations can be formed by creating the object with the appropriate parameters or by updating the appropriate parameter in the object. Figure shows an example where the association is formed between :SomeEO and :AnotherEO by the parameter (AnotherEO_id) being passed to :SomeEO at creation. This makes the getX() message possible.22
- 21. 7.2.1 Action-Message Mapping StageC. Attribute Modification (Set/ Compute/ Convert)For each postcondition that causes a state change, there should be a message. The messages change the value of attributes such as deposit_amount(), calc_subscription_charge(), and convert_cm_to_inch(). Any message that sets a value, computes a value, or converts one unit to another belongs to this message type.Simple Calculation Complex Calculation23
- 22. 7.2.1 Action-Message Mapping StageD. Attribute Access(Get/ Find/ Compare/ Sort)This type of message reads values of attributes. Any message that gets a value, finds a value, compares values, and sorts values belongs to this message type.A frequent mistake of novice developers is to try to update an attribute of a read-only class in the use case. 24X
- 23. 7.2.1 Action-Message Mapping StageE. Input/ Output/ InterfaceThis type of messages is usedto input datato display output, generate report to save a data to a storageto interface with external objects or systems. 25X
- 24. 7.2.1 Action-Message Mapping StageF. Integrity-constraint (IC) Checking26Another message type in an SQD is an IC checking operation. Checking a complex integrity constraint usually requires passing of multiple messages among objects. Examples include validating a user input or computing a discount amount based on the current order and customer credit rating.
- 25. 7.2.2 Message Rearrangement StageMake sure that each message is traceable to the primary Actor through activated objects.Name each message with meaningful namesCheck the SQD for consistency with the Class Diagram.27X
- 26. 7.2.2 Message Rearrangement StageCheck if return messages are implied or required. Check for the correctness of focus of control. 28X
- 27. 7.3 Visual Pattern Level29Using GRASP PatternsHigh Cohesion CheckLow Coupling CheckFork or Stair CheckCentral Class Check
- 28. 7.3.1 High Cohesion CheckResponsibilities of a class are closely related A class should not have diverse responsibilities.As in figure, logically :PaidSubscriber should not be responsible to edit/create the subscription information. Hence, a Controller is used to create a new subscription. 30X
- 29. 7.3.2 Low Coupling Check31Ensure that every recipient of a message and every parameter in the message is either part of the state of the object that is sending it; passed as a parameter to the method sending the new message; or returned from a previous message sent within the current method. (Law of Demeter; Rowlett, 2001)To send a message, use a source class that is already coupled to the target class. Introduce a CO if many messages are being passed between two classes. In this way the CO can coordinate among multiple objects. Make sure a parameter is not passed again and again in multiple messages.
- 30. 7.3.3 Fork or Stair CheckApplication of the aforementioned guidelines result in a visual pattern to the SQD, which is descriptively called a “fork” or “stair” pattern (Jacobson, 1992).A “fork” structure is recommended When messages could change the order When there is a central object that controls many messages as in the case of enforcing an integrity constraint. A “stair” structure is recommendedWhen there is no central object in the SQDWhen messages have strong connections among objects based on relationships such as temporal relationships or an aggregation hierarchy. Fork PatternStair Pattern 32
- 31. 7.3.4 Central Class CheckThe “central class” concept of Chonoles and Schardt(2003) is helpful. They suggest identifying a central class for a use case, and note that this class will probably do a large part of the work in the interaction.It can be seen that Obj2 is the central class – it has the shortest access route (least hops) to all the other classes in the interaction.It might be an indication that responsibilities are incorrectly assigned. (Obj5 has the most difficult access to the other classes). 33X
- 32. 8. Conclusion 34We have presented a multi-level development methodology for developing SQDs in UML. We have included guidelines and common visual patterns in SQDs while highlighting the frequently committed mistakes by novices. The guidelines were tested and examples were collected for the past five years of teaching SQDs in a graduate class. The students found our guidelines usable and effective.
- 33. 9. Future Work 35Perform a more extensive study to measure the number and the nature of mistakes they make at each level of the proposed methodology.Handle loops and conditionals.Create and Delete participants. Deal with Timing Inconsistency. Enhance the resulting SQD to make it easily convertible to the source code.
- 34. Questions, Comments, Thoughts, Ideas???Thank You!!!36