Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm. Rao Casturi 08/27/2015

Transcription

1 Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm Rao Casturi 08/27/2015

2 Class Project Discussion Documents and project list Proposed Project list Project Charter Project Requirement Document Project Grading Peer Review GSU: Software Engineering - CSC4350/ Rao Casturi 5

3 Project List 1.Online Shopping cart 2.Cell phone app? 3.Online SQL Database Engine 4.Inventory for a small company 5.Online Hotel Management System 6.Scheduler 7.Attendance System GSU: Software Engineering - CSC4350/ Rao Casturi 6

4 Introduction to Software Engineering GSU: Software Engineering - CSC4350/ Rao Casturi 7

5 What I asked and What did I get? Acknowledgements to unknown author GSU: Software Engineering - CSC4350/ Rao Casturi 8

6 Software Engineering Failures The explosion of the Ariane 5 (June 4 th. 1996) $7bn Cost, Decade of development 64 bit floating point conversion to a 16 bit signed integer Y2K Bug C-17 unnecessary complexity $500 mm over budget 19 onboard computers 80 microprocessors and 6 different languages Mariner 1 (Venus flyby) 1962 July 22 nd. GSU: Software Engineering - CSC4350/ Rao Casturi 9

7 What is Software Engineering? 1. Modeling Activity Complexity through modeling Focus on relevant details Ignore other details not related to the problem Model is an abstract representation of the system that can answer questions about the system Size, Cost, Time, Complexity Application Domain and Solution Domain OO Methods combine App. Domain and Solution Domain modeling activates into one GSU: Software Engineering - CSC4350/ Rao Casturi 10

8 Modeling Activity Cost, Time & Scope Any one variable will impact other variables Adding people at the end of the project will cut short the project time? GSU: Software Engineering - CSC4350/ Rao Casturi 11

9 What is Software Engineering? 2. Problem Solving Activity Through models we search for a solution Best fit Method (Trial and Error) Usually involves 5 simple steps Formulate the problem Analyze the problem Search for the solutions Decide on the appropriate solution Specify the solution GSU: Software Engineering - CSC4350/ Rao Casturi 12

10 What is Software Engineering? 2. Problem Solving Activity Object Oriented Software Development usually includes 6 steps Requirement Elicitation Analysis System Design Object Design Implementation Testing GSU: Software Engineering - CSC4350/ Rao Casturi 13

11 What is Software Engineering? 3. Knowledge Acquisition Activity Knowledge acquisition is NOT LINEAR New knowledge about the system can through all the acquired knowledge Different Methodologies Risk-based Issue-based GSU: Software Engineering - CSC4350/ Rao Casturi 14

12 What is Software Engineering? 4. Rationale Activity Why the solution was proposed is critical to capture Not easy activity GSU: Software Engineering - CSC4350/ Rao Casturi 15

13 What is Software Engineering? Modeling Problem Solving Software Engineering Rationale Knowledge Acquisition GSU: Software Engineering - CSC4350/ Rao Casturi 16

14 Software Engineering Concepts Software engineering concepts depicted as a UML class diagram. [Bruegge, Dutoit] Projects Activity Tasks and Work Product Software Engineering - Fall 2014 CSC4350/ Rao Casturi 17

15 Roles and Responsibilities Client Provide high level requirements Scope Fund Set delivery time, quality User Provide knowledge about the system Feedback Testing Project Manager Overall management Face to the Client Developer Construction of the system Testing Technical Writer Documentation Reference manual Support Product support Installation Software Engineering - Fall 2014 CSC4350/ Rao Casturi 18

16 Work Product Work Product : Is an artifact produced during the development System Specification Document Operational Manual Status Reports Testing Manual Software Engineering - Fall 2014 CSC4350/ Rao Casturi 19

17 Functional and Non Functional Requirement Functional Specification a system should support Need to have Non Functional Constraint on the System No direct relation to the function of the system Software Engineering - Fall 2014 CSC4350/ Rao Casturi 20

18 Software Engineering Development Activities Requirement Elicitation (Gathering) Analysis System Design Object Design Implementation Testing Requirements Analysis System Design Object Design Implementation Testing Software Engineering - Fall 2014 CSC4350/ Rao Casturi 21

19 Managing Software Development Communication Time consuming activity Critical for the project Rational Management Justification Complex activity Software Configuration Version controls Maintenance Project Management Art Software Life Cycle Putting it all together is the life cycle of the Software Development Software Engineering - Fall 2014 CSC4350/ Rao Casturi 22

20 Software Engineering Development Activities Problem Statement 1 Requirement Elicitation Nonfunctional Requirements Functional Model Use case Diagrams 2 Analysis Stage Diagrams Class Diagrams 3 System Design Analysis Object Model Dynamic Model Sequence Diagrams Design goals Subsystem decomposition System Design Object Model 4 Object Design 6 Testing Coding 5 Implementation Object Design Model Final Product Class Diagrams GSU: Software Engineering - CSC4350/ Rao Casturi 10

21 Managing Software Development Communication Time consuming activity Critical for the project Rational Management Justification Complex activity Software Configuration Version controls Maintenance Project Management Art Software Life Cycle Putting it all together is the life cycle of the Software Development GSU: Software Engineering - CSC4350/ Rao Casturi 11

22 Introduction to UML What is UML? Unified Modeling Language History Why is it so important in Software Engineering? Fundamental Notations of UML GSU: Software Engineering - CSC4350/ Rao Casturi 13

23 Evolution of UML Reference Wikipedia OMT Object Modeling Technique UML -Unified Modeling Language GSU: Software Engineering - CSC4350/ Rao Casturi 14

24 3 Major areas of focus in System Development System Development Functional Model Object Model Dynamic Model Use Case Diagrams Output or produces Class Diagrams Output or produces Interaction, State Machine, Activity Diagrams UML helps us in modeling our problem to get a meaningful solution Functional Model Functionality of the system from users view. Represented in UML via use case diagrams. Object Models Represented in UML: via class diagrams describing the Structure of the system in terms of objects, associations and operations. Dynamic Models Represented in UML via sequence diagrams (ID), state charts and activity diagrams describing the internal behavior of the system. GSU: Software Engineering - CSC4350/ Rao Casturi 15

25 Basic Notations of UML Requirement Phase Analysis Phase Design Phase Object Design Phase Use Case Diagrams Class Diagrams Interactive Diagrams State Machine Diagrams Activity Diagrams GSU: Software Engineering - CSC4350/ Rao Casturi 16

26 UML Notations (Continued) 1. Use Case Diagram: Definitions : Use Case: Statement of functionality required by software 3 Main components of Use Case ACTOR, ACTION,SUBJECT Use Case is written in specific format Use Case (UC) is a Functional Requirement SYSTEM (action) Action Subject Subject represents the object on which the Action will take place Actor GSU: Software Engineering - CSC4350/ Rao Casturi 17

27 Example of an Use Case Portfolio Manager Risk Manager Trader Balance Portfolio Risk Analysis Set Risk Limits Price The bond << Include>> << Include>> Broker Quote (System Boundary) End of Day Holdings Valuation of the Bond Data Warehouse Broker (Use Case) GSU: Software Engineering - CSC4350/ Rao Casturi 18

28 Format for an Use Case Use Case Name UC_001_Bond_Risk_Analysis Actors/Participants Risk Manager, Trader Flow of Events/Scenario 1. Find the historical P&L of the bond 2. Depending on the P&L data decide if we can add this bond to the portfolio or not. 3. Set Risk Target if you need to add to the portfolio Entry Condition Exit Condition Quality constraints When a Portfolio Manager requests a Bond to be analysed The Risk appetite set The Risk Limit set should be in line with the other similar instruments Relationships to Reduce Complexity: Communication Relationships (Solid Line) <<Include>> (Dotted Line) <<Extend>> (Dotted Line) Inheritance (Solid Line with Triangle Head) GSU: Software Engineering - CSC4350/ Rao Casturi 19

29 UML Notations (Continued) 2. Class Diagram: Describes the structure of the system in terms of Classes and Objects Classes : - Collection of objects Objects: - The Entities to capture the state and behavior of the system Consists of 3 Components Class / Object Name 1. Link : Connection between 2 or more classes 2. Association : Relation between 2 or more classes Roles, Multiplicity (1-1,1-m,m-n) 3. Aggregation : Hierarchical model Attributes 4. Inheritance : Relationship to Root Class to many specialized classes Super Class Sub Class Methods or operations GSU: Software Engineering - CSC4350/ Rao Casturi 20

30 Interaction Diagrams (ID) 3. Interaction Diagrams: Capture Communication between objects Messages between objects (Solid arrows) Timing Diagrams or Sequence Diagrams X Axis Objects Y- Axis Time a b c Alternate i>0 option 1 i< 0 option 2 Loop I = 0 option 3 GSU: Software Engineering - CSC4350/ Rao Casturi 21

31 State Machine Diagrams 4. State Machine Diagrams: Describes the sequence of states an object can go through when triggered by an external event. Active, Inactive, Closed etc. Active Active Active GSU: Software Engineering - CSC4350/ Rao Casturi 22

32 Activity Diagrams 5. Activity Diagrams: Technique to describe any procedural logic or business process or work flow Like flow charts but support parallel behavior Forks, Joins, Decisions Swim lane diagrams Active Active Active Active Software Engineering - Fall 2014 CSC4350/ Rao Casturi 23

33 Functional and Non Functional Requirement Functional Specification a system should support Need to have Non Functional Constraint on the System No direct relation to the function of the system GSU: Software Engineering - CSC4350/ Rao Casturi 2

34 Software Engineering Development Activities Requirement Elicitation (Gathering) Analysis System Design Object Design Implementation Testing Requirements Analysis System Design Object Design Implementation Testing GSU: Software Engineering - CSC4350/ Rao Casturi 3

35 Software Engineering Development Activities Problem Statement 1 Requirement Elicitation Nonfunctional Requirements Functional Model Use case Diagrams 2 Analysis Stage Diagrams Class Diagrams 3 System Design Analysis Object Model Dynamic Model Sequence Diagrams Design goals Subsystem decomposition System Design Object Model 4 Object Design 6 Testing Coding 5 Implementation Object Design Model Final Product Class Diagrams GSU: Software Engineering - CSC4350/ Rao Casturi 4

36 Managing Software Development Communication Time consuming activity Critical for the project Rational Management Justification Complex activity Software Configuration Version controls Maintenance Project Management Art Software Life Cycle Putting it all together is the life cycle of the Software Development GSU: Software Engineering - CSC4350/ Rao Casturi 5

37 Project Life Cycle GSU: Software Engineering - CSC4350/ Rao Casturi 17

