Introduction to Software Engineering: Analysis

Transcription

1 Introduction to Software Engineering: Analysis John T. Bell Department of Computer Science University of Illinois, Chicago Based on materials from of Bruegge & DuToit 3e, Ch 5 and UML Distilled by Martin Fowler. Overview of Analysis Phase Preliminary identification of classes needed to implement the system. Develops static models ( class diagrams ) showing relationships between classes, and Dynamic models ( sequence, collaboration / communication, and state diagrams ) showing the interactions between classes during the execution of use cases. Focus on application domain, not solution domain. 3 1

2 Overview of the Design Process ( Analysis is the first step. ) System Design Usecases and reqs. Sequence Diagrams Class & Package Diagrams Design Goals State Diagrams Activity Diagrams Communication Diagrams 4 Concept: Three Types of Objects Entity Objects represent things, generally from the application domain. E.g. trucks, widgets, schedules, meetings, deadlines, etc. Boundary Objects handle the interfaces between the system and user or other systems. E.g. forms, data transfer interfaces. Control Objects encapsulate the control logic for a particular use-case. Directing traffic. 5 2

3 Heuristics for Identifying Entity Objects Terms that need to be defined or clarified. Anything listed in the data dictionary or glossary. Recurring nouns in use-cases or descriptions. Real-world entities the system needs to track. Real-world activities the system needs to track. e.g. emergency plans. Data sources or sinks. e.g. printers, external DB. 6 Grammatical Analysis for Identifying Objects, etc. [ Abbott, 1983 ] Parts of speech identified in descriptions, etc. indicate potential objects, attributes, methods, etc. Part of Speech Model Component Examples Proper noun Instance Alice Common noun Class Field Officer Doing ( action ) verb Operation Creates, submits, selects Being verb Inheritance Is a kind of, is one of, is a Having verb Aggregation Has, consists of, includes Modal verb Constraints Must be Adjective Attribute Color, size, weight 7 3

4 Heuristics for Identifying Boundary Objects Identify user interface controls needed to initiate use cases, e.g ReportEmergencyButton. Identify forms needed to enter data. Identify notices and messages the system needs to issue. When multiple actors are involved, identify separate actor interface terminals for each. Do not model the visual aspects of interfaces. Always use the user s terminology, not solutions. 8 Heuristics for Identifying Control Objects Identify one control object per use case. Identify one control object per actor in the use-case. ( When multiple actors are involved. ) The life span of a control object should span the extent of a use-case or user session. If that is hard to define, then the use-case probably does not have well-defined entry or exit conditions. 9 4

5 Heuristics for Drawing Sequence Diagrams First 3 columns follow ABC: The Actor that initiates the use-case. The Boundary object the actor interacts with. The Control object that controls the use-case. Control objects are created by initial boundary. Additional boundaries are created by control. Entity objects are accessed by boundary & control. Never the other way around. (Makes entities portable.) 12 Sequence Diagram for Report Emergency 1 / 3 A B C b b c 13 5

6 Sequence Diagram for Report Emergency 2 / 3 c b e b a 14 Sequence Diagram for Report Emergency 3 / 3 A C c b 15 6

7 Communication Diagrams show the same Information as Sequence Diagrams a.k.a. Collaboration Diagrams 16 Modeling Interactions with CRC Cards: Class, Responsibilities, & Collaborators Role play use-cases, with cards for classes. Determine responsibilities & collaborators of each class ( for each use-case. ) Identify missing or unused classes. 17 7

8 Heuristics for Identifying Associations Examine verb phrases. Name associations and roles precisely. Use qualifiers to identify namespaces and key attributes. Eliminate any association that can be derived from other associations. Don t worry about multiplicities until the set of associations is stable. Too many associations make a model unreadable. 18 Heuristics for Identifying Attributes Examine possessive phrases. Represent stored state as an attribute of an entity object. Describe each attribute. Do not represent an attribute as an object Use an association instead. Do not waste time describing full details until the object structure is stable. 21 8

9 Sample Results from Analysis 22 Modeling State-Dependent Behavior 23 9

10 State Diagram for Incident 24 Review the Analysis Model for: Correctness E.g. Do all objects match the descriptions in the doc? Completeness E.g. Are all objects needed, created, destroyed, & used? Consistency E.g. Multiple entities with same name or purpose? Realism E.g. Are there novel features we ve never tried or tested? 26 10

11 Iterating Over the Analysis Model The analysis model will typically be developed over three phases: 1. Brainstorming Think of as many potential objects as possible, without filters. 2. Solidification Start to settle in on objects, consolidating duplicates, eliminating unneeded. 3. Maturity The model is fairly stable, with few changes being made. Details are added. 27 ARENA Case Study See Section 5.6 of Bruegge & DuToit 29 11