Software Modeling and Analysis

Section

• General

  • Course Leader Details Forum

                                                                       
    
    

    
    

    Ms. Noor Zuhaili bt Md Yasin

    Master in Computer Science (Software Engineering), Universiti Putra Malaysia

    Field of study: Software Engineering, Programming, Knowledge Management (Ontology)

    : zuhaili@nilai.edu.my

    S222, Science Block (School of Computing, FEST)

    : 012 3634344

    Thursday (10-12pm), Friday (8-10am)

    
    
  • 
    

    
    

    Topic 1	Requirement Analysis and Specification
    	1.1	Understanding the business, the organization and its system
    	1.2	Specifying Requirements
    	1.3	List and describe the contents of the Requirements Specification
    	Summary
    Topic 2	Types of Requirement
    	2.1	Distinguish between the different types of user requirements including functional, non-functional and constraints (or pseudo requirements)
    	2.2	List and describe the techniques used by the analyst to elicit requirements from different users
    	2.3	Interview
    	2.4	Questionnaire
    	2.5	Observation
    	2.6	Document Reading
    	2.7	Requirement Specification and Validation
    	2.8	Explain how modelling the required system in the analysis of requirement
    	Summary
    Topic 3	Requirement Model
    	3.1	Explain the value of use case diagram, as a tool for doing Functional Requirement Analysis
    	3.2	Draw use case diagram
    	3.3	Write use case description
    	3.4	Data dictionary
    	Summary

    
    

    Topic 4	Object Oriented Technology
    	4.1	Describe some of the fundamental concepts of Object Orientation
    	4.2	Explain the difficulties inherent in moving from the use case diagram to written code and how sequence diagram may aid this process
    	Summary
    Topic 5	Scenario Analysis
    	5.1	Describe business process and the interaction of an information system with its environment
    	5.2	Draw activity diagram
    Topic 6	Construction of OO Structural Model
    	6.1	Identification of objects and classes
    	6.2	Draw class diagram
    	6.3	Interaction diagram and state diagram
    	Summary

    
    

    
    

                                                                                       
    

    Kindly refer to the attached links to download "points to note " and cover page.

    1.  https://drive.google.com/file/d/1VCkzl6n1_u79t3Dvw94ut-F0HMoheBJS/view?usp=share_link

    2. https://drive.google.com/file/d/11QHdYjYXW9kui3agRj8ls-DGMp_O6I4-/view?usp=share_link

    
    

    INTRODUCTION TO THE COURSE

    Hi!  Welcome to OEC3114 (Software Modelling and Analysis) Class.

    This course introduces the principles, methods and techniques for the development of automated information systems.  The course will cover the analysis stage and will use Object Oriented techniques to develop an application.

    
    

    CONTINUOUS ASSESSMENT SCHEDULE

    This course is assessed by both coursework and examination.

    
    NZMY~
    

    Mark as done
• 

  Open allClose all

  
• 

  Instructions: Clicking on the section name will show / hide the section.

  