38 Project Organization and Communication Communication Structured / Unstructured Projects consists of 4 major components. Project : 1. Work product 2. Schedule 3. Participants 4. Task Formal Contact / $ Amount / Time Informal Word / Trust GSU: Software Engineering - CSC4350/ Rao Casturi 18

39 Project Organization Concepts 1. Project Organization 2. Roles 3. Tasks and Work Products 4. Schedules GSU: Software Engineering - CSC4350/ Rao Casturi 19

40 1. Project Organization Team Based Organization Hierarchical Cross-Functional Interactions (3 Types) Reporting Used for status information Between Develops or Team Lead to Project manager Decision Making Project Manager can take a decision to move the timelines Team Lead can decide to change the logic to implement a scenario Communication Many forms Formal and informal GSU: Software Engineering - CSC4350/ Rao Casturi 20

41 Hierarchical & Cross-Functional Hierarchical Reaction Time Slow Wrong people making decisions Lowest level participation has no control of the project timelines Budget decisions efficiently Cross-Functional Fast Reaction time Right people at different decision levels Budget control can be an issue Complex communication leads to some slip through gaps GSU: Software Engineering - CSC4350/ Rao Casturi 21

42 2. Roles GSU: Software Engineering - CSC4350/ Rao Casturi 22

43 3. Task and Work Products Task is a well defined unit of work Work Product is a outcome from a task Document Object Subsystems Test Cases Use Cases Work Product Type Description Test Plan Document Gives a test plan for the system or unit Design of Objects Class Model Shows all the class objects in the system Subsystem (Code) Source Code Produced by development team and submitted for review GSU: Software Engineering - CSC4350/ Rao Casturi 23

44 4. Schedule Mapping of task on a timeline or plot Each task has a life of its own (Start and End) 2 Types of Schedule Charts are widely used PERT and Gantt Charts Gantt Chart ( TASK vs Time) PERT (Program Evaluation Review Technique) Critical Path Graphical Representation Source : Wikipedia Page GSU: Software Engineering - CSC4350/ Rao Casturi 24

45 Project Communication Planned & Un planned Planned: Problem presentation Client reviews Project reviews Peer reviews Status reviews Brainstorming Releases Postmortem reviews. Un Planned: Requests for clarification Requests for changes Issue resolution. GSU: Software Engineering - CSC4350/ Rao Casturi 25

46 Recap UML Notation Use Case Diagrams Class Diagrams Interaction Diagrams Source Wikipedia Source Wikipedia GSU: Software Engineering - CSC4350/ Rao Casturi 2

47 Recap UML Notation State Diagrams Activity Diagrams Source Wikipedia Source Wikipedia GSU: Software Engineering - CSC4350/ Rao Casturi 3

48 Project Life Cycle GSU: Software Engineering - CSC4350/ Rao Casturi 4

49 Project Organization and Communication Communication Structured / Unstructured Projects consists of 4 major components. Project : 1. Work product 2. Schedule 3. Participants 4. Task Formal Contact / $ Amount / Time Informal Word / Trust GSU: Software Engineering - CSC4350/ Rao Casturi 5

50 Project Organization Concepts 1. Project Organization 2. Roles 3. Tasks and Work Products 4. Schedules GSU: Software Engineering - CSC4350/ Rao Casturi 6

51 1. Project Organization Team Based Organization Hierarchical Cross-Functional Interactions (3 Types) Reporting Used for status information Between Develops or Team Lead to Project manager Decision Making Project Manager can take a decision to move the timelines Team Lead can decide to change the logic to implement a scenario Communication Many forms Formal and informal GSU: Software Engineering - CSC4350/ Rao Casturi 7

52 Hierarchical & Cross-Functional Hierarchical Reaction Time Slow Wrong people making decisions Lowest level participation has no control of the project timelines Budget decisions efficiently Cross-Functional Fast Reaction time Right people at different decision levels Budget control can be an issue Complex communication leads to some slip through gaps GSU: Software Engineering - CSC4350/ Rao Casturi 8

53 2. Roles GSU: Software Engineering - CSC4350/ Rao Casturi 9

54 3. Task and Work Products Task is a well defined unit of work Work Product is a outcome from a task Document Object Subsystems Test Cases Use Cases Work Product Type Description Test Plan Document Gives a test plan for the system or unit Design of Objects Class Model Shows all the class objects in the system Subsystem (Code) Source Code Produced by development team and submitted for review GSU: Software Engineering - CSC4350/ Rao Casturi 10

55 4. Schedule Mapping of task on a timeline or plot Each task has a life of its own (Start and End) 2 Types of Schedule Charts are widely used PERT and Gantt Charts Gantt Chart ( TASK vs Time) GSU: Software Engineering - CSC4350/ Rao Casturi 11

56 PERT Charts PERT (Program Evaluation Review Technique) Critical Path Graphical Representation Milestones, Sequence of tasks Source : Wikipedia Page GSU: Software Engineering - CSC4350/ Rao Casturi 12

57 GSU: Software Engineering - CSC4350/ Rao Casturi 13

58 Project Communication Planned & Un planned Planned: Problem presentation Client reviews Project reviews Peer reviews Status reviews Brainstorming Releases Postmortem reviews. Un Planned: Requests for clarification Requests for changes Issue resolution. GSU: Software Engineering - CSC4350/ Rao Casturi 14

59 Requirement Elicitation GSU: Software Engineering - CSC4350/ Rao Casturi 16

60 Requirement Engineering First step for understanding the System Very Critical for the System Success 2 Components Requirement Specification (Gathering) Analysis Model Problem Statement Requirements Specification Requirement Elicitation Functional Non Functional Analysis model Analysis Dynamic Model Analysis Object Model Software Engineering - Fall 2014 CSC4350/ Rao Casturi GSU: Software Engineering - CSC4350/ Rao Casturi 17

61 Requirement Engineering Key Ideas: This is about the communication among the resources working on the project Human interaction Story board about the System Proposed Understanding the problem and articulate it back Ability to establish the boundaries GSU: Software Engineering - CSC4350/ Rao Casturi 18

62 Requirement Elicitation Concepts: MUST to have Interactions with the system From Start Develop or work on existing system Build UI/Interfaces Functional Requirements Usability Reliability Robustness Supportability Performance Greenfield, Re Engineering, Interface Development Non Functional Requirements Complete with all variations Unambiguous Correct Completeness, Consistency, Clarity, Accuracy Realism, Verifiability, Traceability Should be realist Able to verify the outcome Should match with the original requirements Software Engineering - Fall 2014 CSC4350/ Rao Casturi GSU: Software Engineering - CSC4350/ Rao Casturi 19

63 Requirement Elicitation Activities: Identify the Actors (Roles) During this phase the system developers will try to layout the various users and their roles This helps understanding of the Application Domain Identify Scenarios: Have discussions on some example how the system will work Helps in understanding the system better Identify Use Case: This is a detailed document of the various scenarios Capture all the possible functions the system should able to perform GSU: Software Engineering - CSC4350/ Rao Casturi 20

64 Requirement Elicitation Activities: Refine the Use Cases: This phase is utilized to refine and eliminate any of the duplicate Re verify that all the requirements re captured and each one has its own Use Case Identify the Relations: During this phase the relationship between the various Use Cases Dependencies are identified Identify the common functions in the system Identify the Non-Functional Requirements Get a confirmation from the client Document the non functional requirements GSU: Software Engineering - CSC4350/ Rao Casturi 21

65 Requirement Elicitation Activities: (Actor) Actors are Role Abstraction - not necessary to map to a persons One Actor can take multiple roles Subsystems can be Actors Questions for identifying actors Which user groups are supported by the system to perform their work? Which user groups execute the system s main functions? Which user groups perform secondary functions, such as maintenance and administration? With what external hardware or software system will the system interact? GSU: Software Engineering - CSC4350/ Rao Casturi 22

66 Requirement Elicitation Activities: (Scenarios) Scenario is a description of the behavior of an ACTOR Single Actor View point Can t replace an Use Case Types (As-Is, Futuristic, Testing and Evaluation, Training) Questions for identifying scenarios What are the tasks that the actor wants the system to perform? What information does the actor access? Who creates that data? Can it be modified or removed? By whom? Which external changes does the actor need to inform the system about? How often? When? Which events does the system need to inform the actor about? With what latency? GSU: Software Engineering - CSC4350/ Rao Casturi 23

67 Requirement Elicitation Activities: (Use Cases) Aggregation of the Scenarios Use Case is initiated by an ACTOR Use Case can interact with other Actors Writing Use Case is an ART Best Practices of Use Case Number each Use Case Uniquely Name the User Case to represent the ACTION (Verb) Name the ACTORS with the Role (Noun) Exit and Entry conditions should be clear Don t write about the user interface Exceptions should be outlined clearly Flow of activity should be clear and numbers for easy identification GSU: Software Engineering - CSC4350/ Rao Casturi 24

68 Requirement Elicitation - Goal Goal of this activity is to capture all the Shall statement sentences from the requirement documents into a table format. End of this activity the Requirements Trace Matrix is a deliverable to the project team Why is this activity important? Scope Creep Foundation for next phases (Use Cases, Categories, Classes, Methods) Cost & Time lines of project Future development (Incremental) Issues GSU: Software Engineering - CSC4350/ Rao Casturi 25

69 Requirement Engineering Key Ideas: This is about the communication among the resources working on the project Human interaction Story board about the System Proposed Understanding the problem and articulate it back Ability to establish the boundaries GSU: Software Engineering - CSC4350/ Rao Casturi 4

70 Problem Statement Requirement Elicitation Requirement Engineering Functional requirements :- This describe the interactions between the system and its environment independent of its implementation. The environment includes the user and any other external system with which the system interacts. Nonfunctional requirements : This activity describe aspects of the system that are not directly related to the functional behavior of the system. Nonfunctional requirements include a broad variety of requirements that apply to many different aspects of the system, from usability to performance. GSU: Software Engineering - CSC4350/ Rao Casturi 5

71 Functional Requirements Object-Oriented Software Engineering Bernd Bruegge and Allen Dutoit GSU: Software Engineering - CSC4350/ Rao Casturi 7

72 Non-Functional Requirements Object-Oriented Software Engineering Bernd Bruegge and Allen Dutoit GSU: Software Engineering - CSC4350/ Rao Casturi 8

73 Identifying Terminology / Glossary Participating objects should have a name Terminology is the first step towards the Analysis Need to be updated regularly Best Practices of Glossary User Application Domain Names Clarify any Technical Terms Data sources to be mentioned GSU: Software Engineering - CSC4350/ Rao Casturi 17

74 Requirement Elicitation Activities: Non Functional Non Functional Product Organizational External Performance Security Dependability Usability Operational Environment Development Standards Legal Accounting Standards Regulatory Ethical GSU: Software Engineering - CSC4350/ Rao Casturi 18

