Rekayasa Perangkat Lunak 2 (IN043): Pertemuan 6. Moving on to Design

Transcription

1 Rekayasa Perangkat Lunak 2 (IN043): Pertemuan 6 Moving on to Design

2 Analysis versus Design The purpose of analysis is to figure out what the business needs are. To achieve this, the analysis activities ignored nonfunctional requirements such as performance and the system environment issues (e.g., distributed or centralized processing, user interface issues, and database issues). The purpose of design is to decide how to build the system. The primary purpose of the design models is to increase the likelihood of successfully delivering a system that implements the functional requirements in a manner that is affordable and easily maintainable. The goal of design is to create a blueprint for a system that makes sense to implement. Final design details in preparation for the implementation phase, and they ensure that programmers have sufficient information to build the right system efficiently. Design also includes activities such as designing the user interface, system inputs, and system outputs, which involve the ways that the user interacts with the system. In system design, it must address both the functional and nonfunctional requirements.

3 Verification and Validation of the Analysis Models Before evolve from analysis representations into design representations, it is a need to verify and validate the current set of analysis models to ensure that they faithfully represent the problem domain under consideration. This includes testing the fidelity of each model; for example, the activity diagram(s), use-case descriptions, and use-case diagrams all describe the same functional requirements, and between the models, for instance, transitions on a behavioral state machine are associated with operations contained in a class diagram.

4 Verification and Validation through Walkthrough A walkthrough is essentially a peer review of a product. The review typically is completed by a team of individuals that comes from the analysis team, the design team, and the client. The purpose of an analysis walkthrough is to thoroughly test the fidelity of the analysis models to the functional requirements and to ensure that the models are consistent. A walkthrough does not correct errors it simply identifies them. Error correction is to be accomplished by the analysis team after the walkthrough is completed.

5 Functional Model Verification and Validation (1) There are different representations for the functional model suggested: activity diagrams, use-case descriptions, and use-case diagrams. A set of rules that will test the consistency within the functional models: First, when comparing an activity diagram to a use-case description, there should be at least one event recorded in the normal flow of events, subflows, or alternate/exceptional flows of the usecase description for each activity or action that is included on an activity diagram, and each event should be associated with an activity or action. Second, all objects portrayed as an object node in an activity diagram must be mentioned in an event in the normal flow of events, subflows, or alternate/exceptional flows of the usecase description. Third, sequential order of the events in a use-case description should occur in the same sequential order of the activities contained in an activity diagram.

6 Functional Model Verification and Validation (2) Fourth, when comparing a use-case description to a use-case diagram, there must be one and only one use-case description for each use case, and vice versa. Fifth, all actors listed in a use case description must be portrayed on the use-case diagram. Furthermore, each one must have an association link that connects it to the use case and must be listed with the association relationships in the use-case description. Sixth, in some organizations, it should also included the stakeholders listed in the usecase description as actors in the use-case diagram. Seventh, all other relationships listed in a use-case description (include, extend, and generalization) must be portrayed on a use-case diagram. Finally, in an activity diagram a decision node can be connected to activity or action nodes only with a control flow, and for every decision node there should be a matching merge node.

7

8 Structural Model Verification and Validation (1) Three representations that could be used for structural modeling: CRC cards, class diagrams, and object diagrams. A set of rules that will test the consistency within the structural models: First, every CRC card should be associated with a class on the class diagram, and vice versa. Second, the responsibilities listed on the front of the CRC card must be included as operations in a class on a class diagram, and vice versa.

9 Structural Model Verification and Validation (2) Third, collaborators on the front of the CRC card imply some type of relationship on the back of the CRC card and some type of association that is connected to the associated class on the class diagram. Fourth, attributes listed on the back of the CRC card must be included as attributes in a class on a class diagram, and vice versa. Fifth, the object type of the attributes listed on the back of the CRC card and with the attributes in the attribute list of the class on a class diagram implies an association from the class to the class of the object type. Sixth, the relationships included on the back of the CRC card must be portrayed using the appropriate notation on the class diagram.