• TOPIC 1- REQUIREMENT ENGINEERING AND SPECIFICATION

  LEARNING OUTCOMES

  By the end of this topics, you will be able to:

  1.      Define the Requirement Engineering

  2.      Describe the Requirement specification

  3.      Discuss the content of requirement specification

   

  1.1 Understanding the business, the organization and its system

  In this part, we first introduce the role of the systems analyst in information systems development projects. We discuss the wide range of skills needed to be successful in this role, and we explain various specialties that systems analysts may develop. We then introduce the basic SDLC that information systems projects follow. This life cycle is common to all projects and serves as a framework for understanding how information systems projects are accomplished. We discuss how projects are identified and initiated within an organization and how they are initially described in a system request.

  As organizations and technology have become more complex, most large organizations now build project teams that incorporate several analysts with different, but complementary, roles. In smaller organizations, one person may play several of these roles. Here we briefly describe these roles and how they contribute to a systems development project. The systems analyst role focuses on the IS issues surrounding the system. This person develops ideas and suggestions for ways that IT can support and improve business processes, helps design new business processes supported by IT, designs the new information system, and ensures that all IS standards are maintained. The systems analyst will have significant training and experience in analysis and design and in programming.

  
  SUMMARY
  
  Requirements engineering is the discipline that involves establishing and documenting requirements. The various activities associated with requirements engineering are elicitation, specification, analysis, verification and validation, and management.
  
                                                                                   
  
                                                                                   
  
                                                                                       
  
                                                    
  

  • Video lecture- Topic 1 (Duration: 1 hour) File

    View

    
    

     

     

    From this lecture, student be able to define the Requirement Engineering, describe the Requirement specification

    and discuss the content of requirement specification

    
    

    
    

  • Self-Check 1.0 (Duration 1 hour) Forum

    View

    A. Look in the classified section of your local newspaper. What kinds of job opportunities are available forpeople who want analyst positions? Compare and contrast the skills that the ads solicit with the skills that were presented in this chapter.

    B. Think about your ideal analyst position. Write a newspaper ad to hire someone for that position. What requirements would the job have? What skills and experience would be required? How would applicants demonstrate that they have the appropriate skills and experience?

    C. Locate a news article in an IT trade magazine (e.g., Computerworld ) about an organization that is implementing a new computer system. Describe the tangible and intangible values that the organization likely will realize from the new system.

    D. Car dealers have realized how profitable it can be to  sell automobiles by using the Web. Pretend that you work for a local car dealership that is part of a large chain such as CarMax. Create a system request that you might use to develop a Web-based sales system. Remember to list special issues that are relevant to the project.

    
    

  • Kahoot Quiz

    View

                                                             

  • Self-Check 1.1: Case Study (Duration: 1 hour) Forum

    Mark as done

                                           

                               
    

    1. Suppose that you are the analyst charged with developing a new system to help senior managersmake better strategic decisions. What requirements gathering techniques will you use? Describe in detail how you would apply the techniques.

    2. Find a partner and interview each other about what tasks you/they did in the last job held (full-time, part-time, past, or current). If you haven’t worked before, then assume that your job is being a student. Before you do this, develop a brief interview plan. After your partner interviews you, identify the type of interview, interview approach, and types of questions used.

    3. Anne has been given the task of conducting a survey of sales clerks who will be using a new order entry system being developed for a household products catalog company. The goal of the survey to identify the clerks’ opinions on the strengths and weaknesses of the current system. There are about 50 clerks who work in three different cities, so a survey seemed like an ideal way of gathering the needed information from the clerks. Anne developed the questionnaire carefully and pretested it on several sales supervisors who were available at corporate headquarters.

    
    

  • SIM Lecture Note- Topic 1 (Duration: 1 hour) File

    Mark as done
  
