Introduction to Software Engineering CEN 4010 Requirements Analysis

Introduction to Software Engineering (CEN 4010) Requirements Analysis: Object Modeling Spring 2005 Instructor: Masoud Sadjadi http: //www. cs. fiu. edu/~sadjadi/Classes/CEN-4010/ CEN 4010 Fifth Lecture Jan. 31, 2005

Acknowledgements Overview: Motivation Dr. Bernd Bruegge Dr. Allen Dutoit Overview Concepts Activities Management Summary CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 2

Agenda Overview: Motivation Overview Concepts Activities Management Summary Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 3

Motivation Overview: Motivation Ambiguity: what do you see? Overview Concepts Activities Management Summary CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 4

Approach Overview: Motivation From Use Cases to Objects Overview Top Level Use Case Level 1 Concepts Activities Management Level 2 Summary Level 3 Level 2 Use Cases Level 2 Level 3 Use Cases Level 3 Level 4 A CEN 4010: Introduction to Software Engineering Operations Level 4 B A and B are called Participating Objects Fifth Lecture on Jan. 31, 2005 5

Our Focus Overview: Motivation Identification of objects Their Behavior Their Relationship Their Classification Their Organization Overview Concepts Activities Management Summary CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 6

Object vs. Class Overview: Motivation Overview Concepts Activities Management Summary Object (instance): Exactly one thing A class describes a group of objects with similar properties Object diagram: A graphic notation for modeling objects, classes and their relationships ("associations"): – Class diagram: Template for describing many instances of data. Useful for taxonomies, patters, schemata. . . – Instance diagram: A particular set of objects relating to each other. Useful for discussing scenarios, test cases and examples CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 7

Agenda Overview: Motivation Overview Concepts Activities Management Summary Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 8

Analysis Overview: Motivation Overview Concepts Analysis results in a model of the system that aims to be correct, complete, consistent, and unambiguous. Activities Problem Statement Management Summary Requirements Elicitation system specification: Model Requirements Analysis analysis model: Model CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 9

Req. Elicitation vs. Analsis Overview: Motivation Overview Concepts Activities Developers focus on structuring and formalizing the elicited requirements. Requirements elicitation Requirements Specification Management nonfunctional requirements Summary functional model Analysis Model dynamic model analysis object model System design Object design CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 10

The Analysis Model Overview: Motivation Overview Concepts The analysis model is composed of the functional model, the object model, and the dynamic model. Activities Management Summary use case diagram: View class diagram: View functional model: Model object model: Model statechart diagram: View sequence diagram: View dynamic model: Model analysis model: Model CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 11

Agenda Overview: Motivation Overview Concepts Activities Management Summary Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 12

Analysis Concepts Overview: Motivation Analysis Object Models and Dynamic Models Entity, Boundary, and Control Objects Generalization and Specifications Overview Concepts Activities Management Summary CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 13

Analysis Object and Dynamic Models Overview: Motivation The analysis object model – focuses on the individual concepts that are manipulated by the system, their properties, and their relationships. – depicted by class diagrams. Overview Concepts Activities Management Summary The dynamic model – focuses on the behavior of the system. – depicted with sequence diagrams and with statecharts. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 14

Example Overview: Motivation Overview Examples and counterexamples of classes in the analysis object model of Sat. Watch. Concepts Activities Management Summary Domain concepts Software classes Universal. Time. Zone. Database Time. Zone GPSLocator Location User. Id CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 15

Object Types 1 Overview: Motivation Entity Objects – Represent the persistent information tracked by the system (Application domain objects, “Business objects”). Overview Concepts Activities Management Summary Boundary Objects – Represent the interaction between the user and the system. Control Objects: – Represent the control tasks performed by the system. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 16

Object Types 2 Overview: Motivation Overview Having three types of objects leads to models that are more resilient to change. – The interface of a system changes more likely than the control – The control of the system change more likely than the application domain Concepts Activities Management Summary Object types originated in Smalltalk: – Model, View, Controller (MVC) CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 17

