1. Jan. 26, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #2 Monday, Jan. 26, 2004

2. Jan. 26, 2004CS 509 - WPI2 §Term Project Administration §Questions §Quiz #1 §Lecture #2: FS, UML & Analysis §In Class Exercises: l UML Diagrams l Analysis Objects l Term Project Discussion Class Format for Today

3. Jan. 26, 2004CS 509 - WPI3 CTS Project §Turn in Phase 1 (Requirements) documents and Journals §Several emails were sent out to the class mailing list about requirements. Did everyone receive the messages? §Hand out Phase 2 document – We will discuss after the quiz

4. Jan. 26, 2004CS 509 - WPI4 Questions? §From last week’s class §From the reading §About the CTS Project §Anything else?

5. Jan. 26, 2004CS 509 - WPI5 Quiz #1 Chapters 1, 4 & 2 You have 15 minutes.

6. Jan. 26, 2004CS 509 - WPI6 Phase 2 Functional Specifications

7. Jan. 26, 2004CS 509 - WPI7 Discussion §What is a Functional Specification? §What purpose does it serve? §What goes into a FS document?

8. Jan. 26, 2004CS 509 - WPI8 Introduction §One of the most common documents used in commercial software industry §Developers might not have much input into requirements §Often your only chance to negotiate features §May need to be updated if requirements change

9. Jan. 26, 2004CS 509 - WPI9 Purpose §Further define goals and scope of the system by detailing functionality §Determine which features impact usability §Distinguish between necessary features and “wish list” features §Get client to sign-off l Consider FS to be like a contract

10. Jan. 26, 2004CS 509 - WPI10 Contents §Introduction l State purpose, scope and objectives §Detailed Functionality l Explain how requirements will be covered §Glossary §Mock-up or Prototype l Show what features will look like l Pictures often worth more than words

11. Jan. 26, 2004CS 509 - WPI11 Chapter 2 – UML Unified Modeling Language

12. Jan. 26, 2004CS 509 - WPI12 What is UML? §Unified Modeling Language comes from a number of places (see 1 st ¶ of Intro., p. 30) §Different notations combined into one standard §Now most commonly used standard in Software Engineering

13. Jan. 26, 2004CS 509 - WPI13 Why do we need notation? §Ability to articulate complex ideas succinctly & precisely §Conventions provide accuracy & clarity §Leaves less room for misinterpretation & ambiguity

14. Jan. 26, 2004CS 509 - WPI14 What does notation provide? §Well defined semantics §Well suited for representing a given aspect of a system l Easy to draw by hand §Well understood among project participants

15. Jan. 26, 2004CS 509 - WPI15 Overview of UML §Subset of UML diagrams covered in book: l Use Case diagrams l Class diagrams l Interaction diagrams (AKA Sequence diagrams) l Statechart diagrams l Activity diagrams

16. Jan. 26, 2004CS 509 - WPI16 Use Case Diagrams WatchUser ReadTime SetTime ChangeBattery SimpleWatch Figure 2-1 (page 25). A UML use case diagram describing the functionality of a simple watch. WatchRepairPerson

17. Jan. 26, 2004CS 509 - WPI17 Class Diagrams Battery load() 1 2 Time now() PushButton state push() release() 1 1 1 1 1 2 blinkIdx blinkSeconds() blinkMinutes() blinkHours() stopBlinking() referesh() LCDDisplay SimpleWatch Figure 2-2 (page 26). An expanded UML class diagram describing the elements of a simple watch

18. Jan. 26, 2004CS 509 - WPI18 Interaction Diagrams :SimpleWatch:Time:Display pressButton1() blinkHours() blinkMinutes() pressButton2() incrementMinutes() refresh() pressButtons1And2() commitNewTime() stopBlinking() pressButton1() :WatchUser Figure 2-3 (page 27). A UML sequence diagram for a simple watch

19. Jan. 26, 2004CS 509 - WPI19 Statechart Diagrams button1&2Pressed button1Pressed button2Pressed button1Pressed button1&2Pressed Increment Minutes Increment Hours Blink Hours Blink Seconds Blink Minutes Increment Seconds Stop Blinking Figure 2-4 (page 27). A UML statechart diagram for a simple watch.

20. Jan. 26, 2004CS 509 - WPI20 Activity Diagrams Open Incident Allocate Resources Coordinate Resources Document Incident Archive Incident Figure 2-5 (page 28). An example of a UML activity diagram.

21. Jan. 26, 2004CS 509 - WPI21 Modeling Concepts §Systems §Models §Views

22. Jan. 26, 2004CS 509 - WPI22 Systems §Organized set of communicating parts designed for a specific purpose §Parts can be broken down into simpler subsystems §Decomposition is recursively applied to subsystems until we get to objects §Objects are small enough to be fully comprehended without further decomposition