75 Requirement Elicitation Management Putting it all together RAD (Requirement Analysis Document) 1. Introduction 2. Current System 3. Future System 4. System Model 5. High Level Time Line Diagrams 6. Appendix (Proto type, Screen Shots etc) 7. Glossary GSU: Software Engineering - CSC4350/ Rao Casturi 19

76 Requirement Traceability Matrix Simple Tabular view of the requirements collected Living document over the project life Source :Use Cases combined with BOOCH OMT UML Putnam Texel & Charles Williams GSU: Software Engineering - CSC4350/ Rao Casturi 20

77 GSU: Software Engineering - CSC4350/ Rao Casturi 21

78 HCC Case Study Continued GSU: Software Engineering - CSC4350/ Rao Casturi 22

79 Requirement Elicitation Activities How do we complete this activity? Simple steps to follow to complete the activity Agree upon a set of initial documents to extract the requirements Look for any sentence with SHALL word Any sentence with Will be extracted and discussed further Prepare the Requirements Trace Matrix (RTM) Example of this activity Number the paragraphs of the agreed upon document Any sentence can now be identified by the paragraph # Scan the sentences for SHALL and note them and number them as individual items on an EXCEL Spread Sheet or any tool which can capture as individual items with Sorting facility Facts but not in a form of requirements First set of Shall identified with an unique line entry Req. Entry Number Paragraph Number Requirement sentence GSU: Software Engineering - CSC4350/ Rao Casturi 23

80 First set of Shall identified with an unique line entry Req. Entry Number Paragraph Number Requirement sentence Some Definitions Shall statement is a conceptual requirement for the complete system development Requirements Trace Matrix (RTM) an organized list of system requirements gathered during the initial phase from the system specification or requirement documents. Derived Requirements where the Shall can t be seen but can still be a requirement for the overall project or system Software Engineering - Fall 2014 GSU: Software CSC4350/6350 Engineering - CSC4350/ Rao Casturi - Rao Casturi 24

81 How to Address Will? Note: The Will sentences usually grouped together either at the end or with the appropriate section with the order. Capture Derived Requirements with out any paragraph number All Windows for the same environmental condition will be same Each environmental condition will be represented by a different color GSU: Software Engineering - CSC4350/ Rao Casturi 25

82 What is the final deliverable? Requirements Traceability Matrix Derived Requirements Only One per project Requirements Traceability Matrix GSU: Software Engineering - CSC4350/ Rao Casturi 26

83 What is Type Column? Pre-agreed categories Software Requirement (SW) Hardware Requirement (HW) Derived Requirement (DR) Nice to have Requirement (NTH) Software Constraint (SWC) GSU: Software Engineering - CSC4350/ Rao Casturi 27

84 Recap Requirement Elicitation Understanding the System Requirement Elicitation has 2 phases Requirement Specifications (Functional and Non Functional Requirements) Natural Language Focused around the communication with the client & user community Analysis Model (Dynamic, Analysis Object Model) More of formal or semi formal object models Communication between Developers and technical teams Concepts: (5) Functional (Need to have) Non-Functional (Not directly related to the System) Realism, Tractability, Verifiability Complete, Unambiguous From scratch, reengineering, just interface GSU: Software Engineering - CSC4350/ Rao Casturi 3

85 Recap - Requirement Elicitation - Goal Goal of this activity is to capture all the Shall statement sentences from the requirement documents as project requirements as a tabular form End of this activity the Requirements Trace Matrix is a deliverable Why is this activity important? Scope Creep Foundation for next phases (Use Cases, Categories, Classes, Methods) Cost & Time lines of project Future development (Incremental) Issues GSU: Software Engineering - CSC4350/ Rao Casturi 4

86 Recap - Requirement Elicitation Activities: Main Theme in this phase Identify the Actors Identify Scenarios Identify Use Case Refine the Use Cases Identify the Relations Terminology documentation Identify Non-Functional Requirements RAD (Requirement Analysis Document) Work product GSU: Software Engineering - CSC4350/ Rao Casturi 5

87 Recap RTM (Requirements Traceability Matrix) First set of Shall identified with an unique line entry Req. Entry Number Paragraph Number Requirement sentence Pre-agreed Types/Categories Software Requirement (SW) Hardware Requirement (HW) Derived Requirement (DR) Nice to have Requirement (NTH) Software Constraint (SWC) Functional (F) Non Functional (NF) Type Only One per project Requirements Traceability Matrix Some Definitions Shall statement is a conceptual requirement for the complete system development Requirements Trace Matrix (RTM) an organized list of system requirements gathered during the initial phase from the system specification or requirement documents. Derived Requirements where the Shall can t be seen but can still be a requirement for the overall project or system GSU: Software Engineering - CSC4350/ Rao Casturi 6

88 Requirement Elicitation Management Putting it all together RAD (Requirement Analysis Document) 1. Introduction 2. Current System 3. Future System 4. System Model 5. High Level Time Line Diagrams 6. Appendix (Proto type, Screen Shots etc) 7. Glossary 7

89 Different Flavors of Software Development Methodologies GSU: Software Engineering - CSC4350/ Rao Casturi 9

90 Software Development Methodologies Water fall (Traditional) Agile XP Scrum Release/Support GSU: Software Engineering - CSC4350/ Rao Casturi 10

91 Agile Methodology Goal : Release the working solution to end users Fast Pace Incremental approach of Software Specification, Development and Delivery Suited for projects where requirements change rapidly during the development process Cut down on Process Bureaucracy and Documentation which may not be used by the end user GSU: Software Engineering - CSC4350/ Rao Casturi 11

92 Agile Philosophy Idea Description of the Idea Client Involvement Clients should be closely involved throughout the development process. Clients are there to prioritize any new requirements and to evaluate released iterations. Incremental Product Delivery Software is developed and released in a small chucks with the a clear direction from the Client People over Process People strength is played all the time. Give the individual opportunity to show the skill to be used in the specific iteration Change is inevitable Expect the change and be flexible to incorporate the change Simplicity Think big but make it small to manage GSU: Software Engineering - CSC4350/ Rao Casturi 12

93 Which one is a better pick? (Agile or Planned) 1. Do we need a detailed specification documents before moving to design and implementation? 2. Can your client carve out sufficient time for review and feedback? 3. Size of the system? Large? 4. Location of the team? 5. What type of system? Real Time? 6. System Life? 7. Top down organization structure? 8. What is your team skill set? 9. Any outside regulations? Software Engineering - Fall 2014 CSC4350/ Rao Casturi GSU: Software Engineering - CSC4350/ Rao Casturi 13

94 XP Extreme Programing User Stories (Scenarios) Break down to Small Tasks Plan a Release Release feedback and evaluation Release the Software Product Develop / Integrate and Test the software product Same concept of Agile Incremental but done at extreme pace 1 day! GSU: Software Engineering - CSC4350/ Rao Casturi 14

95 XP Characteristics Idea Description of the Idea Pair Programming Developers work in pairs Code Check Refactoring Continuous improvements to code Collective ownership No single owner for the knowledge No separate QA Test Case Development First develop unit test cases before code can be developed Big on TESTING and PAIR Programming GSU: Software Engineering - CSC4350/ Rao Casturi 15

96 Agile Project Management - SCRUM Assess Select Outline Planning and Architectural Design Close the project Review Develop Sprint Cycle 3 Phases Sprint Cycle is usually 2 to 4 weeks Scrum Master GSU: Software Engineering - CSC4350/ Rao Casturi 16

97 Requirement Elicitation Analysis Design Implementation Testing Source: Rubin s Vase - Wikipedia Close out GSU: Software Engineering - CSC4350/ Rao Casturi 3

98 Analysis Leads to a System Model with Clarity Completeness Consistent Unambiguous OO- Analysis Attempts to Build a model describing the Application Domain Analysis model is the base for an architectural system design Works an input for the sub system decomposition Source: Rubin s Vase - Wikipedia GSU: Software Engineering - CSC4350/ Rao Casturi 4

99 OO- Analysis Goal : Identification of objects Object behavior Object relationships Object classification Object organization GSU: Software Engineering - CSC4350/ Rao Casturi 5

100 Analysis Model 1.Functional Model Use Cases Scenarios 2.Analysis Object Model (Static) Class Diagram Object Diagrams 3.Dynamic Model State and Machine Diagrams Source: Object-Oriented Software Engineering Bruegge & Dutoit Refine the functional model to generate object and dynamic model GSU: Software Engineering - CSC4350/ Rao Casturi 6

101 Analysis Concepts User view Entity, Boundary and Control Objects Generalization and Specialization Definitions: 1. Entity Object : Represent persistent information tracked by the system 2. Boundary Object : This represents interactions between the actor and the system in design 3. Control object : Takes care or in charge of the Use Cases Top Down Bottoms Up approach For Inheritance Generalization Specialization GSU: Software Engineering - CSC4350/ Rao Casturi 7

102 Activities of the Analysis Phase 1. Identify Entity, Boundary and Control Objects 2. Map Use Cases to Objects with Sequence Diagrams 3. Modeling Interactions between the Objects 4. Identify the Association, Aggregation and Attributes of the Classes 5. Modeling State Behavior of Individual Objects 6. Modeling Inheritance Relationships 7. Review Analysis Model GSU: Software Engineering - CSC4350/ Rao Casturi 8

103 Identify Entity, Boundary and Control Objects GSU: Software Engineering - CSC4350/ Rao Casturi 9

104 Activities of the Analysis Phase 1. Identify Entity, Boundary and Control Objects Source: Object-Oriented Software Engineering Bruegge & Dutoit GSU: Software Engineering - CSC4350/ Rao Casturi 10

105 Model View Controller Design Pattern Subsystems are classified into 3 different types. (Model, View, Controller) MVC is an architectural style used in Software Engineering to give the system flexibility. To isolate the MODEL from the User View. Model holds the domain knowledge (Business Rules). View holds the User input and display model. Controller holds the sequencing of the user inputs and acts as intermediate between Model and View. GSU: Software Engineering - CSC4350/ Rao Casturi 11

106 Model View Controller Design Pattern Refresh USER Request View Controller Results Model Action Smart - Thin- DUMMY approach Initiator, Subscriber & Notifier Observer Design Pattern GSU: Software Engineering - CSC4350/ Rao Casturi 12

107 Identify Entity, Boundary and Control Objects Entity Objects Participating Objects form the basis of this Analysis Model. Natural Language Analysis used to find out the objects, attributes and association from requirement specifications. [Abbott,1983] Parts of Speech (Noun, Verbs, Adjectives etc) used to model components. Advantages: Easy to understand by uses Limitations Quality of the Model is dependent on the Writing Style. Imprecise tool which can put the Model in danger being imprecise. GSU: Software Engineering - CSC4350/ Rao Casturi 13

