Key Ideas. OO Analysis and Design Foundation. Objectives. Adapted from slides 2005 John Wiley & Sons, Inc.

Transcription

1 Slide 1 Information Systems Development COMM005 (CSM03) Autumn Semester 2009 Dr. Jonathan Y. Clark j.y.clark@surrey.ac.uk Course Website: Course Textbook: Systems Analysis and Design With UML 2.0 An Object-Oriented Oriented Approach, Second Edition Chapter 9: Moving on to Design Chapter 13: Physical Architecture Layer Design Slide 2 Key Ideas Adapted from slides 2005 John Wiley & Sons, Inc. Slide 3 The purpose of the analysis phase is to figure out what the business needs. The purpose of the design phase is to figure out how to provide it. The steps in both analysis and design phases are highly interrelated and may require much going back and forth Slide 4 Objectives Understand the transition from analysis to design. Understand the use of factoring, partitions, and layers. Understand package diagrams. Be familiar with the custom, packaged, and outsource design alternatives. Be able to create an alternative matrix. OO Analysis and Design Foundation Use-case driven Architecture centric Iterative and incremental Slide 5 Slide 6

2 Slide 7 OO Analysis and Design - Combining Three Views Functional activity diagrams use case diagrams Static class diagrams object diagrams Dynamic sequence diagrams communication diagrams behavioural state machines (state chart diagrams) A Minimalist Approach Planning Gathering requirements Perform a series of builds Use results of each build as feedback for design and implementation Slide 8 EVOLVING THE ANALYSIS MODELS INTO DESIGN MODELS Avoid Classic Design Mistakes Reducing design time Feature creep Silver bullet syndrome Switching tools in mid-project Slide 9 Slide 10 Factoring Layers Creating modules that account for similarities and differences between units of interest New classes Generalization Aggregation Abstracting Refinement Slide 11 Slide 12

3 Slide 13 Packages Logical grouping of UML elements Simplifies UML diagrams Groups related elements into a single higher-level element Dependency relationships Shows a dependency between packages Syntax for Package Diagram A PACKAGE A DEPENDENCY RELATIONSHIP Package Slide 14 Package Diagram of Dependency Relationships Among Layers Modification Dependency Indicates that a change in one package could cause a change to be required in another package. Example: A change in one method will cause the interface for all objects of this class to change. Therefore, all classes that have objects that send messages to the instances of the modified class could have to be modified. Slide 15 Slide 16 Package Diagram of Appointment System Package Diagram of the PD Layer for the Appointment System Slide 17 Slide 18

4 Slide 19 DESIGN STRATEGIES Custom Development Packaged Software System Integration Outsourcing Custom Development Allows for meeting highly specialized requirements Allows flexibility and creativity in solving problems Easier to change components Builds personnel skills May stretch company s resources May add significant risk Slide 20 Packaged Software Software already written May be more efficient May be more thoroughly tested and proven May range from components to tools to whole enterprise systems Must accept functionality provided May require change in how the firm does business May require significant customization or workarounds System Integration The process of combining packages, legacy systems, and new software Key challenge is integrating data Write data in the same format Revise existing data formats Develop object wrappers Slide 21 Slide 22 Outsourcing Hire external firm to create system May have more skills May extend existing resources Never outsource what you don t understand Carefully choose vendor Prepare contract and payment style carefully Slide 23 Outsourcing Guidelines Keep lines of communication open with outsourcer Define and stabilize requirements before signing a contract View outsourcing relationship as partnership Select outsource vender carefully Assign person to manage relationship Don t outsource what you don t understand Emphasize flexible requirements, long-term relationships, and short-term contracts Slide 24

5 Slide 25 Selecting a Design Strategy Business need In-house experience Project skills Project management Time frame The Alternative Matrix Combines several feasibility analyses into one grid Revisits technical, economic, and organizational feasibility Slide 26 Request for Proposals Description of the system you propose to be built Vendors, developers, service providers respond with proposals including how they will address needs as well as stating cost and time requirements. Slide 27 Slide 28 Summary When evolving analysis into design models, it is important to review the analysis models then add system environment information. Packages and package diagrams help provide structure and less complex views of the new system. Custom building, packages, and outsourcing are alternative ways of creating the new system. The alternative matrix can help with the selection of a design strategy. Slide 29 Slide 30

6 Slide 31 Objectives Physical Architecture Layer Design Understand the different physical architecture components. Understand server-based, client-based, and client server physical architectures. Understand how operational, performance, security, cultural, and political requirements affect the design of the physical architecture layer. Slide 32 Physical Architecture Software Components Data Storage Data Access Logic Application logic Presentation logic Hardware Components Client computers Servers Connecting network Server Based Architecture Client is a terminal Server has functions of Presentation logic Application logic Data access logic Data storage (logic) Slide 33 Slide 34 Server Based Architecture Client-Server Architectures Thin Client/Fat Server Client is little more than a terminal Server handles all processing Fat Client/Thin Server Client does all processing Server may just store data Slide 35 Slide 36

7 Slide 37 Fat (Thick) Client 2-Tiered Architecture Server has data Slide 38 3-Tiered Architecture Client has Presentation Logic N-tiered Architecture Slide 39 Slide 40 Client-Server Benefits Scalable Support multiple clients and servers Less network traffic than server-based Multiple servers make for a generally more reliable network Client-Server Limitations Complexity (2 parts to consider) Software development Installation and testing Updating the whole network computers is more complex All clients and servers must be updated Total cost can be high Slide 41 Slide 42

8 Slide 43 Distributed Objects Computing This is commonly called middleware DOC allows the developer to simply concentrate on the users, objects, and methods of an application instead of worrying about which server contains which set of objects. The client object simply requests the network to locate and execute the server object s method. Middleware Middleware is a type of system software designed to translate between different vendors software. Middleware is installed on both the client computer and the server computer. The client software communicates with the middleware that can reformat the message into a standard language that can be understood by the middleware that assists the server software Slide 44 Competing Approaches Object Management Group Common Object Request Broker Architecture (CORBA) Sun Enterprise JavaBeans (EJB) Java 2 Enterprise Edition (J2EE) Microsoft Distributed Component Object Model (DCOM).net initiative Selecting a Physical Architecture Cost of Infrastructure Cost of Development Ease of Development Interface Capabilities Control and Security Scalability Slide 45 Slide 46 Characteristics The Network Model The network model is a diagram that shows the major components of the information system (e.g., servers, communication lines, networks) and their geographic locations throughout the organization. Slide 47 Slide 48

9 Slide 49 Network Model Example NonFunctional Requirements Operational Specify the operating environment Technical Environment Type of hardware and software System Integration Interaction with other systems Portability Response to changing environments Maintainability Expected business requirement changes Slide 50 Performance Requirements Speed Response time of the system Transaction update time Capacity Number of users Volume of data Availability and Reliability Specify available times Permissible failure rate Security Protect from disruption and data loss Cultural and Political Multilingual Customization Making unstated norms explicit Legal requirements Slide 51 Slide 52 Cultural and Political Requirements. Summary Physical Architecture Layer Choose server vs. client-server Middleware Assess strengths and weaknesses Infrastructure design Various clients Network equipment Nonfunctional Requirements Operational Performance Security Hardware and software specification Slide 53 Slide 54