COMPLEX SYSTEMS TECHNIQUES AND TOOLS FOR THEIR ANALYSIS AND DESIGN

1
COMPLEX SYSTEMS TECHNIQUES AND TOOLS FOR THEIR
ANALYSIS AND DESIGN

• THE KARAKORUM RANGE EXAMPLE
• THE NATIONAL AIRSPACE SYSTEMS (NAS) ADVANCED
  AUTOMATION SYSTEM
• LARGE, COMPLEX SYSTEMS
• MULI-PARTICIPANT EFFORT
• LONG-TERM DEVELOPMENT
• CONSTANTLY CHANGING (external factors, changing
  goals, new technologies)

2
DOMAINS

• APPLICATION DOMAIN CONTEXT OF DISCOURSE,
  PROBLEM AREA/FOCUS
• SOLUTION DOMAIN ENVIRONMENT IN WHICH SYSTEM
  WILL OPERATE OR
• CONTEXTUAL ELEMENT/ENTITIES SYSTEM WILL INTERACT
  WITH
• (e.g., middleware, database systems, OS,
  micro-devices, embedded systems, network systems,
  processors)
• UNDERSTANDING APPLICATION DOMAIN, TECHNOLOGICAL
  CHANGES, CHANGES IN USER PERSPECTIVES, ETC. HELP
  RESHAPE THE REQUIREMENT ANALYSIS AND DESIGN
  PROCESS
• HANDLING COMPLEXITY AND CHANGES

3
TOOLS AND TECHNIQUES

• THE UNIFIED MODELING LANGUAGE (UML)
• JAVA TECHNOLOGIES
• DESIGN PATTERNS
• ARCHITECTURAL MODELING
• SUBSYSTEM INTERFACING AND DECOMPOSITION
• PROCESS AND QUALITY CONTROL / TESTING
• CONFIGURATION MANAGEMENT

4
FIVE QUALITIES OR REQUIREMENTS FOR SOFTWARE
ENGINEERING

• PRACTICAL EXPERIENCE Experiential knowledge
  facilitates insightfulness
• PROBLEM SOLVING Striving for optimal solution
  via refinement and criticism
• LIMITED RESOURCES Encourages component-based
  design (one-at-a-time), reuse
• INTERDISCIPLINARY Encompassing broader
  discipline knowledge or areas, synthesis of
  solution from disciplinary areas - offering
  multiple perspectives and terminologies
• COMMUNICATION Communicate alternatives, argue
  solutions, trade-offs, review, critique

5
SUMMARY TO INTRODUCTION

• COURSE FOCUS SOFTWARE ENGINEERING GUIDED BY
  OBJECT-ORIENTED APPROACHES
• SYSTEMS ANALYSIS
• DESIGN, PROTOTYPING
• (Automatic) CODE GENERATION
• PROJECT MANAGEMENT
• CONFIGURATION MANAGEMENT
• COMPLEXITY AND CHANGE MANAGEMENT
• COMMUNICATION MANAGEMENT

6
SUMMARY OF INTRODUCTION - 2

• COURSE OF DISCUSSION
• INTRO
• FUNDAMENTAL TOOLS
• UML TOOLS AND TECHNIQUES (Drive the software
  process a development environment)
• PROJECT COMMUNICATION PROCESS Tools and
  Techniques
• SYSTEMS REQUIREMENTS
• SYSEMS DESIGN
• OBJECT DESIGN (Detailed Design and
  Hardware/Software Co-design Issues)
• RATIONALE MANAGEMENT (DEALING WITH CHANGES)
• TESTING

7
ASPECTS OF SOFTWARE ENGINEERING

• WHAT IS ENGINEERING ABOUT IT?
• SYSTEMS ARE LARGE, COMPLEX AND POSSIBLY
  NON-EXISTING
• BUILDING HIGH-QUALITY PRODUCTS WITH
  OFF-THE-SHELVE COMPONENTS
• INTEGRATING (SEEMINGLY) DIFFERENT COMPONENTS,
  UNDERSTANDING THE INTERFACES AND BUILDING GLUES
  FOR FITNESS
• SPECIFYING ILL-DEFINED PROBLEMS
• ANAYSIS (Including estimations)
• DESIGN AND BUILD MODELS FOR DEMONSTRATION
• (Patterns, Schematics, Layouts, Prototyping vs
  Breadboarding)
• DEVELOP PARTIAL SOLUTIONS, TESTING, REFINE
• EVALUATE SOLUTIONS, REDESIGN
• TIMELY DEPLOYMENT AND DELIVERY, PACKAGING

