©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Slide 1 Extended Class Diagram

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 2 Slide 2 Analysis Model -> Design Model What we Have: At this point in development we have a CLASS DIAGRAM that contains DOMAIN classes. Classes and Class Structure What we Need: We need an CLASS DIAGRAM that has the classes we will program.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 3 Slide 3 Design Classes l Analysis classes (domain classes) are those classes identified during the analysis phase of the SDLC. They are the classes recognized by the customers as residing in their domain. l l Design classes are needed to implement this system in the world of computing. These classes include various types of classes. l Implementation classes are also needed to implement the system in a particular language.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 4 Slide 4 Design Classes l Design classes include: Use Case Controller Classes User Interface Classes Database Table Classes Classes for Patterns Classes for Frameworks (not covered in this class) Others If we identify all these classes, that may not end up as our design to code but it will be very close to the design.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 5 Slide 5 Design Classes l To explain how to construct your extended class diagram, we will use the VRS example. l We do not construct a design class diagram for the scope of the entire system. That may be too big and unmanageable. Instead we will construct a design class diagram for one use case. l Later we can put together the entire design class diagram if we wish but usually there is no reason to view it from that perspective.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 6 Slide 6 Design Classes l Lets take a look at ONE Use Case from the VRS to construct the Extended Class Diagram for that Use Case. Remembering that extended class diagrams should be limited to use cases rather than the entire system as it would get too large to be an effective tool for communication. l We will use the use case Register as Member.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 7 Slide 7 Design Classes name address phoneNumber creditCard# Address userName password Member copyID VideoCopy barCode title type actor[ ] director length rating videoDescription rentalStore rentalDate dueDate returnDate returnTime Rental name address phoneNumber Store 1 * 1*1* * 1 Payment *0*0 1 * stocks rents request amount paysfor defines Video Rental System CLASS DIAGRAM Using the VRS class diagram built during analysis, we identify the domain class(es) needed for this Use Case.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 8 Slide 8 name address phoneNumber creditCard# Address userName password Member Video Rental System CLASS DIAGRAM Domain Classes In this simple Use Case, there is only one domain class—Member. This type of class is often referred to by other names, entity class, data class, domain class, and others. We will simply call it our Domain class.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 9 Slide 9 name address phoneNumber creditCard# Address userName password Member Video Rental System CLASS DIAGRAM Controller Classes Now we want to add the Use Case Controller Class for this use case. We will call it the name of the use case. We will add attributes and relationships as we progress in design. aMember UCRegisterasMember Register as Membership

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 10 Slide 10 Video Rental System CLASS DIAGRAM Controller Classes Since this use case may include or extend to other use cases, we want to add a Use Case Controller Class for each of those extend or include items in our use case, again with the name of the use case. userId userPassword UCLogin Login

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 11 Slide 11 Interface Classes l Now we are ready to add Interface Classes. These are called boundary classes. l Boundary classes are often built during analysis as a prototype but are certainly developed during design if not already created. They are used to create the interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the software is used. Boundary classes are designed with the responsibility of managing the way domain or entity objects are represented to users. Thus we need some input and output classes -- report classes and screen classes.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 12 Slide 12 Interface Classes These interface classes are the actual screens such as HTML screens, VB screens, Java 2 screens, or other. They the classes that hold the code for those screens.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 13 Slide 13 Interface Classes We have a member class and we need : 1)At least one screen for member information. 2)A class for each screen that hold the code for THAT screen - Named ScrXxxx. name address phoneNumber creditCard# Address userName password Member nameTestfield addressTextPanel phoneNumberTextfield creditCard#Textfield AddressTextfield userNameTextfield passwordTextfield aMember ScrMember aMember UCRegisterasMember

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 14 Slide 14 Interface Classes We will also need a login screen for the login use case but THAT would be in the extended class diagram for the login use case. name address phoneNumber creditCard# Address userName password Member nameTestfield addressTextPanel phoneNumberTextfield creditCard#Textfield AddressTextfield userNameTextfield passwordTextfield aMember ScrMember aMember UCRegisterasMember

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 15 Slide 15 Interface Classes l If we have interfaces that have navigational controls, we will need a controller to place the navigational code that represents the navigation matrix. These classes with the navigational control code are called interface controller classes. They are a type of controller but not the use case controller. l The interface (boundary) classes are limited to only the DISPLAY of the report or screen. The actual control of those interface (boundary) classes is done by this interface (controller) class.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 16 Slide 16 Interface Classes l Interface Controller classes manage the communication between the interface (boundary) objects and the domain (entity) objects. l REMEMBER: l The interface (boundary) object is only for the display code. You can think of it as it can ONLY display itself. l The domain (entity) object is only for holding and manipulating the data it contains. It can only manipulate its data.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 17 Slide 17 Interface Classes 1)A navigation diagram to tell us how to navigate the screen 2)A class for each navigation that hold the code for THAT navigation. So now we need to control the clicks, enters, mouse navigation, etc so we need:

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 18 Slide 18 Interface Classes With the screen and navigation diagram we create the class(es) that hold the code for those navigations. Multiple navigations may be needed for each screen or even multiple panels for each screen with multiple navigations. name address phoneNumber creditCard# Address userName password Member nameTestfield addressTextPanel phoneNumberTextfield creditCard#Textfield AddressTextfield userNameTextfield passwordTextfield aMember ScrMember aMember aMemberScreen Member Update Controller aMember aMemberScreen Member Create Controller

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 19 Slide 19 Interface Classes We will name the controller class(es) as CtrXxxxYyyy CtrMemberCreate CtrMemberUpdate name address phoneNumber creditCard# Address userName password Member nameTestfield addressTextPanel phoneNumberTextfield creditCard#Textfield AddressTextfield userNameTextfield passwordTextfield aMember ScrMember aMember aMemberScreen CtrMemberUpdate aMember aMemberScreen CtrMemberCreate

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 20 Slide 20 Interface Classes But for this use case, for simplicity, we will assume we only need the Member Create Controller. name address phoneNumber creditCard# Address userName password Member nameTestfield addressTextPanel phoneNumberTextfield creditCard#Textfield AddressTextfield userNameTextfield passwordTextfield aMember ScrMember aMember aMemberScreen CtrMemberCreate aMember UCRegisterasMember

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 21 Slide 21 Database Classes A database table class that contains the code needed for that table named TblXxxxx. The Tbl does all the sql for this member table, opens the table, closes the table, checks if a person is in the table, …, all the code to manipulate the table. name address phoneNumber creditCard# Address userName password Member aMember openTable() closeTable() sqlMemberNameSearch() checkMemberonFile() TblMember We have a domain (entity) class that contains the data but we also need a way to have the code that manipulates the database. A table class for each table identified.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 22 Slide 22 Extended Class Diagram aMember openTable() closeTable() sqlMemberNameSearch() checkMemberonFile() TblMember name address phoneNumber creditCard# Address userName password Member nameTestfield addressTextPanel phoneNumberTextfield creditCard#Textfield AddressTextfield userNameTextfield passwordTextfield aMember ScrMember aMember UCRegisterasMember So here is the resulting classes in the extended class diagram. Remember it is for one use case. We need relationships defined. We will need to add class descriptions for these classes userId userPassword UCLogin aMember aMemberScreen CtrMemberCreate

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 23 Slide 23 Extended Class Diagram aMember openTable() closeTable() sqlMemberNameSearch() checkMemberonFile() TblMember name address phoneNumber creditCard# Address userName password Member nameTestfield addressTextPanel phoneNumberTextfield creditCard#Textfield AddressTextfield userNameTextfield passwordTextfield aMember ScrMember aMember aMemberScreen CtrMemberCreate aMember UCRegisterasMember Lets start with the mandatory relationships. Those are the ones where an instance of a class is contained in another. Relationships are shown with cardinality and a sign for option/mandatory. userId userPassword UCLogin

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 24 Slide 24 Extended Class Diagram aMember openTable() closeTable() sqlMemberNameSearch() checkMemberonFile() TblMember name address phoneNumber creditCard# Address userName password Member nameTestfield addressTextPanel phoneNumberTextfield creditCard#Textfield AddressTextfield userNameTextfield passwordTextfield aMember ScrMember aMember aMemberScreen CtrMemberCreate aMember UCRegisterasMember The Member Create Controller will contain an instance of the Member Screen because in order to control the screen, we will need to get the screen components and their contents. userId userPassword UCLogin 1

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 25 Slide 25 Extended Class Diagram aMember openTable() closeTable() sqlMemberNameSearch() checkMemberonFile() TblMember name address phoneNumber creditCard# Address userName password Member nameTestfield addressTextPanel phoneNumberTextfield creditCard#Textfield AddressTextfield userNameTextfield passwordTextfield aMember ScrMember aMember UCRegisterasMember The Member Screen will contain an instance of the Member. because it will want to update the member data from the contents of the components (e.g. textfield). userId userPassword UCLogin 1 aMember aMemberScreen CtrMemberCreate 1

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 26 Slide 26 Extended Class Diagram aMember openTable() closeTable() sqlMemberNameSearch() checkMemberonFile() TblMember name address phoneNumber creditCard# Address userName password Member nameTestfield addressTextPanel phoneNumberTextfield creditCard#Textfield AddressTextfield userNameTextfield passwordTextfield aMember ScrMember aMember UCRegisterasMember The UCRegisterasMember uses the UCLogin because it implements the includes relationship between the two use cases. userId userPassword UCLogin 1 aMember aMemberScreen CtrMemberCreate 1 1

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 27 Slide 27 Extended Class Diagram aMember openTable() closeTable() sqlMemberNameSearch() checkMemberonFile() TblMember name address phoneNumber creditCard# Address userName password Member nameTestfield addressTextPanel phoneNumberTextfield creditCard#Textfield AddressTextfield userNameTextfield passwordTextfield aMember ScrMember aMember UCRegisterasMember The UCRegisterasMember needs the TblMember class because it needs to update the database with the member information. userId userPassword UCLogin 1 aMember aMemberScreen CtrMemberCreate 1 1 1

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 28 Slide 28 Extended Class Diagram aMember openTable() closeTable() sqlMemberNameSearch() checkMemberonFile() TblMember name address phoneNumber creditCard# Address userName password Member nameTestfield addressTextPanel phoneNumberTextfield creditCard#Textfield AddressTextfield userNameTextfield passwordTextfield aMember ScrMember aMember UCRegisterasMember The UCRegisterasMember needs the CtrMemberCreate because it needs to display the screen, and allow entry of data. userId userPassword UCLogin 1 aMember aMemberScreen CtrMemberCreate

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 29 Slide 29 Extended Class Diagram While this information is needed, it does get tedious even for this simple example. What you will hand in is simpler and somewhat different. aMember openTable() closeTable() sqlMemberNameSearch() checkMemberonFile() TblMember name address phoneNumber creditCard# Address userName password Member nameTestfield addressTextPanel phoneNumberTextfield creditCard#Textfield AddressTextfield userNameTextfield passwordTextfield aMember ScrMember aMember UCRegisterasMember userId userPassword UCLogin 1 aMember aMemberScreen CtrMemberCreate

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 30 Slide 30 Considerations l We now have the basic additional design classes defined. However, there are other considerations to make a professional final cut on the classes included in this application. l Additional classes may be needed for other items such as: Additional data classes Additional interface classes Components Deployment Classes Additional architectural classes