Introduction to Software Development

1. NFC-IET-2011 Introduction to Software Development Instructor: SomiaRazzaq Lecture-06 Analysis Dated: April 18, 2011

2. Outline • Analysis • An overview of Analysis • Analysis Concepts • Analysis Activities • Activities during object modeling

3. Analysis • Formalize the specification produced during requirements elicitation • Developers build a model of the application domain • What are the objects? • What are their attributes? • How do the actors and the system interact? • Analysis model +non functional requirements -> Architecture • Why do we call it ANALYSIS? • Define analysis

4. Analysis 1. A separating or breaking up of any whole into its parts so as to find out their nature, proportion, function, relationship, etc. Webster’s New World Dictionary

5. An Overview of Analysis /1 • Analysis ->model • Correct • Complete • Consistent • Verifiable • Requirements elicitation and Analysis • Requirement elicitation: gathering of requirements • Analysis: Structuring and formalization of user requirements. • Analysis Model • Functional model: use case and scenarios • Object model: class and object diagrams • Dynamic model: state chart and sequence diagrams

6. Analysis Concepts: Object models and Dynamic models • Object model • Represented by UML Class diagrams • Classes, attributes and operation • Dynamic model • Behavior of the system • Sequence diagrams and state charts

7. <<entity>> <<control>> <<boundary>> Year ChangeDateControl ButtonBoundary <<entity>> <<boundary>> Month LCDDisplayBoundary <<entity>> Day Analysis Concepts: Object models and Dynamic models • 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 Analysis classes for the 2Bwatch example.

8. Analysis Concepts: Generalization and Specialization • Inheritance • Enables to organize into hierarchies • Generalization • Modeling activity that identifies abstract concepts from lower-level ones. • Specialization • Modeling activity that identifies abstract concepts from high-level one. Incident LowPriority Emergency Disaster EarthQuake ChemicalLeak TrafficAccident BuildingFire

9. Analysis Activities: From use cases to objects • Analysis model activities: • Identify entity objects • Identify boundary objects • Identify control objects • Mapping use case to Objects with Sequence Diagrams • Identifying Associations • Identify aggregates • Identify attributes • Modeling state-dependent behavior of Individual Objects • Modeling Inheritance Relationships • Review the Analysis Model

10. Analysis Activities: Identifying Entity Objects • Participating object form basis for analysis model • Examine each use case: identify candidate objects

11. Analysis Activities: Identifying Boundary Objects • System interfaces with actors • Collect information from the actor and translate it into a form that can be used by other objects in the system • Use a coarse level • Allows the interface to change without having to change the analysis model • Heuristics for identifying boundary objects • Identify data entry forms/windows (e.g. EmergencyReportForm, ReportEmergencyButton) • Identify messages system sends to user (e.g., AcknowledgementNotice) • Use the user’s terms as opposed to implementation terms

12. Analysis Activities: Identifying Control Objects • Coordinate between boundary and entity objects • Usually do not have a real world counterpart • Relate closely to use case • Responsible for collecting information from boundary objects and relaying it to entity objects Heuristics for identifying control objects • Identify a small number of control objects per use case. Each flow of events should have a control object. • Identify a control object for each actor • A control object should exist for only one use case. (Its lifespan should be just one use case.)

13. Analysis Activities: Login to Internet Bookstore Example • Actor: Customer • Use case - flow of events • The customer clicks the login button on the home page. • The system displays the login page. • The customer enters his/her user ID and password and clicks the OK button. • The system validates the login information against the accounts data. • The system returns the customer to the home page. • Entity objects • Customer • Account • Boundary Objects • Home page • Login page • Buttons? • Control Objects • Display

14. Dynamic Modeling • Definition of dynamic model: • The behavioral view of a system: • Sequence Diagram • shows interaction between classes and object in a time ordered way • Purpose: • Detect and supply methods for the object model • How do we do this? • Start with use case or scenario • Model interaction between objects => sequence diagram • Model dynamic behavior of a single object => statechart diagram

15. Dynamic Modeling with UML • Diagrams for dynamic modeling • Interaction diagrams describe the dynamic behavior between objects • Statecharts describe the dynamic behavior of a single object • Interaction diagrams • Sequence Diagram: • Dynamic behavior of a set of objects arranged in time sequence. • Good for real-time specifications and complex scenarios • Collaboration Diagram : • Shows the relationship among objects. Does not show time • State Chart Diagram: • A state machine that describes the response of an object of a given class to the receipt of outside stimuli (Events). • Activity Diagram: A special type of statechart diagram, where all states are action states

16. Classes from Dynamic modeling • How to identify classes from dynamic models • Sequence diagrams • Distribution of behavior of use cases among participating objects. • Model sequence of interactions among objects. • Activity lines in sequence diagrams are candidates for objects. • State chart diagrams • Actions and activities in state chart diagrams are candidates for public operations in classes

17. Mapping Use Cases to Objects with Sequence Diagrams • Sequence diagrams tie use cases and objects together • Objects that participate in use case form columns • Vertical dashed line is called the lifeline • Time progresses from top to bottom • Horizontal arrows represent messages sent from one object to another • Rectangles represent the activation of an operation

18. :SimpleWatch :LCDDisplay :Time :WatchUser pressButton1() blinkHours() pressButton1() blinkMinutes() pressButton2() incrementMinutes() refresh() pressButtons1And2() commitNewTime() stopBlinking() UML First Pass: Sequence Diagram Object Message Activation Sequence diagrams represent the behavior as interactions

