Architectural Design Ian Sommerville 2004 Software Engineering 7

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

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

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

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

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

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

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

Interface Classes l l There are two types of interface classes. The first is the user interface display. Those are called boundary classes. 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. ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 4 Slide 88 Slide

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

GUI Classes We have a member class and we need : Member name address phone. Number credit. Card# email. Address user. Name password ©Ian Sommerville 2004 Member Screen name. Testfield address. Text. Panel phone. Number. Textfield credit. Card#Textfield email. Address. Textfield user. Name. Textfield password. Textfield a. Member 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. Software Engineering, 7 th edition. Chapter 4 Slide 10 10

Interface Classes l 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 Controller classes are designed to manage • • ©Ian Sommerville 2004 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. Software Engineering, 7 th edition. Chapter 4 Slide 11 11

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

Interface Classes Member name address phone. Number credit. Card# email. Address user. Name password Member Update Controller a. Member. Screen ©Ian Sommerville 2004 Member Screen name. Testfield address. Text. Panel phone. Number. Textfield credit. Card#Textfield email. Address. Textfield user. Name. Textfield password. Textfield a. Member Create Controller a. Member. Screen 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. Software Engineering, 7 th edition. Chapter 4 Slide 13 13

Database Classes 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: Member. Table Member name address phone. Number credit. Card# email. Address user. Name password ©Ian Sommerville 2004 a. Member open. Table() close. Table() sql. Member. Name. Search() check. Memberon. File() A database table class that contains the code needed for that table. Software Engineering, 7 th edition. Chapter 4 Slide 14 14

Use Case Classes Register Membership UCRegister. Membership a. Members. Screen a. Member. Screen. Controller a. Member. Table ©Ian Sommerville 2004 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. Software Engineering, 7 th edition. Chapter 4 Slide 15 15

Use Case Classes Log. In Login user. ID user. Password user. Priviledges ©Ian Sommerville 2004 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. Software Engineering, 7 th edition. Chapter 4 Slide 16 16

Considerations l 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. Additional classes may be needed for other items such as: • • • Additional data classes Additional interface classes Components Deployment Classes Additional architectural classes ©Ian Sommerville 2004 Software Engineering, 7 th edition. Chapter 4 Slide 17 17

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

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

Refactoring l Fowler [FOW 99] defines refactoring in the following manner: • l "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. ” When software is refactored, the existing design is examined for • • • ©Ian Sommerville 2004 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. Software Engineering, 7 th edition. Chapter 4 Slide 20 20

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