108 Identify Entity Objects Cont. Entity Objects Developers will name and describe the objects, attributes, responsibilities. Unique naming Standard terminology. Write down the Initial Objects and the description as a table. Iterations will be done talking to client. GSU: Software Engineering - CSC4350/ Rao Casturi 14

109 Identify Entity Objects Cont. Abbott s heuristics for mapping parts of speech to model components Source: Object-Oriented Software Engineering Bruegge & Dutoit Source: Object-Oriented Software Engineering Bruegge & Dutoit GSU: Software Engineering - CSC4350/ Rao Casturi 15

110 Student Registration System (SRS) RC University Management Board approved a new Student Registration System to enable the on line course requirement for the Computer Science Department. The implementation of the new system is proposed to be in place by 2015 Spring. The new system is called SRS. What is expected by the SRS: The Student Registration System (SRS) shall include the ability for any accepted student to view his or her classes for a given semester. The SRS shall permit any active student to add new classes or modify existing classes. The SRS shall give the users to view the student records. The SRS will be able to print the records if needed. The SRS shall give the ability for the administrator to modify the student records for the given semester. The SRS shall log the history. The Course coordinator or department assigned person can view the student educational progress reports. SRS shall provide the functionality to pay the student dues. SRS will be used to capture student grades on the specific classes taken by the student The SRS will run on any standard browser with standard user authentication. SRS will not accept any payments directly but directed to a third party vendor to accept the payments by credit cards only. The data will be updated on SRS from the payment system by end of every day 8:00 pm. GSU: Software Engineering - CSC4350/ Rao Casturi 16

111 Use Case Example (Also discussion for refinement) GSU: Software Engineering - CSC4350/ Rao Casturi 17

112 Entity Objects Example GSU: Software Engineering - CSC4350/ Rao Casturi 18

113 Identify Entity, Boundary and Control Objects Boundary Objects System Interface with the Actors. Each Actor in an Use Case will interact with at least one Boundary Object Boundary Object are User Interface at a very high level. UI will continue to evolve. Identify the need for the UI to initiate the Use Case. Identify the Data entry needs. Always use the end user terms to describe the action GSU: Software Engineering - CSC4350/ Rao Casturi 19

114 Example for Boundary Objects GSU: Software Engineering - CSC4350/ Rao Casturi 20

115 Identify Entity, Boundary and Control Objects Control Objects Responsible for coordinating Entity Objects and Boundary Objects. Control Objects are created at the beginning (Entry) of Use Case. Life span usually at the EXIT condition of the Use Case. Best Practice: Identify one control object per Use Case. Identify one control object per Actor in the Use Case. Check for the Entry and Exit to set the life span of the control object. GSU: Software Engineering - CSC4350/ Rao Casturi 21

116 Example for Control Objects GSU: Software Engineering - CSC4350/ Rao Casturi 22

117 Map Use Cases to Objects with Sequence Diagrams GSU: Software Engineering - CSC4350/ Rao Casturi 23

118 Sequence Diagrams Sequence Diagrams ties Use Cases with Objects. Characteristics of Sequence Diagrams Time on Vertical Axis. Objects on the Horizontal Axis as columns. Messages are show with solid arrows. Labels on solid arrows represent messages names (can contain arguments). Executing Methods (Activation) is represented with vertical rectangles. Actors are usually on the left most column. Messages coming from the Actor represents the interactions described in use cases. GSU: Software Engineering - CSC4350/ Rao Casturi 24

119 Mapping Use Cases to Objects using Sequence Diagrams Student :StudentMenu Click() <<Create>> :ViewOption :ViewPrintObject <<Create>> SemesterSelect() :SemesterSelector Time Line SubmitRequest() <<Create>> :SemesterSubmitObject <<Create>> GSU: Software Engineering - CSC4350/ Rao Casturi 25

120 Mapping Use Cases to Objects using Sequence Diagrams Best Practice: First column should represent the actor who initiated the Use Case. Second column should be the Boundary Object. Third Column usually the Control Object. The control object will drive the rest of the Use Case. Boundary object creates the control object. Entity Objects are accessed by boundary and control objects. Entity Objects never access boundary or control objects. Advantages New Participating objects. Missing behavior. Remove redundancies. GSU: Software Engineering - CSC4350/ Rao Casturi 26

121 Categories and Category Interaction Diagrams (CID) Category is a collection of logically related Classes. Logically related Classes is a collection of Classes related through single inheritance. A collection of Classes related through aggregation, or a collection of Classes based on meaningful context. A Category should not be based on Functional capability unless it is Process Category or an Interface Category. A collection of Categories represents a functional area and is called a Domain in UML GSU: Software Engineering - CSC4350/ Rao Casturi 27

122 Modeling Interactions among objects with CRC Cards CRC : Class, Responsibilities and Collaborators Structure: Top Class Name, Left : Responsibilities, Right: Classes it needs Useful for a group of developers. High level representation of the Sequence Diagrams. Easy follow and easy to modify during the Analysis Phase. AuthenticationControl Responsibilities Collect User Id and Password Pass/Fail Notification Collaborators LoginObject StudentDBObject MessageObject GSU: Software Engineering - CSC4350/ Rao Casturi 28

123 Identify Associations GSU: Software Engineering - CSC4350/ Rao Casturi 29

124 Identify Associations Associations: Shows the relationship between 2 or more classes. Clarifies the model by making the relationship between objects. Enables the developers to discover the boundary cases. Too many associations will complicate the design model. Properties Name Describes the association between the 2 objects Role- Describe the function of each class (at the end of the class) Multiplicity Describe the number of instances the class can have Instructor 1 Teaches * Teacher Class Course GSU: Software Engineering - CSC4350/ Rao Casturi 30

125 Aggregations are special types of associations. Aggregation denotes a whole-part relationship. The UML Symbol is Diamond on the side of the whole part. Types of Associations Composition (Use when the parts depend on the whole) Solid Diamond. Shared (Use when the whole and the part can exist independently) Hallow Diamond. Where do we use them? UI Design. Database architecture. Identify Aggregates GSU: Software Engineering - CSC4350/ Rao Casturi 31

126 Identify Aggregates - Example Composition Shared Source: Object-Oriented Software Engineering Bruegge & Dutoit GSU: Software Engineering - CSC4350/ Rao Casturi 32

127 Identify Attributes Properties of individual objects. Denote by Name and Type. Consider only the attributes relevant to the system. Student StudentName : String SSNNumber: String StudentID: String GSU: Software Engineering - CSC4350/ Rao Casturi 33

128 References Use Cases Combined with BOOCH, OMT UML Process and Products - Putnam P Texel, Charles B Williams Object-Oriented Software Engineering Using UML Patterns, and JAVA -Bernd Bruegge & Allen H. Dutoit Software Engineering 9th Edition - Ian Sommerville GSU: Software Engineering - CSC4350/ Rao Casturi 35

129 Requirements Analysis System Design Object Design Implementation Testing Software Engineering -CSC4350/ Rao Casturi 2

130 System Design System Decomposition Migration from Analysis to System Design. Define Design Goals Design Initial Sub System Decomposition. Refine the Sub System to address the Design Goals. Software Engineering -CSC4350/ Rao Casturi 3

131 System System Design Object Design Implementation Software Engineering -CSC4350/ Rao Casturi 4

132 Activities of System Design This phase will produce the following 1. Design Goals 2. Software Architecture 3. Boundary Use Cases, Exceptions, hardware configurations Software Engineering -CSC4350/ Rao Casturi 5

133 Design Goal: Design Goals come from Non-Functional Requirements. Trade Off decisions made. Sub System Decomposition is the bulk of the System Design. Developers divide the system into manageable parts to reduce complexity. Each Sub-System is assigned to a smaller teams. Software Engineering -CSC4350/ Rao Casturi 6

134 Mapping Architecture to SW Engineering Item Architectural Concept SW Engineering Concept Components Room Subsystem Interfaces Doors Services Non-Functional Requirements Functional Requirements Living Area Residential House Response time Use Cases Costly Rework Moving Walls Change Subsystem Interfaces Software Engineering -CSC4350/ Rao Casturi 7

135 Design Goals Continued Finalize the strategies for Hardware / Software Strategy Persistent Data Management Control Flow Access Control Policy Handling Boundary Conditions Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 8

136 What is a Subsystem? A subsystem is a replaceable part of the system with well-defined interfaces that encapsulates the state and behavior of its contained classes. To reduce the complexity of the Solution Domain, a System is divided into smaller systems called Subsystem. Subsystems are also Called Categories Software Engineering -CSC4350/ Rao Casturi 9

137 More about Subsystems. Service : Is a related operations that share a common purpose. Define the Subsystem in terms of the services they provide. During this phase we define the Services and in the Object Design phase we develop the operations it will provide. Software Engineering -CSC4350/ Rao Casturi 10

138 Services and Subsystem Interfaces Subsystem Interface : A set of operations of a subsystem that are available for other subsystems. Subsystem Interface includes Name of the operation Pass through Parameters and data type Return values High level behavior Object Design focus on the API (Application Programmer Interface) Minimize the information provided about the implementation. Should not reference about the internal data structure. Software Engineering -CSC4350/ Rao Casturi 11

139 Services and Subsystem Interfaces Coupling Number of dependencies between two systems. Loosely coupled relatively independent. Impact analysis. Assembly connectors or Ball-and-Socket Connector Cohesion Number of dependencies within a subsystem. Unrelated objects low cohesion. Software Engineering -CSC4350/ Rao Casturi 12

140 Coupling Example Student Information Display Class Registration Graduation Tracker Student Database Software Engineering -CSC4350/ Rao Casturi 13

141 Cohesion Example Software Engineering -CSC4350/ Rao Casturi Source: OOSE-Bernd Bruegge & Allen H. Dutoit 15

142 Refined Cohesion Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 16

143 Refined Cohesion Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 16

144 Layers and Partitions Software Engineering -CSC4350/ Rao Casturi 17

145 Layers and Partitions A hierarchical decomposition of a system yields an ordered set of layers. A layer is a grouping of subsystems providing related services, possibly realized using services from another layer. Closed Layer Architecture Each Layer can access only one layer immediately below. Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 18

146 Example of Closed Layer Example: the OSI (Open System Interconnection) closed architecture model. 1. The Physical layer - is the hardware interface with the network. 2. The DataLink layer responsible for transmitting data frame using the services from the Physical layer. 3. The Network transmitting and routing packages within the network. 4. The Transport responsible for reliably transmitting data from end to end. This is the layer seen by UNIX programmers/users when transmitting data over TCP/IP (Transmission Connection Protocol/Internet Protocol) sockets between processes. 5. The Session responsible for the initialization of a connection. 6. The Presentation performs data transformation such as byte swapping or encryption. 7. The Application the layer that is designed which may also consist of subsystem layers itself. Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering - Fall 2014 CSC4350/ Rao Casturi 19