8
WHAT IS SOFTWARE ENGINEERING?

• CONSTRUCTING SOFTWARE (EMBEDDED OR APPLICATION)
  FAILURES
• WHAT ARE THE FUNDAMENTAL ACTIVITIES?
• MODELING ACTIVITY Conceptualizing and
  structuring the system via abstraction
• PROBLEM-SOLVING Experimentation with models and
  evaluation via empirical methods
• KNOWLEDGE ACQUISITION Data collection and
  organization, evaluating application domain
  against solution domain
• RATIONALE-DRIVEN Matching evaluated domain
  knowledge against contextual decisions via
  issue/resolution modeling

9
INTRO MODELING ACTIVITY

• THE SYSTEM Natural (molecular system), Social
  (population dynamics simulator), Artificial
  (space shuttle, computer system hardware or
  software)
• MATURED (scientific) SYSTEMS OFFER INSIGHTS INTO
  MODELING THE ARTIFICIAL (E.g., building computer
  CPUs after micromolecular signaing and
  interconnections)
• MODELING ALLOWS DEALING WITH COMPLEXITY,
  UNDERSTANDING, VISUALIZATION (E.g., molecular
  arrangements in liquids, reconstruction of
  dinosaur for missing/assorted bones or parts)
• FACETS OF SYSTEMS
• Real-World Systems described by a set of
  phenomena
• Problem (Application) Domain Model described by
  a set of concepts (part of the Real-World)
• Understanding the systems parts, functional or
  operational aspects, rules, assumptions,
  procedures, and build models of the problem and
  solution (part understood) domains
• OBJECT-ORIENTED MODELING An activity that
  combines or extends the problem domain models to
  encompass the solution domain models (a mapping
  function), where both worlds are unified by
  mapping objects through their relationships

10
INTRO PROBLEM-SOLVING ACTIVITY

• A TRIAL-AND-ERROR PROCESS, EVALUATING ALTERNATIVE
  SOLUTIONS (empirical)
• STEPS
• Problem Formulation (equational, models
  representational)
• Problem Analysis (issues, analyze patterns of
  solutions, reintegrate partial solutions, match
  model with reality user/client requirements or
  expectation)
• Identify/Develop Solutions (evaluate solution
  choices, validate solutions, management of
  solutions)
• Select (optimal) Solution (indicate
  assumptions, rationale for selection)
• Specify Solution (select a suitable
  representation to specify the solution at each
  stage of software process)
• SOFTWARE LIFE CYCLE OR PROCESS
• Requirements Elicitation (problem domain
  identification of objects and relationships)
• Requirements Analysis (problem domain
  decomposition and organization of objects)
• System Design (solution domain functional and
  structural modeling of objects)
• Object Design (solution domain subsystem
  identification and mapping, may reiterate)
• Code Generation (translation of solution model
  into executable representation)
• Testing (verification of correctness of domains
  and validation of requirements satisfaction)
• Project Management (entails configuration,
  change, cost, time, communication,
  certification,)

11
INTRO KNOWLEDGE ACQUISITION ACTIVITY

• A NON-LINEAR ACTIVITY THAT ENTAILS THE
  ACCUMULATION OF KNOWLEDGE, WITH CONSTANT
  VALIDATION AND INVALIDATION OF DATA AS NEW
  KNOWLEDGE BECOMES AVAILABLE
• THE LINEARLITY OF THE WATERFALL MODEL IS WEAKENED
  BY THE KNOWLEDGE ACQUISITION NON-LINEARLITY
• RISK-BASED SOFTWARE PROCESS INCORPORATES
  NON-LINEARITY (in this case, assumptions are made
  to facilitate design, but quickly removed when
  nullified, allowing changes)
• ISSUE-BASED SOFTWARE PROCESS INCORPORATES
  CONFLUENCES AND NON-LINEARITY

12
INTRO RATIONALE MANAGEMENT ACTIVITY

• ANALOGY Timelessness of mathematical proofs
  remain axiomatic (with rules) until rules or
  assumptions change. E.g., the non-Euclidean
  geometry of parallel lines and a point, p.
• IN SOFTWARE PROCESS Assumptions change rapidly,
  hence change must be issued, argued in its
  context and impact, evaluated against criteria,
  resolved and documented.

13
SOFTWARE ENGINEERING CONCEPTS

consumes
is produced by



Figure 1-1. Software engineering concepts,
depicted as a UML class diagram (OMG, 1998).
14
CONCEPTS ENTITIES INVOLVED

• PARTICIPANTS AND THEIR ROLES (associations)
• SYSTEM (the real world) AND THE MODELS
  (abstraction)
