System Design Design Views, object and operations models and the SSAD

1
System Design Design Views, object and
operations modelsand the (SSAD)
2
Brief Review
3
UML Notation

• to-1 ...1
• to-many ...
• to-n ...n

reference librarian
1 employs 1..
library
1 rides on 4
tires
Car
0..1 cools 1
Air Conditioner
Car
4
Identifying Relationships

• Are usually static conditions
• owns, employs, manages, stored in,
• Avoid actions
• displays, updates, activates,
• Avoid comparative statements
• greater, equals, more,

5
Dependencies

• Are constraints
• once a constraint appears, it carries through
• effect faithfulness directly
• Are not formally relationships, but similar
• Any model element can have dependencies
• common attribute, relationship, component

6
Dependencies (continued)

• how one element of the system uses another
• Ex. "area" attribute of "circle
• Dependencies can effect any element of a system,
  including constraints.
• Ex. in a date the upper limit on "day" depends on
  the value of "month"
• Some dependencies occur at the object level.
• Ex. a window is dependent on its delegate for
  custom closing behavior
• Most components level dependencies are described
  by a relationship between two components in which
  case it is important to document how the
  dependent components uses another components

7
Complex component relationships

• Bi-directional Relationships
• Symmetrical Relationships
• Relational Attributes
• Relational Components

8
Bi-directional Relationships
employee
employs 1..
exists
Company
Person
1 employed by .
employer
employment
Company
Person
9
Relational Attributes
employment
Company
Person
salary

• Some relationships imply attributes that are not
  qualities of either the source or destination
• Will need to handle with a special component or
  object later
• Selectors are a special type of relational
  attribute that uniquely identify destination
  instances in a to-many

Works on 1..
Person
Projects
project assignment
10
Multi-Way Relationships
reference librarian
person
library
reference material
11
Relational Components
reference librarian
person
reference desk
library
reference material
12
About ComponentsMembership Relationships

• Part-of Relationship
• relationship the objects within a component have
  to its container
• A transitive relationship
• Deletion of the components objects (the parts)
  triggers the deletion of the container
• Ex. Car - remove engine, transmission, body, etc.
  you have no car
• Visibility of component objects usually limited
  to the container
• Contains Relationship
• the reverse of the part of relationship - from
  the container to the component objects
• A transitive relationship
• Deletion of the container (the component) causes
  the deletion of the components objects (the parts)

13
Composites

• Collections
• a wrapper for a number of contains
  relationships with identical objects
• Ex. Address Book component contains a set of
  Address objects. Address Book is the composite
  component produced by applying the collection
  relationship
• Aggregation
• A contains relationship where the contained
  objects have a part-of relationship to the
  container
• Ex. Automobile engine is an aggregate of pistons,
  crankshaft, spark plugs, etc. that are part of
  an engine. The engine contains the engine parts
  
• What happens if you remove pistons? What about
  engine block?
• Groupings
• like aggregation, but if you delete all (not
  some) of the components objects the container is
  deleted as well.
• Ex. Trades in a portfolio

14
End of Brief Review
15
Enterprise Modeling
16
Enterprise Modeling

• The goal is to get an overview of the overall
  structure of the system components and system
  behaviors
• How?
• Through classification of components and
  behaviors
• Uses abstraction engineering techniques
• Why?
• So that choices on the "elegance" and
  faithfulness of the components can be made
• Finding an elegant system partition e.g. small
  as possible and faithful
• Reduces system complexity

17
Abstraction Engineering

• Operations
• Decomposition (break apart into smaller parts)
• Composition (combine parts to create larger part)
• Classification (group type-of parts together)
• Specialization (identify particular is-kind-of
  sub-groups)
• Generalization (identity group for which
  sub-groups are kinds-of)
• Factoring (Decomposition followed by
  Classification to find natural partitions)
• Used for Enterprise and Class models

18
Abstraction Engineering

• Engineering operations can solve problems
• Proof of the Pythagorean Theorem a2 b2 c2

Specialization
Generalization
c
a
b
Analogy
19
Example Enterprise Components
20
Component Classification

• Start building the Enterprise model by creating a
  class for each component in the Component model.
• Group the classes by
• type-of relationships
• kind-of relationships
• part-of relationships (optional)
• Avoid associations not listed above! (Component
  Model should already contain)

21
Enterprise Modeling

• Component classes and types
• Group components that are the same type-of
• Look for components with mostly the same
  relationships