147 Example of Open Layer The lowest layer is provided by the operating system or by a windowing system, such as X11, and provides basic window management. AWT is an abstract window interface provided by Java to shield applications from specific window platforms. Swing is a library of user interface objects that provides a wide range of facilities, from buttons to geometry management. An Application usually accesses only the Swing interface. However, the Application layer may bypass the Swing layer and directly access AWT Openness of the architecture allows developers to bypass the higher layers to address performance bottlenecks Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 20

148 Architecture Styles 21

149 Repository Architectural Style: In the repository architectural style,subsystems access and modify a single data structure called the central repository. Subsystems are relatively independent and interact only through the repository. Control flow can be dictated either by the central repository or by subsystems. Example Database triggers on the data invoke peripheral systems or by the subsystems Software Engineering -CSC4350/ Rao Casturi 22

150 Repository Architectural Style Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering - Fall 2014 CSC4350/ Rao Casturi 23

151 Model View Controller Classified into 3 different types: 1. Model subsystems responsible for maintaining domain knowledge. 2. View subsystems responsible for display to user. 3. Controller subsystems responsible for managing the sequence of interactions with user. This is also a type of repository architecture. It is used mostly in interactive systems, especially when multiple views of the same model are needed. Software Engineering -CSC4350/ Rao Casturi 24

152 Model View Controller Design Pattern Model holds the domain knowledge (Business Rules). View holds the User input and display model. Controller holds the sequencing of the user inputs and acts as intermediate between Model and View. Software Engineering -CSC4350/ Rao Casturi 25

153 Model View Controller Design Pattern Refresh USER Reques t View Controller Results Model Action Smart - Thin- DUMMY approach Initiator, Subscriber & Notifier Observer Design Pattern Software Engineering -CSC4350/ Rao Casturi 26

154 Client Server Architecture In the client/server architectural style a subsystem, the server, provides services to instances of other subsystems called the clients, which are responsible for interacting with the user. The request for a service is usually done via a remote procedure call mechanism or a common object. Control flow in the clients and the servers is independent except for synchronization to manage requests or to receive results. Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 27

155 Peer-to-Peer Architecture Style A peer-to-peer architectural style is a generalization of the client/ server architectural style in which subsystems can act both as client or as servers, in the sense that each subsystem can request and provide services. The control flow within each subsystem is independent from the others except for synchronizations on requests. Software Engineering -CSC4350/ Rao Casturi 28

156 Three-Tier & Four Tier Architecture In this style the subsystems are organized into three layers The interface layer includes all boundary objects which deal with end users. Example windows, forms, web pages etc. The application logic layer includes all control and entity objects, realizing the processing, rule checking, and notification required by the application. The storage layer realizes the storage, retrieval, and query of persistent objects. Source: OOSE-Bernd Bruegge & Allen H. Dutoit Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 29

157 Pipe and filter Architecture Pipe and filter architectural style the subsystems process data received from a set of inputs and send results to other subsystems via a set of outputs. The subsystems are called filters, and the associations between the subsystems are called pipes. Each filter knows only the content and the format of the data received on the input pipes, not the filters that Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 30

158 System Design Activities: Addressing Design Goals Software Engineering -CSC4350/ Rao Casturi 31

159 Addressing Design Goals 1. Mapping Subsystems to Processors and Components 2. Identifying and Storing Persistent Data 3. Providing Access Control 4. Designing the Global Control Flow 5. Identifying Services 6. Identifying Boundary Conditions 7. Reviewing the System Design Model Software Engineering -CSC4350/ Rao Casturi 32

160 Addressing Design Goals Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 33

161 1. Mapping Subsystem to Processes and Components UML Deployment Diagrams DDs are used to show the relationship among runtime components and nodes. Components: Self-contained entities that provide services to other components. (Eg: Web browsers, Web Servers etc) Node: Is a physical device or an execution environment in which components are executed. System: Composed of interacting run-time components that can be distributed among several nodes. A node can contain another node. Software Engineering -CSC4350/ Rao Casturi 34

162 Example : Components and nodes Software Engineering -CSC4350/ Rao Casturi 35

163 1.Mapping Subsystem to Processes and Components Many Systems run on more than one computer. High-Performance needs Multiple uses Selection of virtual machine Hardware mapping activity has significant impact on the performance and complexity of the system. Suggested approach is to perform it early in system design. Software Engineering -CSC4350/ Rao Casturi 36

164 2. Persistent Data Store Flat Files: Storage abstractions provided by operating system. Data stored as a sequence of bytes. This is relatively low level and could enhance speed. However, data can be corrupted or/and lost easily. Should be used for very small applications that may not grow in size. Relational Database: Data stored in tables each column is an attribute and each row represents a data item as a tuple of attribute values. OO database: Provide similar services to relational databases, but stores data as objects and associations. It also provide inheritance and abstract datatypes. However, it is slower than relational database. Software Engineering -CSC4350/ Rao Casturi 37

165 When to use flat files, relational databases, and object-oriented databases When should you choose flat files? Voluminous data (e.g., images) Temporary data (e.g., core file) Low information density (e.g., archival files, history logs) When should you choose a relational or an object-oriented database? Concurrent accesses Access at finer levels of detail Multiple platforms or applications for the same data When should you choose a relational database? Complex queries over attributes Large data set When should you choose an object-oriented database? Extensive use of associations to retrieve data Medium-sized data set Irregular associations among objects Software Engineering -CSC4350/ Rao Casturi 38

166 3. Designing the Global Control Flow Control flow is the sequencing of actions in a system. Control flow is a design problem. There are 3 possible control mechanisms: Procedure-driven control: Operations wait for input whenever data is needed. Used mainly in systems written using procedural-languages. Event-driven control: A main loop, also waits for an external event. A main loop used. Useful for testing subsystems. Also the most commonly used. Threads: The system creates an arbitrary number of threads and run them concurrently. Each thread is run on the basis of procedure-driven. Software Engineering -CSC4350/ Rao Casturi 39

167 1. Procedure-driven control: Operations wait for input whenever data is needed. Used mainly in systems written using procedural-languages. Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 40

168 2. Event-driven control: A main loop, also waits for an external event. A main loop used. Useful for testing subsystems. Also the most commonly used. Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 41

169 3. Threads-driven control: Concurrent variation of the procedure driven control flow Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 42

170 Identifying Services & Boundary Configuration Conditions Creation of the object and destroying of the object Start-up and Shutdown For each component add 3 uses cases Start, Shutdown and Configuration of the component Exception handling Notify the user when there is any error Software Engineering -CSC4350/ Rao Casturi 43

171 Layers and Partitions Software Engineering -CSC4350/ Rao Casturi 17

172 Layers and Partitions A hierarchical decomposition of a system yields an ordered set of layers. A layer is a grouping of subsystems providing related services, possibly realized using services from another layer. Closed Layer Architecture Each Layer can access only one layer immediately below. Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 18

173 Example of Closed Layer Example: the OSI (Open System Interconnection) closed architecture model. 1. The Physical layer - is the hardware interface with the network. 2. The DataLink layer responsible for transmitting data frame using the services from the Physical layer. 3. The Network transmitting and routing packages within the network. 4. The Transport responsible for reliably transmitting data from end to end. This is the layer seen by UNIX programmers/users when transmitting data over TCP/IP (Transmission Connection Protocol/Internet Protocol) sockets between processes. 5. The Session responsible for the initialization of a connection. 6. The Presentation performs data transformation such as byte swapping or encryption. 7. The Application the layer that is designed which may also consist of subsystem layers itself. Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering - Fall 2014 CSC4350/ Rao Casturi 19

174 Example of Open Layer The lowest layer is provided by the operating system or by a windowing system, such as X11, and provides basic window management. AWT is an abstract window interface provided by Java to shield applications from specific window platforms. Swing is a library of user interface objects that provides a wide range of facilities, from buttons to geometry management. An Application usually accesses only the Swing interface. However, the Application layer may bypass the Swing layer and directly access AWT Openness of the architecture allows developers to bypass the higher layers to address performance bottlenecks Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 20

175 Goal : Categories and Category Interaction Diagrams (CID) To Identify how the Categories interact or relate to implement a Use Case Category Interaction Diagram (CID) A graphical representation of the interactions between Categories required to satisfy, or implement a Use Case using the notation of CASE Tool UML world Interaction Diagram is any diagram that depicts interaction at the Instance Level, and can be either a Sequence Diagram or a Collaboration Diagram UML Interaction Diagram: A UML Interaction Diagram refers to both UML Sequence Diagram and UML Collaboration Diagram. They represent general behavior, specifically interactions between objects UML Sequence Diagram: Shows the collaboration required between objects (instances) Work Product: Produce a CID Software Engineering -CSC4350/ Rao Casturi 21

176 Steps to create a CID Step 1: Establish Naming convention CID will be appended to the USE CASE Name UC16_Operator_Updates_Notional_Values_In_ DB_CID For Category Sequence Diagram it will be CSD Step 2 : Agree upon a Representation Mechanism (to produce) OMT Event Traces Jacobson Interaction Diagrams Booch Object Scenario Diagrams UML Sequence Diagram UML Collaboration Diagrams Software Engineering -CSC4350/ Rao Casturi 22

177 Steps to create a CID Step 3: Agree upon Diagram Contents Include the Title of the Diagram Textual overview of the Use Case Exceptions GUI Classes Step 4: Number each Message Each Message on a CID needs a sequence Number as a part of the message of as a comment attached to the message Step 5: Comment each CID Step 6: Agree to Notation for Use Cases Using/Referencing other Use Cases Unique Name ($Use_Case) Use the Name of the Use Case as the name of the Message to the category Software Engineering -CSC4350/ Rao Casturi 23

178 UC_16_Operator_Updates_Notional_Values_in_DB_ID Steps in the Use Case 1. Operator selects Update all button 2. Display the Update_All_View 3. Disable the Alarm 4. Operator enters values 5. If the OK button is selected then: 6. Start a transaction: 7-12 steps Enter values 13. Commit the transaction and 14. Enable the alarm and 15. Destroy the Update_All_View; 16. Else if the Cancel button selected, then 17. Enable the alarm and 18. Destroy the Update_All_View: Categories System_Boundry SEM_Desktop_View Update_All_View Alarm Living_Quarter Database $Use_Case Software Engineering -CSC4350/ Rao Casturi 24

179 Source: Use Cases Combined with Booch OMT UML Process and Products by Putnam and Charles 25

180 Architecture Styles 26