• WORK PRODUCTS (artifacts) Internal work
  by-product or Deliverable (finished)
• ACTIVITIES (main stages/phases), TASKS
  (basic/atomic unit of work), RESOURCES (tools and
  assets needed to accomplish a task)
• GOALS (a high-level principle important aspects
  of system), REQUIREMENTS (objectives to satisfy
  the goals both Functional and Non-Functional)
• NOTATIONS (form of representation
  graphical/textual, e.g., UML), METHOD
  (step-by-step procedure for doing a task),
  METHODOLOGY (a set of methods often
  complementary)

15
SOFTWARE ENGINEERING DEVELOPMENT ACTIVITIES

• REQUIREMENTS ELICITATION
• User/Client interactions/discussions
• Results in defining use cases and actors
• Use Cases sequence of events or threads of
  actions defining functions of the system,
  depicting how the actors interact/interface with
  the system
• Actors External to the system itself, e.g.,
  people, off-the-shelf applications (OS, DBMS,
  CPU, Disks)
• Results also include non-functional requirements
  (e.g., performance constraints, quality,
  tolerance)
• Fig 1-2

16
SOFTWARE ENGINEERING ACTIVITIES - 2

• ANALYSIS
• Entails transformation of uses cases to object
  models (I.e, software arch of objects and
  associations, attributes, and operations)
• Further exposes inconsistencies and ambiguities
  in the specification (use cases)

valid for
results into
amount paid
Figure 1-3. An object model for the ticket
distributor (UML class diagram). In the
PurchaseOneWayTicket use case, a Traveler
initiates a transaction that will result in a
Ticket. A Ticket is valid only for a specified
Zone. During the Transaction, the system tracks
the Balance due by counting the Coins and Bills
inserted.
17
SOFTWARE ENGINEERING ACTIVITIES - 3

• SYSTEM DESIGN
• Identification of design goals and constraints
• (Functional) Decomposition of object model into
  subsystems (highly cohesive sub-models)
• Definition of interfaces to subsystems, as well
  as selection of integrative components, e.g.,
  CPU, OS, DBMS that will interface with the system

Figure 1-4. A subsystem decomposition for the
TicketDistributor (UML class diagram, folders
represent subsystems, dashed lines represent
dependencies). The Traveler Interface subsystem
is responsible for collecting input from the
Traveler and providing feedback (e.g., display
ticket price, returning change). The Local Tariff
subsystem computes the price of different tickets
based on a local database. The Central Tariff
subsystem, located on a central computer,
maintains a reference copy of the tariff
database. An Updater subsystem is responsible for
updating the local databases at each
TicketDistributor through a network when ticket
prices change.
18
SOFTWARE ENGINEERING ACTIVITIES - 4

• OBJECT DESIGN
• Principal activity is identifying unifying
  objects (including their attributes,
  associations, operations) necessary for mapping
  the analysis model (from the Elicitation/Analysis
  phases) into the external or actor objects
  (e.g., OS, DBMS, CPU)
• Involves restructuring the object model, taking
  into consideration the design goals, to achieve
  an integrated system with high cohesion and
  minimum coherence, allowing extensibility,
  interoperability, and optimization setting the
  stage for efficient code generation
• The integrated subsystems also have annotations
  of constraints (that ensure testability)
• IMPLEMENTATION
• Translation of object model into code manually
  or automatically or both
• Involves transforming the object operations (into
  methods) and attributes (into data structures),
  constraints (into exceptions and conditions),
  object classes (into classes), and subsystems
  (into packages or components)

19
SOFTWARE ENGINEERING ACTIVITIES - 5

• MANAGING SOFTWARE DEVELOPMENT
• Communication exchange of models, documents,
  ideas, reports, partial products, raising issues,
  formal discussion, conflict/issue resolution,
  communicating decisions, meetings, emailing,
  recording minutes with agreed notation/representat
  ion, using common procedures and standards
• Rationale Management Entails issues, arguments,
  constraints/criteria, justification, evaluation,
  consensus, resolution mostly dealing with
  changes and complexity, therefore need modeling
  (e.g., using UML notation)
• Testing Quality assurance (verification and
  validation) of system for given user goals,
  constraints or requirements. Entails test case
  generation (test data, test stub, test driver)
• Software Configuration Management Monitoring
  and controlling changes and product versioning,
  support and control for growth, technological
  changes, system evolution, tracking and
  documenting changes closely related to
  Rationale Management
• Project Management Overarching process, across
  all phases, involves costing/budgeting, setting
  milestones, timetable, people management,
  check-pointing, assessment, communication