1. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 MIS 161 Systems Development Life Cycle II Lecture 2: Design Issues and OO Design

2. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 DESIGN CRITERIA

3. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Principles of Well Designed Systems Decoupling –Separate modules are relatively independent –loose coupling allow one module to be repaired with minimum disruption to others –overlapping/duplicate functions –independence

4. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Principles of Well Designed Systems Cohesion –How well activities within a single module are related to one another Functional cohesion –containing all, and only, those tasks contributing to the generation of a single information function/ product –Method cohesion –Class cohesion –Generalization/specialization cohesion

5. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Principles of Well Designed Systems Modularity –design of a system in relatively small chunks –allows assignment of developers to different tasks –sections of system can be developed independently –maintenance can occur without disturbing other modules User involvement –throughout SDLC –sense of ownership –real, not simulated

6. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Principles of Well Designed Systems Satisficing –“better” not “best” solution –“best” solution not feasible –resource constraints Human Interface –human factors –ergonomics

7. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Connascence How closely modules are related –Literally means “having been born together” OR –“having intertwined destinies in life” Changing one module creates the need to change another module as a result of changing one –Minimize overall connascence –Minimize across encapsulation boundaries –Maximize within encapsulation boundary

8. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Design Coordination Project Scheduling –e.g., Gantt Chart –deliverables/milestones User Participation Design Teams Structured Walkthrough

9. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Structured WalkThroughs A way of using peer reviews to monitor the system’s development, point out problems, and allow the analyst responsible to make suitable changes Can be done when any portion of the system is complete Normally have at least four individuals –Each person has a special role; for example: Person responsible for that part of the system Walkthrough coordinator Programmer or anlayst peer A note taker

10. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Avoid Classic Design Mistakes Reducing design time –Reducing time spent on design in order to jump directly into programming Feature creep –Additional features added to the system during design –Don’t add any unless they are vital Silver bullet syndrome –No one tool can solve all the problems and magically reduce time and costs. Switching tools in mid-project –Switching design tools only adds more time the project due to the time it takes to learn the new tool

11. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Selecting a Design Strategy Business need In-house experience Project skills Project management Time frame

12. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Design Strategies Use Custom Development When… Use a Packaged System When…Use Outsourcing When Business needThe business need is uniqueThe business need is commonThe business need is not core to the business In-house experienceIn-hours functional and technical experience exists Un-house functional experience exists In-house functional or technical experience does not exist Project skillsThere is a desire to build in- house skills The skills are not strategic.The decision to outsource is a strategic decision Project managementThe project has a highly skilled project manager and a proven methodology The project has a project manager who can coordinate the vendor’s efforts The project has a highly skilled project manager at the level of the organization that matches the scope of the outsourcing deal Time FrameThe time frame is flexibleThe time frame is shortThe time frame is short or flexible

13. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Custom Development Allows for meeting highly specialized requirements Allows flexibility and creativity in solving problems Easier to change components Builds personnel skills May tax firm’s resources May add significant risk

14. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 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”

15. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 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”

16. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 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

17. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Infrastructure Considerations

18. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Realities of Infrastructure Design Most often the infrastructure will be in place Coordination of infrastructure components is very complex The application developer will need to coordinate with infrastructure specialists

19. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Selecting an Architecture Cost of infrastructure Cost of development Ease of development Interface capabilities Control and security Scalability

20. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Hardware and Software Specification Used if new hardware or software must be purchased Actual acquisition of hardware and software usually left to a purchasing department -- especially in larger firms

21. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Steps in Hardware and Software Specification Describe equipment in as much detail as possible Consider whether increased processing and traffic will absorb unused hardware capacity Note all software running on each hardware component

22. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Object-Oriented Design

23. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 OBJECT DESIGN ACTIVITIES

24. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Key Ideas 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”

25. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Additional Specification Review the current set of models Signatures for each method Define constraints Identify Opportunities for Reuse Restructure the Design

26. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Optimizing the Design Review access paths Review attributes of each class Consider execution order of statements in often-used methods Avoid recomputation by creating derived attributes and triggers

27. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 OO Life Cycle Using UML Planning –High level (project identification and selection) –Low level (project initiation and planning) Analysis –Determine system requirements Use cases –Structure requirements Preliminary class diagram State diagrams Preliminary interaction diagrams Activity diagrams Package diagrams Design –Logical screens, reports, etc. –Physical Detailed interaction diagrams Add layers –data management –user interface Class interface documentation Deployment diagrams Component diagrams Implementation –Code, test, debug, install

28. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Iterations and Workflow Preliminary Iteration(s) iter. #1 iter. #2 iter. #n iter. #n+1 iter. #n+2 iter. #m iter. #m+1 InceptionElaborationConstructionTransition Iterations Phases Core Workflows An iteration in the elaboration phase Requirements Design Implementation Test Analysis

29. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 From OO Analysis Models to Design Models

30. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 The Problem Domain The term "problem domain" refers to the area that encompasses real-world things and concepts related to the problem that the system is being designed to solve. Domain modeling is the task of discovering "objects" (classes, actually) that represent those things and concepts. This was your focus in MIS 160. Now we move away from this and into the logical design.

31. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 From Analysis Classes to Design Classes Analysis classes captured some physical aspects of the system A design class diagram shows the data types of the attributes, the return types and arguments of the operations, and the visibility specifications for all attributes and operations. –From physical to logical

32. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Design Classes Each design class should specify: –Each attribute Type Visibility –Responsibilities translated into specific operations

33. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 PACKAGES AND PACKAGE DIAGRAMS

34. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Package UML Packages are a grouping of objects into sets of objects that provide related services. The package has responsibilities that are strongly related. The package has low coupling and low cohesion with respect to interfacing with other packages in the system.

35. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Sample Package Diagram

36. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Syntax for Package Diagram A PACKAGEPackage A DEPENDENCY RELATIONSHIP

37. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 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.

38. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 In UML, packages are represented as rectangles with tabs in the top left corner.

39. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Steps for Identifying Packages and Building Package Diagrams Set the context Cluster classes together based on shared relationships Model clustered classes as a package Identify dependency relationships among packages Place dependency relationships between packages

40. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Example Class Diagram

41. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Package Diagram of the PD Layer for the Appointment System

42. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 METHOD SPECIFICATION

43. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Structured English

44. Sylnovie Merchant, Ph.D. MIS 161 Spring 2005 Pseudocode Example (Get CD-info module) Accept (CD_title) {Required} Accept (CD_artist) {Required} Accept (CD_category) {Required} Accept (CD_length) Return