• TOPIC 2- TYPES OF REQUIREMENTS

  LEARNING OUTCOMES

  By the end of this topics, you will be able to:

  1. Describe the FR and NFR

  2. Discuss the techniques might be use to elicit requirement

  3. Explain on how to modelling in the requirement analysis

   

  INTRODUCTION

  The analysis phase is so named because the term analysis refers to breaking a whole into its parts with the intent of understanding the parts’ nature, function, and interrelationships. In the context of the SDLC, the outputs of the planning phase (the system request, feasibility study, and project plan), outline the business goals for the new system, define the project’s scope, assess project feasibility, and provide the initial work plan. These planning phase deliverables are the key inputs into the analysis phase. In the analysis phase, the systems analyst works extensively with the business users of the new system to understand their needs from the new system.

  
  

  SUMMARY

  Functional Requirement And Non- Functional Requirement
  

  A requirement is simply a statement of what the system must do or what characteristics it needs to have. During a systems development project, requirements will be created that describe what the business needs (business requirements); what the users need to do (user requirements); what the software should do (functional requirements); characteristics the system should have (nonfunctional requirements); and how the system should be built (system requirements). Although this list of requirement categories may seem intimidating at first, the categories merely reflect the purpose of the requirements and the stage in the SDLC in which they are defined.

                                                                          
  
  
                                                                                      
                                                                                                    Elicitation Techniques
  

  • Topic 2- Video Lecture (Duration: 1 hour) File

    Mark as done

     

    According to this video, student be able to explain functional requirements - the specifications of the product’s functions (features). Simply put, functional requirements define what precisely a software must do and how the system must respond to inputs. Functional requirements define the software's goals, meaning that the software will not work if these requirements are not met'.

  • Self-Check 2.1: Quiz (Duration: 0.5 hour)

    Restricted Not available unless: The activity Topic 2- Video Lecture (Duration: 1 hour) is marked complete

      

                                                       
    

  • Self-Check 2.2 (Duration: 0.5 hour) Quiz

    Mark as done

    SELF CHECK 2.2

     4. Distinguish between business, user, and functional requirements.

     5. Explain what is meant by a functional requirement. What are two types of functional

         requirements? Give two examples of each.

     6. Explain what is meant by a nonfunctional requirement. What are the primary types of  

        Nonfunctional requirements? Give two examples of each. What role do nonfunctional

        requirements play in the project overall?

     7. What is the value of producing a requirements definition and having the project sponsor and key

         users review and approve it?

    
    

  • Self-Check 2.3 and 2.4 (Duration: 1 hour) Quiz

    Mark as done

    SELF CHECK 2.3

     8. What are the three basic steps of the analysis process? Is each step performed in every project?

          Why or why not?

     9. Discuss the appropriate way to set up and conduct interviews to elicit requirements.

    10. Give an example of a closed-ended question, an  open-ended question, and a probing question.

           When would each type of question be used?

    11. “Interviews should always be conducted as structured interviews.” Do you agree with this  

            statement? Why or why not?

     

    SELF CHECK 2.4

    . 12. Why is document analysis useful? What insights into the organization can it provide?

      13. Outline suggestions to make observation a useful, reliable requirements elicitation technique.

      14. Describe a strategy for using the various requirements elicitation techniques in a project.

      15. Discuss problem analysis as an analysis strategy. What are the strengths and limitations of this

            technique?

     

    
    

  • SIM Lecture Note- Topic 2 (Duration 1 hour) File

    Mark as done
  
• TOPIC 3- REQUIREMENT MODEL

  Restricted Not available unless: The activity Self-Check 2.1: Quiz (Duration: 0.5 hour) is marked complete

  LEARNING OUTCOMES

  By the end of this topics, you will be able to:

  1. Explain how to use case as tool

  2. Draw the use case diagram and write use case descriptions

  3. Show the data dictionary

   

  INTRODUCTION

  Chapter 3 discussed the overall process of the analysis phase of the SDLC, resulting in the system proposal deliverable. Within the system proposal is the requirements definition, defining exactly what the new system should do. As we previously discussed, a key aspect of determining the requirements for the new system is understanding the user requirements: the things the users need to accomplish with the new system. In this chapter, we discuss use cases as a means of expressing user requirements. Since one of our goals in the systems development project is to create usable software, it is imperative to know what the users intend to do with it. Use cases help us understand and clarify the users’ required interactions with the system and can reveal most, if not all, functional requirements of the new system. Consequently, use cases are used extensively in the analysis phase when working with the users in interviews or workshop settings as a means of discovering user and functional requirements.

  For many years, traditional requirements elicitation techniques involved asking the users what they wanted the system to do. The systems analysts would sit down with users and try to express what the system should do by drawing process models and data models. This was a challenge for the users for several reasons. First, the users may not know what is and is not possible for the system to do. Users are not likely to truly understand the capabilities and limitations of information systems technologies, especially new advances in technology. Second, users may have difficulty envisioning new ways to redesign business processes. Most of us find creating new ways of doing things to be a challenge because we are so accustomed to things being done the “old way.” Third, it is common for users to describe things they think they want from the new system, but our focus should be on the real needs for the new system. Finally, users often found it difficult to learn the process and data modeling languages used by the analysts.

  Consequently, the concept of the use case has evolved as an important component of determining requirements for the new system. Use cases originated as a part of the object-oriented development world but have been accepted as a useful tool regardless of the development methodology in use. This is not surprising since in any development approach (waterfall, RAD, or agile) we need to hear and understand what the user needs to accomplish with the system.

  Use cases are especially valuable for business system applications and Web sites. Both of these types of systems commonly involve extensive user interactions, so the use case is particularly helpful. Use cases are not as useful in other settings, such as batch processes, computationally intensive applications, or data warehousing. These settings have extensive “internal” complexity but limited user interactions. Therefore, the use case is not necessarily the best tool to use. As always, the analyst needs to be skilled in using a number of tools and must be able to select and apply the appropriate ones for the situation.

  
  

  SUMMARY

  Requirements modeling is the process used in software development projects where requirements and solutions constantly evolve through collaborative efforts and teamwork. By using this method of cross-functional and self-organizing teams, you can ensure that your team meets the exact needs of the stakeholders.

                                 

                                                                                  
  

                                                
  

                                                                           Requirements Management Tools and Software

  
  

   

   
  

  Refer to this video lecture, student be able to explain how to use case as tool, draw the use case diagram and write use case descriptions

  and Show the data dictionary
  
  Duration: 1 hour
  

  
