1. Sept. 25, 2003CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Thursday, Sept. 25, 2003

2. Sept. 25, 2003CS 509 - WPI2 §Term Project administration §Questions §Quiz #2 §Review Chapter 2 §UML Exercise Class Format for Today

3. Sept. 25, 2003CS 509 - WPI3 Meeting Coordinator Project §Return Phase 1 (Requirements) document l Job well done! l Grading criteria §Group evaluation forms l No major issues l Is this a worthwhile activity?

4. Sept. 25, 2003CS 509 - WPI4 Questions? §About Phase 2 §From last week’s class §From the reading §Anything else?

5. Sept. 25, 2003CS 509 - WPI5 Quiz #2 Choose 5 questions to answer Or answer 6 for extra credit

6. Sept. 25, 2003CS 509 - WPI6 Chapter 2 – UML Unified Modeling Language

7. Sept. 25, 2003CS 509 - WPI7 What is UML? §Unified Modeling Language comes from a number of places (see 1 st ¶ of Intro., p. 24) §Different notations combined into one standard §Now most commonly used standard in Software Engineering

8. Sept. 25, 2003CS 509 - WPI8 Why do we need notation? §Ability to articulate complex ideas succinctly & precisely §Conventions provide accuracy & clarity §Leaves less room for misinterpretation & ambiguity

9. Sept. 25, 2003CS 509 - WPI9 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

10. Sept. 25, 2003CS 509 - WPI10 Overview of UML §Subset of UML diagrams covered in book: l Use Case diagrams l Class diagrams l Sequence diagrams l Statechart diagrams l Activity diagrams

11. Sept. 25, 2003CS 509 - WPI11 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

12. Sept. 25, 2003CS 509 - WPI12 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

13. Sept. 25, 2003CS 509 - WPI13 Sequence 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

14. Sept. 25, 2003CS 509 - WPI14 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.

15. Sept. 25, 2003CS 509 - WPI15 Activity Diagrams Open Incident Allocate Resources Coordinate Resources Document Incident Archive Incident Figure 2-5 (page 28). An example of a UML activity diagram.

16. Sept. 25, 2003CS 509 - WPI16 Modeling Concepts §Systems §Models §Views §Phenomena §Concepts §Abstraction

17. Sept. 25, 2003CS 509 - WPI17 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

18. Sept. 25, 2003CS 509 - WPI18 Modeling §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?)

19. Sept. 25, 2003CS 509 - WPI19 Modeling Example §Airplane models: 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

20. Sept. 25, 2003CS 509 - WPI20 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 2-8 (page 31). A System can be described by many different Models, each of which can be depicted by many different Views

21. Sept. 25, 2003CS 509 - WPI21 Phenomena & Concepts §A Phenomenon is an object as it is perceived in the world l An instance of a concept §A Concept is a generalization (abstraction) for some group of phenomena l Describes properties that are common across a set of phenomena

22. Sept. 25, 2003CS 509 - WPI22 Concepts & Abstraction §A Concept is defined as a 3-tuple: l Name l Purpose (intent) l Members (extent) §Abstraction: l Classification of phenomena into concepts l Simpler to manipulate & examine (less info) l Irrelevant details are “abstracted away”

23. Sept. 25, 2003CS 509 - WPI23 Modeling Revisited §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

24. Sept. 25, 2003CS 509 - WPI24 More Modeling Concepts §Data Types §Abstract Data Types (ADTs) §Instances, Classes and Inheritance §Abstract Classes §Objects §Events & Messages §Falsification & Prototyping

25. Sept. 25, 2003CS 509 - WPI25 Data Types §Abstraction in the context of a programming language §Describes a set of instances that share common characteristics: Name distinguishes it from other data types (e.g. int, char, etc.) l Purpose defines structure & operations valid on all members of the type l Members comprise the extent of the type

26. Sept. 25, 2003CS 509 - WPI26 Abstract Data Types  Defines a data type at a higher level of abstraction ( LinkedList, Stack ) §Defines operations & behavior, but not internal structure: Exposes API only (e.g. push, pop, etc.) l Hides implementation details l Changes to internal representation should not effect use by caller

27. Sept. 25, 2003CS 509 - WPI27 Instances §An Instance is any member of a specific data type (abstract or not) l Can be manipulated with operations defined by the type l Internal structure may or may not be hidden §A data type is similar to a concept §An instance is similar to a phenomenon

28. Sept. 25, 2003CS 509 - WPI28 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

29. Sept. 25, 2003CS 509 - WPI29 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

30. Sept. 25, 2003CS 509 - WPI30 Abstract Classes § Generalization l Purpose is to model shared attributes & behavior § Represents generalized concepts § Never instantiated l Does not correspond to any existing concept § Used to reduce complexity, promote reuse § Examples?

31. Sept. 25, 2003CS 509 - WPI31 Objects §Instances 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?

32. Sept. 25, 2003CS 509 - WPI32 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 §Message: l Usually a request or notification l Name and some arguments l Corresponds to some operation

33. Sept. 25, 2003CS 509 - WPI33 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-14, page 37)

34. Sept. 25, 2003CS 509 - WPI34 Figure 2-14. 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.

35. Sept. 25, 2003CS 509 - WPI35 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?

36. Sept. 25, 2003CS 509 - WPI36 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

37. Sept. 25, 2003CS 509 - WPI37 For Next Time Chapter 3 Project Communication