• Perform abstraction engineering operations on all
  components and iterate until satisfactory or
  stalled
• Document results in Enterprise model and adjust
  Component model as needed

aaaa
aaaa
aaaa
bbbb
bbbb
bbbb
22
Watch For Equivalence

• attribute equivalence
• Components that only differ by some attributes
• E.g. Part-time Employee, Full-time Employee
• relational equivalence
• Components that only differ relationship setting
• E.g. Client, Contact
• semantic equivalence
• Components that only differ by state value
• E.g. Closed Account, Open Account
• Roles
• Components that only differ by role played
• E.g. Employee, Manager
• General approach operational equivalence
• Is there a well-defined sequence of operations
  that would transform one component into another?
• E.g. change open/closed status of Account, assign
  an Employee to a group of Employees to manage, a
  Client is when a Contact has a Company to provide
  service

23
Behavior Classification

• Behaviors are mapped to the components.
• Classify behaviors in an inheritance diagram, as
  this will make the assignment task easier
• Some behaviors will not map naturally to
  components and software level objects will need
  to be introduced later in the Design model to
  handle these.

24
Example Enterprise Behaviors
25
MBASE System Design
26
3. System Design

• Details on how the system can be represented in
  software
• Describes specific technology solutions that meet
  requirements (both project and system)
• high-level resolves Analysis issues
• how will roles and states be handled, expand
  bi-directional relationships, break multi-way
  relationships, handle global and relational
  attributes, decompose Components into objects,
  complex dependencies and other constraint
• low-level direct implementation considerations
• use of databases, web-servers, hardware, critical
  algorithms, sequence, significant events, GUIs,
  etc.

27
General
Specific
Domain Description
System Analysis
People
System Implementation
System Design
Technology
28
targeted
Implementation
development
Design
Analysis
Domain
Description
Center Out
Time, information
Customers
approach
(Why/Where)
Domain Experts
(What)
Developers
(How)
Iterative
development
Technology
(Do)
29
OO models and abstractions

• Models provide a tangible way to work with groups
  of complex concepts through abstractions
• Enable management of complex sets of abstractions
• Offer multiple views of abstractions for a
  variety of purposes
• All models use the language of abstractions

30
What is OOD?

• Mapping Analysis models to software
• Focus on finding software representations and
  solutions to implementation problems
• May target particular technologies
• Addresses
• UIs
• DB descriptions
• Design constructs (e.g. custom value objects,
  layers, ...)

31
Purpose of Design

• Describes how the system components are to be
  realized within specific software structures
• Answers What are the fundamental objects (and
  their relationships) that can faithfully
  represent the system components?

32
OOD Main Tools

• Formalized conventions
• Address many implementation details
• Analysis models
• Traceable evolution from what is wanted
• Architectural views
• Indicate how to implement Components in software
• Design Patterns
• Can help with common complex implementations
• Frameworks and mechanisms
• Provide simple solutions to common problems
• Documentation (models) for implementers

33
Design resolves Analysis issues

• Resolve policies by finding algorithms to carry
  out
• Resolves complex relationships between components
• bi-directional, multi-way
• memberships
• multiplicity (containers, selectors, etc.)
• relational attributes
• Enforces constraints (especially dependencies)
• Resolves roles, complex states, sub-types, modes

34
Design models may include COTS

• COTS solutions
• mechanisms
• frameworks
• APIs
• sub-systems
• entire applications
• Software libraries
• Repositories

35
Design Approaches

• Not an exact science
• many many approaches, variations, choices,
  solutions
• an art but has basic principles to follow
• often no single right answer, usually will
  work, is feasible, or best we can do for now

36
Design Model Views
1.
System Definition
2.
3.
Project
System Requirements
Requirements
4.
5.
Operations Model
Object Model
6.
Class model
37
Integration of MBASE System Definition Elements
Domain Description
System Analysis
System Requirements
LCA
System Definition
Statement of Purpose
Organization Background
Project Requirements
Project Goals
Organization Goals
Levels of Service
Levels of Service Requirements
Organization Activities
System Capabilities
Capability Requirements
System Design
Organization Entities
Component Model
Object Model
Operations Model
Activity Model
Behavior Model
Enterprise model
Interaction Model
Class Model
Operational Concept Description (OCD)
System and Software Requirements Definition (SSRD)
System and Software Architecture Description
(SSAD)
38
3.1 Design Views