10 Structural Model Verification and Validation (3) Seventh, an association class, should be created only if there is indeed some unique characteristic (attribute, operation, or relationship) about the intersection of the connecting classes. If no unique characteristic exists, then the association class should be removed and only an association between the two connecting classes should be displayed. Eighth, there are times that subclasses contained in a class diagram are really nothing more than different states through which an instance of the superclass will go during the instance s lifetime. Finally, as in the functional models, there are specific representation rules that must be enforced. For example, a class cannot be a subclass of itself.

11 Behavioral Model Verification and Validation (1) Three different diagrams that could be used to represent the behavioral model: the sequence diagram, the communication diagram, and the behavioral state machine. A set of rules that will test the consistency within the behavioral models: First, every actor and object included on a sequence diagram must be included as an actor and an object on a communication diagram, and vice versa. Second, if there is a message on the sequence diagram, there must be an association on the communications diagram, and vice versa. Third, every message that is included on a sequence diagram must appear as a message on an association in the corresponding communication diagram, and vice versa.

12 Behavioral Model Verification and Validation (2) Fourth, if a guard condition appears on a message in the sequence diagram, there must be an equivalent guard condition on the corresponding communication diagram, and vice versa. Fifth, the sequence number included as part of a message label in a communications diagram implies the sequential order in which the message will be sent. As such, it must correspond to the top-down ordering of the messages being sent on the sequence diagram. Sixth, all transitions contained in a behavior state machine must be associated with a message being sent on a sequence and communication diagram, and it must be classified as a (C)reate, (U)pdate, or (D)elete message in a CRUD matrix. Finally, all entries in a CRUD matrix imply a message being sent from an actor or object to another actor or object. If the entry is a (C)reate, (U)pdate, or (D)elete, then there must be an associated transition in a behavioral state machine that represents the instances of the receiving class.

13 Balancing Functional and Structural Models (1) To balance the functional and structural models, we must ensure that the two sets of models are consistent with each other. That is, the activity diagrams, use-case descriptions, and use-case diagrams must agree with the CRC cards and class diagrams that represent the evolving model of the problem domain. Some rules balancing functional and structural models: First, each and every class on a class diagram and each and every CRC card must be associated with at least one use case, and vice versa. Second, every activity or action contained in an activity diagram and every event contained in a use-case description should be related to one or more responsibilities on a CRC card and one or more operations in a class on a class diagram and vice versa.

14 Balancing Functional and Structural Models (1) Objective: the activity diagrams, use-case descriptions, and use-case diagrams must agree with the CRC cards and class diagrams that represent the evolving model of the problem domain. Some rules balancing functional and structural models: First, each and every class on a class diagram and each and every CRC card must be associated with at least one use case, and vice versa. Second, every activity or action contained in an activity diagram and every event contained in a use-case description should be related to one or more responsibilities on a CRC card and one or more operations in a class on a class diagram and vice versa.

15 Balancing Functional and Structural Models (2) Third, every object node on an activity diagram must be associated with an instance of a class on a class diagram, (i.e., an object) and a CRC card, or an attribute contained in a class and on a CRC card. Fourth, every attribute and association/aggregation relationships contained on a CRC card (and connected to a class on a class diagram) should be related to the subject or object of an event in a use-case description.

16 Balancing Functional and Behavioral Models (1) Objective: the activity diagrams, use-case descriptions, and use-case diagrams must agree with the sequence diagrams, communication diagrams, behavioral state machines, and CRUD matrix. Some rules balancing functional and behavioral models: First, the sequence and communication diagrams must be associated with a use case on the use-case diagram and a use-case description. Second, actors on sequence diagrams, communication diagrams, and/or CRUD matrices must be associated with actors on the usecase diagram or referenced in the use-case description, and vice versa.

17 Balancing Functional and Behavioral Models (2) Third, messages on sequence and communication diagrams, transitions on behavioral state machines, and entries in a CRUD matrix must be related to activities and actions on an activity diagram and events listed in a use-case description, and vice versa. Fourth, all complex objects represented by an object node in an activity diagram must have a behavioral state machine that represents the object s lifecycle, and vice versa.