181 Repository Architectural Style: In the repository architectural style,subsystems access and modify a single data structure called the central repository. Subsystems are relatively independent and interact only through the repository. Control flow can be dictated either by the central repository or by subsystems. Example Database triggers on the data invoke peripheral systems or by the subsystems Software Engineering -CSC4350/ Rao Casturi 27

182 Repository Architectural Style Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering - Fall 2014 CSC4350/ Rao Casturi 28

183 Model View Controller Classified into 3 different types: 1. Model subsystems responsible for maintaining domain knowledge. 2. View subsystems responsible for display to user. 3. Controller subsystems responsible for managing the sequence of interactions with user. This is also a type of repository architecture. It is used mostly in interactive systems, especially when multiple views of the same model are needed. Software Engineering -CSC4350/ Rao Casturi 29

184 Model View Controller Design Pattern Model holds the domain knowledge (Business Rules). View holds the User input and display model. Controller holds the sequencing of the user inputs and acts as intermediate between Model and View. Software Engineering -CSC4350/ Rao Casturi 30

185 Model View Controller Design Pattern Refresh USER Reques t View Controller Results Model Action Smart - Thin- DUMMY approach Initiator, Subscriber & Notifier Observer Design Pattern Software Engineering -CSC4350/ Rao Casturi 31

186 Client Server Architecture In the client/server architectural style a subsystem, the server, provides services to instances of other subsystems called the clients, which are responsible for interacting with the user. The request for a service is usually done via a remote procedure call mechanism or a common object. Control flow in the clients and the servers is independent except for synchronization to manage requests or to receive results. Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 32

187 Peer-to-Peer Architecture Style A peer-to-peer architectural style is a generalization of the client/ server architectural style in which subsystems can act both as client or as servers, in the sense that each subsystem can request and provide services. The control flow within each subsystem is independent from the others except for synchronizations on requests. Software Engineering -CSC4350/ Rao Casturi 33

188 Three-Tier & Four Tier Architecture In this style the subsystems are organized into three layers The interface layer includes all boundary objects which deal with end users. Example windows, forms, web pages etc. The application logic layer includes all control and entity objects, realizing the processing, rule checking, and notification required by the application. The storage layer realizes the storage, retrieval, and query of persistent objects. Source: OOSE-Bernd Bruegge & Allen H. Dutoit Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 34

189 Pipe and filter Architecture Pipe and filter architectural style the subsystems process data received from a set of inputs and send results to other subsystems via a set of outputs. The subsystems are called filters, and the associations between the subsystems are called pipes. Each filter knows only the content and the format of the data received on the input pipes, not the filters that Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 35

190 System Design Activities: Addressing Design Goals Software Engineering -CSC4350/ Rao Casturi 36

191 Addressing Design Goals 1. Mapping Subsystems to Processors and Components 2. Identifying and Storing Persistent Data 3. Providing Access Control 4. Designing the Global Control Flow 5. Identifying Services 6. Identifying Boundary Conditions 7. Reviewing the System Design Model Software Engineering -CSC4350/ Rao Casturi 37

192 Addressing Design Goals Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 38

193 1. Mapping Subsystem to Processes and Components UML Deployment Diagrams DDs are used to show the relationship among runtime components and nodes. Components: Self-contained entities that provide services to other components. (Eg: Web browsers, Web Servers etc) Node: Is a physical device or an execution environment in which components are executed. System: Composed of interacting run-time components that can be distributed among several nodes. A node can contain another node. Software Engineering -CSC4350/ Rao Casturi 39

194 Example : Components and nodes Software Engineering -CSC4350/ Rao Casturi 40

195 1.Mapping Subsystem to Processes and Components Many Systems run on more than one computer. High-Performance needs Multiple uses Selection of virtual machine Hardware mapping activity has significant impact on the performance and complexity of the system. Suggested approach is to perform it early in system design. Software Engineering -CSC4350/ Rao Casturi 41

196 2. Persistent Data Store Flat Files: Storage abstractions provided by operating system. Data stored as a sequence of bytes. This is relatively low level and could enhance speed. However, data can be corrupted or/and lost easily. Should be used for very small applications that may not grow in size. Relational Database: Data stored in tables each column is an attribute and each row represents a data item as a tuple of attribute values. OO database: Provide similar services to relational databases, but stores data as objects and associations. It also provide inheritance and abstract datatypes. However, it is slower than relational database. Software Engineering -CSC4350/ Rao Casturi 42

197 When to use flat files, relational databases, and object-oriented databases When should you choose flat files? Voluminous data (e.g., images) Temporary data (e.g., core file) Low information density (e.g., archival files, history logs) When should you choose a relational or an object-oriented database? Concurrent accesses Access at finer levels of detail Multiple platforms or applications for the same data When should you choose a relational database? Complex queries over attributes Large data set When should you choose an object-oriented database? Extensive use of associations to retrieve data Medium-sized data set Irregular associations among objects Software Engineering -CSC4350/ Rao Casturi 43

198 3. Designing the Global Control Flow Control flow is the sequencing of actions in a system. Control flow is a design problem. There are 3 possible control mechanisms: Procedure-driven control: Operations wait for input whenever data is needed. Used mainly in systems written using procedural-languages. Event-driven control: A main loop, also waits for an external event. A main loop used. Useful for testing subsystems. Also the most commonly used. Threads: The system creates an arbitrary number of threads and run them concurrently. Each thread is run on the basis of procedure-driven. Software Engineering -CSC4350/ Rao Casturi 44

199 1. Procedure-driven control: Operations wait for input whenever data is needed. Used mainly in systems written using procedural-languages. Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 45

200 2. Event-driven control: A main loop, also waits for an external event. A main loop used. Useful for testing subsystems. Also the most commonly used. Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 46

201 3. Threads-driven control: Concurrent variation of the procedure driven control flow Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 47

202 Identifying Services & Boundary Configuration Conditions Creation of the object and destroying of the object Start-up and Shutdown For each component add 3 uses cases Start, Shutdown and Configuration of the component Exception handling Notify the user when there is any error Software Engineering -CSC4350/ Rao Casturi 48

203 Managing System Design System Design Document 1. Introduction 1.1 Purpose of the system 1.2 Design goals 1.3 Definitions, acronyms, and abbreviations 1.4 References 1.5 Overview 2. Current software architecture 3. Proposed software architecture 3.1 Overview 3.2 Subsystem decomposition 3.3 Hardware/software mapping 3.4 Persistent data management 3.5 Access control and security 3.6 Global software control 3.7 Boundary conditions 4. Subsystem services Glossary Software Engineering -CSC4350/ Rao Casturi 49

204 System Design and Decomposition summary Subsystem decomposition describes the decomposition into subsystems and the responsibilities of each. This is the main product of system design. Hardware/software mapping describes how subsystems are assigned to hardware and off-the-shelf components. It also lists the issues introduced by multiple nodes and software reuse. Persistent data management describes the persistent data stored by the system and the data management infrastructure required for it. This section typically includes the description of data schemes, the selection of a database, and the description of the encapsulation of the database. Access control and security describes the user model of the system in terms of an access matrix. This section also describes security issues, such as the selection of an authentication mechanism, the use of encryption, and the management of keys. Global software control describes how the global software control is implemented. In particular, this section should describe how requests are initiated and how subsystems synchronize. This section should list and address synchronization and concurrency issues. Boundary conditions describes the start-up, shutdown, and error behavior of the system. (If new use cases are discovered for system administration, these should be included in the requirements analysis document, not in this section.) Software Engineering -CSC4350/ Rao Casturi 50

205 References Use Cases Combined with BOOCH, OMT UML Process and Products - Putnam P Texel, Charles B Williams Object-Oriented Software Engineering Using UML Patterns, and JAVA -Bernd Bruegge & Allen H. Dutoit Software Engineering 9th Edition - Ian Sommerville Software Engineering -CSC4350/ Rao Casturi 52

206 System Design Activities: Addressing Design Goals Software Engineering -CSC4350/ Rao Casturi 2

207 Addressing Design Goals 1. Mapping Subsystems to Processors and Components 2. Identifying and Storing Persistent Data 3. Providing Access Control 4. Designing the Global Control Flow 5. Identifying Services 6. Identifying Boundary Conditions 7. Reviewing the System Design Model Software Engineering -CSC4350/ Rao Casturi 3

208 Addressing Design Goals Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 4

209 1. Mapping Subsystem to Processes and Components UML Deployment Diagrams DDs are used to show the relationship among runtime components and nodes. Components: Self-contained entities that provide services to other components. (Eg: Web browsers, Web Servers etc) Node: Is a physical device or an execution environment in which components are executed. System: Composed of interacting run-time components that can be distributed among several nodes. A node can contain another node. Software Engineering -CSC4350/ Rao Casturi 5

210 Example : Components and nodes Software Engineering -CSC4350/ Rao Casturi 6

211 1.Mapping Subsystem to Processes and Components Many Systems run on more than one computer. High-Performance needs Multiple uses Selection of virtual machine Hardware mapping activity has significant impact on the performance and complexity of the system. Suggested approach is to perform it early in system design. Software Engineering -CSC4350/ Rao Casturi 7

212 2. Persistent Data Store Flat Files: Storage abstractions provided by operating system. Data stored as a sequence of bytes. This is relatively low level and could enhance speed. However, data can be corrupted or/and lost easily. Should be used for very small applications that may not grow in size. Relational Database: Data stored in tables each column is an attribute and each row represents a data item as a tuple of attribute values. OO database: Provide similar services to relational databases, but stores data as objects and associations. It also provide inheritance and abstract datatypes. However, it is slower than relational database. Software Engineering -CSC4350/ Rao Casturi 8

213 When to use flat files, relational databases, and object-oriented databases When should you choose flat files? Voluminous data (e.g., images) Temporary data (e.g., core file) Low information density (e.g., archival files, history logs) When should you choose a relational or an object-oriented database? Concurrent accesses Access at finer levels of detail Multiple platforms or applications for the same data When should you choose a relational database? Complex queries over attributes Large data set When should you choose an object-oriented database? Extensive use of associations to retrieve data Medium-sized data set Irregular associations among objects Software Engineering -CSC4350/ Rao Casturi 9

214 3. Designing the Global Control Flow Control flow is the sequencing of actions in a system. Control flow is a design problem. There are 3 possible control mechanisms: Procedure-driven control: Operations wait for input whenever data is needed. Used mainly in systems written using procedural-languages. Event-driven control: A main loop, also waits for an external event. A main loop used. Useful for testing subsystems. Also the most commonly used. Threads: The system creates an arbitrary number of threads and run them concurrently. Each thread is run on the basis of procedure-driven. Software Engineering -CSC4350/ Rao Casturi 10

215 1. Procedure-driven control: Operations wait for input whenever data is needed. Used mainly in systems written using procedural-languages. Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 11

