Software Engineering Lab Manual: Use Case and Activity Diagrams for Software Design, Essays (university) of Software Engineering

Download Software Engineering Lab Manual: Use Case and Activity Diagrams for Software Design and more Essays (university) Software Engineering in PDF only on Docsity! 01 SOFTWARE ENGINEERING LAB MANUAL SCHOOL OF ENGINEERING Department of Computer Science & Engineering III B.TECH – I SEM Academic Year 2018-19 R16 Regulation Prepared by Mr. S. Rajesh Mr. N. Rajender Associate Professor Associate Professor Ms.B.Bhagyalaxmi PROGRAMMER SOFTWARE ENGINEERING LAB MANUAL Course Objectives: 1. To understand the software engineering methodologies involved in the phases for project development. 2. To gain knowledge about open source tools used for implementing software engineering methods. 3. To exercise developing product-startups implementing software engineering methods. Prepare the following documents and develop the software project startup, prototype model, using software engineering methodology for at least two real time scenarios or for the sample experiments. 1. Problem Analysis and Project Planning -Thorough study of the problem – Identify Project scope, Objectives and Infrastructure. 2. Software Requirement Analysis – Describe the individual Phases/modules of the project and Identify deliverables. Identify functional and non-functional requirements. 3. Data Modeling – Use work products – data dictionary. 4. Software Designing - Develop use case diagrams and activity diagrams, build and test class diagrams, sequence diagrams and add interface to class diagrams. 5. Prototype model – Develop the prototype of the product. The SRS and prototype model should be submitted for end semester examination. Course outcome: Develop the software project startup, prototype model, using software engineering methodology Open source Tools: ▲ StarUML / UMLGraph / Topcased INDEX S NO: EXPERIMENT NAME PAGE NO. SOFTWARE ENGINEERING LAB MANUAL 2.6. Apportioning of requirements 3. Specific Requirements 3.1 External interface requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communication interfaces 3.2 Specific requirements 3.2.1 Sequence diagrams 3.2.2 Classes for classification of specific requirements 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.5.1 Reliability 3.5.2 Availability 3.5.3 Security 3.5.4 Maintainability 3.6 Other requirements 4. Supporting information 4.1 Table of contents and index 4.2 Appendices 1. Introduction The following subsections of the SRS should provide an overview of the entire SRS. 1.1 Purpose Identify the purpose of this SRS and its intended audience. 1.2 Scope. SOFTWARE ENGINEERING LAB MANUAL (1) Identify the software product(s) to be produced by name (2) Explain what the software product(s) will, and, if necessary, will not do (3) Describe the application of the software being specified. As a portion of this, it should: (a) Describe the relevant benefits, objectives, and goals as precisely as possible (b) Be consistent with similar statements in higher-level specifications if they exist. 1.3 Definitions, Acronyms, and Abbreviations Provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the SRS. This information may be provided by reference to an appendix or other document(s). 1.4 References In this subsection: (1) Provide a complete list of all documents referenced elsewhere in the SRS. (2) Identify each document by title, report number (if applicable), date, and publishing organization. (3) Specify the sources from which the references can be obtained. 1.5 Overview Describe the rest of the SRS and how it is organized. 2. THE GENERAL DESCRIPTION Describe the general factors that affect the product and its requirements. This section usually consists of the five subsections that follow. This section does not state specific requirements; each of its subsections makes those requirements easier to understand; they do not specify design or express specific requirements. 2.1 Product Perspective This subsection of the SRS relates the product to other products or projects. (1) If the product is independent and totally self-contained, it should be stated here. (2) If the SRS defines a product that is a component of a larger system or project: (a) Describe the functions of each component of the larger system or project, and identify interfaces (b) Identify the principal external interfaces of this software product (not a detailed description) SOFTWARE ENGINEERING LAB MANUAL (c) Describe the computer hardware and peripheral equipment to be used (overview only) A block diagram showing the major components of the larger system or project, interconnections, and external interfaces can be very helpful. 2.2 Product Functions Provide a summary of the functions that the software will perform. Sometimes the function summary that is necessary for this part can be taken directly from the section of the higher-level specification (if one exists) that allocates particular functions to the software product. The functions should be organized in a way that makes the list of functions understandable to the customer or to anyone else reading the document for the first time. Block diagrams showing the different functions and their relationships can be helpful. Such a diagram is not a requirement on the design of a product itself; it is simply an effective explanatory tool. 2.3 User Characteristics Describe those general characteristics of the eventual users of the product that will affect the specific requirements. Many people interact with a system during the operation and maintenance phase of the software life cycle. Some of these people are users, operators, and maintenance and systems personnel. Certain characteristics of these people, such as educational level, experience, and technical expertise impose important constraints on the system's operating environment. SOFTWARE ENGINEERING LAB MANUAL 4. Visual modeling and Rational Rose Tool Visual modeling is the graphic representation of objects and systems of interest using graphical languages. Visual modeling languages may be General-Purpose Modeling languages or Domain-Specific Modeling languages. Rational Rose is an object-oriented Unified Modeling Language (UML) software design tool intended for visual modeling and component construction of enterprise-level software applications. In much the same way a theatrical director blocks out a play, a software designer uses Rational Rose to visually create (model) the framework for an application by blocking out classes with actors (stick figures), use case elements (ovals), objects (rectangles) and messages/relationships (arrows) in a sequence diagram using drag-and-drop symbols. Rational Rose documents the diagram as it is being constructed and then generates code in the designer's choice of C++, Visual Basic, Java, Oracle8, Corba or Data Definition Language. Two popular features of Rational Rose are its ability to provide iterative development and round-trip engineering. Rational Rose allows designers to take advantage of iterative development (sometimes called evolutionary development) because the new application can be created in stages with the output of one iteration becoming the input to the next. (This is in contrast to waterfall development where the whole project is completed from start to finish before a user gets to try it out.) Then, as the developer begins to understand how the components interact and makes modifications in the design, Rational Rose can perform what is called "round-trip engineering" by going back and updating the rest of the model to ensure the code remains consistent. 5. UML INTRODUCTION UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. • UML was created by Object Management Group (OMG) and UML • Specification draft was proposed to the OMG in January 1997. SOFTWARE ENGINEERING LAB MANUAL • OMG is continuously putting effort to make a truly industry standard. • UML stands for Unified Modeling Language. • UML is different from the other common programming languages like C++, Java, and COBOL etc. • UML is a pictorial language used to make software blue prints. GOALS OF UML • A picture is worth a thousand words, this absolutely fits while discussing about UML. • UML diagrams are not only made for developers but also for business users, common people and anybody interested to understand the system. • The system can be a software or non software. So it must be clear that. • UML is not a development method rather it accompanies with processes to make a successful system. CONCEPTUAL MODEL OF UML ▲ A conceptual model can be defined as a model which is made of Concepts and their relationships. ▲ A conceptual model is the first step before drawing a UML diagram. It helps to understand the entities in the real world and how they interact with each other.Conceptual model of UML can be mastered by learning. The following three major elements: ▲ UML building blocks. ▲ Rules to connect the building blocks. ▲ Common mechanisms of UML. OO Analysis and Design The purpose of OO analysis and design can described as: 1.Identifying the objects of a system. 2.Identify their relationships. 3.Make a design which can be converted to executables using OO languages. OO Analysis --> OO Design --> OO implementation using OO languages. ▲ During object oriented analysis the most important purpose is to identify objects and describing them in a proper way. If these objects are identified efficiently then the next job of design iseasy. The objects should be identified with responsibilities. Responsibilities are the SOFTWARE ENGINEERING LAB MANUAL functions performed by the object. Each and every object has some type of responsibilities to be performed. When these responsibilities are collaborated the purpose of the system is fulfilled. ▲ The second phase is object oriented design. During this phase emphasis is given upon the requirements and their fulfillment. In this stage the objects are collaborated according to their intended association. After the association is complete the design is also complete. ▲ The third phase is object oriented implementation. In this phasethe design is implemented using object oriented languages likeJava, C++ etc. BUILDING BLOCKS The building blocks of UML can be defined as: 1. Things 2. Relationships 3. Diagrams (1) Things Things are the most important building blocks of UML. Things can be: • Structural • Behavioral • Grouping • Annotational Structural things The Structural things define the static part of the model. They represent physical and conceptual elements. Following are the brief descriptions of the structural things. Class Class represents set of objects having similar responsibilities. Interface Interface defines a set of operations which specify the responsibility of a class. SOFTWARE ENGINEERING LAB MANUAL ▲ Realization Dependency Dependency is a relationship between two things in which change in one element also affects the other one. Association Association is basically a set of links that connects elements of an UML model. It also describes how many objects are taking part in that relationship. Generalization Generalization can be defined as a relationship which connects a specialized element with a generalized element. It basically describes inheritance relationship in the world of objects. Realization Realization can be defined as a relationship in which two elements are connected. One element describes some responsibility which is not implemented and the other one implements them. This relationship exists in case of interfaces (3) Diagrams Each UML diagram is designed to let developers and customers view a software system from a different perspective and in varying degrees of abstraction. UML diagrams commonly created in visual modeling tools include Use Case Diagram displays the relationship among actors and use cases Class Diagram models class structure and contents using design elements such as classes, packages and objects. It also displays relationships such as containment, inheritance, associations and others. Interaction Diagrams SOFTWARE ENGINEERING LAB MANUAL • Sequence Diagramdisplays the time sequence of the objects participating in the interaction. This consists of the vertical dimension (time) and horizontal dimension (different objects). • Collaboration Diagramdisplays an interaction organized around the objects and their links to one another. Numbers are used to show the sequence of messages. State Diagram displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli, together with its responses and actions. Activity Diagramdisplays a special state diagram where most of the states are action states and most of the transitions are triggered by completion of the actions in the source states. This diagram focuses on flows driven by internal processing. Physical Diagrams • Component Diagram displays the high level packaged structure of the code itself. Dependencies among components are shown, including source code components, binary code components, and executable components. Some components exist at compile time, at link time, at run times well as at more than one time. • Deployment Diagramdisplays the configuration of run-time processing elements and the software components, processes, and objects that live on them. Software component instances represent run-time manifestations of code units. Use Case Diagrams A use case is a set of scenarios that describing an interaction between a user and a system. A use case diagram displays the relationship among actors and use cases. The two main components of a use case diagram are use cases and actors. An actor is represents a user or another system that will interact with the system you are modeling. A use case is an external view of the system that represents some action the user might perform in order to complete a task. SOFTWARE ENGINEERING LAB MANUAL When to Use: Use Cases Diagrams Use cases are used in almost every project. These are helpful in exposing requirements and planning the project. During the initial stage of a project most use cases should be defined, but as the project continues more might become visible. Modeling steps for Use case Diagram 1. Draw the lines around the system and actors lie outside the system. 2. Identify the actors which are interacting with the system. 3. Separate the generalized and specialized actors. 4. Identify the functionality the way of interacting actors with system and specify the behavior of actor. 5. Functionality or behavior of actors is considered as use cases. 6. Specify the generalized and specialized use cases. 7. Se the relationship among the use cases and in between actor and use cases. 8. Adorn with constraints and notes. 9. If necessary, use collaborations to realize use cases. How to Draw: Use Cases Diagrams Use cases are a relatively easy UML diagram to draw, but this is a very simplified example. This example is only meant as an introduction to the UML and use cases. Start by listing a sequence of steps a user might take in order to complete an action. For example a user placing an order with a sales company might follow these steps. 1. Browse catalog and select items. 2. Call sales representative. 3. Supply shipping information. 4. Supply payment information. 5. Receive conformation number from salesperson. These steps would generate this simple use case diagram: SOFTWARE ENGINEERING LAB MANUAL The association relationship is the most common relationship in a class diagram. The association shows the relationship between instances of classes. For example, the class Order is associated with the class Customer. The multiplicity of the association denotes the number of objects that can participate in then relationship. For example, an Order object can be associated to only one customer, but a customer can be associated to many orders. Another common relationship in class diagrams is a eneralization. A generalization is used when two classes are similar, but have some differences. SOFTWARE ENGINEERING LAB MANUAL In this example the classes Corporate Customer and Personal Customer have some similarities such as name and address, but each class has some of its own attributes and operations. The class Customer is a general form of both the Corporate Customer and Personal Customer classes. This allows the designers to just use the Customer class for modules and do not require in-depth representation of each type of customer. When to Use: Class Diagrams Class diagrams are used in nearly all Object Oriented software designs. Use them to describe the Classes of the system and their relationships to each other. Modeling steps for Class Diagrams 1. Identity the things that are interacting with class diagram. 2. Set the attributes and operations. 3. Set the responsibilities. 4. Identify the generalization and specification classes. 5. Set the relationship among all the things. 6. Adorn with tagged values, constraints and notes. How to Draw: Class Diagrams Class diagrams are some of the most difficult UML diagrams to draw. To draw detailed and useful diagrams a person would have to study UML and Object Oriented principles for a long time. Therefore, this page will give a very high level overview of the process. Before drawing a class diagram consider the three different perspectives of the system the diagram will present; conceptual, specification, and implementation. Try not to focus on one perspective and try see how they all work together. When designing classes consider what attributes and operations it will have. Then try to determine how instances of the classes will interact with each other. These are the very first steps of many in developing a class diagram. However, using just these basic techniques one can develop a complete view of the software system. SOFTWARE ENGINEERING LAB MANUAL Interaction Diagrams Interaction diagrams model the behavior of use cases by describing the way groups of objects interact to complete the task. The two kinds of interaction diagrams are sequence and collaboration diagrams. This example is only meant as an introduction to the UML and interaction diagrams. When to Use: Interaction Diagrams Interaction diagrams are used when you want to model the behavior of several objects in a use case. They demonstrate how the objects collaborate for the behavior. Interaction diagrams do not give a in depth representation of the behavior. If you want to see what a specific object is doing for several use cases use a state diagram. To see a particular behavior over many use cases or threads use an activity diagrams. How to Draw: Interaction Diagrams Sequence diagrams, collaboration diagrams, or both diagrams can be used to demonstrate the interaction of objects in a use case. Sequence diagrams generally show the sequence of events that SOFTWARE ENGINEERING LAB MANUAL The next diagrams adds another conditional message to the Order object. If the item is [OutOfStock] it sends a message back to the Order Entry Window object stating that the object is out of stack. This simple diagram shows the sequence that messages are passed between objects to complete a use case for ordering an item. Collaboration diagrams Collaboration diagrams are also relatively easy to draw. They show the relationship between objects and the order of messages passed between them. The objects are listed as icons and arrows indicate the messages being passed between them. The numbers next to the messages are called sequence SOFTWARE ENGINEERING LAB MANUAL numbers. As the name suggests, they show the sequence of the messages as they are passed between the objects. There are many acceptable sequence numbering schemes in UML. A simple 1, 2, 3... format can be used, as the example below shows, or for more detailed and complex diagrams a 1, 1.1 ,1.2, 1.2.1... scheme can be used. Modeling steps for Collaboration Diagrams 1. Set the context for interaction, whether it is ystem, subsystem, operation or class or one scenario of use case or collaboration. 2. Identify the objects that play a role in the interaction. Lay them as vertices in graph, placing important objects in centre and neigboring objects to outside. 3. Set the initial properties of each of these objects. If the attributes or tagged values of an object changes in significant ways over the interaction, place a duplicate object, update with these new values and connect them by a message stereotyped as become or copy. 4. Specify the links among these objects.Lay the association links first represent structural connection lay out other links and adorn with stereotypes. 5. Starting with the message that initiates this interaction, attach each subsequent message to appropriate link, setting sequence number as appropriate. The example below shows a simple collaboration diagram for the placing an order use case. This time the names of the objects appear after the colon, such as :Order Entry Window following the objectName:className naming convention. This time the class name is shown to demonstrate that all of objects of that class will behave the same way. SOFTWARE ENGINEERING LAB MANUAL State chart diagram State diagrams are used to describe the behavior of a system. State diagrams describe all of the possible states of an object as events occur. Each diagram usually represents objects of a single class and track the different states of its objects through the system. Modeling steps for Statechart Diagram 1. Choose the context for state machine, whether it is a class ,a use case, or the system as a whole. 2. Choose the initial & final states of the objects. 3. Decide on the stable states of the object by considering the conditions in which the object may exist for some identifiable period of time. Start with the high level states of the objects & only then consider its possible substates. 4. Decide on the meaningful partial ordering of stable states over the lifetime of the object. 5. Decide on the events that may trigger a transition from state to state. Model these events as triggers to transitions that move from one legal ordering of states to another. 6. Attach actions to these transitions and/or to these states. 7. Consider ways to simplify your machine by using substates, branches, forks, joins and history states. 8. Check that all states are reachable under some combination of events. 9. Check that no state is a dead from which no combination of events will transition the object out of that state. 10.Trace through the state machine, either manually or by using tools, to check it against expected sequence of events & their responses. When to Use: State Diagrams Use state diagrams to demonstrate the behavior of an object through many use cases of the system. Only use state diagrams for classes where it is necessary to understand the behavior of the object SOFTWARE ENGINEERING LAB MANUAL Activity Diagram Activity diagrams describe the workflow behavior of a system. Activity diagrams are similar to state diagrams because activities are the state of doing something. The diagrams describe the state of activities by showing the sequence of activities performed. Activity diagrams can show activities that are conditional or parallel. Modeling steps for Activity Diagrams 1. Select the object that have high level responsibilities. 2. These objects may be real or abstract. In either case, create a swimlane for each important object. 3. Identify the precondition of initial state and post conditions of final state. 4. Beginning at initial state, specify the activities and actions and render them as activity states or action states. 5. For complicated actions, or for a set of actions that appear multiple times, collapse these states and provide separate activity diagram. 6. Render the transitions that connect these activities and action states. 7. Start with sequential flows, consider branching, fork and joining. 8. Adorn with notes tagged values and so on. When to Use: Activity Diagrams Activity diagrams should be used in conjunction with other modeling techniques such as interaction diagrams and state diagrams. The main reason to use activity diagrams is to model the workflow behind the system being designed. Activity Diagrams are also useful for analyzing a use case by describing what actions need to take place and when they should occur; describing a complicated sequential algorithm; and modeling applications with parallel processes. However, activity diagrams should not take the place of interaction diagrams and state diagrams. Activity diagrams do not give detail about how objects behave or how objects collaborate. How to Draw: Activity Diagrams Activity diagrams show the flow of activities through the system. Diagrams are read from top to bottom and have branches and forks to describe conditions and parallel activities. A fork is used when multiple activities are occurring at the same time. The diagram below shows a fork after activity1. This indicates that both activity2 and activity3 are occurring at the same time. After activity2 there is a branch. The branch describes what activities will take place based on a set of conditions. All branches at some point are followed by a merge to indicate the end of the conditional SOFTWARE ENGINEERING LAB MANUAL behavior started by that branch. After the merge all of the parallel activities must be combined by a join before transitioning into the final activity state. Below is a possible activity diagram for processing an order. The diagram shows the flow of actions in the system's workflow. Once the order is received the activities split into two parallel sets of activities. One side fills and sends the order while the other handles the billing. On the Fill Order side, the method of delivery is decided conditionally. Depending on the condition either the Overnight Delivery activity or the Regular Delivery activity is performed. Finally the parallel activities combine to close the order. SOFTWARE ENGINEERING LAB MANUAL Physical Diagrams There are two types of physical diagrams: deployment diagrams and component diagrams. Deployment diagrams show the physical relationship between hardware and software in a system. Component diagrams show the software components of a system and how they are related to each other. These relationships are called dependencies. Modeling steps for Component Diagrams 1. Identify the component libraries and executable files which are interacting with the system. 2. Represent this executables and libraries as components. 3. Show the relationships among all the components. 4. Identify the files,tables,documents which are interacting with the system. 5. Representfiles,tables,documents as components. 6. Show the existing relationships among them generally dependency. SOFTWARE ENGINEERING LAB MANUAL 6. APPLICATIONS 6.1 HOSPITAL MANAGEMENT SYSTEM PROBLEM STATEMENT • A doctor is only associated with one specialized department at a time • At reception the patient details are entered and the fees are also taken and the patient is tracked on the basis of the Id generated SOFTWARE ENGINEERING LAB MANUAL • A patient can visit the doctors either directly selecting a doctor or by getting admitted to the hospital and then a doctor visits the patients. USE CASE DIAGRAM CLASS DIAGRAM SEQUENCE DIAGRAMS 1. TEST AND OPERATION 2. PATIENT ADMIT OR REGISTRATION 3) TREATMENT SOFTWARE ENGINEERING LAB MANUAL COLLABARATION DIAGRAMS 1) ADMIT TO HOSPITAL 2) TEST AND OPERATION ACTIVITY DIAGRAM STATE CHART DIAGRAM COMPONENT DIAGRAM DEPLOYEMENT DIAGRAM 6.2 ATM SYSTEM PROBLEM STATEMENT The main objective is to provide a safe environment for the banking user to withdraw the desired amount (within the limit of bank) through ATM at anytime. This is done through a carefully controlled system which accepts the ATM card and upon providing the authentication PIN it gives access to do various pre-programmed functions like: request to insert card-enter PIN-verify PIN- provide options- withdraw-display balance. USE CASE DIAGRAM SOFTWARE ENGINEERING LAB MANUAL SOFTWARE ENGINEERING LAB MANUAL COLLABORATION DIAGRAM Account + 5 : Process Transaction() 2: Enter Kind() 4: Enter Amount() 13: Terminate() « ‘ATM Machine — Bank Client 8 : Transaction Successful() 6: Withdraw From Checking Account() 7: Withdrawal seeing ‘Checking Account > 1 Regest Kind() 3: Request Amount() 9 : Dispense Cash() 10 : Request Take Cash() 11: Take CashQ) 12 : Request Continuation() 14 : Print Receipt() ACTIVITY DIAGRAM STATE CHART DIAGRAM COMPONENT DIAGRAM DEPLOYMENT DIAGRAM 6.3 ONLINE RESERVATION SYSTEM PROBLEM STATEMENT The main objective of the online ticket reservation system is to book train tickets online. It provides an alternate and convenient method for a customer to book tickets. The system is automatic in nature. Once the data is fed into the database, the staff need not do anything and the entire order is processed by the system. This project also offers the option to refund to the customers. The proposed system allows the customers to book tickets from anywhere. There are provisions in the site for a user to become a registered member. Through a simple operation the customer can select the seat and make the payment. The customer can also cancel the ticket. USE CASE DIAGRAM SOFTWARE ENGINEERING LAB MANUAL CLASS DIAGRAM SEQUENCE DIAGRAM COLLABORATION DIAGRAM ACTIVITY DIAGRAM STATE CHART DIAGRAM COMPONENT DIAGRAM DEPLOYMENT DIAGRAM SOFTWARE ENGINEERING LAB MANUAL world.The core part of the project is the reservation and the banking system to keep track of the reservations and room availability.There are three types of the endusers for this HMS.The first ones are the customers who uses the system for the reservation purpose. The other end users are the admin user and the management users who are given separate authentication to the hotel management system. Use case diagram: SOFTWARE ENGINEERING LAB MANUAL Class diagram: SOFTWARE ENGINEERING LAB MANUAL Sequence diagram: Collaboration diagram: State Chart diagram: SOFTWARE ENGINEERING LAB MANUAL Component diagram: Deployment diagram: 6.6 ONLINE SHOPPING SYSTEM PROBLEM STATEMENT The main objective of the online shopping system is to book train tickets online. It provides an alternate and convenient method for a customer to directly buy goods or services from a seller over the internet using a web browser. The system is automatic in nature. Once the data is fed into the database, the staff need not do anything and the entire order is processed by the system. This project also offers the option to refund to the customers. The proposed system allows the customers to buy goods from anywhere. There are provisions in the site for a user to become a registered member. Through a simple operation the customer can select the seat and make the payment. The customer can also cancel the goods. USE CASE DIAGRAM SOFTWARE ENGINEERING LAB MANUAL SOFTWARE ENGINEERING LAB MANUAL KK Registered Customer A Jo Web Customer New Customer «Subsystem» Online Shopping \ | «include» Make Purchase | «include» Client Register CLASS DIAGRAM © uml-diagrams.org A «Service» Authentication ; \ Identity Provider pk Credit Payment Service A PayPal  SOFTWARE ENGINEERING LAB MANUAL User Customer 4 -customerName: string -address: string -email: string -creditCardinfo: string -shippingInfo: string -userld: string -password; string -loginStatus: string +verifyLogin(): bool +register() +login() +updateProfile() Administrator Shipping Info -adminName: string -email; string 1 -shippingld: int . -shippingType: string o 1 -shippingCost: int 0." -shippingRegionld: int Shopping Cart Orders -cartld: int +updateShippinglnfo() -productiD: int -orderld: int -quantity: int -dateCreated: string ‘| -dateAdded: int +addCartltem() +updateQuantity() +viewCartDetails() -dateShipped: string -customerName: string ~customerld: string -status: string -shippingld: string +updateCatalog(): bool Order Details e— | +checkOut() +placeOrder() -orderld:int -productld: int -productName: string -quantity: int -unitCost: float Subtotal: float +calePrice SOFTWARE ENGINEERING LAB MANUAL Browse store View cart LO Update cart STATE CHART DIAGRAM SOFTWARE ENGINEERING LAB MANUAL Save Order i ‘Submit cr Order Del Placed Cancel Charge Order Customer Charged Order Q Ship lote Order COMPONENT DIAGRAM UML Component Diagram: Online S| customer Oa Customer dataAccess —t = (OnlineShopping ler oO Order oO 2 dataAccess! cor DEPLOYMENT DIAGRAM -—O—2 Sy Persistence as hopping access ntrol -—€ oO Security encryption SOFTWARE ENGINEERING LAB MANUAL