MIS 161 Systems Development Life Cycle II Lecture 2: Design Issues and OO Design

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

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

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

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

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

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

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

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

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

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

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

12. Design Strategies Sylnovie Merchant, Ph.D. MIS 161 Spring 2005

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

28. P h a s e s C o r e W o r k f l o w s I n c e p t i o n E l a b o r a t i o n C o n s t r u c t i o n T r a n s i t i o n A n i t e r a t i o n i n t h e e l a b o r a t i o n p h a s e P r e l i m i n a r y i t e r . i t e r . i t e r . i t e r . i t e r . i t e r . i t e r . I t e r a t i o n ( s ) # 1 # 2 # n # n + 1 # n + 2 # m # m + 1 I t e r a t i o n s Iterations and Workflow Requirements Analysis Design Implementation Test Sylnovie Merchant, Ph.D. MIS 161 Spring 2005

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

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

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

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

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

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

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

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

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

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

39. 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 Steps for Identifying Packages and Building Package Diagrams Sylnovie Merchant, Ph.D. MIS 161 Spring 2005

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

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

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

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

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