OO Design

1
OO Design Development I Architectural Views,
COTS Integration, Prototyping
2
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

3
Component Design Views

• What are they?
• Describe how system components are mapped into
  low-level software architecture
• Why?
• Help identify what objects are needed by grouping
  components into technology representation
  clusters from different perspectives
• discover straightforward implementations and
  design patterns
• identify gaps for which particular system
  objects must be created to fill (no direct
  relevance to domain here, makes components work
  in software)

4
A Brief Review of Objects
5
About 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)

6
Objects in Design

• Objects add implementation refinements to the
  Component Model (SSAD 2.1), but also may appear
  earlier in the design views (SSAD 3.1)
• Objects are software elements introduced to
  directly implement Components, handle component
  interactions and represent design elements within
  logical, topological, and physical views,
  implement complex relationships, attributes, and
  constraints

realize
System Capabilities
Capability Requirements
LCO
implement
Components
Objects
LCA
carry out
Behaviors
Operations
7
Components vs. Objects

• Objects are the smallest (most refined) entity we
  consider in our models prior to implementation
• Components are compositions (membership
  relationships) of objects with a high degree of
  cohesion within the domain
• Components are what you need to describe the
  system to domain experts at a higher level of
  abstraction (less detail)
• Components are used to describe parts in the
  design views
• Objects are usually associated with technology
• Components are usually associated with the domain
  

8
Objects

• In the Design phase you decompose components into
  objects.
• Objects are used to represent the system in
  software.
• Objects are specialized parts of a component.
• An object is an atomic unit for systems analysis
  purposes.
• Introduce objects in the design views (SSAD 3.1)
  to handle technology gaps external to components

9
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
10
Now Back To Design Views!
11
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

12
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)

13
System Topological View Example
View
use layer stereotypes or notes
Control (HTTP Server)
Model
introduced objects
Persistence
requests
VT File
HTML File
image File
notifications
14
SSAD 3.1.1 System Topological View (Web Mail)
15
SSAD 3.1.1 System Topological View (PISE)
16
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)

17
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 -

18
Design Component Specifications(Web Mail)
19
Design Component Inspector
(missing behavior references)
(Relates to component and requirements missing)
20
SSAD 3.1.2 Design Component Specifications
HOMER
MS Acess (API)
system boundary
theMS_Access_ControllerDBController
theHOMER_InterfaceAgent
1
1
theHOMERInterfaceAgent
theMSAccessController
aQueryControllerViewController
1
myQueryController
Zaguan
21
3.1.3 Framework and Protocol Specifications

• Describe the specific frameworks to be used and
  the nature of interactions among the logical
  components (SSAD 2.1) and design components (SSAD
  3.1.2) in order to support all the behaviors of
  the system as described in SSAD 2.2
• Protocols and services are typically independent
  of the domain and their choice depends upon the
  various requirements of the system, most notably
  Level of Service Requirements (SSRD 5).
• Examples of frameworks include CORBA Services
  and Facilities, Java JDK, TCP/IP and various
  network protocols as well as security and audit
  mechanisms.

22
3.1.3 Framework and Protocol Specifications (Web
Mail)

• IMAP
• The Internet Message Access Protocol is the
  email access protocol interface in the existing
  email servers that the components in our system
  talk to. It also provides the user folder
  manipulation in which user preferences or user
  data can be stored through this protocol.
• Refer to IMAP official website http//www.imap.org
  
• Refer to RFC2060 http//www.cis.ohio-state.edu/htb
  in/rfc/rfc2060.html for IMAP specification.
•  
• LDAP
• The Lightweight Directory Access Protocol is the
  communication protocol that existing directory
  server provides us to query and retrieve email
  addresses by using name of the person.
•  Refer to RFC2251 http//www.innosoft.com/ldapworl
  d/rfc2251.txt for LDAP specification.
•  Refer to iPlanet http//www.iplanet.com/downloads
  /developer/detail_43_356.html for Netscape
  Directory SDK for Java.

23
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

24
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

25
SSAD 3.1.4 Deployment View (Web Mail)
26
SSAD 3.1.4 Deployment View (PISE)
27
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

28
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)

29
SSAD 3.1.5 Logical Component View (Web Mail)
30
SSAD 3.1.5 Logical Component View (PISE)
31
COTS Integration and Use of Prototypes in MBASE

