System Analysis and Design

1
System Analysis and Design

• Structural Modeling

2
Outline

• Structural Modeling
• Class diagrams
• Object diagrams
• How to create diagrams

3
What is Structural Model?

• Structural model a view of a system that
  emphasizes the structure of the objects,
  including their classes, relationships,
  attributes and operations.
• Purpose
• Reduce the semantic gap between the real world
  and the world of software
• Create a vocabulary for analysts and users
• Represent things, ideas, and concepts of
  importance in the application domain

4
Elements of Structural Model

• Classes
• Templates for creating instances or objects
• Concrete
• Abstract
• Typical examples
• Application domain, solution domain (user
  interface, data structure, file structure,
  operating environment, document, and multimedia
  classes)
• Attributes
• Units of information relevant to the description
  of the class
• Only attributes important to the task should be
  included
• Operations
• Action that instances/objects can take
• Focus on relevant problem-specific operations (at
  this point
• Relationships (Associations)
• Generalization
• Enables inheritance of attributes and operations
• Aggregation
• Relates parts to wholes
• Association
• Miscellaneous relationships between classes

5
Classes are Classifiers

• A classifier is a mechanism for describing
  structural and behavioral features.
• Nine classifiers in UML 2.0
• Classes, interfaces, datatypes, signals,
  components, nodes, use cases, subsystems.
• Advanced features
• Multiplicity, visibility, signatures, polymorphism

6
Class
name
Window
origin size
attributes
Open() Close() Move() Display()
operations
7
Classes with more details
PackageNameAgent
Name simple, path
Height Float Val Boolean false
Attribute all, only some, or none
Operations services provided.
ltltconstructorgtgt New(p policy) ltltprocessgtgt Proces
s(o order)
Stereotype group attributes/ops and put a
descriptive prefix.
Responsibility obligation of a class.
free-form text.
Responsibilities
-- determine risk of an order -- handle
criteria for fraud
8
Visibility of attr. ops.

• Public Any outside classifier can use ().
• Protected Any descendant of the classifier can
  use ().
• Private Only the classifier itself can use (-).
• Package Only visible within the package()

Toolbar
currentSelection Tool toolCount Integer
pickItem(i integer)
- compact()
9
Multiplicity
- Specification of the range of allowable
cardinalities an entity may assume.
1
Car
wheels Wheel4 persons Person1..5 Engine
Engine
10
Classes operation body
11
Relationships
Window
Event
Open() Close() HandleEvent()
dependency
generalization
association
ConsoleWindow
DialogBox
Control
DisplayPrompt()
12
Generalization Alternative notations
13
Generalization Multiple Classification
14
More about association
Works for
Person
Company
Name an association to describe its
nature. Direction triangle direction of reading.
employee
employer
Person
Company
Role face presented to the other class.
15
More about association
Navigability An arrow may be attached to the end
of the path to indicate that navigation is
supported toward the classifier attached to the
arrow.
Works for
Person
Company
16
More about association
Multiplicity How many objects may be connected
across an instance of an
association.
1..

Person
Company
employee
employer
Multiplicity at one end ? for each object at the
other end, there must be that many objects at
the near end.
Exactly one 1 Zero or one 0 .. 1 Many 0 ..
One or more 1 .. Not shown ? unspecified or
suppressed
17
Aggregation
Plain association peer relationship. Aggregation
whole/part relationship. - An object can
be shared by other aggregates.
Company
whole
1

Department
part
18
More about association
Composition (composite aggregation) - An
object may be a part of ONLY one composite at a
time. - Whole is responsible for the
disposition of its parts.
whole
Window
1

part
Frame
19
Composition vs Aggregation

• Aggregation does not link the lifetimes of the
  whole and its parts.
• Composition
• Parts with nonfixed multiplicity can be created
  after the composite itself. ? lifetime
• Such parts can be explicitly removed before the
  death of the composite. ? lifetime
• An object may be a part of only one composite at
  a time. ? strong ownership

20
Constraints
Constraints add new semantics or change existing
rules.
Portfolio
Corporation
secure
or
BankAccount
Person
21
Constraints and Comments
22
Derived Attributes and Associations
23
More examples of associations
24
More examples of associations
25
Dependencies
26
Relationships Summary
27
Interface

• Defines a set of operation specs
• Never defines an implementation(no attributes,
  no associations, operations not implemented)
• Typically attached to a class or component

28
Interfaces Shorthand Notation
I
I
29
Interfaces Longhand Notation
I
I
30
Instances

• Concrete manifestation of an abstraction
• All objects are instances
• Not all instances are objects. (Instance of an
  association is a link)
• To indicate an instance, underline its name

31
Instances (named, anonymous, multiple)
t Transaction
myCustomer
named
MultimediaAudioStream
anonymous
multiobject
keyCode
32
Object state
Instance with attribute values
myCustomer
Id SSN 432 .. Active true
Instance with explicit state
c Phone
WaitingForAnswer
33
Object diagrams

• Model the instances of things contained in class
  diagrams.
• Show objects are their relationships at a point
  in time.
• No communication is shown.

34
An object diagram
cCompany
d1 Dept
d2 Dept
name RD
name Sales
Objects, links, notes, constraints
d3 Dept
Name .
p Person
ContactInfo
Name jk
Address200 U Av.
35
How do you find classes?

• Finding objects is the central piece in object
  modeling
• Learn about problem domain Observe your client
• Apply general world knowledge and intuition
• Take the flow of events and find participating
  objects in use cases
• Apply design knowledge
• Distinguish different types of objects
• Apply design patterns (Lecture on design
  patterns)
• Do a syntactic analysis of problem statement,
  scenario or flow of events
• Abbott Textual Analysis, 1983, also called
  noun-verb analysis
• Nouns are good candidates for classes
• Verbs are good candidates for operations

36
Finding Participating Objects in Use Cases

• Pick a use case and look at its flow of events
• Find terms that developers or users need to
  clarify in order to understand the flow of events
• Look for recurring nouns (e.g., Incident),
• Identify real world entities that the system
  needs to keep track of (e.g., FieldOfficer,
  Dispatcher, Resource),
• Identify real world procedures that the system
  needs to keep track of (e.g., EmergencyOperationsP
  lan),
• Identify data sources or sinks (e.g., Printer)
• Identify interface artifacts (e.g.,
  PoliceStation)
• Be prepared that some objects are still missing
  and need to be found
• Model the flow of events with a sequence diagram
• Always use the users terms

37
Entity, Boundary and Control Classes

• Entity classes represent persistent data in the
  system
• Data available between two sessions
• Recurring nouns ( Incident)
• Real world activities and entities (Field
  Officer, Dispatcher)
• Boundary classes represent the interface with the
  actors
• input buttons and forms (EmergencyButton,
  ReportEmergencyForm)
• output messages and signals(AcknowledgeMessage)
  
• Control classes realize use cases and mediate
  between the entity and boundary classes
• One control object per use case
• One control object per actor and use case
• ReportEmergencyControl
• ManageEmergencyControl

38
Example 2BWatch Objects
Button
Year
ChangeDate
Month
LCDDisplay
Day
Entity Objects
Control Objects
Interface Objects
39
Naming of Object Types in UML

• UML provides several mechanisms to extend the
  language
• UML provides the stereotype mechanism to present
  new modeling elements

ltltBoundarygtgt Button
ltltEntitygtgt Year
ltltControlgtgt ChangeDate
ltltEntititygtgt Month
ltltBoundarygtgt LCDDisplay
ltltEntitygtgt Day
Entity Objects
Control Objects
Boundary Objects
40
Example Flow of events

• The customer enters a store with the intention of
  buying a toy for his child with the age of n.
• Help must be available within less than one
  minute.
• The store owner gives advice to the customer. The
  advice depends on the age range of the child and
  the attributes of the toy.
• The customer selects a dangerous toy which is
  kind of unsuitable for the child.
• The store owner recommends a more yellow doll.

41
Mapping parts of speech to object model
components Abbott, 1983
42
Another Example

• The customer enters the store to buy a toy.
• It has to be a toy that his daughter likes and it
  must cost less than 50 Euro.
• He tries a videogame, which uses a data glove and
  a head-mounted display. He likes it.

Flow of events
Is this a good use Case?
An assistant helps him. The suitability of the
game depends on the age of the child. His
daughter is only 3 years old. The assistant
recommends another type of toy, namely the
boardgame Monopoly".
Not quite!
Monopoly is probably a left over from the
scenario
The use case should terminate with the customer
leaving the store
43
Textual Analysis using Abbots technique
Grammatical construct
UML Component
Example
Concrete Person, Thing
Object
Monopoly"
noun
class
toy"
Adjective
Attribute
"3 years old"
verb
Operation
enters"
Intransitive verb
Operation (Event)
depends on."
Classifying verb
Inheritance
is a" ,either..or", kind of"
Possessive Verb
Aggregation
"Has a ", consists of"
modal Verb
Constraint
must be", less than"
44
Generation of a class diagram from flow of events
Flow of events

• The customer enters the store to buy a toy. It
  has to be a toy that his daughter likes and it
  must cost less than 50 Euro. He tries a
  videogame, which uses a data glove and a
  head-mounted display. He likes it.

store
enters
customer
buy
Customer
toy
daughter
less than 50 Euro
videogame
An assistant helps him. The suitability of the
game depends on the age of the child. His
daughter is only 3 years old. The assistant
recommends another type of toy, namely a
boardgame. The customer buy the game and leaves
the store
depends
age
type of toy
boardgame
45
Some issues in object modeling

• Improving the readability of class diagrams
• Managing object modeling
• Different users of class diagrams

46
Avoid Ravioli Models
Account
Amount
Has
Deposit()


CustomerId
Withdraw()
GetBalance()
Savings Account
Checking Account
Mortgage Account
Dont put too many classes into the same
package 7-2 (or even 5-2)
Withdraw()
Withdraw()
Withdraw()
47
Put Taxonomies on a separate Diagram
Savings Account
Checking Account
Mortgage Account
Withdraw()
Withdraw()
Withdraw()
48
Project Management Heuristics

• Explicitly schedule meetings for object
  identification
• First just find objects
• Then try to differentiate them between entity,
  interface and control objects
• Find associations and their multiplicity
• Unusual multiplicities usually lead to new
  objects or categories
• Identify Inheritance Look for a Taxonomy,
  Categorize
• Identify Aggregation
• Allow time for brainstorming , Iterate, iterate

49
Who uses class diagrams?

• Purpose of Class diagrams
• The description of the static properties of a
  system (main purpose)
• Who uses class diagrams?
• The customer and the end user are often not
  interested in class diagrams. They usually focus
  more on the functionality of the system.
• The application domain expert uses class diagrams
  to model the application domain
• The developer uses class diagrams during the
  development of a system,that is, during analysis,
  system design, object design and implementation.

50
Class-diagrams have different types of users

• According to the development activity, the
  developer plays different roles.
• Analyst
• System-Designer,
• DetailedDesigner
• Implementor.
• In small systems some of the roles do not exist
  or are played by the same person.
• Each of these roles has a different view about
  the models.
• Before I describe these different views, I want
  to distinguish the types of classes that appear
  in class diagrams.
• Application domain classes
• Solution domain classes

51
Application domain vs solution domain

• Application domain
• The problem domain (financial services,
  meteorology, accident management, architecture,
  ).
• Application domain class
• An abstraction in the application domain. If we
  model business applications, these classes are
  also called business objects.
• Example Board game, Tournament
• Solution domain
• Domains that help in the solution of problems
  (tele communication, data bases, compiler
  construction, operting systems, .)
• Solution domain class
• An abstraction, that is introduced for technical
  reasons, because it helps in the solution of a
  problem.
• Examples Tree, Hashtable, Scheduler

52
The Role of the Analyst

• The analyst is interested
• in application classes The associations between
  classes are relationships between abstractions in
  the application domain.
• whether the use of inheritance in the model
  reflect the taxonomies in the application domain.
  
• Definition Taxonomy A hierarchy of abstractions
• The analyst is not interested
• in the exact signature of operations.
• in solution classes.

53
Designer

• The designer focuses on the solution of the
  problem, that is the solution domain.
• Design consists of many tasks (subsystem
  decomposition, selection of the hardware
  platform, data management system, etc.).
• An important design problem is the specification
  of interfaces
• The designer describes the interface of classes
  (object design) and subsystems (system design).
• The goal of the designer is usability and
  reusability of interface
• Design-Usability the interfaces are usable from
  as many classes as possible within in the system.
  
• Design-Reusability Definition of interfaces,
  such that they can also be used in other (future)
  software systems. gt Class libraries.

54
Three Types of Implementors

• Class implementor
• Implements the class. The implementor chooses
  appropriate data structures (for the attributes)
  and algorithms (for the operations), and
  realizes the interface of the class ina
  programming language.
• Class extender
• Extends the class by a subclass, which is needed
  for a new problem or a new application domain.
• Class-user (client)
• The programmer, who wants to use an existing
  class (e.g. a clas from a class library or a
  class from another subsystem).
• The class user is only interested in the
  Signatures of the class operations and the
  preconditions, under which they can be invoked.
  The class user is not so much interested in the
  implementation of the class.

55
Why do we distinguish these different users of
class diagrams?

• Models often dont distinguish between
  application classes (address book") and
  solution class (array", tree").
• Reason Modelling languages like UML allow the
  use of both types of classes in the same model.
• Preferred No solution classes in the analysis
  model.
• Many systems dont distinguish between
  specification and implementation of a class.
• Reason Object-oriented programming languages
  allow the simultaneous use of specification and
  implementation of a class.
• Preferred The object design model does not
  contain implementations.
• The key for creating high quality software
  systems is the exact distinction between
• Application and solution domain classes
• Interface specification and implementation
  specification

56
Summary

• Modeling vs reality
• System modeling
• Object model
• Dynamic model
• Functional model
• Object modeling is the central activity
• Class identification is a major activity of
  object modeling
• There are some easy syntactic rules to find
  classes/objects
• Different roles during software development
• Requirements Analysis Document Structure

57
Ways to find objects

• Syntactical investigation with Abbotts techniqe
• In the problem statement (originally proposed,
  but rarely works if the problem statement is
  large (more than 5 pages)
• In the flow of events of use cases
• gt Textual Analysis with Abbott
• Use of various knowledge sources
• Application knowledge Interviews of end users
  and experts, to determine the abstractions of
  the application domain.
• Design knowledge Reusable abstractions in the
  solution domain.
• General world knowledge Also use your generic
  knowledge and intution.
• Formulation of scenarios (in natural language)
• Description of the concrete usage of the system.
• Formulation of use cases (natural language and
  UML)
• Description of functions with actors and flow of
  events