Example Overview: Motivation Analysis classes for the 2 Bwatch example Overview Concepts Activities Management Summary <<entity>> Year <<control>> Change. Date. Control <<entity>> Month <<boundary>> Button. Boundary <<boundary>> LCDDisplay. Boundary <<entity>> Day CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 18

Generalization and Specialization Overview: Motivation Inheritance – enables us to organize concepts. – At the top of the hierarchy is a general concept. – At the bottom are the most specialized concepts. Overview Concepts Activities Management Summary Generalization – is the modeling activity that identifies abstract concepts from lower-level ones. Specialization – is the activity that identifies more specific concepts from a high-level one. Generalization-specialization relationship is another name for inheritance relationship. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 19

Example Overview: Motivation An example of a generalization hierarchy Overview Concepts Activities Incident Management Summary Low. Priority Emergency Cat. In. Tree Traffic. Accident CEN 4010: Introduction to Software Engineering Disaster Earth. Quake Chemical. Leak Building. Fire Fifth Lecture on Jan. 31, 2005 20

Agenda Overview: Motivation Overview Concepts Activities Management Summary Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 21

Analysis Activities Overview: Motivation Overview Concepts – Iterate and correct the model Activities Management Summary Main goal: Find the important abstractions What happens if we find the wrong abstractions? Steps during object modeling – 1. Class identification Based on the fundamental assumption that we can find abstractions – 2. Find the attributes – 3. Find the methods – 4. Find the associations between classes Order of steps – Goal: get the desired abstractions – Order of steps secondary, only a heuristic – Iteration is important CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 22

From Use Cases to Objects Overview: Motivation Overview 1. 2. Concepts Activities Management Summary 3. 4. 5. 6. 7. 8. 9. 10. 11. Identifying Entity Objects Identifying Boundary Objects Identifying Control Objects Mapping Use Cases to Objects Modeling Interactions among Objects Identifying Associations Identifying Aggregations Identifying Attributes Modeling Objects State-Dependent Behavior Modeling Inheritance Relationship Reviewing the Analysis Model CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 23

Identifying Entity Objects Overview: Motivation Participating objects form the basis of the analysis model. Natural language analysis [Abbott, 1983]. Other heuristics Overview Concepts Activities Management Summary – Terms that developers or users need to clarify in order to understand the use case. – Recurring nouns in the use cases. – Real-world entities that the system needs to track. – Real-world activities that the system needs to track. – Data source or sinks. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 24

Identifying Boundary Objects Overview: Motivation Boundary objects represent the system interface with the actors. Heuristics Overview Concepts Activities Management Summary – Identify the user interface controls that the user needs to initiate a use case. – Identify the forms. – Identify notices and messages. – Identify actor terminals, if multiple users are involved. – Do not model the visual aspects of the interface (use mock-ups instead). – Always use the end user’s terms for describing interfaces; do not use terms from solution domain. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 25

Identifying Control Objects Overview: Motivation Control objects are responsible for coordinating boundary and entity objects. Heuristics Overview Concepts Activities Management Summary – Identify one control object per use case. – Identify one control object per actor in the use case. – The life span of a control object should cover the extent of the use case or the extent of a user session. – If difficult, then the use case is required to be refined. The entry and exit conditions are not well defined. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 26

Mapping Use Cases to Objects Overview: Motivation A sequence diagram – ties use cases with objects. – It shows how the behavior of a use case (or scenario) is distributed among its participating objects. Overview Concepts Activities Management Summary Heuristics – The first column is an actor initiating the use case. – The second column a boundary object creating a control object. – The third column is a control object managing the rest of the use case. – Boundary and control object know about each other. – Entity objects do not know about boundary and control objects (independency promotes sharing). CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 27

Example Overview: Motivation Overview Sequence diagram for the Report. Emergency use case. Concepts Activities Summary Manage Emergency. Control Report Emergency. Button Management Field. Officer press() «create» Report. Emergency Control «create» Report. Emergency Form fill. Contents() submit. Report() «create» «destroy» CEN 4010: Introduction to Software Engineering Emergency Report submit. Report. To. Dispatcher() Fifth Lecture on Jan. 31, 2005 28

