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

Jan. 26, 2004CS 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

Jan. 26, 2004CS WPI3 CTS Project §Turn in Phase 1 (Requirements) documents and Journals §Several s 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

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

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

Jan. 26, 2004CS WPI6 Phase 2 Functional Specifications

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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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

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

Jan. 26, 2004CS 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

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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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

Jan. 26, 2004CS WPI17 Class Diagrams Battery load() 1 2 Time now() PushButton state push() release() 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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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.

Jan. 26, 2004CS 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.

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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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?)

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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

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

Jan. 26, 2004CS 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?

Jan. 26, 2004CS 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?

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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?

Jan. 26, 2004CS 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?

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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)

Jan. 26, 2004CS WPI37 Figure 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.

Jan. 26, 2004CS 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?

Jan. 26, 2004CS 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

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

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

Jan. 26, 2004CS WPI42 Analysis Chapter 5

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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?

Jan. 26, 2004CS 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

Jan. 26, 2004CS 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?

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

Jan. 26, 2004CS 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

Jan. 26, 2004CS WPI58 Term Project Discussion §Use of tools: Rational Rose, ClearCase, etc. §Send soft copy of phase 1 by 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

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