ISM 301 Ch 7: Moving on to Design PDF

CH 7: Moving on to Design ISM 301 SDLC Idea Drawing Blueprint Construction Planning Analysis Development Implementation System Design Overview System design is the phase where we take the requirements identified during system analysis and translate them into a blueprint for bu...

CH 7: Moving on to Design ISM 301 SDLC Idea Drawing Blueprint Construction Planning Analysis Development Implementation System Design Overview System design is the phase where we take the requirements identified during system analysis and translate them into a blueprint for building the system. The main goal is to decide how the system will be built, ensuring it aligns with the business’s needs while considering technical and environmental factors. Steps in System Design 1. Verify and Validate Analysis Model 2. Evolving Analysis Models into Design Verify and Validate Analysis Model Check that the analysis models (use cases, class diagrams, sequence diagrams, etc.) accurately represent the business requirements. This ensures consistency between different models and reduces errors later in development. E.g., activity diagrams, use case descriptions, and use case diagrams should all relate to the same set of functional requirements. Evolving Analysis Models into Design Once verified, the analysis models evolve into design models. The focus shifts from capturing business needs (functional requirements) to how the system will operate in its environment (non-functional requirements like performance and security). This phase involves reviewing and refining the system’s classes, attributes, methods, and their relationships. From the Unified Process perspective, we are moving from the analysis workflow to the design workflow, and we are moving further into the elaboration phase and partially into the Construction phase. Unified Process Evolving Analysis Models into Design Factoring Partitions and Layers Collaboration Factoring Factoring is the process of separating out a module into a stand‐alone module. The new module can be a new class or a new method. Example: If multiple classes share similar attributes or methods, these can be factored out into a new, more general class. For instance, creating an “Employee” class from overlapping parts of “Nurse,” “Doctor,” and “Receptionist” classes.  Partitions and Collaborations Grouping similar elements into subsystems or partitions based on how they interact. Partitions are based on the pattern of activity (messages sent) among the objects in an object‐ oriented system. A partition is the object‐oriented equivalent of a subsystem, where a subsystem is a decomposition of a larger system into its component systems (e.g., an accounting information system could be functionally decomposed into an accounts‐payable system, an accounts‐ receivable system, a payroll system, etc.) Example: A hospital management system might be split into smaller systems like payroll, appointment scheduling, and patient records. Layers Until the analysis phase, the primary focus has been on the problem domain. Now, in the design phase, we expand our focus on the system environment – data management, user interface, and physical architecture. A layer represents an element of the software architecture of the evolving system. Layers Examples Foundation Date, Enumeration Problem Domain Employee, Customer Data Management DataInputStream Human-Computer Interaction Button, Panel Physical Architecture Server Design Quality Coupling Cohesion Connascence Coupling Coupling refers to the level of interdependency between different modules (classes, objects, or methods) in a system. When two modules are tightly coupled, a change in one often necessitates changes in the other. Lower (or loose) coupling is preferred because it allows different parts of the system to be modified independently, making the system more adaptable and easier to maintain.  Types of Coupling Interaction Coupling: Occurs when one object sends a message to another. It’s essential to minimize unnecessary interactions, as too many connections between objects can lead to a fragile system. Inheritance Coupling: Arises from the inheritance relationship between classes. While inheritance promotes code reuse, overuse can lead to tightly coupled hierarchies, where changes in a parent class affect all child classes. Best Practices: Objects should only communicate with closely related objects. This means sending messages to themselves, their attributes, or objects passed as parameters, but avoiding unnecessary dependencies. Reduce interaction coupling by limiting the number of classes an object interacts with directly. Use inheritance carefully. Inherit only when there’s a clear “is-a” relationship (e.g., a Dog is a type of Animal). Example of Interaction Coupling Object Class Attribute Cohesion Definition: Cohesion measures how closely related and focused the responsibilities of a module are. High cohesion means that a class or method is dedicated to a single, well-defined purpose, making the system easier to understand, test, and maintain. Low cohesion, on the other hand, occurs when a module tries to do too many unrelated things, making it more complex and harder to manage.  Types of Cohesion Method Cohesion: A method should perform only one task. For example, a method named calculateTotal() should only calculate a total, not perform any unrelated tasks like printing a report. Class Cohesion: A class should represent a single entity or concept. For instance, an Employee class should contain attributes and methods related to employees, like name, address, and salary, but not unrelated data, such as project schedules. Generalization/Specialization Cohesion: This deals with how well a class fits within an inheritance hierarchy. A subclass should only inherit from a superclass when there is a true “is-a” relationship (generalization). Avoid creating unnecessary subclasses just for code reuse, as this can lead to low cohesion and maintenance issues Best Practices: Ensure methods have a single, well-defined purpose. Group attributes and methods in a class that are directly related to the class’s main role or responsibility. Avoid adding unnecessary features to classes, which can dilute their focus. Connascence Connascence refers to the degree to which different parts of a system must change together. If two modules are connascent, changing one typically requires changing the other. Connascence generalizes the idea of coupling and cohesion by focusing on how interrelated different parts of a system are. Best Practices: Minimize connascence across different modules by reducing the number of dependencies between them. Maximize connascence within a module, where changes can be controlled and limited in scope. For example, tightly related methods within the same class (such as getPrice() and setPrice()) can share behavior, but avoid sharing behavior across unrelated classes. Encapsulate logic and data tightly, so that changes in one module don’t cascade across the system. Design Strategies Design Strategy Description Pros Cons Custom Building the system Complete control Time-consuming Development from scratch to fit and flexibility in More costly specific business design Requires skilled needs. developers Packaged Purchasing pre-built Faster to implement Limited flexibility Development software and Cheaper than May not fit perfectly customizing it for custom with business needs your organization. development Outsourcing Hiring an external Reduces internal Less control over vendor to build or workload the process manage the Can leverage Potential security system. specialized risks expertise Dependency on external vendors  Choosing the Right Strategy Consider the following factors Business Needs: If the system is unique, custom development may be the best fit. For common needs, packaged software could be more efficient. In-House Experience: If the team has the necessary technical skills, custom development may work. Otherwise, consider packaged software or outsourcing. Project Timeline: If the project is time-sensitive, packaged software or outsourcing may deliver faster results than custom development. Choosing Design Strategy  End of THANK YOU! Lecture Class Exercise Describe the differences in the two diagram. Which diagram is better? Fig 1 Fig 2 From a cohesion, coupling, and connascence perspective, is the following class diagram a good model? Why or why not? From a cohesion, coupling, and connascence perspective, are the following class diagrams good models? Why or why not? Fig 1 Fig 2 Scenario A mid-sized retail company, “RetailCo,” is looking to implement a new CRM system to better manage customer interactions, sales, and marketing campaigns. The company has a moderate budget, a small in-house IT team, and a tight deadline to launch the system before the holiday season. Roles IT Manager: Concerned with technical feasibility, integration with existing systems, and long-term maintenance. Software Developer: Interested in the technical challenges and opportunities for innovation. Project Manager: Focused on meeting deadlines, managing resources, and ensuring project success. Customer Service Representative: Needs a user-friendly system that improves customer service efficiency. Business Owner (CEO): Focused on overall business growth, cost-effectiveness, and quick implementation.