216 2. Event-driven control: A main loop, also waits for an external event. A main loop used. Useful for testing subsystems. Also the most commonly used. Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 12

217 3. Threads-driven control: Concurrent variation of the procedure driven control flow Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 13

218 Identifying Services & Boundary Configuration Conditions Creation of the object and destroying of the object Start-up and Shutdown For each component add 3 uses cases Start, Shutdown and Configuration of the component Exception handling Notify the user when there is any error Software Engineering -CSC4350/ Rao Casturi 14

219 Managing System Design System Design Document 1. Introduction 1.1 Purpose of the system 1.2 Design goals 1.3 Definitions, acronyms, and abbreviations 1.4 References 1.5 Overview 2. Current software architecture 3. Proposed software architecture 3.1 Overview 3.2 Subsystem decomposition 3.3 Hardware/software mapping 3.4 Persistent data management 3.5 Access control and security 3.6 Global software control 3.7 Boundary conditions 4. Subsystem services Glossary Software Engineering -CSC4350/ Rao Casturi 15

220 System Design and Decomposition summary Subsystem decomposition describes the decomposition into subsystems and the responsibilities of each. This is the main product of system design. Hardware/software mapping describes how subsystems are assigned to hardware and off-the-shelf components. It also lists the issues introduced by multiple nodes and software reuse. Persistent data management describes the persistent data stored by the system and the data management infrastructure required for it. This section typically includes the description of data schemes, the selection of a database, and the description of the encapsulation of the database. Access control and security describes the user model of the system in terms of an access matrix. This section also describes security issues, such as the selection of an authentication mechanism, the use of encryption, and the management of keys. Global software control describes how the global software control is implemented. In particular, this section should describe how requests are initiated and how subsystems synchronize. This section should list and address synchronization and concurrency issues. Boundary conditions describes the start-up, shutdown, and error behavior of the system. (If new use cases are discovered for system administration, these should be included in the requirements analysis document, not in this section.) Software Engineering -CSC4350/ Rao Casturi 16

221 Review System Design System Design is an Iterative process System Design model equal to Analysis Model Correctness Completeness Consistent Realistic Readable Software Engineering -CSC4350/ Rao Casturi 17

222 Object Design Software Engineering -CSC4350/ Rao Casturi 18

223 Object Design Close the gap between the application objects and the off-the shelf components. Identify additional solution objects. Refine the existing objects. Software Engineering -CSC4350/ Rao Casturi 19

224 Object Design includes (4 Groups of Activities) 1. Reuse (Component Selection) 2. Service Specification 3. Object Model Restructuring 4. Object Model Optimization Software Engineering -CSC4350/ Rao Casturi 20

225 Reuse or off-the-shelf components Off-the-Shelf components are identified during system design. Class Libraries and additional components are selected for basic data structures and services. Design patterns are selected for solving common problems. Classes are protected from future changes. Buy-versus-Build trade off Software Engineering -CSC4350/ Rao Casturi 21

226 Service Specification The subsystem services identified during the system design are specified in terms of : [Class Interfaces, Operations, arguments, type signatures and exceptions]. Additional operations and objects needed for data transfer among subsystems are identified. The subsystem service specification is also called API (Application Programmer Interface) Software Engineering -CSC4350/ Rao Casturi 22

227 Object Model Restructuring In this phase the focus is more on the reuse of the code. Revisit the N-ary Association of classes and see if we can get it to Binary association Look for Merging 2 similar classes, 2 similar subsystems. Attribute merging. Complex class decomposition for simple inheritance. Maintainability, Readability, Understandability Software Engineering -CSC4350/ Rao Casturi 23

228 Object Model Optimization This phase addresses the performance requirements of the system model. Efficiency of algorithms, Memory management is a focus. Techniques like simplicity vs multiplicity Rearrange Execution order for efficiency Adding redundancy / derived attributes for speedup. Software Engineering -CSC4350/ Rao Casturi 24

229 Solution Objects, Inheritance and Design Patterns Christopher Alexander says, Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it same way ever twice. Objects and interfaces instead of Walls and doors Software Engineering -CSC4350/ Rao Casturi 25

230 Reuse Concepts: Solution Objects, Inheritance, and Design Patterns Application Objects and Solution Objects Specification Inheritance and Implementation Inheritance Delegation The Liskov Substitution Principle Delegation and Inheritance in Design Patterns Software Engineering -CSC4350/ Rao Casturi 26

231 Application Objects & Solution Objects During analysis, we identify entity objects and their relationships, attributes, and operations. Most entity objects are application objects that are independent of any specific system. During analysis, we also identify solution objects that are visible to the user, such as boundary and control objects representing forms and transactions defined by the system. During system design, we identify more solution objects in terms of software and hardware platforms. During object design, we refine and detail both application and solution objects and identify additional solution objects needed to bridge the object design gap. Software Engineering -CSC4350/ Rao Casturi 27

232 Specification Inheritance and Implementation Inheritance Superclass, Subclass The focus of inheritance during object design is to reduce redundancy and enhance extensibility. By factoring all redundant behavior into a single superclass, we reduce the risk of introducing inconsistencies during changes (e.g., when repairing a defect) since we have to make changes only once for all subclasses By Providing abstract classes interfaces that are used by the application, we can write new specialized behavior by writing new subclasses that comply with the abstract interfaces. Software Engineering -CSC4350/ Rao Casturi 28

233 Delegation Delegation is the alternative to implementation inheritance that should be used when reuse is desired. A class is said to delegate to another class if it implements an operation by resending a message to another class. Delegation makes explicit the dependencies between the reused class and the new class. Software Engineering -CSC4350/ Rao Casturi 29

234 The Liskov Substitution Principle If a client code uses the methods provided by a superclass, then developers should be able to add new subclasses without having to change the client code. Software Engineering -CSC4350/ Rao Casturi 30

235 The Liskov Substitution Principle Liskov Substitution Principle If an object of type S can be substituted in all the places where an object of type T is expected, then S is a subtype of T. Interpretation In object design, the Liskov Substitution Principle means that if all classes are subtypes of their superclasses, all inheritance relationships are specification inheritance relationships. In other words, a method written in terms of a superclass T must be able to use instances of any subclass of T without knowing whether the instances are of a subclass. Consequently, new subclasses of T can be added without modifying the methods of T, hence leading to an extensible system. An inheritance relationship that complies with the Liskov Substitution Principle is called strict inheritance. Software Engineering -CSC4350/ Rao Casturi 31

236 Design pattern 4 Essential Elements 1. A name that uniquely identifies the pattern from other patterns. 2. A problem description that describes the situations in which the pattern can be used. Problems addressed by design patterns are usually the realization of modifiability and extensibility design goals and nonfunctional requirements. 3. A solution stated as a set of collaborating classes and interfaces. 4. A set of consequences that describes the trade-offs and alternatives to be considered with respect to the design goals being addressed. Software Engineering -CSC4350/ Rao Casturi 32

237 Cataloging of the Design Patterns Software Engineering -CSC4350/ Rao Casturi 33

238 Example - Adapter Software Engineering -CSC4350/ Rao Casturi 34

239 Questions? Software Engineering -CSC4350/ Rao Casturi 35

240 References Use Cases Combined with BOOCH, OMT UML Process and Products - Putnam P Texel, Charles B Williams Object-Oriented Software Engineering Using UML Patterns, and JAVA -Bernd Bruegge & Allen H. Dutoit Software Engineering 9th Edition - Ian Sommerville Software Engineering -CSC4350/ Rao Casturi 36

241 Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm Rao Casturi 11/03/2015

242 Object Design Software Engineering -CSC4350/ Rao Casturi 2

243 Object Design Close the gap between the application objects and the off-the shelf components. Identify additional solution objects. Refine the existing objects. Software Engineering -CSC4350/ Rao Casturi 3

244 Object Design includes (4 Groups of Activities) 1. Reuse (Component Selection) 2. Service Specification 3. Object Model Restructuring 4. Object Model Optimization Software Engineering -CSC4350/ Rao Casturi 4

245 Reuse or off-the-shelf components Off-the-Shelf components are identified during system design. Class Libraries and additional components are selected for basic data structures and services. Design patterns are selected for solving common problems. Classes are protected from future changes. Buy-versus-Build trade off Software Engineering -CSC4350/ Rao Casturi 5

246 Service Specification The subsystem services identified during the system design are specified in terms of : [Class Interfaces, Operations, arguments, type signatures and exceptions]. Additional operations and objects needed for data transfer among subsystems are identified. The subsystem service specification is also called API (Application Programmer Interface) Software Engineering -CSC4350/ Rao Casturi 6

247 Object Model Restructuring In this phase the focus is more on the reuse of the code. Revisit the N-ary Association of classes and see if we can get it to Binary association Look for Merging 2 similar classes, 2 similar subsystems. Attribute merging. Complex class decomposition for simple inheritance. Maintainability, Readability, Understandability Software Engineering -CSC4350/ Rao Casturi 7

248 Object Model Optimization This phase addresses the performance requirements of the system model. Efficiency of algorithms, Memory management is a focus. Techniques like simplicity vs multiplicity Rearrange Execution order for efficiency Adding redundancy / derived attributes for speedup. Software Engineering -CSC4350/ Rao Casturi 8

249 Solution Objects, Inheritance and Design Patterns Christopher Alexander says, Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it same way ever twice. Objects and interfaces instead of Walls and doors Software Engineering -CSC4350/ Rao Casturi 9

250 Reuse Concepts: Solution Objects, Inheritance, and Design Patterns Application Objects and Solution Objects Specification Inheritance and Implementation Inheritance Delegation The Liskov Substitution Principle Delegation and Inheritance in Design Patterns Software Engineering -CSC4350/ Rao Casturi 10

251 Application Objects & Solution Objects During analysis, we identify entity objects and their relationships, attributes, and operations. Most entity objects are application objects that are independent of any specific system. During analysis, we also identify solution objects that are visible to the user, such as boundary and control objects representing forms and transactions defined by the system. During system design, we identify more solution objects in terms of software and hardware platforms. During object design, we refine and detail both application and solution objects and identify additional solution objects needed to bridge the object design gap. Software Engineering -CSC4350/ Rao Casturi 11

252 Specification Inheritance and Implementation Inheritance Superclass, Subclass The focus of inheritance during object design is to reduce redundancy and enhance extensibility. By factoring all redundant behavior into a single superclass, we reduce the risk of introducing inconsistencies during changes (e.g., when repairing a defect) since we have to make changes only once for all subclasses By Providing abstract classes interfaces that are used by the application, we can write new specialized behavior by writing new subclasses that comply with the abstract interfaces. Software Engineering -CSC4350/ Rao Casturi 12

