Software_Engg_PB_Unit12345_241001_001550.pdf

Software Engineering/CS3CO40 III Year-V Sem. Session : Aug-Dec. 2024 (AY-2024-25) Prepared By : Mr. Pradeep Baniya Asst. Prof. CSE, Dept. MU Indore  Unit...

Software Engineering/CS3CO40 III Year-V Sem. Session : Aug-Dec. 2024 (AY-2024-25) Prepared By : Mr. Pradeep Baniya Asst. Prof. CSE, Dept. MU Indore  Unit-1 Introduction of Software 1. Problem and Prospects 2. Software development process I. System Development Life Cycle II. Process Models:- (Waterfall Model, Spiral Model and Other Process Models) 3. Unified process Agile development I. Agile Process- Extreme Programming II. Other agile Process models (Lean, Kanban)  Introduction of Software The software is a collection of integrated programs. Software subsists of carefully-organized instructions and code written by developers on any of various particular computer languages. Computer programs and related documentation such as requirements, design models and user manuals. Engineering is the application of scientific and practical knowledge to invent, design, build, maintain, and improve frameworks, processes, etc. Introduction of Software  Introduction of Software Software Engineering is an engineering branch related to the evolution of software product using well-defined scientific principles, techniques, and procedures. The result of software engineering is an effective and reliable software product.  Introduction of Software Why is Software Engineering required?  Introduction of Software Why is Software Engineering required? Handling Big Projects: A corporation must use a software engineering methodology in order to handle large projects without any issues. To manage the cost: Software engineering programmers plan everything and reduce all those things that are not required. To decrease time: It will save a lot of time if you are developing software using a software engineering technique. Reliable software: It is the company’s responsibility to deliver software products on schedule and to address any defects that may exist.  Introduction of Software Effectiveness: Effectiveness results from things being created in accordance with the standards. Reduces complexity: Large challenges are broken down into smaller ones and solved one at a time in software engineering. Individual solutions are found for each of these issues. Productivity: Because it contains testing systems at every level, proper care is done to maintain software productivity.  Introduction of Software Problems : Difficulty of Software Engineering and Ways to Overcome Common Software Engineering Challenges 1. Rapid Advancement of Technology 2. Growing Customer Demands 3. Time Constraints 4. Limited Infrastructure 5. Software Testing Conflicts 6. Changing Requirements 7. Limited Time and Resources 8. Security 9. Scalability 10. High Availability  Software Development Process Definition: A software development process is a way to improve design and product management by breaking software development work into smaller steps or sub-processes that can be done in parallel or in-order. The Software Development Process is the structured approach to developing software for a system or project, sometimes called the Software Development Life Cycle (SDLC). There are several approaches (see Software Development Approaches) that can be used to include waterfall, spiral, and incremental development. These different approaches will focus the testing effort at different points in the development process. However, each approach is composed of the same basic steps of development.  Purpose of Software Development Process A solid software development process ensures that high-quality software products are made quickly and well. A well-thought-out and well-executed method has several advantages: 1. Quality assurance 2. Consistency and repeatability 3. Collaboration and coordination 4. Risk management 5. Scalability and efficiency 6. Continuous improvement  Purpose of Software Development Process Software Development Process Steps The software development process consists of four major steps. Step 1: Planning Step 2: Implementation Step 3: Testing Step 4: Deployment and Maintenance  Software Development Life Cycle (SDLC) Software Development Life Cycle A software life cycle model (also termed process model) is a pictorial and diagrammatic representation of the software life cycle. A life cycle model represents all the methods required to make a software product transit through its life cycle stages. It also captures the structure in which these methods are to be undertaken. A software life cycle model describes entry and exit criteria for each phase. A phase can begin only if its stage-entry criteria have been fulfilled. So without a software life cycle model, the entry and exit criteria for a stage cannot be recognized. Without software life cycle models, it becomes tough for software project managers to monitor the progress of the project. Software Development Life Cycle (SDLC) SDLC Phases  Software Development Life Cycle (SDLC) Software Development Life Cycle The different phases of SDLC include planning, requirements, design, development, testing, deployment, and maintenance. Several SDLC models exist, including the waterfall model, spiral model, V-shaped model, iterative model and agile model. The use of SDLC enables programmers to work concurrently and evaluate each part of the software development process effectively. ***It is important to note that SDLC is a process and not a technique.  Software Development Life Cycle (SDLC) Phases in SDLC There are various phases in the Software Development Life Cycle (SDLC), which are as follows: 1. Requirement Gathering Phase 2. Analysis Phase 3. Design Phase 4. Development Phase 5. Testing Phase 6. Deployment & Maintenance Phase  Software Development Life Cycle (SDLC) SDLC Models There are many different SDLC Models for implementation in the software development process. The most important and popular ones are: 1. Waterfall or Linear Sequential Model 2. Iterative Waterfall Model 3. Incremental 4. Evolutionary Model(Combination of Iterative and Incremental Model) 5. Spiral Model 6. Prototype Model 7. RAD Model 8. Component Assembly Model SDLC Models  SDLC Models When to use SDLC Waterfall Model? Some Circumstances where the use of the Waterfall model is most suited are: 1. When the requirements are constant and not changed regularly. 2. A project is short 3. Where the tools and technology used is consistent and is not changing 4. When resources are well prepared and are available to use.  SDLC Models Advantages of Waterfall model Today, Agile methodology is often used in place of the waterfall model. However, there are advantages to the waterfall approach, such as the following: 1. enables large or changing teams to move toward a common goal that's been defined in the requirements stage; 2. forces structured, disciplined organization; 3. simplifies understanding, following and arranging tasks; 4. facilitates departmentalization and managerial control based on the schedule or deadlines; 5. reinforces good coding habits to define before implementing design and then code; 6. enables early system design and specification changes to be easily done; and 7. clearly defines milestones and deadlines.  SDLC Models Disadvantages of Waterfall model 1. Disadvantages of the waterfall model typically center around the risk associated with a lack of revision and flexibility. Specific issues include the following: 2. Design isn't adaptive; when a flaw is found, the entire process often needs to start over. 3. Method doesn't incorporate mid process user or client feedback, and makes changes based on results. 4. Waterfall model delays testing until the end of the development lifecycle. 5. It doesn't consider error correction. 6. The methodology doesn't handle requests for changes, scope adjustments and updates well. 7. Waterfall doesn't let processes overlap for simultaneous work on different phases, reducing overall efficiency. 8. No working product is available until the later stages of the project lifecycle. 9. Waterfall isn't ideal for complex, high-risk ongoing projects. 2. Iterative Waterfall Model  When to use the Iterative Waterfall Model 1. Requirements are well known and stable. 2. Technology is understood. 3. Experienced development team. Iterative Waterfall Model strengths 1. Easy to understand, easy to use. 2. Provides a reference for inexperienced staff. 3. Milestones are well understood by the team. 4. It provides requirements stability. 5. Facilitates strong management controls.  Iterative Waterfall Model deficiencies 1. All requirements must be known upfront. 2. Deliverables created for each phase are considered frozen. 3. It can give a false impression of progress as there is no output until the project’s completion. 4. Integration is one big bang at the end. 5. Little opportunity for the customer to preview the system. 3. Incremental Model  When to Use an Incremental Model 1. The incremental model can be used when: 2. the objectives of the entire system are clearly stated and recognized, though some details can evolve at each increment over time. 3. there's a pressing need to get a product to market as soon as possible. 4. the consumer expects the product to be readily available as soon as possible. 5. there's a need to get a product to the market early. 6. new technology is being deployed. 7. the software team is inexperienced or unskilled. 8. a project's development timeline is prolonged. 9. there are some high-risk features and goals. 10. there are no resources with the necessary skills.  Pros of the Incremental Model The incremental model offers many advantages, including the ability to risk-manage progress and increase efficiency. Here are a few other advantages of this approach: 1. Improved efficiency—The incremental model can help to increase efficiency by allowing teams to plan and organize work more effectively. This approach can also help to reduce the risk of bottlenecks or dependency issues. 2. Risk-managed progress—Teams can risk-manage progress by testing their project in stages. This means that they can identify and address issues as they emerge and make adjustments as necessary. 3. Clear reporting and tracking—The incremental model allows teams to clearly report and track their progress, which can help to improve project visibility and collaboration across teams.  Pros of the Incremental Model 4. Feedback is possible— In the incremental model, the user or the customer can submit feedback at each level to avoid sudden changes. 5. Meeting goals—Once the requirements are mapped out, all software goals and objectives can be satisfied completely through incremental development.  Cons of Incremental Model The incremental model is not suitable for every project and comes with some inherent risks, including: 1. This model has to be carefully planned and designed at the beginning, or the entire goal of incrementing will be defeated. 2. There's a risk that teams will lose focus and their project will become uncoordinated. 3. The iteration stages are rigorous, and they don't overlap. 4. If teams don't take time to plan their work and organize their project, they may end up delivering low-quality work and falling behind schedule. 5. It can lead to wasted effort, as teams may continually have to renegotiate and reprioritize work, which can lead to inefficiencies. 6. When there's a problem in one unit, it has to be fixed in all units, which is time-consuming. 4. Evolutionary Model Evolutionary Model :- An evolutionary model involves breaking down the software development process into smaller, manageable increments or iterations. Each iteration involves the completion of a subset of the overall software requirements, allowing for continuous testing, feedback, and refinement. This approach enables the software to evolve and improve over time, as new requirements and insights emerge. In simple words, “Iterative” + “Incremental model” = Evolutionary model.  Advantages and Disadvantages Advantages Disadvantages Allows for incremental development May require more time and effort to and improvement manage and coordinate changes Enables early delivery of working Requires a high level of collaboration software and communication among team members Facilitates continuous feedback and May not be suitable for projects with collaboration with stakeholders strict deadlines or fixed budgets Reduces the risk of project failure by Can result in a less predictable and more identifying issues early on uncertain development process 5. Prototype Model Prototype Model :- In this process model, the system is partially implemented before or during the analysis phase thereby giving the customers an opportunity to see the product early in the life cycle. The process starts by interviewing the customers and developing the incomplete high-level paper model. This document is used to build the initial prototype supporting only the basic functionality as desired by the customer. Once the customer figures out the problems, the prototype is further refined to eliminate them. The process continues until the user approves the prototype and finds the working model to be satisfactory. Steps of Prototype Model Requirement Gathering and Analysis Quick Decision Build a Prototype Assessment or User Evaluation Prototype Refinement Engineer Product Advantage of Prototype Model Reduce the risk of incorrect user requirement Good where requirement are changing/uncommitted Regular visible process aids management Support early product marketing Reduce Maintenance cost. Errors can be detected much earlier as the system is made side by side. Disadvantage of Prototype Model An unstable/badly implemented prototype often becomes the final product. Require extensive customer collaboration ❖ Costs customer money ❖ Needs committed customer ❖ Difficult to finish if customer withdraw Difficult to know how long the project will last. Easy to fall back into the code and fix without proper requirement analysis, design, customer evaluation, and feedback. Prototyping tools are expensive. Special tools & techniques are required to build a prototype. It is a time-consuming process. 6. Spiral Model Spiral Model Spiral Model = Concept of Waterfall lifecycle+ Iterative model. The spiral model, is an evolutionary software process model that couples the iterative feature of prototyping with the controlled and systematic aspects of the linear sequential model. It implements the potential for rapid development of new versions of the software. Using the spiral model, the software is developed in a series of incremental releases. During the early iterations, the additional release may be a paper model or prototype. During later iterations, more and more complete versions of the engineered system are produced. Spiral Model Each cycle in the spiral is divided into four parts: Objective setting: Each cycle in the spiral starts with the identification of purpose for that cycle, the various alternatives that are possible for achieving the targets, and the constraints that exists. Risk Assessment and reduction: The next phase in the cycle is to calculate these various alternatives based on the goals and constraints. The focus of evaluation in this stage is located on the risk perception for the project. Development and validation: The next phase is to develop strategies that resolve uncertainties and risks. This process may include activities such as benchmarking, simulation, and prototyping. Spiral Model Each cycle in the spiral is divided into four parts: Planning: Finally, the next step is planned. The project is reviewed, and a choice made whether to continue with a further period of the spiral. If it is determined to keep, plans are drawn up for the next step of the project. Spiral Model When to use Spiral Model? When deliverance is required to be frequent. When the project is large When requirements are unclear and complex When changes may require at any time Large and high budget projects Spiral Model Advantages High amount of risk analysis Useful for large and mission-critical projects. Disadvantages Can be a costly model to use. Risk analysis needed highly particular expertise Doesn't work well for smaller projects 7. RAD Model 7. RAD Model RAD Model The RAD model is a type of incremental process model in which there is an extremely short development cycle. When the requirements are fully understood and the component-based construction approach is adopted then the RAD model is used. Various phases in RAD are Requirements Gathering, Analysis and Planning, Design, Build or Construction, and finally Deployment. The critical feature of this model is the use of powerful development tools and techniques. A software project can be implemented using this model if the project can be broken down into small modules wherein each module can be assigned independently to separate teams. RAD Model These modules can finally be combined to form the final product. Development of each module involves the various basic steps as in the waterfall model i.e. analyzing, designing, coding, and then testing, etc. as shown in the previous figure. Another striking feature of this model is a short period i.e. the time frame for delivery(time-box) is generally 60-90 days. Multiple teams work on developing the software system using the RAD model parallely. When to use RAD Model? When the customer has well-known requirements, the user is involved throughout the life cycle, the project can be time-boxed, the functionality delivered in increments, high performance is not required, low technical risks are involved and the system can be modularized. In these cases, we can use the RAD Model. when it is necessary to design a system that can be divided into smaller units within two to three months. when there is enough money in the budget to pay for both the expense of automated tools for code creation and designers for modeling. Advantages: The use of reusable components helps to reduce the cycle time of the project. Feedback from the customer is available at the initial stages. Reduced costs as fewer developers are required. The use of powerful development tools results in better quality products in comparatively shorter time spans. The progress and development of the project can be measured through the various stages. It is easier to accommodate changing requirements due to the short iteration time spans. Productivity may be quickly boosted with a lower number of employees. Disadvantages: The use of powerful and efficient tools requires highly skilled professionals. The absence of reusable components can lead to the failure of the project. The team leader must work closely with the developers and customers to close the project on time. The systems which cannot be modularized suitably cannot use this model. Customer involvement is required throughout the life cycle. It is not meant for small-scale projects as in such cases, the cost of using automated tools and techniques may exceed the entire budget of the project. Not every application can be used with RAD. Applications: This model should be used for a system with known requirements and requiring a short development time. It is also suitable for projects where requirements can be modularized and reusable components are also available for development. The model can also be used when already existing system components can be used in developing a new system with minimum changes. This model can only be used if the teams consist of domain experts. This is because relevant knowledge and the ability to use powerful techniques are a necessity. The model should be chosen when the budget permits the use of automated tools and techniques required. Limitations/Drawbacks: It requires multiple teams or a large number of people to work on the scalable projects. This model requires heavily committed developer and customers. If commitment is lacking then RAD projects will fail. The projects using RAD model requires heavy resources. If there is no appropriate modularization then RAD projects fail. Performance can be problem to such projects. The projects using RAD model find it difficult to adopt new technologies. 8. Component Assembly Model Component Based Development Model: This model uses various characteristics of spiral model. This model is evolutionary by nature. Hence, software development can be done using iterative approach. In CBD model, multiple classes can be used. These classes are basically the prepackaged components. The model works in following manner: Step-1: First identify all the required candidate components, i.e., classes with the help of application data and algorithms. Step-2: If these candidate components are used in previous software projects then they must be present in the library. Component Based Development Model: Step-3: Such preexisting components can be excited from the library and used for further development. Step-4: But if the required component is not present in the library then build or create the component as per requirement. Step-5: Place this newly created component in the library. This makes one iteration of the system. Step-6: Repeat steps 1 to 5 for creating n iterations, where n denotes the number of iterations required to develop the complete application. Characteristics of Component Assembly Model: Uses object-oriented technology. Components and classes encapsulate both data and algorithms. Components are developed to be reusable. Paradigm similar to spiral model, but engineering activity involves components. The system produced by assembling the correct components. Rational Unified Process Rational Unified Process (RUP) RUP is a software development process for object-oriented models. It is also known as the Unified Process Model. It is created by Rational corporation and is designed and documented using UML (Unified Modeling Language). This process is included in IBM Rational Method Composer (RMC) product. IBM allows us to customize, design, and personalize the unified process. RUP is proposed by Ivar Jacobson, Grady Bootch, and James Rambaugh. Some characteristics of RUP include use-case driven, Iterative (repetition of the process), and Incremental (increase in value) by nature. RUP reduces unexpected development costs and prevents wastage of resources. Phases of RUP 1. Inception – Communication and planning are the main ones. Identifies the scope of the project using a use-case model allowing managers to estimate costs and time required. Customers’ requirements are identified and then it becomes easy to make a plan for the project. The project plan, Project goal, risks, use-case model, and Project description, are made. The project is checked against the milestone criteria and if it couldn’t pass these criteria then the project can be either canceled or redesigned. Phases of RUP 2. Elaboration – Planning and modeling are the main ones. A detailed evaluation and development plan is carried out and diminishes the risks. Revise or redefine the use-case model (approx. 80%), business case, and risks. Again, checked against milestone criteria and if it couldn’t pass these criteria then again project can be canceled or redesigned. Executable architecture baseline. 3. Construction – The project is developed and completed. System or source code is created and then testing is done. Coding takes place. Phases of RUP 4. Transition – The final project is released to the public. Transit the project from development into production. Update project documentation. Beta testing is conducted. Defects are removed from the project based on feedback from the public. 5. Production – The final phase of the model. The project is maintained and updated accordingly. Agile Development What is Agile? Agile development is a phrase used in software development to describe methodologies for incremental software development. Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project. Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks. Agile methods also emphasize working software as the primary measure of progress Agile Manifesto Four Important Manifestos of Agile development :--- 1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan Principles Of Agile 1. Customer Satisfaction 2. Working Software 3. Measure Of Progress 4. Late Changes Are Welcome 5. Face_To_Face Communication 6. Motivated Individuals 7. Technical Excellence 8. Simplicity 9. Self_organizing 10. Regular Adoption Characteristics Of Agile 1. Modularity 2. Iterative 3. Time-bound 4. Incremental 5. People oriented 6. Less defect 7. Collaborative 8. Motivating the team  Advantages Of Agile Model 1. Customer Satisfaction. 2. People and interactions 3. Customers, developers and testers constantly interact with each other. 4. Working software is delivered frequently. 5. Face-to-face conversation. 6. Close, daily cooperation between business people and developers. 7. Continuous attention to technical good design. 8. Regular adaptation to changing circumstances. 9. Even late changes in requirements are welcomed  Disadvantages Of Agile Model 1. In case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle. 2. There is lack of emphasis on necessary designing and documentation. 3. The project can easily get taken off track if customer representative is not clear what outcome that they want. 4. Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.  Unit-2 Requirement Analysis, Stakeholders, Elicitation Techniques, Requirement Modelling 1. Requirement Analysis, Stakeholders, Elicitation Techniques, Requirement Modelling. I. Use Cases, Activity Diagrams II. Swimlane Diagrams, Data Modelling. III. Data Flow Diagram. IV. Class Based Modelling. V. Requirement Tracking.  Requirement Engineering 1. The process to gather the software requirements from client, analyze and document them is known as requirement engineering. 2. The goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System Requirements Specification’ document. Requirement Engineering Process It is a four step process, which includes – 1. Feasibility Study 2.Requirement Gathering 3. Software Requirement Specification 4. Software Requirement Validation  Software Requirement Validation After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following conditions – If they can be practically implemented If they are valid and as per functionality and domain of software If there are any ambiguities If they are complete If they can be demonstrated  Requirement Elicitation Process Requirement elicitation process can be depicted using the folloiwng diagram: Requirements gathering - The developers discuss with the client and end users and know their expectations from the software. Organizing Requirements - The developers prioritize and arrange the requirements in order of importance, urgency and convenience.  Requirement Elicitation Process Requirement elicitation process can be depicted using the following diagram: Negotiation & discussion - If requirements are ambiguous or there are some conflicts in requirements of various stakeholders, if they are, it is then negotiated and discussed with stakeholders. Requirements may then be prioritized and reasonably compromised. The requirements come from various stakeholders. To remove the ambiguity and conflicts, they are discussed for clarity and correctness. Unrealistic requirements are compromised reasonably. Documentation - All formal & informal, functional and non-functional requirements are documented and made available for next phase processing.  Requirement Elicitation Techniques Requirements Elicitation is the process to find out the requirements for an intended software system by communicating with client, end users, system users and others who have a stake in the software system development. There are various ways to discover requirements. ▪ Interviews Interviews are strong medium to collect requirements. Organization may conduct several types of interviews such as: 1.Structured (closed) interviews, where every single information to gather is decided in advance, they follow pattern and matter of discussion firmly. 2.Non-structured (open) interviews, where information to gather is not decided in advance, more flexible and less biased.  Requirement Elicitation Techniques 3. Oral interviews 4. Written interviews 5. One-to-one interviews which are held between two persons across the table. 6. Group interviews which are held between groups of participants. They help to uncover any missing requirement as numerous people are involved. ▪ Surveys Organization may conduct surveys among various stakeholders by querying about their expectation and requirements from the upcoming system.  Requirement Elicitation Techniques ▪ Questionnaires A document with pre-defined set of objective questions and respective options is handed over to all stakeholders to answer, which are collected and compiled. A shortcoming of this technique is, if an option for some issue is not mentioned in the questionnaire, the issue might be left unattended. ▪ Task analysis Team of engineers and developers may analyze the operation for which the new system is required. If the client already has some software to perform certain operation, it is studied and requirements of proposed system are collected.  Requirement Elicitation Techniques ▪ Domain Analysis Every software falls into some domain category. The expert people in the domain can be a great help to analyze general and specific requirements. ▪ Brainstorming An informal debate is held among various stakeholders and all their inputs are recorded for further requirements analysis. ▪ Observation Team of experts visit the client’s organization or workplace. They observe the actual working of the existing installed systems. They observe the workflow at client’s end and how execution problems are dealt. The team itself draws some conclusions which aid to form requirements expected from the software.  Requirement Elicitation Techniques ▪ Prototyping Prototyping is building user interface without adding detail functionality for user to interpret the features of intended software product. It helps giving better idea of requirements. If there is no software installed at client’s end for developer’s reference and the client is not aware of its own requirements, the developer creates a prototype based on initially mentioned requirements. The prototype is shown to the client and the feedback is noted. The client feedback serves as an input for requirement gathering.  Requirement Modelling Introduction Requirements modeling involves creating a graphical representation of a system’s requirements. It provides a visual and structured approach to documenting requirements, which helps to ensure that all stakeholders have a clear understanding of the system’s functionalities and constraints. Effective requirements modelling can help to identify potential issues early in the development process, which can save time and resources in the long run.  (UML)Unified Modelling Language Introduction UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. UML was created by the Object Management Group (OMG) and UML 1.0 specification draft was proposed to the OMG in January 1997. OMG is continuously making efforts to create a truly industry standard.  (UML)Unified Modelling Language Introduction UML stands for Unified Modeling Language. UML is different from the other common programming languages such as C++, Java, COBOL, etc. UML is a pictorial language used to make software blueprints. UML can be described as a general purpose visual modeling language to visualize, specify, construct, and document software system. Although UML is generally used to model software systems, it is not limited within this boundary. It is also used to model non-software systems as well. For example, the process flow in a manufacturing unit, etc.  (UML)Unified Modelling Language Goals of UML A picture is worth a thousand words, this idiom absolutely fits describing UML. It’s a pictorial language used to make software blueprints. There are a number of goals for developing UML but the most important is to define some general purpose modeling language, which all modelers can use and it also needs to be made simple to understand and use. UML diagrams are not only made for developers but also for business users, common people, and anybody interested to understand the system. In conclusion, the goal of UML can be defined as a simple modeling mechanism to model all possible practical systems in today’s complex environment.  (UML)Unified Modelling Language A Conceptual Model of UML A conceptual model can be defined as a model which is made of concepts and their relationships. A conceptual model is the first step before drawing a UML diagram. It helps to understand the entities in the real world and how they interact with each other. As UML describes the real-time systems, it is very important to make a conceptual model and then proceed gradually. The conceptual model of UML can be mastered by learning the following three major elements − UML building blocks Rules to connect the building blocks Common mechanisms of UML  (UML)Unified Modelling Language UML building blocks. The building blocks of UML can be defined as − Things Relationships Diagrams Things are the most important building blocks of UML. Things can be − Structural Behavioral Grouping Annotational  (UML)Unified Modelling Language Structural Things Structural things define the static part of the model. They represent the physical and conceptual elements. Following are the brief descriptions of the structural things. Class − Class represents a set of objects having similar responsibilities. Interface − Interface defines a set of operations, which specify the responsibility of a class. Collaboration −Collaboration defines an interaction between elements.  (UML)Unified Modelling Language Use case −Use case represents a set of actions performed by a system for a specific goal. Component −Component describes the physical part of a system. Node − A node can be defined as a physical element that exists at run time.  (UML)Unified Modelling Language Behavioral Things A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral things − Interaction − Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task. State machine − State machine is useful when the state of an object in its life cycle is important. It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change  (UML)Unified Modelling Language Grouping Things Grouping things can be defined as a mechanism to group elements of a UML model together. There is only one grouping thing available − Package − Package is the only one grouping thing available for gathering structural and behavioral things. Annotational Things Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments of UML model elements. Note - It is the only one Annotational thing available. A note is used to render comments, constraints, etc. of an UML element.  (UML)Unified Modelling Language Relationship Relationship is another most important building block of UML. It shows how the elements are associated with each other and this association describes the functionality of an application. There are four kinds of relationships available. Dependency Dependency is a relationship between two things in which change in one element also affects the other. Association Association is basically a set of links that connects the elements of a UML model. It also describes how many objects are taking part in that relationship.  (UML)Unified Modelling Language Generalization Generalization can be defined as a relationship which connects a specialized element with a generalized element. It basically describes the inheritance relationship in the world of objects. Realization Realization can be defined as a relationship in which two elements are connected. One element describes some responsibility, which is not implemented and the other one implements them. This relationship exists in case of interfaces.  UML Diagrams UML diagrams are the ultimate output of the entire discussion. All the elements, relationships are used to make a complete UML diagram and the diagram represents a system. The visual effect of the UML diagram is the most important part of the entire process. All the other elements are used to make it complete. UML includes the following nine diagrams  UML Diagrams Use case diagram Class diagram Object diagram Sequence diagram Collaboration diagram Activity diagram State chart diagram Deployment diagram Component diagram  UML Diagrams Use Case Diagram in UML A Use Case Diagram is a type of Unified Modeling Language (UML) diagram that represents the interaction between actors (users or external systems) and a system under consideration to accomplish specific goals. It provides a high-level view of the system’s functionality by illustrating the various ways users can interact with it. Use Case Diagram Notations  UML Diagrams Use Case Diagram Notations UML notations provide a visual language that enables software developers, designers, and other stakeholders to communicate and document system designs, architectures, and behaviors in a consistent and understandable manner. Actors Actors are external entities that interact with the system. These can include users, other systems, or hardware devices. In the context of a Use Case Diagram, actors initiate use cases and receive the outcomes. Proper identification and understanding of actors are crucial for accurately modeling system behavior.  UML Diagrams Use Cases Use cases are like scenes in the play. They represent specific things your system can do. In the online shopping system, examples of use cases could be “Place Order,” “Track Delivery,” or “Update Product Information”. Use cases are represented by ovals.  UML Diagrams Use Cases Use cases are like scenes in the play. They represent specific things your system can do. In the online shopping system, examples of use cases could be “Place Order,” “Track Delivery,” or “Update Product Information”. Use cases are represented by ovals. System Boundary UML Diagrams The system boundary is a visual representation of the scope or limits of the system you are modeling. It defines what is inside the system and what is outside. The boundary helps to establish a clear distinction between the elements that are part of the system and those that are external to it. The system boundary is typically represented by a rectangular box that surrounds all the use cases of the system. Purpose of System Boundary: Scope Definition: It clearly outlines the boundaries of the system, indicating which components are internal to the system and which are external actors or entities interacting with the system. Focus on Relevance: The diagram can focus on illustrating the essential functionalities provided by the system without unnecessary details about external entities. Use Case Diagram Relationships UML Diagrams n a Use Case Diagram, relationships play a crucial role in depicting the interactions between actors and use cases. These relationships provide a comprehensive view of the system’s functionality and its various scenarios. Association Relationship The Association Relationship represents a communication or interaction between an actor and a use case. It is depicted by a line connecting the actor to the use case. This relationship signifies that the actor is involved in the functionality described by the use case. Example: Online Banking System 1. Actor: Customer 2. Use Case: Transfer Funds 3. Association: A line connecting the “Customer” actor to the “Transfer Funds” use case, indicating the customer’s involvement in the funds transfer process.  UML Diagrams Example: Online Banking System 1. Actor: Customer 2. Use Case: Transfer Funds 3. Association: A line connecting the “Customer” actor to the “Transfer Funds” use case, indicating the customer’s involvement in the funds transfer process. Include Relationship UML Diagrams The Include Relationship indicates that a use case includes the functionality of another use case. It is denoted by a dashed arrow pointing from the including use case to the included use case. This relationship promotes modular and reusable design. Example: Social Media Posting Use Cases: Compose Post, Add Image Include Relationship: The “Compose Post” use case includes the functionality of “Add Image.” Therefore, composing a post includes the action of adding an image. Extend Relationship UML Diagrams The Extend Relationship illustrates that a use case can be extended by another use case under specific conditions. It is represented by a dashed arrow with the keyword “extend.” This relationship is useful for handling optional or exceptional behavior. Example: Social Media Posting Example: Flight Booking System UML Diagrams Use Cases: Book Flight, Select Seat Extend Relationship: The “Select Seat” use case may extend the “Book Flight” use case when the user wants to choose a specific seat, but it is an optional step. Generalization Relationship UML Diagrams The Generalization Relationship establishes an “is-a” connection between two use cases, indicating that one use case is a specialized version of another. It is represented by an arrow pointing from the specialized use case to the general use case. Example: Vehicle Rental System Use Cases: Rent Car, Rent Bike Generalization Relationship: Both “Rent Car” and “Rent Bike” are specialized versions of the general use case “Rent Vehicle.”  UML Diagrams Class Diagram In object-oriented programming (OOP), a class is a blueprint or template for creating objects. Objects are instances of classes, and each class defines a set of attributes (data members) and methods (functions or procedures) that the objects created from that class will possess. The attributes represent the characteristics or properties of the object, while the methods define the behaviors or actions that the object can perform.  UML Class Notation UML Diagrams class notation is a graphical representation used to depict classes and their relationships in object-oriented modeling.  UML Diagrams UML Class Notation 1. Class Name: The name of the class is typically written in the top compartment of the class box and is centered and bold. 2. Attributes: Attributes, also known as properties or fields, represent the data members of the class. They are listed in the second compartment of the class box and often include the visibility (e.g., public, private) and the data type of each attribute. 3. Methods, also known as functions or operations, represent the behavior or functionality of the class. They are listed in the third compartment of the class box and include the visibility (e.g., public, private), return type, and parameters of each method.  UML Diagrams 4. Visibility Notation: Visibility notations indicate the access level of attributes and methods. Common visibility notations include: + for public (visible to all classes) - for private (visible only within the class) # for protected (visible to subclasses) ~ for package or default visibility (visible to classes in the same package) 5. Parameter Directionality: In class diagrams, parameter directionality refers to the indication of the flow of information between classes through method parameters. It helps to specify whether a parameter is an input, an output, or both. This information is crucial for understanding how data is passed between objects during method calls.  UML Diagrams There are three main parameter directionality notations used in class diagrams: In (Input): An input parameter is a parameter passed from the calling object (client) to the called object (server) during a method invocation. It is represented by an arrow pointing towards the receiving class (the class that owns the method). Out (Output): An output parameter is a parameter passed from the called object (server) back to the calling object (client) after the method execution. It is represented by an arrow pointing away from the receiving class.  UML Diagrams InOut (Input and Output): An InOut parameter serves as both input and output. It carries information from the calling object to the called object and vice versa. It is represented by an arrow pointing towards and away from the receiving class.Out (Output):  UML Diagrams Relationships between classes: In class diagrams, relationships between classes describe how classes are connected or interact with each other within a system. There are several types of relationships in object-oriented modeling, each serving a specific purpose. Here are some common types of relationships in class diagrams:  UML Diagrams 1. Association: An association represents a bi-directional relationship between two classes. It indicates that instances of one class are connected to instances of another class. Associations are typically depicted as a solid line connecting the classes, with optional arrows indicating the direction of the relationship. The “Library” class can be considered the source class because it contains a reference to multiple instances of the “Book” class. The “Book” class would be considered the target class because it belongs to a specific library.  UML Diagrams 2. Directed Association: A directed association in a UML class diagram represents a relationship between two classes where the association has a direction, indicating that one class is associated with another in a specific way. In a directed association, an arrowhead is added to the association line to indicate the direction of the relationship. The arrow points from the class that initiates the association to the class that is being targeted or affected by the association. Directed associations are used when the association has a specific flow or directionality, such as indicating which class is responsible for initiating the association or which class has a dependency on another.  UML Diagrams Consider a scenario where a “Teacher” class is associated with a “Course” class in a university system. The directed association arrow may point from the “Teacher” class to the “Course” class, indicating that a teacher is associated with or teaches a specific course. The source class is the “Teacher” class. The “Teacher” class initiates the association by teaching a specific course. The target class is the “Course” class. The “Course” class is affected by the association as it is being taught by a specific teacher.  UML Diagrams Consider a scenario where a “Teacher” class is associated with a “Course” class in a university system. The directed association arrow may point from the “Teacher” class to the “Course” class, indicating that a teacher is associated with or teaches a specific course.  UML Diagrams 3. Aggregation Aggregation is a specialized form of association that represents a “whole-part” relationship. It denotes a stronger relationship where one class (the whole) contains or is composed of another class (the part). Aggregation is represented by a diamond shape on the side of the whole class. In this kind of relationship, the child class can exist independently of its parent class. Let’s understand aggregation using an example: The company can be considered as the whole, while the employees are the parts. Employees belong to the company, and the company can have multiple employees. However, if the company ceases to exist, the employees can still exist independently. UML Diagrams  UML Diagrams 4. Composition Composition is a stronger form of aggregation, indicating a more significant ownership or dependency relationship. In composition, the part class cannot exist independently of the whole class. Composition is represented by a filled diamond shape on the side of the whole class. Let’s understand Composition using an example: Imagine a digital contact book application. The contact book is the whole, and each contact entry is a part. Each contact entry is fully owned and managed by the contact book. If the contact book is deleted or destroyed, all associated contact entries are also removed.  UML Diagrams This illustrates composition because the existence of the contact entries depends entirely on the presence of the contact book. Without the contact book, the individual contact entries lose their meaning and cannot exist on their own.  UML Diagrams 5. Generalization(Inheritance) Inheritance represents an “is-a” relationship between classes, where one class (the subclass or child) inherits the properties and behaviors of another class (the superclass or parent). Inheritance is depicted by a solid line with a closed, hollow arrowhead pointing from the subclass to the superclass. In the example of bank accounts, we can use generalization to represent different types of accounts such as current accounts, savings accounts, and credit accounts.  UML Diagrams The Bank Account class serves as the generalized representation of all types of bank accounts, while the subclasses (Current Account, Savings Account, Credit Account) represent specialized versions that inherit and extend the functionality of the base class.  UML Diagrams 6. Realization (Interface Implementation) Realization indicates that a class implements the features of an interface. It is often used in cases where a class realizes the operations defined by an interface. Realization is depicted by a dashed line with an open arrowhead pointing from the implementing class to the interface. Let’s consider the scenario where a “Person” and a “Corporation” both realizing an “Owner” interface. Owner Interface: This interface now includes methods such as “acquire(property)” and “dispose(property)” to represent actions related to acquiring and disposing of property.  UML Diagrams Person Class (Realization): The Person class implements the Owner interface, providing concrete implementations for the “acquire(property)” and “dispose(property)” methods. For instance, a person can acquire ownership of a house or dispose of a car. Corporation Class (Realization): Similarly, the Corporation class also implements the Owner interface, offering specific implementations for the “acquire(property)” and “dispose(property)” methods. For example, a corporation can acquire ownership of real estate properties or dispose of company vehicles.  UML Diagrams Both the Person and Corporation classes realize the Owner interface, meaning they provide concrete implementations for the “acquire(property)” and “dispose(property)” methods defined in the interface.  UML Diagrams 7. Dependency Relationship A dependency exists between two classes when one class relies on another, but the relationship is not as strong as association or inheritance. It represents a more loosely coupled connection between classes. Dependencies are often depicted as a dashed arrow. Let’s consider a scenario where a Person depends on a Book. Person Class: Represents an individual who reads a book. The Person class depends on the Book class to access and read the content. Book Class: Represents a book that contains content to be read by a person. The Book class is independent and can exist without the Person class.  UML Diagrams The Person class depends on the Book class because it requires access to a book to read its content. However, the Book class does not depend on the Person class; it can exist independently and does not rely on the Person class for its functionality.  UML Diagrams State Machine Diagram A state diagram is used to represent the condition of the system or part of the system at finite instances of time. It’s a behavioral diagram and it represents the behavior using finite state transitions. State Machine diagrams are also referred to as State Machines Diagrams and State-Chart Diagrams. These terms are often used interchangeably. So simply, a state machine diagram is used to model the dynamic behavior of a class in response to time and changing external entities. We can say that each and every class has a state but we don’t model every class using State Machine diagrams. We prefer to model the states with three or more states.  UML Diagrams State Machine Diagram A state diagram is used to represent the condition of the system or part of the system at finite instances of time. It’s a behavioral diagram and it represents the behavior using finite state transitions. UML Diagrams State Machine Diagram  UML Diagrams Activity Diagram Activity Diagrams are used to illustrate the flow of control in a system and refer to the steps involved in the execution of a use case. We can depict both sequential processing and concurrent processing of activities using an activity diagram ie an activity diagram focuses on the condition of flow and the sequence in which it happens. We describe what causes a particular event using an activity diagram. An activity diagram portrays the control flow from a start point to a finish point showing the various decision paths that exist while the activity is being executed. They are used in business and process modeling where their primary use is to depict the dynamic aspects of a system.  UML Diagrams Activity Diagram Activity Diagram Notations  UML Diagrams Activity Diagram Activity Diagram Notations  UML Diagrams Sequence Diagram The sequence diagram represents the flow of messages in the system and is also termed as an event diagram. It helps in envisioning several dynamic scenarios. It portrays the communication between any two lifelines as a time-ordered sequence of events, such that these lifelines took part at the run time. In UML, the lifeline is represented by a vertical bar, whereas the message flow is represented by a vertical dotted line that extends across the bottom of the page. It incorporates the iterations as well as branching.  UML Diagrams Purpose of a Sequence Diagram To model high-level interaction among active objects within a system. To model interaction among objects inside a collaboration realizing a use case. It either models generic interactions or some certain instances of interaction. Notations of a Sequence Diagram Lifeline An individual participant in the sequence diagram is represented by a lifeline. It is positioned at the top of the diagram