• CS577b
• Fall 2001

32
COTS Integration Spiral

• Identify next level system elements, objectives,
  and constraints
• Factor elements into system partitions
• Identify patterns
• Map patterns to COTS
• Reconcile architectural mismatches, constraint
  violations, establish COTS alternatives
• Evaluate trade-off considerations (e.g.
  integration effort)
• Evaluate COTS alternatives with respect to
  objectives and trade-off considerations
• Define next level system elements, objectives,
  constraints
• Validate COTS integration design
• Review system elements represented and objectives
  met

33
MBASE COTS Integration Spiral

• Identify next level system capabilities (OCD
  4.3), goals and constraints (OCD 4.2), and L.O.S.
  (OCD 4.4)
• Factor system capabilities and requirements into
  system components and objects (SSAD 2.1, 3.1,
  3.2)
• Identify architectural patterns and design
  patterns (from component model SSAD 2.1, design
  views SSAD 3.1, and object model SSAD 3.2
• Map patterns to COTS
• Reconcile architectural mismatches, constraint
  violations, establish COTS alternatives (FRD 2.2,
  5.2)
• Evaluate trade-off and risk considerations (OCD
  5, FRD 2.1, 2.2, 4, 5)
• Evaluate COTS alternatives with respect to
  objectives and trade-off considerations (OCD 5.3,
  FRD 5)
• Define next level system elements, objectives,
  constraints
• Validate COTS integration design (prototypes, FRD
  2.2, CTS Test Description and Results)
• Review system elements represented and objectives
  met

34
Component Design Views and COTS

• Since Components are often a simple object
  mechanism, many COTS products have been developed
  to handle common situations (patterns) reducing
  complex , tedious, repetitive, or unnecessary
  implementation details
• The Component model (SSAD 2.1) helps you identify
  and analyze architectural patterns for your
  system independent of technology implementation
  details e.g. information self service,
  distributed services
• The design views (SSAD 3.1) help you identify
  design patterns e.g. publish and subscribe,
  client-server
• COTS often exist to implement, partially
  implement, or assist in implementing design
  patterns!
• Warning You must carefully and explicitly
  account for
• trade-offs for identifying and integrating COTS
  into you system

35
COTS in Design Views

• Design Views are a natural place to match COTS to
  design patterns
• Topology (SSAD 3.1.1)
• Connectors and layers in are often associated
  with COTS
• Design Components (SSAD 3.1.2)
• Typically COTS will exist for common complex
  patterns in Component model. Watch for
  applications and object libraries
• Frameworks (SSAD 3.1.3)
• Frameworks are constructed to deal with common
  design needs and thus often are COTS
• Deployments (SSAD 3.1.4)
• Legacy systems, common hardware and operating
  systems usually have COTS
• Logical Blocks (SSAD 3.1.5)
• Many common block patterns, often these imply COTS

36
Prototypes and Design Views

• Prototypes directly explore design issues
• Design views help connect system analysis to
  design and thus to prototypes
• Care should be taken to ensure prototypes do not
  drive the system analysis e.g. do not choose
  components or capabilities based on prototypes,
  use for risk reduction
• Topology (SSAD 3.1.1)
• Prototypes explore component connectivity
• Design Components (SSAD 3.1.2)
• Prototypes explore utility and feasibility of
  COTS for design use
• Frameworks (SSAD 3.1.3)
• Prototypes often make extensive use of frameworks
  that imply design (watch for risk factors here)
• Deployments (SSAD 3.1.4)
• Prototypes and final system often have similar
  deployment elements
• Logical Blocks (SSAD 3.1.5)
• Prototypes must relate to logical system
  elements, helps with design

37
COTS and Prototypes

• Prototypes are also a natural place to map
  patterns to COTS
• Often use COTS in prototypes that imply use in
  design
• COTS often have competition that may be more
  suitable for the final product e.g. MS Access ?
  Oracle, MySQL, MS SQL
• Common to use prototyping to establish COTS
  trade-off factors (integration effort, L.O.S.
  qualities, etc.)
• Good planning can help make this proactive,
  advanced prototyping may still be required to
  resolve details
• Design Views identify what COTS need prototyping

38
Mustnt forget about requirements
39
Necessary Condition

• All requirements must be testable and
  implementable (subject to risk considerations)
• There must be some way to demonstrate that a
  requirement has been satisfied by the system
  (will be documented in FRD)
• System Capability either supports or does not
  support a typical or non-trivial scenario
  (Use-Case)
• Project must have a measure, what is being
  measured, definition of satisfactory
• Level of Service must have a measure, specific
  instances with respect to capabilities,
  satisfactory threshold (relative measures are
  useful)
• System Interface must specify checklist for all
  interface parameters
• Evolutionary must refer to a design or
  implementation scenario that supports a possible
  future satisfaction

40
Requirements, WinWin, Prototypes

• Fundamental relationship between WinWin results,
  Prototypes, and Requirements
• No formula but some general rules of thumb
• WinWin agreements often become requirements
• WinWin taxonomy items contribute to requirements
• Specialized taxonomy (as in HW) can be used in
  SSRD sections
• WinWin options may need to be prototyped
• Prototype results may contribute to later WinWin
  cycles
• Prototype results often contribute to
  requirements
• Helps resolve IKIWISI requirements model clash
• Iteration and simultaneous development common
• Must integrate results and have some degree of
  consistency!

41
Prototyping

• CS577b
• Fall 2001

42
Prototyping

• Contents
• Goals of prototyping.
• Types of prototype.
• What should you have for LCO?
• Prototyping guidelines.
• To reuse to throw away?
• Rapid prototyping tools.
• How to choose a tool?
• Scenarios.

43
Prototyping goals, 1

• Prototypes help with your customer negotiations
• Reality check are you building what the
  customer expected?
• A prototype gets you past Ill know it when I
  see it.
• Makes your project concrete for the customer.
• Focuses negotiations on user concerns (when the
  customer isnt the end user).

44
Prototyping goals, 2

• Prototypes help you design your product
• Any gaps or inconsistencies in the
  design/requirements may be revealed.
• Questionable or difficult aspects can be tried
  out.
• Outright errors in your initial design may show
  up.
• Weaknesses in the development teams skills may
  be revealed (in time to get training).
• Unanticipated problems with implementation
  technologies may be revealed (in time to try
  something else).
• More important or more difficult requirements or
  components show up knowing about these things
  helps with making a reasonable schedule and
  division of labor.

45
Types of prototype, 1

• Prototypes may be classified as
• Non-functional (for look and feel)
• Images.
• Static interface (in some language).
• Example interaction (series of slides, or a log
  or journal file).
• Functional (in various degrees)
• Anything that runs and shows off some system
  features.
• Prototypes may be classified as corresponding to
  phases in the development, from Initial to
  Pre-alpha.

Alpha and Beta are industry parlance for
pre-release software. An Alpha release includes
major features, but isnt intended for general
use. A beta release should be mostly complete,
but still needs testing.
46
Types of prototype, 2

• Prototypes may be classified by their intended
  use
• A prototype might be used to demonstrate the user
  interface, rather than the programs function.
• A prototype might be used to demonstrate a
  programs function (in this case the UI is less
  important).
• Any test program written to try out a
  technology or design aspect is a prototype.
  Prototypes may exist only to help the development
  team, rather than to show to the world.

47
What should you have for RLCA?

• Your RLCA prototypes may be very simple!
• Your prototypes should focus on demonstrating the
  core features/behaviors and risky design issues
  to your customer
• Does not have to have full system functionality
• Should address high risk design issues providing
  confidence the real thing will work as expected
• Clear understanding of tradeoffs, particularly
  for COTS
• Particular high risk areas related to
  prototyping
• requirements changes, developer skills, COTS,
  design defects, over-optimistic implementation
  schedule and L.O.S. qualities
• Focus on a clear, risk managed plan for IOC

48
RLCA Prototyping guidelines(construction and
presentation)

• Create (and demonstrate) your prototype from the
  point of view of the user
• Prototype should give an idea of what the real
  system will be like for the user
• Use realistic data and use scenarios
• Present highly technical or abstract design
  issues in a concrete manner
• Focus on the high risk areas first!
• What are the greatest areas of concern and how
  are they being addressed with prototyping?
• What are contentious issues/features among the
  development team, and with the customer?
• What features will be difficult?

49
To reuse or to throw away?

• A key decision with a prototype is whether to try
  to make it reusable (such that it can be a basis
  for the construction of the final product), or
  whether to plan to throw it away. Consideration
  include
• Can you (or do you want to) do the prototype in
  the final implementation language?
• How much time do you have for this prototype?
• Are you planning multiple prototypes?
• What is the goal for the prototype (UI, user
  behaviors, technological feasibility)?
• Why would you throw away a prototype?
• In doing the prototype, the design or
  requirements change substantially.
• Prototyping with an easy, fast tool lets you get
  on to the good parts.
• Prototyping lets you try things easily, which may
  be difficult in the final implementation.
• Prototype implementation likely did not follow
  development quality standards, be well commented,
  or have good documentation
• Understand carefully what the tradeoffs are for
  evolving a prototype into the final product!

50
Rapid prototyping tools

• Rapid prototyping tools are languages or
  programs that let you create prototypes more
  quickly than you could in your projects real
  implementation language/technology.
• The languages/programs listed here may be
  prototyping tools for one project, but final
  implementation tools for another.
• Prototyping tools include (but are not limited
  to)
• Pencil and paper.
• Images (Photoshop).
• Static web pages (HTML and images).
• Dynamic web pages (Javascript and CGI).
• Scripting languages (Perl, Python, Tcl).
• Visual programming environments (MS Visual
  Basic).
• Database development tools (MS Access).
• A real but nice language like Java (with AWT
  or Swing).

51
Tools Static web pages

• Web pages are provide a common, familiar look,
  and basic set of functions.
• May be used to demonstrate user input forms.
• May easily be made colorful and attractive.
• May be created in various visual editors
  (Netscape Composer, MS FrontPage, Adobe
  PageMill).
• Can be accessed almost anywhere, from any nearly
  any type of (networked) computer.
• May be easily augmented with a certain amount of
  functionality.
• Disadvantages
• Relatively static interface the display is
  constrained to pages.
• Input widgets are limited (relative to VB, for
  instance).
• Layout varies across platforms.

52
Tools Dynamic web pages

• Javascript can add considerable function to a web
  page
• Error and confirmation dialogues.
• Simple processing (arithmetic).
• Modifications to the display (eg, cycling an
  image).
• Frames can implement multi-window displays (eg, a
  tool bar and a work area).
• Server-side CGI can be used to implement complex
  processing (eg, database interaction).

53
Tools scripting languages

• Benefits of a scripting language (Perl, Python,
  Tcl, sh)
• Interpreted you dont have to recompile.
• High level data types (extensible arrays, hash
  tables).
• High level system functions (file I/O, string
  manipulation, networking).
• Regular expressions for parsing/scanning strings
  and files.
• Tk is a windowing library that may be used with
  any of the above to quickly script a GUI.
• Disadvantages
• Interpreted code is generally slower than
  compiled code.
• Missing or flaky OO features (except Python).
• Less support for proprietary libraries and
  existing code.

54
Tools Visual programming environments

• Visual Basic (and similar products such as
  Symantec Café) let you
• Drag and drop to create an interface.
• Define attributes and methods from menus.
• Access lots of existing, reusable code.
• VB is probably the very fastest way to put
  together a functional program with a
  sophisticated graphical user interface.
• Disadvantages
• VB programs may be slower, larger and less robust
  than equivalent programs written with (say)
  Visual C.
• VB programs are in no way portable to a operation
  system other than windows.
• VB programs may not be able access as many
  libraries and Windows internals as C programs
  can.

55
Tools database development tools

• Database development tools (such as MS Access)
  allow
• Graphical design of a database and corresponding
  user interfaces (data entry, reports).
• Access to different databases (you can bring
  together various existing databases).
• These tools are particularly useful to try out
  the features of a complex database schema,
  particularly if youre not very familiar with
  SQL.
• Disadvantages
• MS Access isnt portable off of Windows (and
  Mac?) platforms, though you may be able to use it
  to develop portable SQL statements.
• Performance and external interfaces may be
  lacking (though not if youre using, for example,
  SQL Server and IIS on Windows NT).

56
Tools real languages

• You may find it convenient to code your prototype
  in a real language, like Java. Reasons include
• Your final product will be in Java.
• Youre more familiar with Java (you can start
  using it now, while training on the
  implementation language).
• AWT and Swing are flexible, powerful windowing
  libraries.
• Java provides easier, safer networking and
  threads than C.
• Java is type-safe and object-oriented.
• Disadvantages
• Programming in Java is usually slower than in,
  for example, Perl theres nothing rapid about
  prototyping in Java.
• It takes more work to get something going in Java
  (particularly user interfaces) likewise it takes
  longer to change it, and thus its harder to try
  ideas.

57
How do I choose a prototyping tool?

• Some considerations in choosing a prototyping
  too
• Do you want to reuse the code?
• Are you focusing on the user interface? The
  behavior? Internal implementations?
• How many prototypes are you doing? Will you want
  to extend this one?
• What tools do you know already?
• What tools might be useful later (and are thus
  worth learning/practicing now)?

58
Scenarios

• The next few slides present three imaginary
  example project scenarios. Each describes the
  project, then describes a series of prototypes,
  their focus, and the tools theyll use.

59
Scenario A web application, 1

• Project amazon.com, or a subset thereof. Ie,
  an e-commerce web site for selling books, with a
  shopping cart and credit card payment. The final
  system will be database-backed dynamic web pages
  via CGIs coded in Perl.
• Prototype 1, technical feasibility a Perl
  program that makes credit card transactions work
  (probably by working with a library provided by
  an e-commerce service or bank. If this cant be
  made to work, the implementation language will
  have to be changed. If it still doesnt work,
  the project is doomed.

60
Scenario A web application, 2

• Prototype 2, basic UI a set of static web pages
  demonstrating the product search, product
  display, shopping cart contents, checkout and
  billing form screens look like. The page layouts
  will be there, but the team wont spend too much
  time on making them pretty. The prototype will
  be modified iteratively in conjunction with the
  customer, until s/he is happy.
• Prototype 3, full demo the pages from 2 are
  backed by functional scripts a user may access
  the site, search for a product, add it to his/her
  cart, and then buy it. Credit transactions and
  inventory management may not be integrated yet.
  Again, the customer is consulted to make sure
  s/he approves of the interface and features.

61
Scenario GUI application

• Project A slideshow editor. The user can
  have a series of slides and switch back and
  forth between them. The user can add more or
  less arbitrary text to a slide. The system
  should be able to save slideshows to the disk and
  then open them again. The system should be in
  Java (for platform independence).
• Prototype 1, UI A mock-up of the main
  application window in Visual Basic. It has all
  the buttons, tool bars, menus and main slide
  editing window, but they dont do anything. The
  prototype is shown to the customer and a few of
  the future users, and refined according to their
  comments.
• Prototype 2, editing a slide An rough start at
  the main slide-editing functionality, in Java.
  This prototype is for the use of the developers,
  to insure that they know how to do it, and to get
  an idea of the time required to finish the full
  project. Some code may be reuseable, but it will
  probably need to be redone.

62
Scenario Application with no UI

• Project Implement a simple, fast web server in
  C. The server should support the full HTTP
  protocol, including support for CGI and cookies.
• Prototype 1, making sure we can code C The
  first prototype implements a very basic server
  which takes client requests and answers OK.
  The server has to do networking with sockets, has
  to be able to handle multiple requests
  simultaneously (threads or multi-process?) and
  has to be in C. This exercise proves the skills
  of the development team. The code may be reused
  if it is good otherwise it will be redone in the
  construction phase.
• Prototype 2, getting the behavior right The
  second prototype helps the team understand the
  the HTTP, CGI and Cookie protocols, so to
  implement them correctly. This prototype need
  not be fast, robust or handle multiple
  connections. The prototype will be in Perl or
  Python, for their easy, safe data structures and
  string processing and easy networking libraries.
  The final prototype should correctly implement
  the protocols, so to serve as an example to the
  real implementation in C.

63
Exercise design your own prototypes

• Project A web-based email client. Columbia
  wants a full-featured email client on the web, so
  that students can check their cunix email from
  anywhere. The system has to be extremely
  intuitive and easy-to-use.
• Step 1 Identify a set of requirements for the
  systems function and interface. Of these, which
  are most important (which have the highest
  priority)?
• Step 2 Suggest one or more prototypes to help
  in the following
• The customer negotiations (figuring out what CU
  wants, what they mean by full-featured).
• The design (how should the development team
  decide on an implementation? What are the hard
  parts of the implementation?).
• The users perspective (how does the team develop
  a good, intuitive, easy-to-use interface?).