23. Jan. 26, 2004CS 509 - WPI23 Modeling (Slide 1) §Abstraction for dealing with complexity §Complex systems described by >1 model §Each model focuses on a different aspect §What’s interesting, what’s irrelevant? l Depends on what you’re trying to model §Rule of thumb: each entity should contain at most 7  2 parts (Why?)

24. Jan. 26, 2004CS 509 - WPI24 Modeling (Slide 2) §Abstractions that can answer specific questions about phenomena §May exist prior to the phenomena it represents l UML model of system not yet implemented l Theory derived from model prior to discovery (black hole, top quark, dark matter, etc.) §Used to communicate about the system l Notation describes model l Views show aspects of model for specific need

25. Jan. 26, 2004CS 509 - WPI25 Modeling Example §Airplane models: (see Figure 2-6, p. 36) l Scale model of exterior surface allows investigation of aerodynamics l Flight simulator models layout & behavior of flight instruments §Both models are less complex than the real life concept (airplane) they represent

26. Jan. 26, 2004CS 509 - WPI26 Views §Decomposition of a model into smaller parts §Focus on a subset of a model to make it more understandable §Views may overlap §Different notations can be used to represent the same view View Model System ** describes depicts 11 Figure from 1 st Edition of text book. A System can be described by many different Models, each of which can be depicted by many different Views

27. Jan. 26, 2004CS 509 - WPI27 More Modeling Concepts §Data Types §Abstract Data Types (ADTs) §Instances, Classes and Inheritance §Abstract Classes §Objects §Events & Messages §Falsification & Prototyping

28. Jan. 26, 2004CS 509 - WPI28 Data Types §Abstraction in context of a programming lang. §Describes an extent - a set of objects that share common characteristics: l Unique name distinguishes it from other types l Denotes a set of values valid for members of type l Defines structure of data l Defines operations valid for members of type §Examples of Data Types? l How are they defined?

29. Jan. 26, 2004CS 509 - WPI29 Abstract Data Types §Defined by an implementation-independent specification l Reason about type without worrying about impl. l Changes to implementation do not effect use §Define operations & behavior, but not internal structure - expose API only §Example ADTs? l How are they defined?

30. Jan. 26, 2004CS 509 - WPI30 Instances §Specific object of a particular type or class l Contains value in range defined by type l Has structure defined by type l Can be manipulated with operations defined by type §In Java, an instance variable is a reference to an object – what does this mean? §Difference between Type and Instance? l Examples of instances

31. Jan. 26, 2004CS 509 - WPI31 Classes §Abstraction in the context of an object-oriented programming language §Like ADT, encapsulates structure & behavior §Unlike ADT, defined in terms of other classes in an inheritance hierarchy: l Base, Super or Parent class is a generalization l Sub or Child class is a more specific refinement

32. Jan. 26, 2004CS 509 - WPI32 Inheritance §Classes define operations and attributes that can be applied to instances §Operations/attributes defined in base class are inherited by subclass §Operations/attributes which are defined only in subclass are not accessible in base class

33. Jan. 26, 2004CS 509 - WPI33 Abstract Classes § Generalization l Purpose is to model shared attributes & behavior § Used to reduce complexity, promote reuse § Represents generalized concept § Never instantiated l Does not correspond to any existing concept l Reference may be used in polymorphism § Examples?

34. Jan. 26, 2004CS 509 - WPI34 Objects §Instance of a class l Unique identity, stores attribute values (state) l Each object belongs to exactly one class §Instance names are underlined in UML l Distinguish from type/class that defines them § Attributes may not be visible to entire system l Type modifiers specify visibility l Examples?

35. Jan. 26, 2004CS 509 - WPI35 Events and Messages §Event Class: an abstraction for a kind of event §Event: instance of an Event Class l Can be a Message sent from one object to another l Other examples? §Message: l Usually a request or notification l Name and some arguments l Corresponds to some operation

36. Jan. 26, 2004CS 509 - WPI36 Object-oriented Modeling §Used in both analysis and design §Analysis focuses on application domain l Represents aspects of the user’s environment l Helps developers understand the problem(s) §Design focuses on solution domain l Richer space of all possible solutions l Changes with technology (Figure 2-12, page 42)

37. Jan. 26, 2004CS 509 - WPI37 Figure 2-12. The application domain model represents entities of the environment which are relevant to an air traffic control system (e.g., aircraft, traffic controllers). The system model represents entities that are part of the system (e.g., map display, flight plan database). In object-oriented analysis and design, the application domain model is also part of the system model. An example in this figure is the TrafficControl package that appears in both models.

38. Jan. 26, 2004CS 509 - WPI38 Falsification and Prototyping §Falsification: l Process of identifying defects in the model Details missing or incorrectly represented Model doesn’t correspond to reality §Prototype: l Simulate some aspect of solution (often UI) l Users may falsify prototype §Easier to demonstrate that a model is incorrect than to prove it is correct – why?

39. Jan. 26, 2004CS 509 - WPI39 UML Exercise – Diagrams Vending Machine Problem §Discussion: define problem l How would you model a vending machine? l What is the process of making a purchase? §Create Diagrams l Which type of diagram l Model some piece of problem l Present to class