• TOPIC 4- OBJECT ORIENTED TECHNOLOGY

  Restricted Not available unless: The activity Self-Check 3.1: Case Study (Duration: 2 hours) is marked complete

  LEARNING OUTCOMES

  By the end of this topics, you will be able to:

  1.  Describe the fundamental concept of OO

  2. Explain some difficulties in moving to written code

  3. Show on how sequence diagram can aid this matter

   

  INTRODUCTION

  By this point, we have presented the important skills that you will need for a real world systems development project. You can be certain that all projects move through the four phases of planning, analysis, design, and implementation; all projects require you to gather requirements, model the business needs, and create blueprints for how the system should be built; and all projects require an understanding of organizational behavior concepts like change management and team building.
  

  This is true for large and small projects; custom built and packaged; local and global. These underlying skills remain largely unchanged over time, but the actual techniques and approaches that analysts and developers use do change—often dramatically—over time. As we implied in Chapter 1, the field of system analysis and design still has a lot of room for improvement: Projects still run over budget, users often cannot get applications when they need them, and some systems still fail to meet important user needs. Thus, the state of the systems analysis and design field is one of constant transition and continuous improvement. Analysts and developers learn from past mistakes and successes and evolve their practices to incorporate new techniques and new approaches that work better.
  

  
  

  Today, an exciting enhancement to systems analysis and design is the application of the object-oriented approach. The object-oriented approach views a system as a collection of self-contained objects, including both data and processes. As you know, traditional systems analysis and design methodologies are either data-centric or process-centric. (See Chapter 1.) Until the mid-1980s, developers had to keep the data and processes separate in order to build systems that could run on the mainframe computers of that era. Due to the increase in processor power and the decrease in processor cost, object-oriented approaches became feasible. Consequently, developers focused on building systems more efficiently by enabling the analyst to work with a system’s data and processes simultaneously as objects. These objects can be built as individual pieces and then put together to form a system. The beauty of objects is that they can be reused over and over in many different systems and changed without affecting other system components.
  

  
  
  Although some people feel that the move to objects will radically change the field of systems analysis and design and the SDLC, we see the incorporation of objects as an evolving process in which object-oriented techniques are gradually integrated into the mainstream SDLC. Therefore, it is important for you as an analyst to understand what object orientation is and why it is causing such a stir in the industry, as well as to become familiar with some popular object-oriented techniques that you may need to use on projects.
  
  
  

  SUMMARY

  Object-oriented technology (OOT) is a software design model in which objects contain both data and the instructions that work on the data. It is increasingly deployed in distributed computing.
  

                                                                                 
  

                                                                                                Object Oriented Concepts

                                                                                             
  

                                                                            
  

  
  

  
  

                                                                            Figure 4.1: Class Hierarchy and without class

   According to this video lecture you will be able to identify the class and object, encapsulation / information hiding, inheritance and polymorphism.
  
  Duration: 1 hour
  

  
