1. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Slide 1 Architectural Design

2. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 2 Slide 2 Analysis Model -> Design Model

3. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 3 Slide 3 Analysis Model -> Design Model What we Need: Preliminary Design Architecture - thin client, thick client, central, distributed GUI Components - with layouts, navigation Database Components – Database Tables, Segments, or Objects Classes and Class Structure

4. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 4 Slide 4 Preliminary Design Architecture The Preliminary Design Architecture defines the computing environment such as: Computers (servers, mainframes, and clients), Operating Systems on those computers Database Management Systems used Communications Systems Used Middleware used

5. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 5 Slide 5 Preliminary Design Architecture Client Server DB Server Client Server DB Server Environment Environment Environment Environment Environment Environment Compaq PC NT Visual Basic ….. Compaq Server NT Visual Basic MSMQ SNA Server (COMTI) Mainframe IBMXXX MVS CICS Cobol Programs Access IMS Crystal Reports SQL - 7 Hand Readers Cameras VB Screens TCPIP, T1 MSMQ Messages SNA Server(COMTI) TCPIP CICS Trans T1 Line

6. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 6 Slide 6 Preliminary Design Architecture If we decide to do processing on more than one computer, we will need A class diagram for each computer Perhaps some communication between classes AND PERHAPS MORE……

7. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 7 Slide 7 Design Classes l Analysis classes (domain classes) are refined during design and more classes are added to accommodate the design of the system. l Analysis classes generally become entity classes (this is especially true in information systems). l Classes are added for other items such as the user interface, database, use cases and communication.

8. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 8 Slide 8 Interface Classes l There are two types of interface classes. The first is the user interface display. Those are called boundary classes. l Boundary classes are developed during design 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 entity objects are represented to users. Thus we need some input and output classes -- report classes and screen classes.

9. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 9 Slide 9 GUI Classes We need : 1)the actual screens such as HTML screens, VB screens, Java 2 screens, or other 2)We need the classes that hold the code for those screens.

10. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 10 Slide 10 GUI Classes We have a member class and we need : 1)At least one screen for member information. (perhaps composed of many panels and other components). 2)A class for each screen that hold the code for THAT screen. name address phoneNumber creditCard# emailAddress userName password Member nameTestfield addressTextPanel phoneNumberTextfield creditCard#Textfield emailAddressTextfield userNameTextfield passwordTextfield aMember Member Screen

11. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 11 Slide 11 Interface Classes l The second type of interface class we need is called controller class. The boundary classes are limited to only the display of the report or screen. The actual control of those interface developed during design to create l Controller classes are designed to manage the creation or update of entity objects; the instantiation of boundary objects as they obtain information from entity objects; complex communication between sets of objects; validation of data communicated between objects or between the user and the application.

12. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 12 Slide 12 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. We have a member class and a member screen class and now we need to control the clicks, enters, mouse navigation so we need:

13. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 13 Slide 13 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# emailAddress userName password Member nameTestfield addressTextPanel phoneNumberTextfield creditCard#Textfield emailAddressTextfield userNameTextfield passwordTextfield aMember Member Screen aMember aMemberScreen Member Update Controller aMember aMemberScreen Member Create Controller

14. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 14 Slide 14 Database Classes A database table class that contains the code needed for that table. name address phoneNumber creditCard# emailAddress userName password Member aMember openTable() closeTable() sqlMemberNameSearch() checkMemberonFile() MemberTable We have a member entity on the entity relationship diagram and a member class that has the data for the table entry and we need:

15. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 15 Slide 15 Use Case Classes Another type of controller class is the use case classes. For each use case on the use case diagram (and perhaps others you identify as design progresses, create a use case class. aMember aMembersScreen aMemberScreenController aMemberTable UCRegisterMembership Register Membership

16. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 16 Slide 16 Use Case Classes Another controller class is needed for the use case extensions and inclusions. For each use case extension or inclusion where the use case will be reused, there needs to be a controller for that use case. userID userPassword userPriviledges Login LogIn

17. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 17 Slide 17 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

18. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 18 Slide 18 Design Model Classes l Additional Data Classes Data model --> data structures such as lists, collections Data model --> database architecture such as database management, etc l Additional Interface Classes External interfaces to other systems, devices, networks or other producers or consumers of information Internal interfaces between various design components. l Components Vendor supplied or built l Deployment Classes Classes needed to deploy software

19. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 19 Slide 19 Design Model Classes l Additional Architectural Classes Additional Application domain classes Relationship classes from the analysis classes not known at analysis time Pattern Classes Programming Patterns Design Patterns Architectural Patterns Analysis Patterns Framework Classes such as STRUTS type classes Refactored Classes

20. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 20 Slide 20 Refactoring l Fowler [FOW99] defines refactoring in the following manner: "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.” l When software is refactored, the existing design is examined for redundancy unused design elements inefficient or unnecessary algorithms poorly constructed or inappropriate data structures or any other design failure that can be corrected to yield a better design.

21. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 21 Slide 21 Use Case Packets l At this point, we have the basic classes that need to associated with each use case. l We can put together something called a Use Case Packet discussed later. l The Use Case Packet can be given to a programmer for them to code the use case.