253 Meta Model - Inheritance Source : Object Oriented Softeare Engineering Using UML, Patterns, and Java Brenda Bruegge and Allen Dutoit In object-oriented analysis and design, inheritance is used for achieving several goals, in particular modeling taxonomies and reusing behavior from abstract classes. When modeling taxonomies, the inheritance relationships can be identified either during specializations (when specialized classes are identified after general ones) or during generalizations (when general classes are abstracted out of a number of specialized ones). When using inheritance for reuse, specification inheritance represents subtyping relationships, and implementation inheritance represents reuse among conceptually unrelated classes. Software Engineering -CSC4350/ Rao Casturi 13

254 Inheritance Example The use of inheritance for the sole purpose of reusing code is called implementation inheritance. With implementation inheritance, developers reuse code quickly by subclassing an existing class and refining its behavior. A Set implemented by inheriting from a Hashtable is an example of implementation inheritance. Conversely, the classification of concepts into type hierarchies is called specification inheritance (also called interface inheritance ) Software Engineering -CSC4350/ Rao Casturi 14

255 Delegation Delegation is the alternative to implementation inheritance that should be used when reuse is desired. A class is said to delegate to another class if it implements an operation by resending a message to another class. Delegation makes explicit the dependencies between the reused class and the new class. Software Engineering -CSC4350/ Rao Casturi 15

256 Delegation The only significant change is the private field table and its initialization in the MySet() constructor. This addresses 2 problems : Extensibility. The MySet on the right column does not include the containskey() method in its interface and the new field table is private. Hence, we can change the internal representation of MySet to another class (e.g., a List) without impacting any clients of MySet. Subtyping. MySet does not inherit from Hashtable and, hence, cannot be substituted for a Hashtable in any of the client code. Consequently, any code previously using Hashtables still behaves the same way. Delegation is a preferable mechanism to implementation inheritance as it does not interfere with existing components and leads to more robust code. Note that specification inheritance is preferable to delegation in subtyping situations as it leads to a more extensible design. Software Engineering -CSC4350/ Rao Casturi 16

257 The Liskov Substitution Principle If a client code uses the methods provided by a superclass, then developers should be able to add new subclasses without having to change the client code. Software Engineering -CSC4350/ Rao Casturi 17

258 The Liskov Substitution Principle Liskov Substitution Principle If an object of type S can be substituted in all the places where an object of type T is expected, then S is a subtype of T. Interpretation In object design, the Liskov Substitution Principle means that if all classes are subtypes of their superclasses, all inheritance relationships are specification inheritance relationships. In other words, a method written in terms of a superclass T must be able to use instances of any subclass of T without knowing whether the instances are of a subclass. Consequently, new subclasses of T can be added without modifying the methods of T, hence leading to an extensible system. An inheritance relationship that complies with the Liskov Substitution Principle is called strict inheritance. Software Engineering -CSC4350/ Rao Casturi 18

259 Design pattern 4 Essential Elements 1. A name that uniquely identifies the pattern from other patterns. 2. A problem description that describes the situations in which the pattern can be used. Problems addressed by design patterns are usually the realization of modifiability and extensibility design goals and nonfunctional requirements. 3. A solution stated as a set of collaborating classes and interfaces. 4. A set of consequences that describes the trade-offs and alternatives to be considered with respect to the design goals being addressed. Software Engineering -CSC4350/ Rao Casturi 19

260 Cataloging of the Design Patterns Software Engineering -CSC4350/ Rao Casturi 20

261 Example - Adapter Software Engineering -CSC4350/ Rao Casturi 21

262 Delegation- Standard The client class accesses the pattern. In the class diagram of the Adapter pattern this class is simply called Client. Client classes can be either existing classes of a class library or new classes of the system under development. The pattern interface is the part of the pattern that is visible to the client class. Often, the pattern interface is realized by an abstract class or an interface. In the Adapter pattern, this class is called ClientInterface. The implementor class provides the lower-level behavior of the pattern. In the Adapter pattern, the LegacyClass and the Adapter are implementor classes. In many patterns, a number of collaborating implementor classes are needed to realize the pattern behavior. The extender class specializes an implementor class to provide a different implementation or an extended behavior of the pattern. In the Adapter pattern, the subtypes of LegacyClass are extender classes. Note that, often, extender classes represent future classes that developers anticipate. Software Engineering -CSC4350/ Rao Casturi 22

263 Identification of Design Patterns Software Engineering -CSC4350/ Rao Casturi 23

264 Object Design Interface Specification Concepts Software Engineering -CSC4350/ Rao Casturi 24

265 Activities Identify missing attributes and operations During this activity, we examine each subsystem service and each analysis object. We identify missing operations and attributes that are needed to realize the subsystem service. We refine the current object design model and augment it with these operations. Specify visibility and signatures During this activity, we decide which operations are available to other objects and subsystems, and which are used only within a subsystem. We also specify the turn type of each operation as well as the number and type of its parameters. This goal of this activity is to reduce coupling among subsystems and provide a mall and simple interface that can be understood easily by a single developer. Specify contracts During this activity, we describe in terms of constraints the behavior of the operations provided by each object. In particular, for each operation, we describe the conditions that must be met before the operation is invoked and a specification of the result after the operation returns. Software Engineering -CSC4350/ Rao Casturi 25

266 Class Implementor, Class Extender, and Class User Software Engineering -CSC4350/ Rao Casturi 26

267 Types, Signatures, and Visibility During analysis, we identified attributes and operations without necessarily specifying their types or their parameters. The Type of an attribute specifies the range of values the attribute can take and the operations that can be applied to the attribute. The Type constrains the range of values the parameter or the return value can take. Given an operation, the tuple made out of the types of its parameters and the type of the return value is called the signature of the operation. The Visibility of an attribute or an operation is a mechanism for specifying whether the attribute or operation can be used by other classes or not. Software Engineering -CSC4350/ Rao Casturi 27

268 Types, Signatures, and Visibility A private attribute can be accessed only by the class in which it is defined. Similarly, a private operation can be invoked only by the class in which it is defined. Private attributes and operations cannot be accessed by subclasses or calling classes. Private operations and attributes are intended for the class implementor only. A protected attribute or operation can be accessed by the class in which it is defined and by any descendant of that class. Protected operations and attributes cannot be accessed by any other class. Protected operations and attributes are intended for the class extender. A public attribute or operation can be accessed by any class. The set of public operations and attributes constitute the public interface of the class and is intended for the class user. An attribute or an operation with visibility package can be accessed by any class in the nearest enclosing package. This visibility enables a set of related classes (for example, forming a subsystem) to share a set of Software Engineering -CSC4350/ Rao Casturi 28

269 Questions? Software Engineering -CSC4350/ Rao Casturi 29

270 References Use Cases Combined with BOOCH, OMT UML Process and Products - Putnam P Texel, Charles B Williams Object-Oriented Software Engineering Using UML Patterns, and JAVA -Bernd Bruegge & Allen H. Dutoit Software Engineering 9th Edition - Ian Sommerville Software Engineering -CSC4350/ Rao Casturi 30

271 Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm Rao Casturi 11/10/2015

272 Class announcements Final Exam date - Dec 1 st. Final Presentations Dec 3 rd. And Dec 8 th. Ability to run the program in the class Prepare for Q&A Each member should talk about their role in the project Final deliverables & Date Dec 3 rd. One Printed copy of the whole project (All phases & Code) Software Engineering -CSC4350/ Rao Casturi 2

273 Testing Software Engineering -CSC4350/ Rao Casturi 3

274 Testing What is testing? Process of finding the divergence between the expected behavior of the designed system model vs implemented final system. Why testing is important? Cost to fix is high Credibility What is the goal? Who Should Do Testing? Software Engineering -CSC4350/ Rao Casturi 4

275 Stages in Testing Unit Testing Differences between a specification of an object and its realization as a component Structural Testing Differences between the system design model and a subset of integrated subsystems Functional Testing Differences between the use case model and the system Performance Testing Differences between nonfunctional requirements and actual system performance Software Engineering -CSC4350/ Rao Casturi 5

276 Testing Concepts Software reliability is the probability that a software system will not cause system failure for a specified time under specified conditions. Failure is any deviation of the observed behavior from the specified behavior. An erroneous state (also called an error) means the system is in a state such that further processing by the system will lead to a failure, which then causes the system to deviate from its intended behavior. A fault, also called defect or bug, is the mechanical or algorithmic cause of an erroneous state. The goal of testing is to maximize the number of discovered faults, which then allows developers to correct them and increase the reliability of the system. Software Engineering -CSC4350/ Rao Casturi 6

277 How to increase the Software Reliability? Fault avoidance Technique Fault Detection Technique Fault Tolerance Technique Software Engineering -CSC4350/ Rao Casturi 7

278 Fault avoidance Technique Detect faults before they can happen This includes Development methodologies: Unambiguous relationship Data Encapsulation Coupling and Coherence Configuration Management: Better communications and upgrades/edits in other parts of the system Verification Check pre and post conditions Trust but verify Review Methods. (Walkthrough and inspection) Frequent Code Review Software Engineering -CSC4350/ Rao Casturi 8

279 Fault detection & Tolerance Techniques Detection: During the development or after the release. Debugging. Uncontrolled and controlled experiments used during the development to find faults in the system. Testing (Planned way) Tolerance: Know issues but ready to release. Fault resistance systems with redundancy built in Software Engineering -CSC4350/ Rao Casturi 9

280 Test Planning Usability Testing Overall Testing Activities User Interface Testing Unit Testing Integration Testing & Structural Testing System Testing Functional Testing (Requirements from RAD and User Manual) Performance Testing (Non Functional and SDD) Acceptance Testing (Agreed upon project goals) Software Engineering -CSC4350/ Rao Casturi 10

281 Testing Concepts 1. A component: a part of the system that can be isolated for testing could be an object, a group of objects or one or more subsystems. 2. A fault: bug or defect a design or coding mistake that may cause abnormal component behavior. 3. An error: manifestation of a fault during the execution of the system. 4. A failure: deviation between the specification of a component and its behavior. This is triggered by one or more errors. Software Engineering -CSC4350/ Rao Casturi 11

282 Testing Concepts 5. A test case: a set of inputs and expected results that exercises a component with the purpose of causing failures and detecting faults. 6. A test stub: a partial implementation of components on which the test component depends. 7. A test driver: a partial implementation of a component that depends on the tested component. 8. A correction: a change to a component repair a fault. Software Engineering -CSC4350/ Rao Casturi 12

283 Why do Faults, errors and failures occur? Communication. Subsystem Integration Issues. Resource rotation. Lack of proper design and model documentation. Fault and Erroneous state Fault by Algorithmic or Mechanical Cause Source: OOSE-Bernd Bruegge & Allen H. Dutoit Software Engineering -CSC4350/ Rao Casturi 13