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. Project Activity Work Product Task Resources System Participant Model Time Document Equipment SOFTWARE ENGINEERING CONCEPTS * is produced by consumes * * * 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. Transaction Ticket Zone Coin Balance Bill 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. Updater Traveler Interface Local Tariff Central Tariff 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 TravelerInterface subsystem is responsible for collecting input from the Traveler and providing feedback (e.g., display ticket price, returning change). The LocalTariff subsystem computes the price of different tickets based on a local database. The CentralTariff 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/representation, 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