21. Example Sequence Diagram

22. Heuristics for drawing sequence diagrams • Actor who initiates – on the left • Next - the boundary object that the actor uses to initiate • Next – the first use case control object • Boundary objects are created by control objects • Entity objects are accessed by control objects and boundary objects

23. What else can we get out of sequence diagrams? • Sequence diagrams are derived from the use cases. We therefore see the structure of the use cases. • The structure of the sequence diagram helps us to determine how decentralized the system is.

24. Class name Responsibilities Collaborators tasks that the class is required to carry out (will become operations on the class) the classes that request the tasks Modeling Interactions among Objects with CRC CARDS • helps us to “think object” • too many responsibilities Ælow cohesion • too many collaborators Æhigh coupling

25. Modeling Interactions among Objects with CRC CARDS CRC cards for the ReportEmergencyControl and the Incident classes.

26. Identifying Associations • Association • Relationship between two or more classes • One-to-many association • An example of association between the EmergencyReport and the FieldOfficer classes. EmergencyReport FieldOfficer 1 writes * document author

27. Country City name:String name:String Mechanics Plane Identifying Associations Has-capital One-to-one association Many-to-many association Work on * *

28. Identifying Aggregation • Models "part of" hierarchy • Useful for modeling the breakdown of a product into its component parts • UML notation: uses a small diamond to indicate the assembly end of the relationship.

29. Automobile serial number Engine year manufacturer horsepower volume model on color off weight drive purchase Battery Wheel amps volts Brakelight diameter Door charge discharge number of bolts open on close off Identifying Aggregation 1 3,4,5 2,4 1 *

30. State FireStation County FireFighter LeadCar FireEngine Ambulance Township Identifying Aggregation • Aggregation • Special types of associations; whole-part relationship • Composition Aggregation • Existence of the parts depends on the whole • Shared Aggregation

31. EmergencyReport emergencyType:{fire,traffic,other} location:String description:String Identifying Attribute • Attributes • Proprieties of individual objects • Attributes • Name • A brief description • Type; legal values

32. Statechart Diagrams • Graph whose nodes are states and whose directed arcs are transitions labeled by event names. • A statechart diagram relates events and states for one class • An object model with a set of objects has a set of state diagrams

33. State • State • State is a defined set of properties which describe an object or thing at a given time. • State may change when the properties making up the state change. • An abstraction of the attribute of a class • A condition that is satisfied by the attribute values of an object or subsystem • State is the aggregation of several attributes of a class • Incident: Active, Inactive, Closed and Archived • State has duration

34. UML Statechart Diagram Notation • A UML statechart diagram can be mapped into a finite state machine Event trigger With parameters State1 State2 Event1(attr) [condition]/action do/Activity Guard condition entry /action exit/action

35. all reports are submitted Active Inactive Closed Archived numAllocatedResource == 0 when incident.date > 1yr. UML statechart for Incident.

36. Increment Hours button2Pressed button1&2Pressed Blink Hours button1Pressed Increment Minutes button2Pressed button1&2Pressed Blink Minutes button1Pressed Increment Seconds button2Pressed Blink Stop Seconds Blinking Statechart diagram for 2Bwatch State Initial state Transition Event button1&2Pressed Final state

37. PoliceOfficer badgeNumber:Integer FieldOfficer Dispatcher Modeling Inheritance Relationship between Objects • Generalization • Eliminate redundancy from the analysis model • Two or more classes share attributes or behavior • Similarities are consolidated into super class • badgeNumber

38. Analysis activities (UML activities diagram).

39. Reviewing the Analysis Model • Analysis model built incrementally and iteratively • omission discovered during analysis may lead to new use case • E.g. What happens to student applications after students have been selected for a term? Do we need an archive or purge applications use case? • Reviews conducted to ensure that the necessary attributes are met

40. 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 users’ definitions? • Do all use cases and control objects have meaningful verb phrases as names? • Etc.

41. 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 phenomena? • Are all entities described at the same level of detail?

42. Model Realistic? • Are there any novel features of the system? Were any studies or prototypes built to ensure their feasibility? • Can the performance and reliability be met? • Etc.

43. Managing Analysis • Documenting • Assigning Responsibilities • Communicating • Client Sign-off

44. Requirements Analysis Document Template 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

45. Documenting Analysis • RAD documents both requirements elicitation and analysis activities • Many sections written during requirements elicitation • Those sections are reviewed and revised • New sections are added • Object models • Dynamic models • User interface: screen mockups, forms

46. Object Models • Document the domain objects identified • Attributes • As complete as possible • No data types needed • Operations • From sequence diagrams • List may be incomplete • No logic • Class diagrams showing relationships • Data Dictionary with text descriptions

47. Dynamic Models • Statechart diagrams for complex behavior of objects • Sequence diagrams for use cases • Although they contain redundant information (have textual flow of events with use cases) useful because they are more precise and will help the designers understand the system

48. Assigning Responsibilities • Analysis involves many individuals • User and client • Analyst, architect, document editor, configuration manager, reviewer • Challenging to coordinate and communicate • Assign types of roles: • Generation of information • Integration • Review

49. User and Client • User • Domain expert • Generates information about the current system and about the tasks that the future system should support • Corresponds to one or more actors • Helps identify their use cases • Client • Integration of user requests • Defines the scope of the system based on (sometimes conflicting) user requirements

50. Analyst and Architect • Analyst • Development domain expert • Models current system • Generates information about the future system • Architect • Integrates the use case and object models • Ensures consistency and completeness • Develops system philosophy