1. 1 CMPT 275 High Level Design Phase Modularization

2. Janice Regan, 2008 2 Objectives of Design  The design phase takes the results of the requirements analysis phase and evolves these results further  Use cases and use case diagrams  Context diagram, requirements, class diagrams, state diagrams …  The results of the design phase feeds directly into the implementation phase  Requirements analysis → WHAT the system must do  Next Goal: determine HOW the software system is to accomplish what it must do

3. Janice Regan, 2008 3 Map of design phase DESIGN HIGH LEVEL DESIGN Modularization User Interface Module Interfaces Data Persistance Subsystem User Manual architecture LOW LEVEL DESIGN Classes Class Interfaces Interaction Diagrams Implementation

4. Janice Regan, 2008 4 Example Repository: CASE Tools Project Repository Design Editor Code Generator Design Translator Design Analyser Program editor Report Generator From figure 11.2 Sommerville 2004 CASE: Computer Aided Software Engineering

5. Janice Regan, 2008 5 Example Repository: CASE Tools Project Repository Design Editor Code Generator Design Translator Design Analyser Program editor Report Generator From figure 11.2 Sommerville 2004 CASE: Computer Aided Software Engineering

6. Janice Regan, 2008 6 Client-server Game Client Game Server Internet

7. Janice Regan, 2008 7 The OSI Layers: Layered Model Expanded from Figure 1.10 Stallings (2000) Ethernet TCP/IP CORBA

8. Janice Regan, 2008 8 Model/View/Controller  Model: maintains all domain knowledge  Controller, manages sequence of interaction with the user  View: Display model to user Controller Model View initiator repository Subscriber * 1 Notifier

9. Janice Regan, 2008 9 Map of design phase DESIGN HIGH LEVEL DESIGN Modularization User Interface Module Interfaces Data Persistance Subsystem User Manual architecture LOW LEVEL DESIGN Classes Class Interfaces Interaction Diagrams Implementation System design or object design or

10. Janice Regan, 2008 10 System design activities Analysis System design Object design Functional requirements Non Functional requirements Analysis object model Analysis dynamic model Design goals Subsystem decomposition

11. Janice Regan, 2008 11 Objectives of system design  Transforms analysis model (from requirements analysis) into a system design model  System decomposition  Identify design goals (choose aspects of the system to be optimized)  Develop and refine a subsystem decomposition that satisfies the maximum number of design goals and or the most critical design goals  Identify, model system architecture

12. Janice Regan, 2008 12 Software Modularization  Software system modularization (module decomposition)  decompose software system into subsystems  Subsystems interface (communication) description  define which subsystems communicate with one another and describe how this communication is accomplished

13. Janice Regan, 2008 13 Modularization Goals  Good modularity eases  Simplicity: Makes it easy to understand, implement and test  Extension: Facilitates the addition of features  Change: Facilitates the modification of requirements  A module can be replaced with minimal effects on the rest of the software system

14. Janice Regan, 2008 14 Building on the Context Diagram Now we are interested with the architecture of the software inside the central software system, its modularization and how the modules work and interact with outside agents Patron Resources (Books, CDs..) Web Student Information Repository (DB) Employee Information Repository (DB) Online Journals Folder is UML notation for a package Librarian GUI

15. Janice Regan, 2008 15 Software Architecture  Software system modularization (module decomposition)  Decompose software system into subsystems and modules  Different levels of decomposition system-subsystem, subsystem-module (may have more levels)

16. Janice Regan, 2008 16 Software Architecture  Subsystems interface descriptions  define which subsystems communicate with one another and describe how this communication is accomplished  Different types of system architectures or decomposition styles lead to different approaches to modularization

17. Janice Regan, 2008 17 Modularization Goals  Good modularity promotes  Simplicity: Make it easy to understand, implement and test  Effective inter-system/module communication (internally and with external environment)  Encapsulation (Information hiding)

18. Janice Regan, 2008 18 Modularization Goals  Encapsulation (Information hiding) promotes ease of  Extension: Facilitates the addition of features  Change: Facilitates the modification of requirements  Replacement of single modules when needed

19. Janice Regan, 2008 19 Modularization Guidelines  Coupling: degree to which subsystems are dependent on each other. This is sometimes illustrated by the number of relations (communications) between subsystems or (or on the module level between modules within subsystems).  Desirable: low coupling amongst subsystems -> minimize interfaces between subsystems -> make interfaces between subsystems as simple as possible

