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 Figure 1-1. Software engineering concepts, depicted as a UML class diagram (OMG, 1998). consumes Activity Work ProductResourcesTask Equipment Time ParticipantDocument Model System is produced by * * ** Project

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) results into valid for amount paid Coin BillZoneBalanceTicketTransaction 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 Traveler InterfaceUpdaterLocal TariffCentral Tariff 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/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