18 Balancing Structural and Behavioral Models (1) Objective: to discover the interrelationships among the structural and behavioral models. Some rules balancing structural and behavioral models: First, objects that appear in a CRUD matrix must be associated with classes that are represented by CRC cards and appear on the class diagram, and vice versa. Second, because behavioral state machines represent the life cycle of complex objects, they must be associated with instances (objects) of classes on a class diagram and with a CRC card that represent the class of the instance.

19 Balancing Structural and Behavioral Models (2) Third, communication and sequence diagrams contain objects that must be an instantiation of a class that is represented by a CRC card and is located on a class diagram. Fourth, messages contained on the sequence and communication diagrams, transitions on behavioral state machines, and cell entries on a CRUD matrix must be associated with responsibilities and associations on CRC cards and operations in classes and associations connected to the classes on class diagrams. Fifth, the states in a behavioral state machine must be associated with different values of an attribute or set of attributes that describe an object.

20 Evolving from Analysis to Design From an object-oriented perspective, system design models simply refine the system analysis models by adding system environment (or solution domain) details to them and refining the problem domain information already contained in the analysis models. When evolving the analysis model into the design model, it should first carefully review the use cases and the current set of classes (their operations and attributes, and the relationships between them). A way to evolve problem domain-oriented analysis models into optimal solution domain-oriented design models: Factoring, partitions and collaborations, and layers.

21 Factoring Factoring is the process of separating out a module into a stand-alone module in and of itself. The new module can be a new class or a new method. Abstraction and refinement are two processes closely related to factoring. Abstraction deals with the creation of a higher-level idea from a set of ideas. The refinement process is the opposite of the abstraction process.

22 Partitions and Collaborations Partitions: Based on all the factoring, refining, and abstracting that can take place to the evolving system, the sheer size of the system representation can overload both the user and the developer. At this point in the evolution of the system, it may make sense to split the representation into a set of partitions. A partition is the object-oriented equivalent of a subsystem, where a subsystem is a decomposition of a larger system into its component systems. From an object-oriented perspective, partitions are based on the pattern of activity (messages sent) among the objects in an object oriented system. Collaborations: One useful way to identify collaborations is to create a communication diagram for each use case. It can be an easy describe to model partitions and collaborations later with packages and package diagrams. Depending on the complexity of the merged collaboration, it may be useful in decomposing the collaboration into multiple partitions.

23 Layers (1) A layer represents an element of the software architecture of the evolving system. There should be a layer for each of the different elements of the system environment (e.g., data management, user interface, physical architecture). Like partitions and collaborations, layers also can be portrayed using packages and package diagrams

24

25 Layers (2) Foundation layer: It contains classes that are necessary for any object-oriented application to exist. They include classes that represent fundamental data types (e.g., integers, real numbers, characters, strings), classes that represent fundamental data structures, sometimes referred to as container classes (e.g., lists, trees, graphs, sets, stacks, queues), and classes that represent useful abstractions, sometimes referred to as utility classes (e.g., date, time, money). Problem domain layer: To further detail the classes so that it will be possible to implement them in an effective and efficient manner.

26 Layers (3) Data management layer: Addresses the issues involving the persistence of the objects contained in the system. The types of classes that appear in this layer deal with how objects can be stored and retrieved. Human computer interaction layer: Contains classes associated with the View and Controller idea. The primary purpose of this layer is to keep the specific user interface implementation separate from the problem domain classes. This increases the portability of the evolving system. Physical security layer: Addresses how the software will execute on specific computers and networks.

27 Package A package is a general construct that can be applied to any of the elements in UML models, for instance: To group use cases together to make the use-case diagrams easier to read and to keep the models at a reasonable level of complexity. To group classes and communication diagrams. To group packages.

28 Package Diagrams

29 Package Diagram of Package Diagram Layers for the Appointment System

30 Package Diagram of CD Selections Internet Sales System

31 Selecting a Design Strategy

32 Exercise Do s0me verification, validation, and balancing of your models built several weeks ago. Build a package diagram of your cases.

33