Architectural Design

1. Architectural Design

2. Analysis Model -> Design Model

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. 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. Preliminary Design Architecture Client Server DB Server Environment Environment Environment SNA Server(COMTI) TCPIP CICS Trans T1 Line TCPIP, T1 MSMQ Messages Compaq Server NT Visual Basic MSMQ SNA Server (COMTI) Mainframe IBMXXX MVS CICS Cobol Programs Compaq PC NT Visual Basic ….. Access Crystal Reports SQL - 7 IMS Hand Readers Cameras VB Screens

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. Design Classes • 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.

8. Interface Classes • There are two types of interface classes. The first is the user interface display. Those are called boundary classes. • Boundary classesare 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. GUI Classes • We need : • the actual screens such as HTML screens, VB screens, Java 2 screens, or other • We need the classes that hold the code for those screens.

10. GUI Classes • We have a member class and we need : • At least one screen for member information. (perhaps composed of many panels and other components). • A class for each screen that hold the code for THAT screen. Member Member Screen name address phoneNumber creditCard# emailAddress userName password nameTestfield addressTextPanel phoneNumberTextfield creditCard#Textfield emailAddressTextfield userNameTextfield passwordTextfield aMember

11. Interface Classes • 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 • 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. 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: • A navigation diagram to tell us how to navigate the screen • A class for each navigation that hold the code for THAT navigation.

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. Member Member Screen name address phoneNumber creditCard# emailAddress userName password nameTestfield addressTextPanel phoneNumberTextfield creditCard#Textfield emailAddressTextfield userNameTextfield passwordTextfield aMember Member Update Controller Member Create Controller aMember aMemberScreen aMember aMemberScreen

14. 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 MemberTable A database table class that contains the code needed for that table. aMember openTable() closeTable() sqlMemberNameSearch() checkMemberonFile() Member name address phoneNumber creditCard# emailAddress userName password

15. Use Case Classes Register Membership 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. UCRegisterMembership aMember aMembersScreen aMemberScreenController aMemberTable

16. Use Case Classes LogIn 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. Login userID userPassword userPriviledges

17. Considerations • 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

18. Design Model Classes • Additional Data Classes • Data model --> data structures such as lists, collections • Data model --> database architecture such as database management, etc • Additional Interface Classes • External interfaces to other systems, devices, networks or other producers or consumers of information • Internal interfaces between various design components. • Components • Vendor supplied or built • Deployment Classes • Classes needed to deploy software

19. Design Model Classes • 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. Refactoring • 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.” • 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. Use Case Packets • 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.