Modeling Interactions among Objects Overview: Motivation CRC cards – Class, Responsibilities, and Collaborators. – Initially was introduced as a tool for teaching objectoriented concepts to novices. Overview Concepts Activities Management Summary CRC cards vs. Sequence Diagrams – provide different representations for supporting the same type of activity. – Sequence diagrams are a better tool for single modeler. – CRC cards are better for a group of developers. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 29

Example Overview: Motivation Overview Concepts Examples of CRC cards for the Report. Emergency. Control and the Incident classes. Activities Management Report. Emergency. Control Summary Responsibilities Collaborators Collects input from Fieldofficer Controls sequence of forms during emergency reporting Emergency. Report. Form Emergency. Report Acknowledgement. Notice Incident Responsibilities Collaborators T rack all information related to a single incident. Resource CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 30

Identifying Associations Overview: Motivation Overview An association shows relationship between two or more classes. 1. 2. 3. – Concepts Activities Management Summary A name (optional) A role A multiplicity The associations among entity objects are the most important ones. Heuristics – – – Examine verb phrases. Name associations and roles precisely. Eliminate any redundant association. Do not worry about multiplicity at the beginning. Do not define too many associations. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 31

Example Overview: Motivation Overview An example of association between the Emergency. Report and the Field. Officer classes. Concepts Activities Field. Officer Management * writes author Summary 1 Emergency. Report document Eliminating redundant association. Field. Officer document writes 1 Emergency. Report author * 1 1 reports 1 Incident CEN 4010: Introduction to Software Engineering triggers 1 Fifth Lecture on Jan. 31, 2005 32

Identifying Aggregations Overview: Motivation Aggregation – is a special type of association denoting a wholepart relationship. Overview Concepts Activities Management Summary 1. Composition aggregation – indicates that the existence of the parts depends of the whole. 2. Shared aggregation – indicates that the existence of the whole and the parts are independent. If you are not sure, then start with a one-tomany association relationship until you are sure about the whole-part relationship. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 33

Example Overview: Motivation Examples of aggregations and compositions. Overview Concepts Activities Management Fire. Station State Summary County Fire. Fighter Fire. Engine Lead. Car Ambulance Township CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 34

Identifying Attributes Overview: Motivation Attributes – are properties of individual objects. – Consider only the ones relevant to the system. – Properties that are represented by objects are not attributes. – A name, a brief description, and a basic type. Overview Concepts Activities Management Summary Heuristics – Examine possessive phrases. – Represent stored state as an attribute of the entity object. – Describe each attribute. – Objects are not attributes. Use associations. – Do not go to details, unless the object structure is stable. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 35

Example Overview: Motivation Attributes of the Emergency. Report class. Overview Concepts Activities Management Summary Emergency. Report emergency. Type: {fire, traffic, other} location: String description: String CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 36

Modeling State-Dependent Behavior Overview: Motivation Sequence Diagrams – used to distribute behavior across objects and to identify operations. – represent the behavior of the system from the perspective of a single use case. – Good for identifying missing objects. Overview Concepts Activities Management Summary Statechart Diagrams – represent behavior from the perspective of a single object. – Only objects with an extended lifespan and statedependent behavior are worth considering. – Good for identifying missing use cases. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 37

Example Overview: Motivation UML statechart for Incident. Overview Active Concepts field officer arrives on site Activities Management Summary Reported Assessment dispatcher allocates resources field officer requests additional resources Response Disengagement field officer releases resources all resources deallocated when date > 1 yr. Inactive Closed Archived all resources submitted reports CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 38

Modeling Inheritance Relationship Overview: Motivation Generalization – is used to eliminate redundancy from the analysis model. – if two or more classes share attributes or behavior, the similarities are consolidated into a superclass. Overview Concepts Activities Management Summary An example of inheritance relationship. Police. Officer badge. Number: Integer Field. Officer CEN 4010: Introduction to Software Engineering Dispatcher Fifth Lecture on Jan. 31, 2005 39