20. Janice Regan, 2008 20 Modularization Guidelines  Cohesion : degree to which a subsystems’ modules, or a modules classes depend on each other. Sometimes indicated by the number of dependencies between modules in subsystems.  Desirable: high cohesion within a subsystem -> localize all elements responsible for performing related functions in one subsystem or module

21. Janice Regan, 2008 21 Low Coupling

22. Janice Regan, 2008 22 High Coupling

23. Janice Regan, 2008 23 High Cohesion within a module  Responsibilities of module or subsystem are cohesive when  Elements related to one concept or resource are grouped to hide the detailed function of that concept or device from other modules, no side effects (informational)  Elements contribute to a single well defined task (functional)  Elements operate on the same input or produce the same output (communicational, not usually OO except perhaps within objects) betterbetter

24. Janice Regan, 2008 24 High Cohesion within module  Responsibilities of module or subsystem are cohesive when  Elements occur in sequence input of one to output of another, a series of procedures that occur in a fixed sequence (procedural or sequential)  Elements occur together in time e.g. startup (temporal)  Elements perform related tasks, one of which is selected on each call to the module (logical) for example related utilities betterbetter

25. Janice Regan, 2008 25 Lower Cohesion

26. Janice Regan, 2008 26 Higher Cohesion

27. Janice Regan, 2008 27 Why low coupling is desirable  Simplifies interfaces between subsystems/modules  Reduces the number of interfaces between subsystems  Reduces dependency between modules of a subsystem or subsystems of a system  Encapsulation (information hiding)  Localization of functions Why high cohesion is desirable

28. Janice Regan, 2008 28 Objectives of system design  Transforms analysis model (from requirements analysis) into a system design model  Identify, model system architecture  Develop an efficient system decomposition  Identify boundary use cases describing configuration, startup, shutdown, exceptional conditions.

29. Janice Regan, 2008 29 Design goals, System decomposition  Identify design goals (choose aspects of the system to be optimized) Design goals are often derived from non-functional requirements.  Guide designers in assessing trade offs  Develop and refine a subsystem decomposition that satisfies the maximum number of design goals and or the most critical design goals  Refine the decomposition to better satisfy the design goals

30. Janice Regan, 2008 30 Design goals  When assessing design goals consider  Selection of existing components (off the shelf modules or components )  Hardware / software mapping,  Are there multiple nodes or systems  What is each node responsible for  selecting solutions for managing persistent data  Access control policies  Control flow on a solution wide basis  Boundary conditions (startup, error, shutdown)

31. Janice Regan, 2008 31 How to modularize - 1  Start with the big picture (conceptualization of your software system)  Consider its functions (use cases) Functional partitioning is useful for dividing a software system into smaller pieces (use case -> subset of functionality) or Division of responsibility  Look at data access  It may help to choose an already existing architecture style

32. Janice Regan, 2008 32 How to modularize - 2  Subsystems waiting for data then execute?  Soln: Pipes-and-filters architectural style  An application centered on a data store?  Soln: Repository  A process supplying the needs of user processes?  Soln: Client-server  Few subsystems arranged in layers?  Soln: Layered

33. Janice Regan, 2008 33 How to modularize - 3  Once you have a set of subsystems, go through the goals and guidelines and see if your subsystems make sense

34. Janice Regan, 2008 34 Format for Subsystem Diagram  Folder -> subsystem/module  Line -> communication between two subsystems/modules Name of SubSystem

35. Janice Regan, 2008 35 Possible Architecture for LMS  Want concurrent access for multiple clients (accessing from a network) to centrally stored data  Want an Data server module that will interact with Database, then database can be changed without changing the data server module  This suggests a client server architecture DBMS DB server module Client 2 Client 1Client 4Client 3 Client 5 Network

36. Janice Regan, 2008 36 Possible Architecture for LMS DBMS DB server module Client 2 Client 1Client 4Client 3Client 5 Remember for client server architecture client means a process requesting services. This is not the same as our client, the user or source of the project!!! Patron 1Librarian 1Patron 2Patron 3 Librarian 2

37. Janice Regan, 2008 37 When Modularizing BrowseResource ReserveResource DetermineOverdue Charge Check out resource Verify Patron > Module B Module A

38. Janice Regan, 2008 38 Tricks  Do not over- or under-modularize  If over-modularize (lots of modules) then lots of interfaces to define  If under-modularize (few modules) complexity of module great  Complexity of each module (subsystem) should be the maximum that still provides a simple and understandable module  1 use case is not usually one subsystem