CS 3610 Software Engineering Spring 2009 Dr Hisham

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 8 Analysis Modeling Part II Elements and methods of analysis modeling

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Step 1: Class Modeling (for OO Analysis) • Identify analysis classes by examining the problem statement • Use “grammatical pars” to identify potential classes • Identify the attributes of each class • Identify operations that manipulate the attributes Note that this is the approach we’ll follow for modeling our class projects. Refer to this set of slides when working on your Analysis Model. Refer to SRS Components document and use project requirements template on the website.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Analysis Classes: what to look for • External entities (e. g. , other systems, devices, people) that produce or consume information to be used by a computer-based system. • Things (e. g, reports, displays, letters, signals) that are part of the information domain for the problem. • Occurrences or events (e. g. , a property transfer or the completion of a series of robot movements) that occur within the context of system operation. • Roles (e. g. , manager, engineer, salesperson) played by people who interact with the system. • Organizational units (e. g. , division, group, team) that are relevant to an application. • Places (e. g. , manufacturing floor or loading dock) that establish the context of the problem and the overall function of the system. • Structures (e. g. , sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. CRC Modeling Method CRC modeling involves selecting classes, defining their responsibilities, and identifying collaborations among classes. Class name: Class type: (e. g. , device, property, role, event, . . . ) Class characteristics: (e. g. , tangible, atomic, concurrent, . . . ) Responsibilities: Collaborators:

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Selecting Analysis Classes A selection criteria for potential objects (classes): • Retained information: Does the system need to know about the object? • Needed services: Does the object provide needed operations? • Multiple attributes: Does the object have multiple attributes? • Common attributes: Do attributes apply to all instances of the object? • Common operations: Do operations apply to all instances of the object? • Essential requirements: Does the object represent essential entity of the system? An object that satisfies these criteria is a potential candidate for inclusion in the CRC model.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Be Aware of Class Types • Entity classes, also called model or business classes, are extracted directly from the problem statement (e. g. , Floor. Plan and Sensor). • Boundary classes are used to create the interface (e. g. , interactive screen or printed reports) that the user sees and interacts with when using the software. • Controller classes manage a “unit of work” from start to finish. That is, controller classes can be designed to manage – the creation or update of entity objects; – the instantiation of boundary objects as they obtain information from entity objects; – complex communication between sets of objects; – validation of data communicated between objects or between the user and the application.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Defining Class Responsibilities - 1 Class responsibility implies attributes and operations (i. e. , needed content such that the class performs its intended function as per the scope statement or system narrative). Suggested guideline (OO principles) for allocating responsibilities to a class: 1. System intelligence should be evenly distributed across classes. - Uneven distribution of responsibilities may lead to few dominant classes (avoid high coupling) - If a class has a long list of responsibilities, try to divide it to subclasses (facilitate maintainability)

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Defining Class Responsibilities - 2 2. Each responsibility should be stated as generally as possible, so that polymorphism is utilized (generic methods, different implementations). 3. Information and the behavior related to the class should reside within the same class, so that encapsulation is utilized (data and their methods are in the same object). 4. Information about one thing should be localized with a single class, not distributed across multiple classes. Thus, a class should be complete (maximum cohesion, minimize coupling). 5. Responsibilities should be shared among related classes, when appropriate. Thus, achieving needed collaborations.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Identifying Class Collaborations - 1 Collaboration is required when a class cannot fulfill all of its responsibility on its own (i. e. , the class doesn’t have methods to manipulate its attributes). Potential relationships: part-of: This is a subclass relationship (part of an aggregate) e. g. , class engine is part (subclass) of class car. e. g. , class sensor is part (subclass) of class controls panel. has-knowledge-of: This is true when a class requires information from another class that is not a sub/parent class. e. g. , class Engine_Status read engine temperature value from class Temperature_Sensor.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Identifying Class Collaborations - 2 depends-upon: This is true when dependency exists and not achieved via part-of or has-knowledge-of relationship. e. g. , class Transmission may depend upon class Engine. e. g. , class student_schedule may depend on class offered_courses. For a potential class, the names of collaborator classes and their relationships are recorded on the index card.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Reviewing the CRC Cards - 1 Reviewing CRC index cards can be done in different ways. • All participants in the review (of the CRC model) are given a subset of the CRC model index cards. – Cards that collaborate should be separated (i. e. , no reviewer should have two cards that collaborate). • All use-case scenarios (and corresponding use-case diagrams) should be organized into categories. • The review team leader reads the use-case deliberately. – As the review leader comes to a named object, he/she passes a token to the person holding the corresponding class index card.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Reviewing the CRC Cards - 2 • When the token is passed, the holder of the class index card is asked to describe the responsibilities noted on the card. – The group determines whether one (or more) of the responsibilities satisfies the use-case requirement. • If the responsibilities and collaborations noted on the index cards cannot accommodate the use-case, modifications are made to the cards. – This may include the definition of new classes (and corresponding CRC index cards) or the specification of new or revised responsibilities or collaborations on existing cards.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Devise Class Hierarchy Class hierarchy is a graphical presentation of class relationships (called class model) At a higher level, the system is represented by subsystems (packages in UML, page 216) and their relationships (dashed and solid arrows in UML). For example, Car system may include the subsystems Engine, Body, Powertrain, and Electronics. Various notations are available for class modeling (Booch, Coad/Yourdon, Rumbaugh). UML offers various class diagrams for different relationships, including generalization/specialization, aggregation, realization, and dependency.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Class Hierarchy Diagram - 1 Generalization Specialization

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Class Hierarchy Diagram - 2 Composite Aggregates

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Class Hierarchy Diagram - 3 Package

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Step 2: Object Relationship Modeling - 1 Object relationship modeling focus on the various relationships between objects of the system (in addition to class relationships) (derived from ER modeling). Potential relationships: part of, contains, produces, coordinates, composed of, transmits to, polls, controls, reads from, manages, next to, etc… (verbs and verb phrases) Grammatical pars of the scope statement (use-case descriptions) identifies such relationships (verbs), which in turn are recorded on the index cards.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Object Relationship Modeling - 2 Steps for deriving an object relationship model: 1. From the index cards, draw objects of the system or (subsystem) with unlabeled lines. 2. From the index cards, evaluate responsibilities and collaborators for object relationships. Label the lines on the diagram and indicate the relationship direction. 3. Evaluate each labeled relationship for cardinality and modality (similar to ERD). Repeat these steps for every subsystems.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Object Relationship Diagram Object Relationships

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Multiplicity Diagram Wa ll Figure 8. 17 1 page 215 is used to build 1 is used to build 0. . * is used to build 1. . * Wa ll. Se gm ent 1 Window Doo r 0. . *

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Dependency Diagram Camera Display. Window <<access>> {password} Figure 8. 18, Page 215

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Step 3: Behavior Modeling Object behavior modeling represents the dynamic view of the system (i. e. , system responses to external events). Object behavior modeling consists of two models: 1. Behavior modeling of the various states of each object 2. Behavior modeling of the entire system This is the approach we are using to model our class projects. Refer to the previous and this set of slides when working on your Analysis Model. Refer to SRS Components document and use project requirements template on the website.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Object Behavior Modeling states of an object: An objects may be associated with different states represented by the values of its attributes. Events (exchange of information) result in changing the values of attributes.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Object Behavior Model To create the object behavior model, the analyst must perform the following steps: - Evaluate all use-cases to fully understand the sequence of interactions within the system. - Identify events that drive the interaction sequence and understand how these events relate to specific objects. - Create an event sequence for each use-case. - Build a state diagram for the system. - Review the behavioral model to verify accuracy and consistency.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. State Representation In the context of behavioral modeling, two different characterizations of states must be considered: - the state of each class as the system performs its function and - the state of the system as observed from the outside as the system performs its function The state of a class takes on both passive and active characteristics: - A passive state is simply the current status an object’s attributes. - The active state of an object indicates the current status of the object as it undergoes a continuing transformation or processing (in response to events/triggers).

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. The State of a System • • State: a set of observable circumstances that characterizes the behavior of a system at a given time. State transition: the movement from one state to another. Event: an occurrence that causes the system to exhibit some predictable form of behavior. Action: process that occurs as a consequence of making a transition. Diagrams: • Sate Diagram: representation of an object’s states. • Sequence Diagram: representation of behavior flow among classes (derived form use-case).

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. State Diagram - Control. Panel Class t imer < locked. Time t imer > locked. Time password = incorrect & number. Of. Tries < max. Tries Figure 8. 20 page 219 locked key hit comparing reading password ent ered do: validate. Password number. Of. Tries > max. Tries password = correct select ing act ivat ion successful

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Another State Diagram

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Sequence Diagram cont rol panel homeowner system ready A sensors system reading password entered comparing request lookup result Figure 8. 21 page 220 password = correct number. Of. Tries > max. Tries A request activation locked timer > locked. Time selecting activation successful Figur e 8. 2 7 Sequence diagr am ( part ial) f or activation successful Saf e. Home secur ity f unct ion

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Event Trace Diagram Event trace diagram shows event flow among involved objects to help verify object responsibilities and event flow.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Event Flow Diagram Selects Stay/away Enter password Control panel Homeowner Ready for next action Ready for activation/deactivation System Ready Beep sounded Sensors activated/deactivated Red light on Indicates beep Activate/deactivate sensors Red light request System Event flow diagram shows input and output events for each object involved in the represented use-case.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Writing the Software Specifications Everyone knew exactly what had to be done until someone wrote it down!

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Specifications Guidelines - 1 - Use a layered format that provides increasing detail as "layers" deepen. - Use consistent graphical notation and apply textual terms consistently (stay away from aliases). - Be sure to define all acronyms. - Be sure to include a table of contents; ideally, include an index and/or a glossary. - Write in a simple, unambiguous style (see "editing suggestions" on the following slide). - Always put yourself in the reader's position, "Would I be able to understand this if I wasn't intimately familiar with the system? “

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Specifications Guidelines - 2 - Be on the lookout for persuasive connectors, ask why? keys: certainly, therefore, clearly, obviously, it follows that. . . - Watch out for vague terms. keys: some, sometimes, often, usually, ordinarily, mostly. . . - When incomplete lists are given, be sure all items are understood. keys: etc. , and so forth, and so on, such as - Be sure stated ranges don't contain unstated assumptions. e. g. , Valid codes range from 10 to 100. Integer? Real? Hex? - Beware of vague verbs such as handled, rejected, processed, . . . - Beware "passive voice" statements. e. g. , The parameters are initialized. By what? - Beware "dangling" pronouns. e. g. , The I/O module communicated with the data validation module and its control flag is set. Whose control flag?

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Specifications Guidelines - 3 - When a term is explicitly defined in one place, try substituting the definition for other occurrences of the term. - When a structure is described in words, draw a picture. - When a structure is described with a picture, try to redraw the picture to emphasize different elements of the structure. - When symbolic equations are used, try expressing their meaning in words. - When a calculation is specified, work at least two examples. - Look for statements that imply certainty, then ask for proof (e. g. , always, every, all, none, never). - Search behind certainty statements. Be sure restrictions or limitations are realistic.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Your Class Project - SRS Document - 1 First draft: Use-Case and Class modeling (3/3/09) Final draft: Object and Behavior modeling (3/17/09) High expectation: completeness, quality, and professionalism. Must include: - Use-Case Modeling Identify your actors/users of the system, define usage scenarios, define the event flow for each scenario, draw UML use-case diagrams, and provide use-case descriptions in table format. - Class Modeling Apply CRC method (chapter 8) to use-cases to identify analysis classes, draw “conceptual” UML class inheritance diagram showing relationships among classes, and provide class descriptions in table format.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Your Class Project - SRS Document - 2 - Sequence Diagrams Draw UML sequence diagram for each use-case. Derived from “Event Flow” section of use-case descriptions. - Object Collaboration Modeling Draw UML object collaboration diagram(s) to show objects interact with each other. Interactions are based on methods invocations among objects. - Object Behavior Modeling Draw UML state diagram(s) for the system to show what events make the system transition from one state to another. States are derived from actions performed classes. See Chapter 8 slides and “SRS Components” handout on the website. Use project requirements template posted on the website.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Suggested Problems Consider working the following problems from chapter 8 (textbook, page 224) for review purpose: 8. 1, 8. 2, 8. 4, 8. 5, 8. 6, 8. 7, 8. 8, 8. 11, 8. 17, and 8. 19 NO submission is required. Work them for yourself!