Reviewing the Analysis Model Overview: Motivation Overview Concepts Activities Management The analysis model is built incrementally and iteratively. We say the model is stable, when the number of changes to the model are minimal. Summary Review – To make sure that the model is correct, complete, consistent, unambiguous, realistic, and verifiable. – internal review after the model is stable, it is first reviewed by the developers. – joint review next the model is reviewed jointly by the developer and the client. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 40

Is Our Model Correct? Overview: Motivation Overview Concepts Activities Management Summary Is the glossary of entity objects understandable by the user? Do abstract classes correspond to user-level concepts? Are all descriptions in accordance with the users’ definitions? Do all entity and boundary objects have meaningful noun phrases as names? Do all use cases and control objects have meaningful verb phrases as names? Are all error cases described and handled? CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 41

Is Our Model Complete? Overview: Motivation – Is it needed by any use case? – In which use case is it created? Modified? Destroyed? – Can it be accessed from a boundary object? Overview Concepts Activities Management For each object: For each attribute: – When is it set? – What is its type? – Should it be a qualifier? Summary For each association: – When is it traversed? – Why was the specific multiplicity chosen? – Can association with one-to-many and many-to-many multiplicities be qualified? For each control object: – Does it have the necessary associations to access the objects participating in its corresponding use case? CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 42

Is Our Model Consistent? Overview: Motivation Are there multiple classes or use cases with the same name? Do entities (e. g. , use cases, classes, attributes) with similar names denote similar concepts? Are there objects with similar attributes and associations that are not in the same generalization hierarchy? Overview Concepts Activities Management Summary CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 43

Is Our Model Realistic? Overview: Motivation Are there any novel features in the system? Were any studies or prototypes built to ensure their feasibility? Can the performance and reliability requirements be met? Were these requirements verified by any prototypes running on the selected hardware? Overview Concepts Activities Management Summary CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 44

Summary of the Analysis Activities Overview: Motivation Define use cases Overview Concepts Define participating objects Activities Management Summary Define entity objects Define boundary objects Define control objects Define interactions Define nontrivial behavior Define attributes Define associations Consolidate model Review model CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 45

Agenda Overview: Motivation Overview Concepts Activities Management Summary Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 46

Managing Analysis Overview: Motivation In the end, the requirements analysis document (RAD) should describe a single coherent system understandable to a single person. Documenting Analysis Assigning Responsibilities Communicating about Analysis Iterating over the Analysis Model Client Sign-Off Overview Concepts Activities Management Summary CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 47

Requirements Analysis Document Overview: Motivation Overview Concepts Activities Management Summary 1. Introduction 2. Current system 3. Proposed system 3. 1 Overview 3. 2 Functional requirements 3. 3 Nonfunctional requirements 3. 4 Constraints (“Pseudo requirements”) 3. 5 System models 3. 5. 1 Scenarios 3. 5. 2 Use case model 3. 5. 3 Object model 3. 5. 3. 1 Data dictionary 3. 5. 3. 2 Class diagrams 3. 5. 4 Dynamic models 3. 5. 5 User interface 4. Glossary CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 48

Object Models and Dynamic Models Overview: Motivation Object Models Section – documents in detail all the objects we identified, their attributes, and, when we used sequence diagrams, operations. – As each object is described with textual definitions, relationships among objects are illustrated with class diagrams. Overview Concepts Activities Management Summary Dynamic Models Section – documents the behavior of the object model in terms of statechart diagrams and sequence diagrams. – Although this information is redundant with the use case model, it describes precisely more complex behaviors. Once RAD is completed and published, it will be baselined and put under configuration management. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 49

Assigning Responsibilities Overview: Motivation Roles – Generation of Information – Integration – Review Overview Concepts Activities Management Summary Participants – – – – The End User The Client The Analyst The Architect The Document Editor The Configuration Manger The Reviewer CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 50