• Consist of
• 3.1.1 Topological (Layered)
• 3.1.2 Design Component Specifications
• 3.1.3 Framework and Protocol Specs
• 3.1.4 Deployment View
• 3.1.5 Logical View

39
Component Design Views

• What are they?
• Describe how system components are mapped into
  low-level architecture
• Why?
• Help identify what objects are needs by grouping
  components into technology representation
  clusters
• discovers straightforward implementations
• identifies gaps for which particular system
  objects must be created to fill (I.e. no direct
  relevance to domain, only makes components work
  in software)

40
3.1.1 System Topological View

• System Layered View elements are often called
  subsystems.
• Subsystems are organized in a hierarchy of
  layers, where each layer has a well defined
  interface. Some of the layers that can be found
  in a system
• User Interface (View)
• Application Specific Packages
• Reusable Business Packages
• Key Mechanisms (Persistence, Control, etc.)
• Hardware and Operating System Packages

41
System Topological View

• Assigns components to system layers
• components in the same layer implicitly
  communicate
• notifications move upward, requests downward
• Helps identify useful mechanisms and frameworks
  (particularly COTS DBs, file systems, GUIs)
• Loosely based on C2 Architectural style (see
  http//www.ics.uci.edu/pub/arch/c2.html)
• Splits system into communication areas
• very common that components that communicate
  across communication areas require new objects to
  facilitate (e.g. JDBC for Java, Apache for file
  system to WWW browser)

42
System Topological View Example
View
use layer stereotypes or notes
Control (HTTP Server)
Model
requests
Persistence
notifications
VT File
HTML File
image File
22
43
SSAD 3.1.1 System Topological View
44
3.1.4 Deployment View

• Consistent with System Component View diagrams
  and the various interface diagrams
• Use the Deployment View to document the physical
  (i.e., hardware components) architecture of the
  system and how the logical components are
  deployed on them.
• Use a UML Deployment Diagram

45
System Deployment View

• Assigns components to deployed hardware and
  software
• if known, includes OS, mechanisms, and frameworks
  
• Splits system into physical groups
• very common that components that communicate
  across physical groups will require glue objects

46
Deployment View Example
22
47
SSAD 3.1.4 Deployment View
48
3.1.5 Logical View

• Logical description of the system
• Should be consistent with System Definition (SSRD
  2.1)
• Start with Block Diagram from SSRD 2.1

49
Logical Component View

• Assigns components to system block diagram or
  other logical system group
• conceptual understanding and completeness
• ensures consistency, accessibility, and necessity
  of system parts and relationships to outside
  (system boundaries)
• may introduce new technology choices (some may
  exist from block diagram or requirements)

50
Logical Component View Example
WWW browser
VT Generator
display tour
view tour
WWW Server (Apache)
create tour
51
SSAD 3.3.5 Logical Component View
52
3.2 Object Model

• The Object Model is a refinement of the Component
  Model (SSAD 2.1)
• Objects are introduced to represent Components,
  handle component interactions (logical, layer,
  physical), implement complex relationships,
  attributes, and constraints

53
Objects

• A fundamental, semi-autonomous software-level
  structure that embodies both data and operations
  to represent or support system components
• Examples DB tables, Java classes, HTML pages,
  files
• may be introduced simply to handle technical
  issues
• GUI
• special buttons, HW/SW constraints, input/output
  validation (dates, time, SS, etc.)
• DB unique ids, primary keys, stored procedures
• Facilitate integration and communication through
  APIs, translations, multiple constrained
  relationships
• Event handling - exceptions, sequence of
  operations (precedence, synchronization, model
  loops)

54
Straightforward Component Design

• Often a simple object mechanism (or framework)
  suffice to realize a component in software

Object Mechanism
(Java, Perl, C,)

runtime
Class instance
DB
(SQL, stored procs,)

DB row
operations DB functions
data HTML operations HTML, JavaScript (browser)
HTTP server

application
operations HTTP functions
HTML file

File system

Operating system
operationsfile functions, OS
flat file
55
3.1.2 Design Component Specifications

• Describe how the components from the Component
  Model (SSAD 2.1) will be implemented as software
  elements
• Add new components as necessary to make the
  system realizable in software
• May be implementation (technology) specific
• Complex relationships of software elements which
  are never considered independently (e.g., a COTS
  package with no source code)

56
Component Specification

• Component 1
• Identity -
• Attributes -
• Assigned Behaviors -
• Relationships (aggregation, association,
  interface, observer, etc.) -
• State Groups -
• Possible Roles -
• Constraints -
• Implementation (Kind Of Object) - e.g.,
  application, server, existing subsystem, COTS
  package
• Relates to component -

57
Design Component Inspector
(missing behavior references)
(Relates to component and requirements missing)
58
SSAD 3.1.2 Component Specifications
HOMER
MS Acess (API)
system boundary
theMS_Access_ControllerDBController
theHOMER_InterfaceAgent
1
1
theHOMERInterfaceAgent
theMSAccessController
aQueryControllerViewController
1
myQueryController
Zaguan
59
3.2 Object Specifications

• Use Object Specification as follows
• Identity -
• Defining quality -
• Name -
• Variables or Attributes - public, private,
  protected
• Specify for each whether it's
• Global (shared attribute by all instances)
• Instance (attribute specific to a particular
  instance)
• Object Interactions -
• Operations - public, private, protected (just
  list operations, sequence diagram in Operations
  model will diagram interactions)
• Outlets - interface relationships to objects and
  components
• Use UML class association diagram

60
Object Specification (continued)

• States -
• Use state transition diagrams
• Roles -
• Use UML Role diagrams
• ...
• Constraints -
• Component Membership -
• Which component does it belong to or
  participates in its implementation?
• Implementation - (kind of object)
• e.g., Java object, API, HTML page, Database
  table

61
Object Inspector
variables/attributes
operations
62
Object Interactions
63
Notation

• myObject
• myObjects
• theObject
• theObjects
• anObjectTheClass

64
Object Inspector
(inconsistent name)
65
Object Interactions
(should have URL hyperlinks as outlets)
66
Object Inspector
67
Object Interactions
(should have references or creation operations)
68
3.3 Operations Model

• The Operations Model should be a refinement of
  the Behavior Model (SSAD 2.2) with respect to
  System Requirements (SSRD 3.2,4 sometimes 5, 6)
• Create operations by refining behaviors from the
  Behavior Model (SSAD 2.2) to "leaf" behaviors
  (operations) and mapping to system requirements
  (usually SSRD 3.2, 4)

69
Operations

• Performs an atomic function on data within the
  system
• calculations
• notifications
• inputs/outputs
• requests
• value changes
• Behaviors can only be implemented through
  operations
• Operations can only be carried out through
  objects
• All operations must eventually be assigned to
  objects
• operations modeling assigns operations to objects
  
• may require the introduction of new design
  objects to handle orphan operations (behaviors)
• typical for global attributes, constraints,
  complex relationships

70
Designing behaviors
System Responsibility behavior 1 behavior
2 behavior 3 ...
System Requirement op, op, op, op,
op, op, ...
Two kinds of behaviors Events
Operations (response to event, e.g.
notification) Policy Algorithms
Operations
71
Designing Behaviors

• Augment behavior model with critical operations
  needed to carry out
• BH4 Authorize user ltpolicygt
• input_userName()
• input_password()
• user authorization ltalgorithmgt
• encrypt_password(password)
• get_systemPassword_for_userName(userName)
• compare(systemPassword, password)
• create_ticket(time, expiration, userName)
• Use sequence diagram to detail
• order of operations
• non-critical operations (such as notifications)
• assign operations to objects
• try to use existing objects, minimize messages
  outside self
• take care when introducing new objects to handle
  ops - remember elegance!!

21
72
Example Sequence Diagram
RQ-07 Authorize user and assign ticket
73
Operations Across Objects
Imply static (outlets) and dynamic (dependencies)
relationships often needed for calling operations
theAuthorizationManager.encrypt_password(password
String)
74
Static and Dynamic Relationships

• Static use outlets
• need a relationship in object interaction diagram
• myOutlet.anOperation()
• Dynamic use references
• need to specify communication in operations
  diagram
• ltobject typegt (outputs) getReference(inputs)
• Variable Notation
• Private _private_variable
• get_private_variable(), set_private_variable()
• Public a_public_variable
• anObject.public_variable

75
3.3.1 Critical Algorithms

• Specify non-trivial, uncommon, novel or otherwise
  notable algorithms that must be implemented (do
  not
• Detailed policies and associated algorithms for
  carrying out policies
• Label all operations that are initiated by
  behavior events with an event name

76
3.3.2 Operation Specifications

• Operation 1
• Event, Policy -
• Passed parameters -
• Return values -
• Exception handling -
• Callers -
• Guards -
• Validation -
• Messages -
• Exits -
• Synchronization - (valid event sets, timing,
  concurrency, etc.)
• Constraints -
• Relates to requirements -

77
SSAD 3.3.1 Operations Model
78
3.4 Class Model

• Refinement of the Enterprise Model (SSAD 2.3)
• Start with Enterprise Model (SSAD 2.3) ask which
  Enterprise classes will be used for
  implementation?
• Take all components/objects from Object Model
  (SSAD 3.2) and create classes for them
• Perform generalization, specialization,
  decomposition, factoring to create Is-Kind-Of
  relationships
• Label associations (aggregation relationships,
  etc...) to create Is-Part-Of relationships

79
3.4 Class Model (continued)

• Include the following Object classifications
• Database Schema
• Object inheritance (abstract, concrete, leaf)
• HTML templates and Organization
  Folders/Directories
• API groups
• Operation library groups
• Enterprise classes

80
SSAD 3.4 Class Model
81
SSAD 3.4 Class Model
82
3.5 Configuration Model

• Include as necessary to document any of the
  following
• Data structures
• Data organization (DB tables handles as objects)
• Program structure
• File Structure (file types handled as objects)
• Global Data
• File and data cross reference
• Document as necessary any product-specific or
  implementation related issues (e.g., indexes for
  a database application)
• Not a catch-all section

83
SSAD 3.5 Configuration Model
84
SSAD 3.5 Configuration Model
85
4. Common Definition Language (CDL) for System
Design

• Definitions of unfamiliar terms, and acronyms
  encountered or introduced during the requirements
  elicitation process
• Do not repeat the common definition language for
  the domain description (will make it harder to
  ensure consistency)

86
6. Appendix

• Supplementary data
• algorithm descriptions
• alternative procedures
• Vendor documents
• technical specification sheets on the COTS
• domain or application independent components
• Frameworks
• Components
• Class Libraries

87
Straightforward Designs
88
Bi-directional Relationships
89
Relational Attributes and Selectors
salary
Employee
90
Continuation of our example from OOADesigning
roles
91
Component Roles
92
Designing Object Roles
93
Example Inheritance Hierarchy
Person
Han. V. M.
Person Role
Board Member Role
Patron Role
Curator Role
94
Designing Multi-target Roles
Implies re-classification of Patron Role
95
Multi-role Target
selector
96
Designing Components
97
Introduction to Design Patterns
98
Design PatternsExpanding Classifications
Library Card
Faculty L.C.
Student L.C.
Non-University L.C.
Multi-Medua S.L.C
Multi-Medua S.L.C
Multi-Medua S.L.C
Standard S.L.C
Standard S.L.C
Standard S.L.C
Silver M.S.L.C
Gold M.S.L.C
Silver S.S.L.C
Gold S.S.L.C
Blue M.S.L.C
Blue S.S.L.C
Silver M.F.L.C
Gold M.F.L.C
Silver S.F.L.C
Gold S.F.L.C
Silver M.N.L.C
Gold M.N.L.C
Gold S.N.L.C
Blue M.F.L.C
Blue S.F.L.C
Blue M.N.L.C
Blue S.N.L.C
Silver S.N.L.C
99
Expanding Classifications Have Redundancy
Repetitive Layers
Library Card
Faculty L.C.
Student L.C.
Non-University L.C.
Multi-Medua S.L.C
Multi-Medua S.L.C
Multi-Medua S.L.C
Standard S.L.C
Standard S.L.C
Standard S.L.C
Silver M.S.L.C
Gold M.S.L.C
Silver S.S.L.C
Gold S.S.L.C
Blue M.S.L.C
Blue S.S.L.C
Silver M.F.L.C
Gold M.F.L.C
Silver S.F.L.C
Gold S.F.L.C
Silver M.N.L.C
Gold M.N.L.C
Gold S.N.L.C
Blue M.F.L.C
Blue S.F.L.C
Blue M.N.L.C
Blue S.N.L.C
Silver S.N.L.C
100
Component Based Sub-typing
Media Type
Library Card
Multi-Medua
Standard
Staff/Faculty
Non-University
Student
Card Color
Blue Card
Silver Card
Gold Card
101
CBS Class and Instance Diagrams
Media Type
Library Card
Card Color
102
Model-View
view
model
103
Model-Controller-View
view
controller
model
104
Model-Controller-Association-View
view
association
controller
model