40. Jan. 26, 2004CS 509 - WPI40 Short Break Review Functional Specification Assignment

41. Jan. 26, 2004CS 509 - WPI41 Questions? §Lecture on Chapter 2 §About FS Assignment §Anything else?

42. Jan. 26, 2004CS 509 - WPI42 Analysis Chapter 5

43. Jan. 26, 2004CS 509 - WPI43 Purpose of Analysis §To better understand requirements §Identify objects & types in the problem domain l May or may not be same objects in design of solution §Identify attributes & associations §Model interactions between objects §Model Nontrivial Behavior §Model Generalization Relationships

44. Jan. 26, 2004CS 509 - WPI44 Terminology & Activities §Entity, Boundary and Control Objects §Mapping Use Cases to Objects §Modeling Interactions among Objects §Associations, Aggregates & Attributes §Modeling State-Dependent Behavior §Modeling Inheritance Relationships

45. Jan. 26, 2004CS 509 - WPI45 Identifying Object Types §Entity Object: l Persistent information tracked by system l E.g. Month, Day, Year §Boundary Object: l Interactions between actors & system l E.g. Button, Display §Control Object: l Tasks performed by User, supported by System l E.g. ChangeDate

46. Jan. 26, 2004CS 509 - WPI46 Heuristics for Object Types §Entity objects: l Box on page 181 §Boundary objects: l Box on page 183 §Control objects: l Box on page 184

47. Jan. 26, 2004CS 509 - WPI47 Mapping Use Cases to Objects §Sequence diagrams tie use cases to objects §Show how behavior in use case is distributed among participating objects §Model the sequence of interactions among objects to realize use case §Sequence diagrams are not appropriate for a non-technical audience (Why not?) §See example diagrams on pages 186-187

48. Jan. 26, 2004CS 509 - WPI48 Interactions Among Objects §CRC cards can also be used to model interactions among objects l Class, Responsibilities, Collaborators, Beck & Cunningham, 1989 §Each class is represented with an index card l Name of class, Responsibilities, Names of other classes (dependencies) §See examples on page 190

49. Jan. 26, 2004CS 509 - WPI49 Identifying Associations §Class diagrams describe interdependencies among classes §Associations depict relationships between 2 or more classes §Heuristics box on page 191 §Association examples on pages 190, 192

50. Jan. 26, 2004CS 509 - WPI50 Associations & Multiplicity §Types of associations: l one-to-one l one-to-many l many-to-many §Symbols used to represent multiplicity: l 1 - may be assumed by default, 2 … n l * - zero or more l + - one or more l ? - zero or one

51. Jan. 26, 2004CS 509 - WPI51 Identifying Aggregates §An Aggregate is a type of association: l Whole-part relationship, denotes containment §Composition Aggregation l Existence of parts depends on the whole §Shared Aggregation l Whole and parts can exist independently §See examples, bottom of page 192

52. Jan. 26, 2004CS 509 - WPI52 Identifying Attributes §Properties of individual objects §Each attribute should have: l name identifying it within an object l description to remember what it’s for l type defining legal values it can take on §Heuristics for identifying attributes, p. 194

53. Jan. 26, 2004CS 509 - WPI53 State-Dependent Behavior §Statechart diagrams can be used to model behavior of a single object §Gives a different perspective when compared to Sequence diagrams §By focusing on states, can identify new behavior §Which objects require statecharts?

54. Jan. 26, 2004CS 509 - WPI54 Inheritance Relationships §Generalization relationships can be modeled using UML Class diagrams l See Figure 5-18, page 196 §Use when two or more classes share attributes and/or behavior §Organize concepts into hierarchies from most general to most specific §Eliminate redundancy

55. Jan. 26, 2004CS 509 - WPI55 Analysis Model §Is this a useful activity? l Identifying object types – terminology, concepts l Constructing sequence & state-chart diagrams l Associations and generalizations §At what point does analysis apply to a software development project? §Is it required for this course?

56. Jan. 26, 2004CS 509 - WPI56 Analysis Exercise Identifying Objects & Object Types

57. Jan. 26, 2004CS 509 - WPI57 File System Analysis (From textbook, exercises #1-5, page 219) §File system with GUI – e.g., File Explorer §Activity: copy file from floppy to hard disk l How is this accomplished? §Tasks: l Identify objects & object types l Identify associations, attributes, generalizations

58. Jan. 26, 2004CS 509 - WPI58 Term Project Discussion §Use of tools: Rational Rose, ClearCase, etc. §Send soft copy of phase 1 by email l If there’s time, I will consolidate requirements §Continue with phase 2 for same tool(s) as phase 1 l Research technology – include feasibility analysis l Anyone want to change tool(s) at this point? §Can choose different piece for phase 3

59. Jan. 26, 2004CS 509 - WPI59 For Next Time Read Chapter 3 Project Communication