Download presentation
Presentation is loading. Please wait.
Published byAnn Rose Modified over 9 years ago
1
CEN 4010 -Sixth Lecture Requirements Analysis: Object Modeling Introduction to Software Engineering (CEN- 4010) Instructor: Masoud Sadjadi http://www.cs.fiu.edu/~sadjadi/Teaching
2
Sixth LectureCEN 4010: Introduction to Software Engineering 2 Acknowledgements Dr. Bernd Bruegge Dr. Allen Dutoit Overview: Motivation Overview Concepts Activities Management Summary
3
Sixth LectureCEN 4010: Introduction to Software Engineering 3 Agenda Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary Overview: Motivation Overview Concepts Activities Management Summary
4
Sixth LectureCEN 4010: Introduction to Software Engineering 4 Motivation Ambiguity: what do you see? Overview: Motivation Overview Concepts Activities Management Summary
5
Sixth LectureCEN 4010: Introduction to Software Engineering 5 Approach From Use Cases to Objects Top Level Use Case A and B are called Participating Objects Level 1 AB Level 3 Use Cases Level 3 Level 3 Level 3 Operations Level 4 Level 4 Level 2 Use Cases Level 2 Level 2 Overview: Motivation Overview Concepts Activities Management Summary
6
Sixth LectureCEN 4010: Introduction to Software Engineering 6 Our Focus Identification of objects Their Behavior Their Relationship Their Classification Their Organization Overview: Motivation Overview Concepts Activities Management Summary
7
Sixth LectureCEN 4010: Introduction to Software Engineering 7 Object vs. Class 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 Overview: Motivation Overview Concepts Activities Management Summary
8
Sixth LectureCEN 4010: Introduction to Software Engineering 8 Agenda Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary Overview: Motivation Overview Concepts Activities Management Summary
9
Sixth LectureCEN 4010: Introduction to Software Engineering 9 Analysis Overview system specification: Model analysis model: Model Problem Statement Requirements Analysis Requirements Elicitation Analysis results in a model of the system that aims to be correct, complete, consistent, and unambiguous. Overview: Motivation Overview Concepts Activities Management Summary
10
Sixth LectureCEN 4010: Introduction to Software Engineering 10 Req. Elicitation vs. Analsis Developers focus on structuring and formalizing the elicited requirements. Analysis functional model nonfunctional requirements analysis object model Requirements elicitation dynamic model Requirements Analysis Model Specification System design Object design Overview: Motivation Overview Concepts Activities Management Summary
11
Sixth LectureCEN 4010: Introduction to Software Engineering 11 The Analysis Model The analysis model is composed of the functional model, the object model, and the dynamic model. analysis model:Model dynamic model:Model object model:Model functional model:Model use case diagram:View class diagram:View statechart diagram:View sequence diagram:View Overview: Motivation Overview Concepts Activities Management Summary
12
Sixth LectureCEN 4010: Introduction to Software Engineering 12 Agenda Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary Overview: Motivation Overview Concepts Activities Management Summary
13
Sixth LectureCEN 4010: Introduction to Software Engineering 13 Analysis Concepts Analysis Object Models and Dynamic Models Entity, Boundary, and Control Objects Generalization and Specifications Overview: Motivation Overview Concepts Activities Management Summary
14
Sixth LectureCEN 4010: Introduction to Software Engineering 14 Analysis Object and Dynamic Models The analysis object model –focuses on the individual concepts that are manipulated by the system, their properties, and their relationships. –depicted by class diagrams. The dynamic model –focuses on the behavior of the system. –depicted with sequence diagrams and with statecharts. Overview: Motivation Overview Concepts Activities Management Summary
15
Sixth LectureCEN 4010: Introduction to Software Engineering 15 Example Examples and counterexamples of classes in the analysis object model of SatWatch. UniversalTime TimeZone LocationTimeZoneDatabaseGPSLocatorUserId Software classes Domain concepts Overview: Motivation Overview Concepts Activities Management Summary
16
Sixth LectureCEN 4010: Introduction to Software Engineering 16 Object Types 1 Entity Objects –Represent the persistent information tracked by the system (Application domain objects, “Business objects”). Boundary Objects –Represent the interaction between the user and the system. Control Objects: –Represent the control tasks performed by the system. Overview: Motivation Overview Concepts Activities Management Summary
17
Sixth LectureCEN 4010: Introduction to Software Engineering 17 Object Types 2 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 Object types originated in Smalltalk: –Model, View, Controller (MVC) Overview: Motivation Overview Concepts Activities Management Summary
18
Sixth LectureCEN 4010: Introduction to Software Engineering 18 Example Analysis classes for the 2Bwatch example > Year > Month > Day > ChangeDateControl > LCDDisplayBoundary > ButtonBoundary Overview: Motivation Overview Concepts Activities Management Summary
19
Sixth LectureCEN 4010: Introduction to Software Engineering 19 Generalization and Specialization Inheritance –enables us to organize concepts. –At the top of the hierarchy is a general concept. –At the bottom are the most specialized concepts. 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. Overview: Motivation Overview Concepts Activities Management Summary
20
Sixth LectureCEN 4010: Introduction to Software Engineering 20 Example An example of a generalization hierarchy Incident LowPriorityEmergencyDisaster EarthQuakeChemicalLeakCatInTree TrafficAccidentBuildingFire Overview: Motivation Overview Concepts Activities Management Summary
21
Sixth LectureCEN 4010: Introduction to Software Engineering 21 Agenda Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary Overview: Motivation Overview Concepts Activities Management Summary
22
Sixth LectureCEN 4010: Introduction to Software Engineering 22 Analysis Activities Main goal: Find the important abstractions What happens if we find the wrong abstractions? –Iterate and correct the model 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 Overview: Motivation Overview Concepts Activities Management Summary
23
Sixth LectureCEN 4010: Introduction to Software Engineering 23 From Use Cases to Objects 1. Identifying Entity Objects 2. Identifying Boundary Objects 3. Identifying Control Objects 4. Mapping Use Cases to Objects 5. Modeling Interactions among Objects 6. Identifying Associations 7. Identifying Aggregations 8. Identifying Attributes 9. Modeling Objects State-Dependent Behavior 10. Modeling Inheritance Relationship 11. Reviewing the Analysis Model Overview: Motivation Overview Concepts Activities Management Summary
24
Sixth LectureCEN 4010: Introduction to Software Engineering 24 Identifying Entity Objects Participating objects form the basis of the analysis model. Natural language analysis [Abbott, 1983]. Other heuristics –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. Overview: Motivation Overview Concepts Activities Management Summary
25
Sixth LectureCEN 4010: Introduction to Software Engineering 25 Identifying Boundary Objects Boundary objects represent the system interface with the actors. Heuristics –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. Overview: Motivation Overview Concepts Activities Management Summary
26
Sixth LectureCEN 4010: Introduction to Software Engineering 26 Identifying Control Objects Control objects are responsible for coordinating boundary and entity objects. Heuristics –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. Overview: Motivation Overview Concepts Activities Management Summary
27
Sixth LectureCEN 4010: Introduction to Software Engineering 27 Mapping Use Cases to Objects 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. 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). Overview: Motivation Overview Concepts Activities Management Summary
28
Sixth LectureCEN 4010: Introduction to Software Engineering 28 Example FieldOfficer Report EmergencyButton ReportEmergency Control ReportEmergency Form Emergency Report Manage EmergencyControl press() «create» submit() fillContents() submitReport() submitReportToDispatcher() «create» «destroy» Sequence diagram for the ReportEmergency use case. Overview: Motivation Overview Concepts Activities Management Summary
29
Sixth LectureCEN 4010: Introduction to Software Engineering 29 Modeling Interactions among Objects CRC cards –Class, Responsibilities, and Collaborators. –Initially was introduced as a tool for teaching object- oriented concepts to novices. 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. Overview: Motivation Overview Concepts Activities Management Summary
30
Sixth LectureCEN 4010: Introduction to Software Engineering 30 Example Examples of CRC cards for the ReportEmergencyControl and the Incident classes. ReportEmergencyControl Responsibilities Collects input from Field- officer Controls sequence of forms during emergency reporting Collaborators EmergencyReportForm EmergencyReport AcknowledgementNotice Incident Responsibilities rack all information related to a single inci- Collaborators Resource T dent. Overview: Motivation Overview Concepts Activities Management Summary
31
Sixth LectureCEN 4010: Introduction to Software Engineering 31 Identifying Associations An association shows relationship between two or more classes. 1.A name (optional) 2.A role 3.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. Overview: Motivation Overview Concepts Activities Management Summary
32
Sixth LectureCEN 4010: Introduction to Software Engineering 32 Example An example of association between the EmergencyReport and the FieldOfficer classes. Eliminating redundant association. * 1 writes authordocument FieldOfficerEmergencyReport * 1writes author document 1 1 1 1 triggers reports FieldOfficerEmergencyReport Incident Overview: Motivation Overview Concepts Activities Management Summary
33
Sixth LectureCEN 4010: Introduction to Software Engineering 33 Identifying Aggregations Aggregation –is a special type of association denoting a whole- part relationship. 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-to- many association relationship until you are sure about the whole-part relationship. Overview: Motivation Overview Concepts Activities Management Summary
34
Sixth LectureCEN 4010: Introduction to Software Engineering 34 Example Examples of aggregations and compositions. State County Township FireStation FireFighter FireEngine LeadCar Ambulance Overview: Motivation Overview Concepts Activities Management Summary
35
Sixth LectureCEN 4010: Introduction to Software Engineering 35 Identifying Attributes 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. 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.Overview: Motivation Overview Concepts Activities Management Summary
36
Sixth LectureCEN 4010: Introduction to Software Engineering 36 Example Attributes of the EmergencyReport class. EmergencyReport emergencyType:{fire,traffic,other} location:String description:String Overview: Motivation Overview Concepts Activities Management Summary
37
Sixth LectureCEN 4010: Introduction to Software Engineering 37 Modeling State-Dependent Behavior 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. Statechart Diagrams –represent behavior from the perspective of a single object. –Only objects with an extended lifespan and state- dependent behavior are worth considering. –Good for identifying missing use cases. Overview: Motivation Overview Concepts Activities Management Summary
38
Sixth LectureCEN 4010: Introduction to Software Engineering 38 Example UML statechart for Incident. Active InactiveClosedArchived all whendate > 1yr. resources submitted reports ReportedAssessment DisengagementResponse field officer arrives on site field officer releases resources dispatcher allocates resources field officer requests additional resources all resources deallocated Overview: Motivation Overview Concepts Activities Management Summary
39
Sixth LectureCEN 4010: Introduction to Software Engineering 39 Modeling Inheritance Relationship 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. An example of inheritance relationship. FieldOfficerDispatcher PoliceOfficer badgeNumber:Integer Overview: Motivation Overview Concepts Activities Management Summary
40
Sixth LectureCEN 4010: Introduction to Software Engineering 40 Reviewing the Analysis Model The analysis model is built incrementally and iteratively. We say the model is stable, when the number of changes to the model are minimal. 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. Overview: Motivation Overview Concepts Activities Management Summary
41
Sixth LectureCEN 4010: Introduction to Software Engineering 41 Is Our Model Correct? 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? Overview: Motivation Overview Concepts Activities Management Summary
42
Sixth LectureCEN 4010: Introduction to Software Engineering 42 Is Our Model Complete? For each object: –Is it needed by any use case? –In which use case is it created? Modified? Destroyed? –Can it be accessed from a boundary object? For each attribute: –When is it set? –What is its type? –Should it be a qualifier? 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? Overview: Motivation Overview Concepts Activities Management Summary
43
Sixth LectureCEN 4010: Introduction to Software Engineering 43 Is Our Model Consistent? 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: Motivation Overview Concepts Activities Management Summary
44
Sixth LectureCEN 4010: Introduction to Software Engineering 44 Is Our Model Realistic? 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: Motivation Overview Concepts Activities Management Summary
45
Sixth LectureCEN 4010: Introduction to Software Engineering 45 Summary of the Analysis Activities Review model Consolidate model Define interactions Define associations Define attributes Define nontrivial behavior Define use cases Define participating objects Define boundary objects Define control objects Define entity objects Overview: Motivation Overview Concepts Activities Management Summary
46
Sixth LectureCEN 4010: Introduction to Software Engineering 46 Agenda Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary Overview: Motivation Overview Concepts Activities Management Summary
47
Sixth LectureCEN 4010: Introduction to Software Engineering 47 Managing Analysis 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: Motivation Overview Concepts Activities Management Summary
48
Sixth LectureCEN 4010: Introduction to Software Engineering 48 Requirements Analysis Document 1.Introduction 2.Current system 3.Proposed system 3.1Overview 3.2Functional requirements 3.3Nonfunctional requirements 3.4Constraints (“Pseudo requirements”) 3.5System 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 1.Introduction 2.Current system 3.Proposed system 3.1Overview 3.2Functional requirements 3.3Nonfunctional requirements 3.4Constraints (“Pseudo requirements”) 3.5System 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 Overview: Motivation Overview Concepts Activities Management Summary
49
Sixth LectureCEN 4010: Introduction to Software Engineering 49 Object Models and Dynamic Models 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. 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. Overview: Motivation Overview Concepts Activities Management Summary
50
Sixth LectureCEN 4010: Introduction to Software Engineering 50 Assigning Responsibilities Roles –Generation of Information –Integration –Review Participants –The End User –The Client –The Analyst –The Architect –The Document Editor –The Configuration Manger –The Reviewer Overview: Motivation Overview Concepts Activities Management Summary
51
Sixth LectureCEN 4010: Introduction to Software Engineering 51 Participants 1 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. 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. Overview: Motivation Overview Concepts Activities Management Summary
52
Sixth LectureCEN 4010: Introduction to Software Engineering 52 Participants 2 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. 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. Overview: Motivation Overview Concepts Activities Management Summary
53
Sixth LectureCEN 4010: Introduction to Software Engineering 53 Participants 3 The Document Editor –is responsible for low-level integration of the document and for the overall format of the document and its index. 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. Overview: Motivation Overview Concepts Activities Management Summary
54
Sixth LectureCEN 4010: Introduction to Software Engineering 54 Communicating about Analysis The information communication is one of the most challenging tasks. –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. Overview: Motivation Overview Concepts Activities Management Summary
55
Sixth LectureCEN 4010: Introduction to Software Engineering 55 Iterating over the Analysis Model Analysis occurs iteratively and incrementally. Often in parallel with other development activities such as system design and implementation. 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. Overview: Motivation Overview Concepts Activities Management Summary
56
Sixth LectureCEN 4010: Introduction to Software Engineering 56 Client Sign-Off 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. Overview: Motivation Overview Concepts Activities Management Summary
57
Sixth LectureCEN 4010: Introduction to Software Engineering 57 Prioritizing requirements High priority (“Core requirements”) –Must be addressed during analysis, design, and implementation. –A high-priority feature must be demonstrated successfully during client acceptance. 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. Overview: Motivation Overview Concepts Activities Management Summary
58
Sixth LectureCEN 4010: Introduction to Software Engineering 58 Example An example of a revision process. Report problem or Design change and change requestestimate impact Update requirements Update design Update code (if applicable) Design test Execute all relevant tests Archive request [change approved] Review proposed change Review actual change ClientDeveloper Overview: Motivation Overview Concepts Activities Management Summary
59
Sixth LectureCEN 4010: Introduction to Software Engineering 59 Agenda Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary Overview: Motivation Overview Concepts Activities Management Summary
60
Sixth LectureCEN 4010: Introduction to Software Engineering 60 Summary Modeling vs. reality System modeling –Functional model –Object model –Dynamic model 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 Overview: Motivation Overview Concepts Activities Management Summary
61
Sixth LectureCEN 4010: Introduction to Software Engineering 61 Next Session 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: Motivation Overview Concepts Activities Management Summary
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.