jan. 26, 2004cs 509 - wpi1 cs 509 design of software systems lecture #2 monday, jan. 26, 2004
Post on 17-Jan-2016
222 Views
Preview:
TRANSCRIPT
Jan. 26, 2004 CS 509 - WPI 1
CS 509Design of Software Systems
Lecture #2Monday, Jan. 26, 2004
Jan. 26, 2004 CS 509 - WPI 2
Term Project AdministrationQuestionsQuiz #1Lecture #2: FS, UML & AnalysisIn Class Exercises:
UML Diagrams Analysis Objects Term Project Discussion
Class Format for Today
Jan. 26, 2004 CS 509 - WPI 3
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
Jan. 26, 2004 CS 509 - WPI 4
Questions?
From last week’s classFrom the readingAbout the CTS ProjectAnything else?
Jan. 26, 2004 CS 509 - WPI 5
Quiz #1
Chapters 1, 4 & 2You have 15 minutes.
Jan. 26, 2004 CS 509 - WPI 6
Phase 2
Functional Specifications
Jan. 26, 2004 CS 509 - WPI 7
Discussion
What is a Functional Specification?
What purpose does it serve?What goes into a FS document?
Jan. 26, 2004 CS 509 - WPI 8
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, 2004 CS 509 - WPI 9
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 Consider FS to be like a contract
Jan. 26, 2004 CS 509 - WPI 10
Contents
Introduction State purpose, scope and objectives
Detailed Functionality Explain how requirements will be
coveredGlossaryMock-up or Prototype
Show what features will look like Pictures often worth more than words
Jan. 26, 2004 CS 509 - WPI 11
Chapter 2 – UML
Unified Modeling Language
Jan. 26, 2004 CS 509 - WPI 12
What is UML?
Unified Modeling Language comes from a number of places (see 1st ¶ of Intro., p. 30)
Different notations combined into one standard
Now most commonly used standard in Software Engineering
Jan. 26, 2004 CS 509 - WPI 13
Why do we need notation?
Ability to articulate complex ideas succinctly & precisely
Conventions provide accuracy & clarity
Leaves less room for misinterpretation & ambiguity
Jan. 26, 2004 CS 509 - WPI 14
What does notation provide?
Well defined semanticsWell suited for representing a
given aspect of a system Easy to draw by hand
Well understood among project participants
Jan. 26, 2004 CS 509 - WPI 15
Overview of UML
Subset of UML diagrams covered in book: Use Case diagrams Class diagrams Interaction diagrams (AKA Sequence
diagrams) Statechart diagrams Activity diagrams
Jan. 26, 2004 CS 509 - WPI 16
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, 2004 CS 509 - WPI 17
Class Diagrams
Batteryload()
1
2
Timenow()
PushButtonstatepush()release()
1
1
1
1
1
2
blinkIdxblinkSeconds()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, 2004 CS 509 - WPI 18
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, 2004 CS 509 - WPI 19
Statechart Diagrams
button1&2Pressed
button1Pressed
button2Pressed
button2Pressed
button2Pressed
button1Pressed
button1&2Pressed IncrementMinutes
IncrementHours
BlinkHours
BlinkSeconds
BlinkMinutes
IncrementSeconds
StopBlinking
Figure 2-4 (page 27). A UML statechart diagram for a simple watch.
Jan. 26, 2004 CS 509 - WPI 20
Activity Diagrams
OpenIncident
AllocateResources
CoordinateResources
DocumentIncident
ArchiveIncident
Figure 2-5 (page 28). An example of a UML activity diagram.
Jan. 26, 2004 CS 509 - WPI 21
Modeling Concepts
SystemsModelsViews
Jan. 26, 2004 CS 509 - WPI 22
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, 2004 CS 509 - WPI 23
Modeling (Slide 1)
Abstraction for dealing with complexityComplex systems described by >1 modelEach model focuses on a different aspectWhat’s interesting, what’s irrelevant?
Depends on what you’re trying to modelRule of thumb: each entity should contain
at most 7 2 parts (Why?)
Jan. 26, 2004 CS 509 - WPI 24
Modeling (Slide 2)Abstractions that can answer specific
questions about phenomenaMay exist prior to the phenomena it
represents UML model of system not yet implemented Theory derived from model prior to discovery
(black hole, top quark, dark matter, etc.)Used to communicate about the system
Notation describes model Views show aspects of model for specific need
Jan. 26, 2004 CS 509 - WPI 25
Modeling Example
Airplane models: (see Figure 2-6, p. 36) Scale model of exterior surface allows
investigation of aerodynamics Flight simulator models layout &
behavior of flight instrumentsBoth models are less complex than
the real life concept (airplane) they represent
Jan. 26, 2004 CS 509 - WPI 26
Views
Decomposition of a model into smaller partsFocus on a subset of a model to make it
more understandableViews may overlapDifferent notations can be used to represent
the same view
View Model System**
describesdepicts
1 1
Figure from 1st 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, 2004 CS 509 - WPI 27
More Modeling Concepts
Data TypesAbstract Data Types (ADTs)Instances, Classes and InheritanceAbstract ClassesObjectsEvents & MessagesFalsification & Prototyping
Jan. 26, 2004 CS 509 - WPI 28
Data Types
Abstraction in context of a programming lang.
Describes an extent - a set of objects that share common characteristics: Unique name distinguishes it from other types Denotes a set of values valid for members of
type Defines structure of data Defines operations valid for members of type
Examples of Data Types? How are they defined?
Jan. 26, 2004 CS 509 - WPI 29
Abstract Data Types
Defined by an implementation-independent specification Reason about type without worrying about
impl. Changes to implementation do not effect
useDefine operations & behavior, but not
internal structure - expose API onlyExample ADTs?
How are they defined?
Jan. 26, 2004 CS 509 - WPI 30
Instances
Specific object of a particular type or class Contains value in range defined by type Has structure defined by type Can be manipulated with operations defined
by typeIn Java, an instance variable is a reference
to an object – what does this mean?Difference between Type and Instance?
Examples of instances
Jan. 26, 2004 CS 509 - WPI 31
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: Base, Super or Parent class is a
generalization Sub or Child class is a more specific
refinement
Jan. 26, 2004 CS 509 - WPI 32
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, 2004 CS 509 - WPI 33
Abstract Classes
Generalization Purpose is to model shared attributes &
behaviorUsed to reduce complexity, promote
reuseRepresents generalized conceptNever instantiated
Does not correspond to any existing concept Reference may be used in polymorphism
Examples?
Jan. 26, 2004 CS 509 - WPI 34
Objects
Instance of a class Unique identity, stores attribute values (state) Each object belongs to exactly one class
Instance names are underlined in UML Distinguish from type/class that defines them
Attributes may not be visible to entire system Type modifiers specify visibility Examples?
Jan. 26, 2004 CS 509 - WPI 35
Events and Messages
Event Class: an abstraction for a kind of event
Event: instance of an Event Class Can be a Message sent from one object to
another Other examples?
Message: Usually a request or notification Name and some arguments Corresponds to some operation
Jan. 26, 2004 CS 509 - WPI 36
Object-oriented Modeling
Used in both analysis and designAnalysis focuses on application domain
Represents aspects of the user’s environment
Helps developers understand the problem(s)Design focuses on solution domain
Richer space of all possible solutions Changes with technology
(Figure 2-12, page 42)
Jan. 26, 2004 CS 509 - WPI 37
Application Domain Solution DomainApplication Domain Model System Model
AircraftTrafficController
FlightPlan Airport
MapDisplay
FlightPlanDatabase
SummaryDisplay
TrafficControl
TrafficControl
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.
Jan. 26, 2004 CS 509 - WPI 38
Falsification and Prototyping
Falsification: Process of identifying defects in the model
• Details missing or incorrectly represented• Model doesn’t correspond to reality
Prototype: Simulate some aspect of solution (often UI) Users may falsify prototype
Easier to demonstrate that a model is incorrect than to prove it is correct – why?
Jan. 26, 2004 CS 509 - WPI 39
UML Exercise – Diagrams
Vending Machine ProblemDiscussion: define problem
How would you model a vending machine?
What is the process of making a purchase?
Create Diagrams Which type of diagram Model some piece of problem Present to class
Jan. 26, 2004 CS 509 - WPI 40
Short Break
Review Functional SpecificationAssignment
Jan. 26, 2004 CS 509 - WPI 41
Questions?
Lecture on Chapter 2About FS AssignmentAnything else?
Jan. 26, 2004 CS 509 - WPI 42
Analysis
Chapter 5
Jan. 26, 2004 CS 509 - WPI 43
Purpose of Analysis
To better understand requirementsIdentify objects & types in the problem
domain May or may not be same objects in design of
solutionIdentify attributes & associationsModel interactions between objectsModel Nontrivial BehaviorModel Generalization Relationships
Jan. 26, 2004 CS 509 - WPI 44
Terminology & Activities
Entity, Boundary and Control ObjectsMapping Use Cases to ObjectsModeling Interactions among ObjectsAssociations, Aggregates & AttributesModeling State-Dependent BehaviorModeling Inheritance Relationships
Jan. 26, 2004 CS 509 - WPI 45
Identifying Object Types
Entity Object: Persistent information tracked by system E.g. Month, Day, Year
Boundary Object: Interactions between actors & system E.g. Button, Display
Control Object: Tasks performed by User, supported by
System E.g. ChangeDate
Jan. 26, 2004 CS 509 - WPI 46
Heuristics for Object Types
Entity objects: Box on page 181
Boundary objects: Box on page 183
Control objects: Box on page 184
Jan. 26, 2004 CS 509 - WPI 47
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
Jan. 26, 2004 CS 509 - WPI 48
Interactions Among Objects
CRC cards can also be used to model interactions among objects Class, Responsibilities, Collaborators,
Beck & Cunningham, 1989Each class is represented with an
index card Name of class, Responsibilities, Names of
other classes (dependencies)See examples on page 190
Jan. 26, 2004 CS 509 - WPI 49
Identifying Associations
Class diagrams describe interdependencies among classes
Associations depict relationships between 2 or more classes
Heuristics box on page 191Association examples on pages
190, 192
Jan. 26, 2004 CS 509 - WPI 50
Associations & MultiplicityTypes of associations:
one-to-one one-to-many many-to-many
Symbols used to represent multiplicity: 1 - may be assumed by default, 2 … n * - zero or more + - one or more ? - zero or one
Jan. 26, 2004 CS 509 - WPI 51
Identifying Aggregates
An Aggregate is a type of association: Whole-part relationship, denotes
containmentComposition Aggregation
Existence of parts depends on the wholeShared Aggregation
Whole and parts can exist independentlySee examples, bottom of page 192
Jan. 26, 2004 CS 509 - WPI 52
Identifying Attributes
Properties of individual objectsEach attribute should have:
name identifying it within an object description to remember what it’s for type defining legal values it can take
onHeuristics for identifying
attributes, p. 194
Jan. 26, 2004 CS 509 - WPI 53
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, 2004 CS 509 - WPI 54
Inheritance Relationships
Generalization relationships can be modeled using UML Class diagrams 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, 2004 CS 509 - WPI 55
Analysis Model
Is this a useful activity? Identifying object types – terminology,
concepts Constructing sequence & state-chart
diagrams Associations and generalizations
At what point does analysis apply to a software development project?
Is it required for this course?
Jan. 26, 2004 CS 509 - WPI 56
Analysis Exercise
Identifying Objects& Object Types
Jan. 26, 2004 CS 509 - WPI 57
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 How is this accomplished?
Tasks: Identify objects & object types Identify associations, attributes,
generalizations
Jan. 26, 2004 CS 509 - WPI 58
Term Project Discussion
Use of tools: Rational Rose, ClearCase, etc.
Send soft copy of phase 1 by email If there’s time, I will consolidate
requirementsContinue with phase 2 for same tool(s)
as phase 1 Research technology – include feasibility
analysis Anyone want to change tool(s) at this point?
Can choose different piece for phase 3
Jan. 26, 2004 CS 509 - WPI 59
For Next Time
Read Chapter 3Project Communication
top related