Preview Extract
Chapter 12 – Object-Oriented Design: Fundamentals Table of Contents Chapter Overview Learning Objectives Notes on Opening Case and EOC Cases Instructor's Notes (for each section) Key Terms Lecture notes Quick quizzes Classroom Activities Troubleshooting Tips Discussion Questions Chapter Overview In the earlier parts of the textbook, we have taken several chapters to explain the various object-oriented analysis models. Due to the complexity of object-oriented design, we take two chapters to explain design. In Chapter 12, we present the fundamental principles, and in Chapter 13 we present more advanced concepts particularly for detailed design with use case realizations. We have taken this two chapter approach for design with two objectives in mind. First, for those teachers and courses where the time allowed for design is limited, Chapter 12 provides a complete coverage of design principles and skills so that students will be able to at least do basic object-oriented design. Second for those teachers and courses where a more in depth coverage of detailed design is desired, then Chapter 13 teaches enhanced detailed design skills. Chapter 13 also teaches concepts related to design patterns, which are critically important for students who will be doing programming. In Chapter 12, we first introduce the basic idea of what object-oriented design is and why it is useful. The later part of the chapter introduces and teaches concepts related to detailed design. After introducing the concepts of design, the chapter teaches about design class diagrams. A method of actually doing detailed design is presented via the concepts of Class-Responsibility-Collaboration or CRC cards. The use of CRC cards is a popular method of doing detailed design, and works quite well for simple systems. The chapter ends with a discussion of principles that determine whether a detailed design is “good” according to metrics of design quality. Learning Objectives After reading this chapter, the student should be able to: Explain the purpose and objectives of object-oriented design Develop design class diagrams Use CRC cards to define class responsibilities and collaborations Explain important fundamental principles of object-oriented design Notes on Opening Case and EOC Cases Opening Case New Capital Bank: Part 1: This case centers around object-oriented development with an iterative, adaptive project approach. Bill Santora has just finished a technical review of the first-cut design of a new system and he is discussing his approach with his manager. The discussion in the case high lights the benefits of iterative development in that the first four use cases will have a preliminary executable version available after the first iteration in four weeks. The utility of the design class diagrams is also mentioned. EOC Cases The State Patrol Ticket-Processing System (Revisited): The original case was first presented in Chapter 3 and describes a ticket processing system. Based on the information presented in Chapter 3, the student is asked to develop a domain class diagram for the four use cases identified in Chapter 3. For the use case Record a traffic ticket the student is required to create a set of CRC cards and a design class diagram. Community Board of Realtors (running case): Community Board of Realtors is a professional organization that supports real estate offices and agents. In Chapters 3 and 5 the student developed use cases and domain classes. In this chapter the student is required to develop a first-cut DCD and then a set of CRC cards for the Create new listing use case, and then to update the DCD with method names. Spring Breaks 'R' Us Travel Services (SBRU) (running case): SBRU is an online travel services that books spring break trips to resorts for college students. In Chapters 3, 4, and 5 the student developed use cases and domain model for this case. For this chapter the student is required to develop a first-cut DCD and then a set of CRC cards for the Book a reservation use , and then to update the DCD with method names. On the Spot Courier Services (running case): On the Spot is a small, but growing, courier service that needs to track customers, package pickups, package deliveries, and delivery routes. In Chapter 6 the student develop a network diagram for this case. In other chapters (Chapters 3, 4, and 5) use cases, domain model, and activity diagrams were developed. Based on those previous diagrams, the student is required to develop a first-cut design class diagram and set of CRC cards for the two use cases Request a package pickup and Pick up a package. Any additional classes should be added to the DCD. Sandia Medical Devices (running case): Sandia Medical Devices is a company that specializes in medical monitoring through remote, mobile telecommunication devices. Earlier chapters provided detailed description of the requirements. Figure 12-25 is a review of the use cases. The student is required to develop a deployment diagram based on the solution from Chapters 6 and 9. The student is asked to enhance the domain class diagram based on new requirements in this chapter's case description, and to develop the design class diagram and CRC cards relative to the View/respond to alert use case. Instructor's Notes Object-Oriented Design: Bridging from Analysis to Implementation Key Terms instantiation – creation of an object based on the template provided by the class definition Lecture Notes Object-oriented design is a process by which a set of detailed object-oriented design models are built and then used by the programmers to write and test the new system. One strength of the object-oriented approach is that the design models are often just extensions of the requirements models. Sometimes, new developers misinterpret the Agile guidelines to mean that they don’t need to develop design models. The design models may not be formalized into a comprehensive set of documents and diagrams, but they are certainly necessary. One important point about adaptive approaches is that requirements, design, and programming are done in parallel within iterations, so programming is often done along with the design. Overview of Object-Oriented Programs An object-oriented program consists of a set of program objects that cooperate to accomplish a result. Each program object has program logic and any necessary attributes encapsulated into a single unit. These objects work together by sending each other messages and working in concert to support the functions of the main program. Figure 12-1 depicts how an object-oriented program works. It also illustrates three-layer architecture. An object-oriented system consists of sets of computing objects. Each object has data and program logic encapsulated within itself. The objects come into existence, i.e., they are instantiated when the program begins to execute. Analysis Models to Design Models During analysis two types of information are captured, which are used to define the requirements: information about things and information about the business processes. To write a computer program, a programmer needs to know what the classes are, and what the methods are in those classes. Figure 12-3 illustrates how this model building process flows from analysis to design to implementation. Again, note the two types of information—information about things, and information about the flow or the process. Introduction to the Design Models The primary model used to document the classes and the methods is the design class diagram. The design class diagram is an extension of the domain model class diagram that was developed during analysis activities and requirements definition. The primary difference between the two is the addition of the method signatures for the class. A method signature includes the method name, the input parameters, and the type for the returned value. Figure 12-4 illustrates the class diagrams. To document the flow of execution of a particular use case, you use the information provided in a UML interaction model or a CRC card. The three models that capture the process flow are a sequence diagram, a communication diagram, or CRC (class responsibility collaboration) cards. Sequence diagrams and communication diagrams are standard UML interaction diagrams. A communication diagram is similar to a sequence diagram and serves the same purpose. Some developers prefer sequence diagrams, whereas others prefer communication diagrams. See Figures 12-5 and 12-6 for examples. CRC cards are not standard UML, but are very popular for designing simple systems. CRC cards include a set of cards, with each card representing a class. Each card identifies the class, its responsibilities (i.e., its methods), and the other classes with which it collaborates. Quick Quiz Q: What is the fundamental execution model of OO programs? A: Objects execute methods and interact with messages. A program is a set of interacting objects. Q: How is an object created in a computer system, or what is the process called? A: An object is created by being instantiated, or the system makes an “instance” of it. Q: What is the most central diagram for documenting OO classes? What details are provided? A: Design Class Diagram, which shows class names, attributes, and method names. Q: Name the OO diagrams used for OO detailed design. A: Design class diagrams, interaction diagrams – including sequence diagrams and communication diagrams, and CRC cards. Steps of Object-Oriented Design Key Terms object-oriented design – the process to identify the set of classes, their methods, and their messages required to execute a use case Lecture Notes An object-oriented program will have classes in three separate layers: user interface, problem domain, and database access layers. Thus, object-oriented design is the process that identifies and describes the classes within each layer and defines the messages that are used to invoke the methods of the involved classes. Another important issue about object-oriented design is that it is “use-casedriven.” As was discussed earlier, a programmer will code all of the methods across various classes that are required to implement the flow of execution of a single use case. Figure 12-8 illustrates steps required in object-oriented design. The first step is to choose a single use case. Then, you create a model, the type of which depends on the complexity of the use case. The final result is to produce a complete design class diagram with supporting detail as required from interaction diagrams. This figure identifies three possible model paths for generating a final design class diagram, CRC cards, Communication diagrams, or Sequence diagrams. In any of the three techniques for modeling, the objective is to identify and define the methods that are required in each class. Quick Quiz Q: What are the three modeling methods and models to model a use case? A: CRC cards, communication diagrams, and sequence diagrams. Q: What is the objective of detailed object-oriented design? A: To define the methods for each class to carry out a use case. Design Classes and the Design Class Diagram Key Terms stereotype – a way of categorizing a model element by its characteristics, indicated by guillemets ( « » ) entity class – a design identifier for a problem domain class persistent class – an entity class whose objects exist after a system is shut down boundary class, or view class – a class that exists on a system’s automation boundary, such as an input window controller class – a class that mediates between boundary classes and entity classes, acting as a switchboard between the view layer and domain layer data access class – a class that is used to retrieve data from and send data to a database visibility – a notation that indicates (by plus or minus sign) whether an attribute can be directly accessed by another object method signature – a notation that shows all the information needed to invoke, or call, the method class-level method – a method that is associated with a class instead of with objects of the class class-level attribute – an attribute that contains the same value for all objects in the system navigation visibility – a design principle in which one object has a reference to another object and thus can interact with it Lecture Notes A first iteration of the design class diagram is created based on the domain model and on software design principles. The preliminary design class diagram is then used to help develop sequence diagrams. During detailed design, it is important to elaborate on the detailed information about attributes such as public or private and type. It is also important to define the methods and parameters that are passed to the methods and the return values from methods. Design Class Stereotypes To assist in identifying the various types of design classes, developers often stereotype each design class to identify whether it comes from a problem domain class, a user interface definition, and so forth. There are four types of stereotypes that are frequently used, with the symbols as shown in the Figure 12-19: An entity class is the design identifier for a problem domain class. It is also usually a persistent class. A persistent class is one with objects that exist after the program quits. A boundary class, or view class, is specifically designed to live on the system’s automation boundary. In a desktop system, these classes would be the windows classes and all the other classes associated with the user interface. A controller class mediates between the boundary classes and the entity classes. In other words, its responsibility is to catch the messages from the boundary class objects and send them to the correct entity class objects. It acts as a kind of switchboard, or controller, between the view layer and the domain layer. A data access class is used to retrieve data from and send data to a database. Design Class Notation Figure 12-10 shows the details within a design class symbol. The lower two compartments contain more details about the attributes and the methods. The format that analysts use to define each attribute includes: Visibility—Visibility denotes whether other objects can directly access the attribute. Attribute name Data-type-expression (such as character, string, integer, number, currency, or date) Initial-value Property (within curly braces), such as {key} The third compartment contains the method signature information. A method signature shows all the information needed to invoke (or call) the method. It shows the format of the message that must be sent, which consists of these: Method visibility Method name Method parameter list (incoming arguments) Return type-expression (the type of the return parameter from the method) A class-level method, which is denoted by an underline, operates on the class instead of on an individual object in the class. A class-level attribute, which is also underlined, apply to the class and not to an object. Developing the First-Cut Design Class Diagram The first-cut design class diagram is developed by extending the domain model class diagram. It requires two steps: (1) elaborating on the attributes with type and initial value information and (2) adding navigation visibility arrows. Elaboration of Attributes: The type information is determined by the designer based on his or her expertise. In most instances, all attributes are kept invisible or private and are indicated with minus signs before them. Navigation Visibility: For one object to interact with another by sending a message, the first object must be visible to the second object. In this context, navigation visibility refers to the ability of one object to view and interact with another object, and is indicated by an arrow pointing to the visible class. We use two types of navigation visibility during design: attribute navigation visibility and parameter navigation visibility. Attribute navigation visibility occurs when a class has an attribute that references another object. Visibility is obtained through the attribute reference. Parameter navigation visibility occurs when a class is passed a parameter that references another object. To add navigation visibility to class diagram the develop cycles through the classes in the domain class diagram and asks which classes need to have references to or be able to access witch other classes. Here are a few guidelines: One-to-many associations that indicate a superior/subordinate relationship are usually navigated from the superior to the subordinate. Mandatory associations, in which objects in one class can’t exist without objects of another class, are usually navigated from the more independent class to the dependent class. When an object needs information from another object, a navigation arrow might be required. Navigation arrows may be bidirectional. Figure 12-14 is an example from RMO based on a single use case. Figure 12-14 has one additional design class in the diagram for this use case—SaleHandler—which is stereotyped as a controller class. Three points are important to note. First, as detailed design proceeds use case by use case, we need to ensure that the sequence diagrams support and implement the navigation that was initially defined. Second, the navigation arrows need to be updated as design progresses to be consistent with the design details. Finally, method signatures will be added to each class based on the design decisions made when creating the sequence diagrams for the use cases. Quick Quiz Q: What is the difference between a domain class diagram and a design class diagram? A: The domain class diagram defines the problem domain classes. It is a tool of analysis. The design class diagram defines design classes. It includes domain classes and other design classes. The detail information within the classes is also elaborated with attribute details and method names. Q: What is a controller class? A: It is a class that serves as the interface between the view layer and the logic layer. Q: What are the elements of a method signature? A: method visibility, method name, method parameter list, and return type Q: What is a class level method? A: A method that works on the class level and not on just an object. It often references all of the objects in a class. Q: What is navigation visibility used for? A: It identifies which classes can access the methods (API) of which other classes. If another class is 'visible' then its methods can be accessed. Q: Which way does visibility usually go in a one-to-many relationship? A: Usually from the one class to the many. Often there is a superior (the one class) and an subordinate (the many class), where the superior has access to the subordinate. Designing with CRC Cards Key Terms CRC cards – a brainstorming technique for designing interactions in use cases by assigning responsibilities and collaborations for classes Lecture Notes “CRC” is an acronym for Class-Responsibility-Collaboration. A CRC card is a card layout for a single class and identifies the class and its attributes, its responsibilities, i.e., functions, and its collaborations, i.e. the methods in its API. Figure 12-15 shows the notation. The name is on top. The attributes are listed on the back side. The methods (responsibilities) are listed on a left rectangle, and the list of collaborating classes is in the right rectangle. The process of developing a CRC model is usually done in a brainstorming session. The process is as follows: Select a use case—Because the process is to design, or realize, a single use case, start with a set of unused CRC cards. Identify the problem domain class that has responsibility for this use case—This object will receive the first message from the use case controller. Using the domain model that was developed during analysis, select one class to take responsibility. Focus only on the problem domain classes. On the left side of the card, write the object’s responsibility. Identify other classes that must collaborate with the primary object class to complete the use case—Other classes will have required information. List these classes on the primary problem domain card. As you identify the other classes, write their responsibilities on their cards. Include the user-interface classes as necessary. Add other required utility classes such as data-access classes. At the end of this process, you will have a small set of CRC cards that collaborate to support the use case. At the end of the design for one use case, two other important tasks remain. Because the CRC cards only have data for a single use case, the information can be transferred to the design class diagram. If the use case is a simple one, the CRC cards can be taken by a programmer and the use case can be implemented. Figure 12-17 through Figure 12-21 illustrate an example for the Create customer account use case. Figure 12-22 is the updated design class diagram based on the methods and classes added from the CRC design. Figure 12-23 and Figure 12-24 illustrate an example for the Create telephone sale use case, showing the CRC cards and the updated design class diagram. Quick Quiz Q: What does CRC stand for? A: Class-Responsibility-Collaboration Q: What is the format of a CRC card? A: Class name on top. Class attributes on the back side. Method names (responsibilities) on the left box. Collaborating class names on right box. Q: How is CRC design done? A: Take a single use case, identify the primary domain class, identify the other domain classes, add the collaboration messages, add other classes as desired for completeness. Fundamental Principles for Good Design Key Terms object responsibility – a design principle in which objects are responsible for carrying out system processing separation of responsibilities – a design principle that recommends segregating classes into separate packages or groupings based on a primary focus of processing responsibility protection from variations – a design principle in which parts of a system that are unlikely to change are segregated from those that will indirection – a design principle in which an intermediate class is placed between two classes to decouple them but still link them coupling – a qualitative measure of how closely the classes in a design class diagram are linked cohesion – a qualitative measure of the focus or unity of purpose within a single class Lecture Notes Object Responsibility One of the most fundamental principles of object-oriented development is the idea of object responsibility. These responsibilities are categorized in two major areas: knowing and doing. In other words, what is an object expected to know, and what is an object expected to do or to initiate? “Knowing” includes an object’s responsibilities for knowing about its own data and knowing about other classes with which it must collaborate to carry out use cases. “Doing” includes all the activities an object does to assist in executing a use case. Separation of Responsibilities or Separation of Concerns Separation of responsibilities, also called separation of concerns, is a design principle that is applied to a group of classes rather than to each class individually. The basic idea of separation of responsibilities is to segregate classes into packages or groupings based on a primary focus of processing responsibility. Separation of responsibilities is the fundamental principle behind multilayer design. Protection from Variations One of the underlying principles of good design is protection from variations—the idea that the parts of a system that are unlikely to change should be segregated (or protected) from those that will change. Protection from variations is a principle that drives the multilayer design pattern. If the user-interface classes are tightly coupled to the business classes, there could be a ripple effect of changes throughout the user interface classes whenever a change is required. Protection from variations affects almost every design decision, so you should watch for and recognize the application of this principle in all design activities. Indirection Indirection is the principle of decoupling two classes or other system components by placing an intermediate class between them to serve as a link. A good example of indirection is where companies have firewalls and proxy servers that receive and send messages between an internal network and the Internet. Coupling Coupling is a qualitative measure of how closely the classes in a design class diagram are linked. A simple way to think about coupling is as the number of navigation arrows on the design class diagram. Low coupling is usually better for a system than high coupling. In other words, fewer navigation visibility arrows indicate that a system is easier to understand and maintain. High coupling is bad because a change in one class ripples through the entire system. Cohesion Cohesion is a qualitative measure of the focus or unity of purpose within a single class. Classes with low cohesion have several negative effects. First, they are hard to maintain. Because they perform many different functions, they tend to be overly sensitive to changes within the system, suffering from ripple effects. Second, it is hard to reuse such classes. Quick Quiz Q: Why is low coupling a good thing? A: Low coupling between classes allows one class to be changed often with little or no impact to other classes. Q: Why is high cohesion good? A: It is easier to maintain a system if the classes are focused on doing only one thing. Multiple use classes are changed more frequently with resulting potential of errors. Q: How does indirection work? A: To reduce coupling between classes, and third class may be inserted between the two classes. The third class acts as a layer or protection. Q: What does separation of responsibilities mean? A: It is a technique to divide classes into groups based on their focus or responsibility. It is the basis for three-layer design. Q: What is protection from variations? A: It is the concept that classes that have a higher probability of requiring changes should be segregated from those that are more stable. One way to implement this is through plug-in classes or methods. Classroom Activities An interesting classroom activity is often done by doing some reverse engineering using documentation tools. For example, using a source-code documentation tool, (javadoc, phpDocumentor, NDOC for .net) you can take an existing system and show class libraries and methods and attributes. You could also show two or three layer design, which if the developers did a good job might even be divided into packages based on the layers. You certainly should be able to determine view, business logic, and data access logic. If the system is poorly designed, that would provide a good counter example. You could have a lively class discussion on difficulties of maintaining a poorly designed system. An additional activity would be to look at the classes and estimate the level of cohesion and coupling in the system. Do you see any indirection and protection from variations. Students can make suggestions how to improve the system structure. For the skills based topics, particularly CRC cards and design class diagrams, you could have the student teams do a simple CRC card design. Presentations by one or two teams will provide an effective forum for discussion of issues and difficulties of design. Then have the teams take one or two classes from the CRC cards and actually write some pseudocode. Nothing helps a person to learn how to design well than having to write the code from the design documents, discussion of issues, and difficulties of design. Then have the teams take one or two classes from the CRC cards and actually write some pseudocode. Nothing helps a person to learn how to design well than having to write the code from the design documents. Troubleshooting Tips Design is a fairly complex topic and students have trouble understanding the principles. However, most students have taken or are taking a programming course. In the programming course, the students are doing design activities. Typically they just don't recognize that is what they are doing. One of the best ways to teach about design, is to relate it to their programming course, and either to their current course projects or have a simple programmed system to review. You can ask leading questions such as how did you decided which classes to create? How did you decide on which methods to have in those classes? How hard would this (an example system) be if you had to add a new input field, to change the processing of some function or calculation? There are areas that the students typically may struggle with – The design process (and CRC cards), the concept of navigation visibility, and design principles such as Coupling, cohesion and object responsibility. The design process: The major idea that students need to recognize is that design is done use case by use case. Each use case will add to the DCD by identifying methods for each class. The best way to teach this concept is by having the students do design using CRC cards. One of the primary reasons that CRC cards are included in the textbook is that it is a powerful technique to teach design principles. Navigation visibility: Students who have done programming are familiar with the basic concept. One object cannot access a method in another class without addressability. Students who have programmed are familiar with address spaces and with global methods and attributes and local methods and attributes. The concept of navigation visibility is nothing more than identifying addressability except during design instead of waiting until programming starts. The best way to teach this is with programming examples. Coupling, Cohesion and Object responsibility: These concepts are fairly simple to understand at the conceptual level, but hard to grasp at the implementation level. Two ways to teach this. First with some reverse engineering examples you should be able to point out examples of good and bad coupling and cohesion and even object responsibility. Then during classroom activities with CRC cards, help students think about where to put methods based on these principles. This is a detailed activity and class discussion about which class should update the quantity on hand, or a person's address, etc. will help solidify these concepts. Discussion Questions Much of the class discussion will center on the classroom activities as described above. However, the following two questions are interesting, and important philosophical questions that directly impact how a project is executed. 1. Analysis and Design Models If a use case diagram is modified due to a design omission, which diagrams would need to be revisited and potentially revised? During the design of interaction diagrams, if a missing actor is identified, which diagrams would need to be revisited and potentially revised? How important is it to keep the analysis models updated when changes are made to design models? This is an interesting question particularly in the context of Agile development. If analysis models are used to document business requirements decisions, how important is it to keep them current, especially prior to user acceptance testing? When modifications are made to a use case diagram or when a missing actor is identified during the design of interaction diagrams, several related diagrams may need to be revisited and potentially revised: 1. Use Case Diagram: If there's a modification due to a design omission, it's likely that related use cases, actors, or relationships might need adjustments. 2. Class Diagram: Changes in the use case diagram could affect the classes and their relationships, so the class diagram may need to be revised accordingly. 3. Sequence Diagrams: In the case of interaction diagram design modifications, sequence diagrams might need revisiting to ensure that the interactions between objects or actors are accurately represented. 4. Activity Diagrams: Any changes to the use case or interaction diagrams could impact the flow of activities within the system, necessitating updates to activity diagrams. 5. State Diagrams: If the modifications affect the system's behavior or state transitions, then state diagrams might need adjustments to reflect these changes. 6. Collaboration Diagrams: Similar to sequence diagrams, collaboration diagrams may need revisiting to ensure accurate representation of object interactions. It's essential to keep analysis models updated when changes are made to design models, especially in Agile development. Agile emphasizes continuous iteration and adaptation, and keeping all models aligned ensures that the development team has a clear and up-to-date understanding of the system requirements and design. This alignment becomes particularly crucial before user acceptance testing (UAT), as any discrepancies between the analysis and design models could lead to misunderstandings, rework, or even project delays. In Agile, where requirements and designs evolve through collaboration and feedback, maintaining current analysis models is vital for documenting business requirements decisions accurately. These models serve as a reference point for stakeholders to ensure that the developed system aligns with their expectations and needs. Keeping analysis models updated facilitates effective communication between stakeholders, developers, and testers throughout the development process, ultimately leading to a successful project outcome. 2. Implementation Issues for Three-Layer Design Three layer design defines the responsibilities for the view layer, domain layer, and data access layer classes. Should these classes be designed by one person, or should each layer be designed by different people with separate knowledge of the view layer, the business logic layer, and the data access layer? Which is more important, getting the overall structure right, or capturing the details for each layer? If the approach is to use three separate people, how do they collaborate to get to a common design and understanding? After the design is complete, can the implementation work be done by different individuals, or by the same person? The decision of whether one person should design all layers or different people should handle each layer depends on various factors, including the project's size, complexity, team expertise, and organizational structure. Here are considerations for both approaches: 1. Single Designer Approach: Advantages: • Cohesive Vision: One person designing all layers ensures a cohesive and unified vision for the entire system. • Consistency: Ensures consistency in design choices across all layers. • Efficiency: Can be more efficient in smaller projects or when the designer has expertise in all layers. Challenges: • Limited Expertise: The designer may not have in-depth expertise in all layers, leading to potential design flaws or suboptimal solutions. • Bottleneck: The workload may become a bottleneck, especially in larger projects or tight deadlines. 2. Different Designers for Each Layer: Advantages: • Specialization: Allows each designer to focus on their area of expertise, potentially leading to better designs for each layer. • Collaboration: Encourages collaboration and knowledge sharing among team members. • Reduced Bottleneck: Distributes the workload and reduces dependency on a single person. Challenges: • Coordination: Requires effective coordination and communication among designers to ensure consistency and coherence across layers. • Integration: Ensuring seamless integration of different layers' designs can be challenging. Regarding the importance of getting the overall structure right versus capturing the details for each layer, both aspects are crucial. Getting the overall structure right establishes the foundation for the system's architecture and functionality. However, capturing the details for each layer is essential for ensuring that individual components fulfill their responsibilities effectively and interact seamlessly with other layers. If the approach involves using three separate people to design each layer, collaboration is key to achieving a common design and understanding. Regular meetings, discussions, and reviews can help align the designers' visions, address any discrepancies, and ensure consistency across layers. Documentation, such as design documents or diagrams, can also aid in communication and maintaining a shared understanding. After the design is complete, the implementation work can be done by different individuals or by the same person, depending on team dynamics, workload distribution, and individual expertise. Effective communication, documentation, and possibly code reviews can help ensure that the implemented solution adheres to the design specifications and meets the project requirements. Instructor Manual for Systems Analysis and Design in a Changing World John W. Satzinger, Robert B. Jackson, Stephen D. Burd 9781305117204, 9781111951641
