Software Engineering 1 CS 1131 1st Semester 2024-2025 PDF

CS 1131 SOFTWARE ENGINEERING 1 1 st Semester, SY 2024-2025 BELEN M. TAPADO, DIT Professor VI CHAPTER 4 Software Modeling Lesson Outline Data Flow Structured HIPO UML Use Case Modeling Diagram Charts Diagram Modeling Diagram Le...

CS 1131 SOFTWARE ENGINEERING 1 1 st Semester, SY 2024-2025 BELEN M. TAPADO, DIT Professor VI CHAPTER 4 Software Modeling Lesson Outline Data Flow Structured HIPO UML Use Case Modeling Diagram Charts Diagram Modeling Diagram Lesson Objectives explain the process of creating software models using the different software modeling tools such as DFD, UML, etc create an appropriate diagram that accurately models a system to develop Key Concepts and Terms Data Flow Data Condition Control Flow Data Flow Diagram Entity Storage (DFD) HIPO Chart Jump Level 0 DFD Level 1 DFD Level 2 DFD Logical DFD Physical Loop Modeling Module Process Sink DFD Unified Structured Source Modeling Use Case Charts Language LESSON 1 MODELING Modeling We build We build models of models so complex that we can system A model is a Models can better because we simplification be informal understand cannot of reality. or formal. the system comprehend we are such a developing. system in its entirety. Characteristics of Modeling Tools To identifying inconsistencies and defects within the model. To help in identifying and prioritizing areas of the model for testing. To predict system response and behavior under various situations, such as level of load Principles of Modeling The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped. Every model can be expressed at different levels of precision. The best models are connected to reality. No single model is enough. Every nontrivial system is best approached through a small set of nearly independent models LESSON 2 DATA FLOW DIAGRAM Context Diagram Context Diagram How to Construct Context Diagram How to Construct Context Diagram (2) How to Construct Context Diagram (3)  Data flow diagram is graphical representation of flow of data in an information system. It can depict incoming data flow, outgoing data flow and stored data. The DFD does not mention anything about how data flows through the system. Data Data flow diagram (DFD) is a picture of the movement of Flow data between external entities and the processes and data stores within a system. Diagram There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of control in program modules. DFDs depict flow of data in the system at various levels. DFD does not contain any control or branch elements.  Types of Data Flow Diagram Logical DFD - This type of DFD concentrates on the system process, and flow of data in the system. Example: in a Banking software system, how data is moved between different entities. Physical DFD - This type of DFD shows how the data flow is implemented in the system. It is more specific and closer to the implementation. Data Flow Diagram Components Flow of Source Destination Storage data  Entities Entities are source and destination of information data. Entities are represented by a rectangle with their respective names. External entity that is origin or destination of data (outside the system) Is the singular form of a department, outside organization, other IS, or person Labels should be noun phrases Source - Entity that supplies data to the system Sink - Entity that receives data from the Rule: Must be connected to a process by a data flow system Process Activities and action taken on the data are represented by Circle or Round-edged rectangles. Work or actions performed on data (inside the system) Labels should be verb phrases Receives input data and produces output Example: Data Storage There are two variants of data storage - it can either be represented as a rectangle with absence of both smaller sides or as an open-sided rectangle with only one side missing. Is used in a DFD to represent data that the system stores Labels should be noun phrases Rule: Must have at least one incoming and one outgoing data flow Data Flow ◦ Movement of data is shown by pointed arrows. Data movement is shown from the base of arrow as its source towards head of the arrow as destination. ◦ Is a path for data to move from one part of the IS to another ◦ Arrows depicting movement of data ◦ Can represent flow between process and data store by two separate arrows Example: Levels of DFD Context Diagram Level 1 Level 2 Level 0 Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the entire information system as one diagram concealing all the underlying details. Level 0 DFDs are also known as Context Level DFDs Level 1 The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1 DFD depicts basic modules in the system and flow of data among various modules. Level 1 DFD also mentions basic processes and sources of information Level 2 ◦ At this level, DFD shows how data flows inside the modules mentioned in Level 1. ◦ Higher level DFDs can be transformed into more specific lower level DFDs with LESSON 3 STRUCTURED CHARTS Structured Charts Structure chart is a chart derived from Data Flow Diagram. It represents the system in more detail than DFD. It breaks down the entire system into lowest functional modules, describes functions and sub-functions of each module of the system to a greater detail than DFD. Structure chart represents hierarchical structure of modules. At each layer a specific task is performed. Symbols used in Structured Charts Modules Conditions Jump Control Loop Data Flow Flow Module It represents process or subroutine or task. A control module branches to more than one sub-module. Library Modules are re-usable and invokable from any module. Condition It is represented by small diamond at the base of module. It depicts that control module can select any of sub-routine based on some condition. Jump An arrow is shown pointing inside the module to depict that the control will jump in the middle of the sub- module Loop A curved arrow represents loop in the module. All sub-modules covered by loop repeat execution of module. Data Flow ◦ A directed arrow with empty circle at the end represents data flow. Control Flow A directed arrow with filled circle at the end represents control flow. LESSON 4 HIPO Diagram HIPO Diagram HIPO (Hierarchical Input Process Output) diagram is a combination of two organized method to analyze the system and provide the means of documentation. HIPO model was developed by IBM in year 1970. HIPO diagram represents the hierarchy of modules in the software system. Analyst uses HIPO diagram in order to obtain high-level view of system functions. It decomposes functions into sub-functions in a hierarchical manner. It depicts the functions performed by system. HIPO diagrams are good for documentation purpose. Their graphical representation makes it easier for designers and managers to get the pictorial idea of the system structure.  In contrast to IPO (Input Process Output) diagram, which depicts the flow of control and data in a module, HIPO does not provide any information about data flow or control flow. Example: Both parts of HIPO diagram, Hierarchical presentation and IPO Chart are used for structure design of software program as well as documentation of the same.  LESSON 5 Unified Modeling Language (UML) Unified Modeling Language (UML) Language and notation for specification, construction, visualization and documentation of models of software systems. Provides the mechanisms for creating detailed models that portray a system’s design. Developed by Grady Booch, Ivar Jacobson, James Rumbaugh Reasons for studying UML UML enhances: system analysis specification communications UML Models… behavioral implementation class diagrams diagrams diagrams UML is… language process syntax only comprehensive Independent Independent not well understood used originally for tool Independent well-documented when applied system modeling UML Building Blocks Enhancing Classifiers Relationships Features Classifiers… are structural things that represent conceptual or physical elements of a model. are typically the main elements of UML models and each type of UML diagram has a specific type of classifiers so that not all classifiers are relevant to all UML diagrams. provide designers the capability of defining the structure for achieving some desired system features. allows designers to visualize the structural design of systems, provide analysis, and make design improvements, all the design time. The usefulness of modeling classifiers (and their behavioral counterparts) is maximized when defining and visualizing the interconnections that exist among them  Common UML Classifiers Classifier Description Use Case Models a single required system behavior; represented with icons of elliptical shape. Component Represents a modular and irreplaceable part of the system; modeled using a box with the keyword and optional component icon on the top right corner. Class Models a type in terms of operation, attributes, relationships and other semantics modeled with a rectangular box. Active Class Models a class that owns an independent flow of execution and can initiate control activity; model as a class with double lines on each side. Interface Models a set of operations that specify the services provided by a class or component; represented a stereotyped class or using the ball and socket notations. Node Models a physical element (e.g. computer), its processing capabilities, and other semantics; model using a cube. Artifact Models a physical deployable information element (e.g..exe,.dll, script, etc.); modeled using a rectangle with a keyword. Common UML Relationships Relationships Description Dependency Dashed lines (typically directed with a stick arrow) used to model the relationship between two UML elements indicating that changes to one element affect the other. Association Line used to model the relationship between two UML elements indicating that a connection exists between associated instances at run time; association can be directed using a stick arrow. Generalization Line with a hollow arrowhead used to model the relationship between two UML elements indicating that one element (i.e. a child) inherits features from another (i.e. parent) Realization Relationship between two UML elements indicating that one element realizes a specified interface; modeled using a dashed line with hollow arrowhead. Common UML Mechanism for Enhancement Mechanism Description Notes Mechanism for adding directive information to UML elements and diagrams, modeled using a rectangle with a dog-eared corner and can be connected to a design element using a dashed line. Stereotype Mechanism for extending UML by adding information that gives existing UML element a different meaning, therefore creating a semantically different element for modeling application-specific concepts, modeled as existing UML element with the mechanism (e.g. Tagged Values Mechanism for adding new properties to a stereotype; modeled by adding the tagged value in the form of property = value to existing stereotyped UML elements (e.g. data rate = 5 Mbps) Constraints Mechanism for specifying constraints to design elements; associated with specific design elements in the form of {constraint description} (e.g. {secure line} Structured Diagrams Diagram Description Component High-level; used to model the software as group of components connected to each other through well-defined interfaces and thus to be replaceable within the context Class Used to model software as a set of classes, including their operations, attributes and their mutual relationships. Object Used to model an instant snapshot of the life of an object during execution, including its state and attribute values Deployment Used to model the physical realization of software systems, including physical nodes where software is deployed, interfaces between nodes software artifacts executing on nodes, and the manifestation of software components within the software artifacts. Package Diagram Diagram used to model the division of software as a set of packages, including the relationship between packages. UML… defines thirteen types of diagrams is divided into three categories has six (6) diagram types that represent static application structure. has three (3) diagram types that represent general types of behavior. has four (4) diagram types that represent different aspects of interactions LESSON 6 Use Case Diagram Eliciting functional requirements can rely on the construction of a use case-based requirements. Overview Use case diagrams are used to visualize, specify, construct, and document the (intended) behavior of the system, during requirements capture and analysis. A use case diagram is an excellent way to communicate to management, customers, and other non-development people what a system will do when it is completed. It serves as basis for testing. Use case diagrams contain use cases, actors, and their relationships. Use cases were defined by Ivar Jacobson in 1992 and have since become an integral part of UML. Use Case USE CASE: A TEXT IT IS WRITTEN USE CASES ARE THE USE CASES HELP US STORY OF WHAT A DESCRIPTIONS OF WAYS IN WHICH A DISCOVER/DOCUME SYSTEM DOES TO USER'S INTERACTION SYSTEM CAN BE NT REQUIREMENTS COMPLETE ONE WITH THE SOFTWARE USED (THE SPECIFIC GOAL. PRODUCT TO FUNCTIONS WHICH ACCOMPLISH A THE SYSTEM GOAL PROVIDES TO ITS USERS) Each use case has: Clear value – it must help the actor or Use Case user to achieve a certain goal. Start and Stop – something begins and ends the process. External Initiator – there should be an external initiator to start out a use case. Name – it starts with a verb. UML Use Case Diagram Symbols Use Case Name Actor Boundary Connection Include Relationship Extend Relationship Use Case Diagram/Model ◦ It contains the following: Actors Use Cases Boundary Connection Relationship Use Case Diagram Symbols Use Case Actor Boundary Connection Use Case Diagram Actors (stick men) are anything outside the system that interacts with the system. Use Cases (ellipses) are the procedures by which the actors interact with the system. A use case is shown as an ellipse, with a name inside identifying the use case. Solid lines indicate which actors interact with the system as part of which procedures.  ACTORS Use Case Modelling What is an Actor? Actor Name ◦ An actor is represented by a stickman with a unique actor name next to it. ◦ Actor is an external entity that interacts with the system and expects some useful results. ◦ Most actors represent user roles, but actors can also be external systems. ◦ An actor is a role, not a specific user; one user may play many roles, and an actor may represent many users. ◦ Different results are expected when actors are interacting with different use cases of the system. What is an Actor(2) Actor Name ◦ Actors can be human or automated systems. ◦ Actors are entities which require help from the system to perform their task or are needed to execute the system’s functions. ◦ Actors are not part of the system. 81 BOUNDARY Use Case Modelling System Boundary ▪ Marks off the system as separate from its environment ▪ Actors are outside ▪ Use cases are within the boundary. CONNECTION Use Case Modelling Connection ◦ Lines between Actor and Use Case summarize interactions graphically ◦ Actors and use cases exchange information to achieve the goal but the details of interaction are not shown ◦ A connection is an association between an actor and a use case. ◦ It depicts a usage relationship USE CASES Use Case Modelling Use Case ▪ It is a text story of what a system does to complete one specific goal. ▪ A use case achieves a goal of value to an actor ▪ It starts with an active verb from the point of view of the system USE CASES & ACTORS Use Case Modelling Use Cases & Actors ◦ From the perspective of a given actor, a use case does something that is of value to the actor, such as calculate a result or change the state of an object. 89 Use Cases and Actors(2) ◦ Actors may be connected to use cases by associations, indicating that the actor and the use case communicate with one another using messages. updating grades faculty 90 Use Cases & Actors(3) ▪ When an actor is involved in a use case, a line is drawn from the actor to the use case. We say that the actor communicates with the use case. Who is initiating the communication can be indicated by an arrowhead use case use case use case actor actor actor Both actor and use case The actor initiate the The use case initiate can initiate the communication. communication. the communication. USE CASE MODEL Use Case Modelling  What Is a Use-Case Model? View ◦ It is a model that describes a Report Card system’s functional requirements in terms of use cases. ◦ A model of the system’s intended Register for Courses functionality (use cases) and its environment (actors). Student Login Example1: Use Case Diagram ▪A cashier uses the POS system to scan an item. ▪A cashier uses the POS system to total items. Example2: Use Case Diagram register for a course update grades student faculty generate output 95  Example3: Use Case Diagram register as student admin register for course student instructor register for exam work with course lab System Boundary make/edit course lecturer RELATIONSHIP BETWEEN USE CASES Use Case Modelling Relationships Between Use Cases 1. Generalization - use cases that are specialized versions of other use cases. 2. Include - use cases that are included as parts of other use cases. It enables to factor common behavior. 3. Extend - use cases that extend the behavior of other core use cases. Enable to factor variants. 98 1. Generalization ◦ The child use case inherits the parent behavior and meaning of the parent use case. ◦ The child may add to or child override the behavior of its parent. 99 Relationships between Actors ◦Generalization. student graduate non-graduate student student 100 More about Generalization registration non-graduate graduate registration registration 101 2. Include base included ◦ The base use case explicitly incorporates the behavior of another use case at a location specified in the base. ◦ The included use case never stands alone. It only occurs as a part of some larger base that includes it. 102 More about Include ◦ Enables to avoid describing the same flow of events several times by putting the common behavior in a use case of its own. updating grades verifying student id output generating 103 Example: Using Include Relationship 3. Extend base extend ◦ The base use case implicitly incorporates the behavior of another use case at certain points called extension points. ◦ The base use case may stand alone, but under certain conditions its behavior may be extended by the behavior of another use case. 105 What is an Relationship? ◦ A connection between two use cases ◦ Extends a use case by adding new behavior or actions ◦ Specialized use case extends the general use case More about Extend ◦ Enables to model optional behavior or branching under conditions. Exam copy request Exam-grade appeal 107 Example: Using Extend Relationship Example: Using Extend Relationship(2) place place conference phone call call cellular network receive receive additional phone call call use user scheduler Cellular Telephone 109 How to Write Use Case Diagram? ◦ Step1: Identify the Actors list down all the nouns or noun phrases that appear in the description. These nouns or noun phases must be analyzed carefully and must be dropped if they do not meet the criteria of being the actor. ◦ Step2:Identify the use cases ◦ Step3: Construct Use Case Model ◦ Step4: Identify Use Case sequence of actions ◦ Step 5: Identify Use Case dependencies ◦ Step6: Write the use case description Step 1: Identify Actors ◦ When looking for actors, ask the following questions: Who or what provides inputs to the system? Who or what receives outputs from the system? Are interfaces required to other systems? Are there events that are automatically triggered at a predetermined time? Who will maintain information in the system? ◦ Actors should be named with a noun or noun phrase Step 2: Identify Use Cases ◦ When looking for use cases, ask the following questions: What are the main tasks of the actor? What information does the actor need form the system? What information does the actor provide to the system? Does the system need to inform the actor of any changes or events that have occurred? Does the actor need to inform the system of any changes or events that have occurred? ◦ Use cases should be named with a verb phrase specifying the goal of the actor (i.e. Submit Subscription Order) Suggested Readings Lodhi, F. (n.d.). CS504-Software Engineering – I Lecture Notes. Retrieved from genrica.com › vustuff › CS504: Behera, H. S., & Sahu, K. K. (n.d.). Lecture Notes on Software Engineering - Course Code: BCS-306. Retrieved from www.vssut.ac.in › lecture_notes › lecture1428551142: https://www.vssut.ac.in/lecture_notes/lecture1428551142.pdf Software Engineering Course Lecture Slides. (2018, January 18). Retrieved from Software Engineering Textbook. Software Engineering Tutorial. https://www.tutorialspoint.com/software_engineering/index.htm