• TOPIC 5- SCENARIO ANALYSIS

  Restricted Not available unless: The activity SIM Lecture Note- Topic 4 (Duration: 6 hours) is marked complete

  LEARNING OUTCOMES

  By the end of this topics, you will be able to:

  1. Discuss the business process and the interaction with its environment based on scenario analysis

  2. Draw an activity diagram

   

  INTRODUCTION

  Generally, scenario is a typical situation in the operation of a system. In term of definitions in the context of requirements engineering refer a story or example of events taken from real world experience. This is an outline with details of scenes or an imagined sequence of future events, which may include details of the system context (scenes). It captured and represented as speech or text narratives and may be embellished with still or moving images to illustrate the context.

  A future vision of a designed system with sequences of behavior and possibly contextual description and a scenario comes close to a design mock up. The scenario can be represented by anything from storyboard sketch to animated sequences in a concept demonstrator. This is the sense in which the OO community use the word scenario.

  
  

  5.1 Process and interaction of an information system with its environment

  There have two types of scenario. First is generic scenario and secondly is concrete scenario. The generic scenario is a sequence of events without detailed data and it representation of a set of particular instances of similar operations of the system shown in figure 5.

  Figure 5: Generic scenario for online shopping

  Concrete scenarios refer to the sequence of events with every detail of data and specific operation of the system as shown in figure 5.1:

  Figure 5.1: Concrete scenario for online shopping

  From the figure, you can see the events are specified clearly with specific operation.

   

  5.1.1 Roles of Scenario in requirement engineering

  In term of functional requirement, we can use a set of scenarios as a model of an existing system and as a specification of requirements. Developing a scenario with a client clarifies many functional requirements that must be agreed before a system can be built, e.g., policies, procedures, etc.

  The scenario will often clarify the requirements for the user interface, but the design of the user interface should not be part of the scenario (refer to figure 5.2). Although this scenario is quite simple, many details have been left out. Once we identify the details scenario, we can link the use case diagram to an activity diagram. This is on how you modelling scenario into the diagram.

  Figure 5.2: Paths of online shopping use case

  5.2 Activity diagram

  Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams are intended to model both computational and organizational processes (i.e., workflows), as well as the data flows intersecting with the related activities. Although activity diagrams primarily show the overall flow of control, they can also include elements showing the flow of data between activities through one or more data stores.

   

  
  

  
  

  SUMMARY

  Scenario analysis

  scenario is a typical situation in the operation of a system. In term of definitions in the context of requirements engineering refer a story or example of events taken from real world experience. This is an outline with details of scenes or an imagined sequence of future events, which may include details of the system context (scenes). It captured and represented as speech or text narratives and may be embellished with still or moving images to illustrate the context.

  
  

                                                                                  
  

  Generic scenario
  

  The generic scenario is a sequence of events without detailed data and it representation of a set of particular instances of similar operations of the system.

                               
  

   

  Concrete scenario

  Concrete scenarios refer to the sequence of events with every detail of data and specific operation of the system.

  Example:
                                                                      
  

  
  

  
   

                                                                                                            SCENARIO ANALYSIS CASE STUDY
  According to this video, student be able to discuss the business process and the interaction with its environment based on scenario analysis
  

  and draw an activity diagram through the business organization.
  
  Duration spend time for the video lecture/ explanation: 1 hour
  

  