Participants 1 Overview: Motivation The End User – is the application domain expert. – generates information about the current system, the environment of the future system, and the tasks it should supports. – Each user corresponds to one or more actors and helps identify their associated use cases. Overview Concepts Activities Management Summary The client – funds the project and coordinates the user side of the effort. – serves as an integrator of application domain info. – defines the scope of the system based on user requirements. – Different users may have different views of the system. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 51

Participants 2 Overview: Motivation The Analyst – is the application domain expert. – Typically a developer with broad application domain knowledge. – models the current system and generates information about the future system. – Each analyst is initially responsible for detailing one or more use cases. Overview Concepts Activities Management Summary The Architect – has an integration role. – unifies the use case and object models from a system point of view. – Different analyst may have different style of modeling and different view of the parts of the systems for which they are not responsible. – provides a system philosophy and detects omissions. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 52

Participants 3 Overview: Motivation – is responsible for low-level integration of the document and for the overall format of the document and its index. Overview Concepts Activities Management Summary The Document Editor The Configuration Manager – is responsible for maintaining a revision history of the document as well as traceability information relating the RAD with other documents. The Reviewer – validates the RAD for correctness, completeness, consistency, and clarity. – Users, clients, developers, or other individuals may become reviewers during requirements validations. – If an individual has not been involved with the system, s/he may provide an excellent review. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 53

Communicating about Analysis Overview: Motivation Overview The information communication is one of the most challenging tasks. – – Concepts Activities Management Summary Participants with different backgrounds. Stakeholders with different expectations. New teams. Evolving system Approach – Clearly define territories (define roles and responsibilities). – Clearly define objectives and success criteria. – Set up brainstorming meetings. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 54

Iterating over the Analysis Model Overview: Motivation Overview Concepts Activities Management Analysis occurs iteratively and incrementally. Often in parallel with other development activities such as system design and implementation. Summary Steps toward a stable model: – Brainstorming Initiated before any other activities. – Solidification Once the client and the developers converge on a common idea. – Maturity Changes at the higher level are still possible but more difficult, and thus, are made more carefully. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 55

Client Sign-Off Overview: Motivation Overview Concepts Activities Management Summary The client sign-off represents the acceptance of the analysis model by the client. The client and the developers agree about the functionality and features of the system In addition they agree on – A list of priorities – A revision process – A list of criteria that will be used to accept or reject the system – A schedule and a budget After the sign-off, the RAD is baselined and is used for refining the cost estimate of the project. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 56

Prioritizing requirements Overview: Motivation – Must be addressed during analysis, design, and implementation. – A high-priority feature must be demonstrated successfully during client acceptance. Overview Concepts Activities Management Summary High priority (“Core requirements”) Medium priority (“Optional requirements”) – Must be addressed during analysis and design. – Usually implemented and demonstrated in the second iteration of the system development. Low priority (“Fancy requirements”) – Must be addressed during analysis (“very visionary scenarios”). – Illustrates how the system is going to be used in the future if not yet available technology enablers are available. CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 57

Example Overview: Motivation An example of a revision process. Overview Client Concepts Report problem or change request Activities Management Summary Developer Design change and estimate impact Review proposed change [change approved] Update requirements Design test Archive request Update design Update code (if applicable) Execute all relevant tests Review actual change CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 58

Agenda Overview: Motivation Overview Concepts Activities Management Summary Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 59

Summary Overview: Motivation Overview Concepts Modeling vs. reality System modeling – Functional model – Object model – Dynamic model Activities Management Summary Object modeling is the central activity – Class identification is a major activity of object modeling – There are some easy syntactic rules to find classes/objects Requirements Analysis Document Structure Different roles and responsibilities during software development CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 60

Next Session Overview: Motivation We will spend the next session on your group projects. We will work on the requirement analysis document for each project. Please bring your scenarios and use cases as the input for the meeting. Overview Concepts Activities Management Summary CEN 4010: Introduction to Software Engineering Fifth Lecture on Jan. 31, 2005 61