• TOPIC 6- CONSTRUCTION OF OO STRUCTURAL MODEL

  Restricted Not available unless: The activity Self Check 5.1: Test Your Self (Duration: 8 hours)- Student must complete 4 Questions is marked complete

  LEARNING OUTCOMES

  By the end of this topics, you will be able to:

  1. Explain what is objects and class in class diagram

  2. Draw a class diagram

  3. Draw a sequence and behavioral state machine diagram

   

  INTRODUCTION

  The next major diagramming technique is the class diagram. The class diagram is a static model that supports the static view of the evolving system. It shows the classes and the relationships among the classes that remain constant in the system over time. The class diagram is very similar to the entity relationship diagram (ERD) ; however, the class diagram depicts classes, which include attributes, behaviors, and states, while entities in the ERD include only attributes. The scope of a class diagram, like the ERD, is system wide. The sections that follow will first present the syntax of the class diagram and then the way in which a class diagram is drawn.

  
  

  SUMMARY 

  CLASS DIAGRAM

  The class diagram shows the classes and relationships among classes that remain constant in the system, over time. The main building block of the class diagram is a class, which stores and manages information in the system. Classes have attributes that capture information about the class and about operations, which are actions that a class can perform. There are three kinds of operations: constructor, query, and update. The classes are related to each other through an association, which has a name and a multiplicity that denotes the minimum and maximum instances that participate in the relationship.

  Two special associations, aggregation and generalization, are used when classes comprise other classes or when one subclass inherits properties and behaviors from a superclass, respectively. Class diagrams are created by first identifying classes, along with their attributes and operations. Then relationships are drawn among classes to show associations. Special notations are used to depict the aggregation and generalization associations.

   

  SEQUENCE DIAGRAM

  The sequence diagram is a dynamic model that illustrates instances of classes that participate in a use case and messages that pass between them over time. Objects are placed horizontally across the top of a sequence diagram, each having a dotted line, called a lifeline, vertically below it. The focus of control, represented by a thin rectangle, is placed over the lifeline to show when the objects are sending or receiving messages. A message is a communication between objects that conveys information with the expectation that activity will ensue, and the messages are shown by an arrow connecting two objects that points in the direction that the message is being passed. To create a sequence diagram, first identify the classes that participate in the use case and then add the messages that pass among them. Finally, you will need to add the lifeline and focus of control. Sequence diagrams are helpful for understanding real-time specifications and for complex scenarios of a use case.

  
  

  STATE MACHINE DIAGRAM

  The behavioral state machine diagram shows the different states that a single instance of a class passes through during its life in response to events, along with responses and actions. A state is a set of values that describes an object at a specific point in time, and it represents a point in an object’s life in which it satisfies some condition, performs some action, or waits for something to happen. An event is something that takes place at a certain point in time and changes a value(s) that describes an object, which in turn changes the object’s state. As objects move from state to state, they undergo transitions. When drawing a behavioral state machine diagram, rectangles with rounded corners are first placed on the model to represent the various states that the class will take. Next, arrows are drawn between the rec- tangles to denote the transitions, and event labels are written above the arrows to describe the event that causes the transition to occur.

  
  

  WHAT IS AN OBJECT?

  An object is a person, place, or thing about which we want to capture information. Each object has attributes that describe information about it and its behaviors, which are described by methods that specify what an object can do. Objects are grouped into classes, which are collections of objects that share common attributes and methods. The classes can be arranged in a hierarchical fashion in which low-level classes, or subclasses, inherit attributes and methods from superclasses above them, to reduce the redundancy in development. Objects communicate with each other by sending messages, which trigger methods.

  Object-oriented analysis and design using UML allows the analyst to decompose complex problems into smaller, more manageable components through a commonly accepted set of notation. UML is a standard set of diagramming techniques that provide a graphical representation rich enough to model any systems development project, from analysis through implementation. Typically, today most object oriented analysis and design approaches use the UML to depict an evolving system.

  Finally, many people believe that users do not think in terms of data or processes,but instead in terms of a collection of collaborating objects. As such, object-oriented analysis and design using UML allows the analyst to interact with the user, employing objects from the user’s environment instead of a set of separate processes and data.

  
  

  We can conclude these using the following figure:

                                                                     
  

  
  

  
  

                                                      
  

  
  

                                                          Example of Class diagram for holiday travel vehicles

  
  

  **Duration spend time for the video lecture- 1 hour

  
  

  
• Example of UML Diagram- For Lab Activity

                                                                                            

  In this section, students be able to:

  • Draw Class diagrams."                                                                                                                                 

  • Discuss and draw class and object diagrams for scenario                                                                  

  • Discuss and draw a state and communication diagram for a scenario

  • Discuss and draw activity diagram for scenario                                                                    

  • Discuss and draw sequence diagram for scenario                                                                               

  • Discuss and draw usecase diagram for the scenario                                                                  

  • Interaction diagram and state diagram

  1. Interaction Diagram

                                                    
  

  
  

  2. Use Case Diagram

                                                                                            
  

  3. Activity Diagram

                                                           
  

  
  

  4. State Diagram

                                                                            
  

  
  

  5. Communication Diagram

                                                                            
  

  
  

  6. Class Diagram

                                                                                     

  
  
  
• REFERENCE

                                                                                                             
                                                                                                                          

  • E-Book File

    Mark as done
  
• Examination

  • Final Examination (Remotely Proctored) Quiz

    View