Software Development Notes

Software Engineering Overview

  • Recent Trends:
    • In 2014, the global software market was worth USD 1.2692 trillion, indicating software's growing influence across industries.
    • Systematic software development and management are crucial for system quality and productivity.
  • Learning Objectives:
    • Explain software characteristics and problems.
    • Explain the background and purpose of software engineering.
    • Explain software development process models.
  • Keywords:
    • Software characteristics
    • Software lifecycle
    • Requirements analysis, design, implementation, testing
    • Software requirement management, software maintenance, software configuration management, software quality management
  • Practical Business Preview:
    • Software is key to digital transformation, exemplified by Uber and Airbnb.
    • Companies like GE and Goldman Sachs view themselves as software companies.
    • AI, like AlphaGo, demonstrates software's potential.
    • Autonomous driving relies heavily on software.
    • Software quality management and productivity improvements are essential.
    • The domestic software industry faces challenges like budget constraints and developer shortages.
    • Systematic implementation is crucial for managing large projects and complex requirements.

Background to and Purpose of Software Engineering

  • Introduction to software engineering:
    • Software engineering technology is crucial for developing complex software.
    • It provides systematic management to overcome difficulties from requirements analysis to maintenance.
    • Effective application requires balanced key elements: process, organization/people, and infrastructure/technology.
  • Background to software engineering:
    • 1950s: Introduction of software engineering concepts.
    • 1960s: Software engineering introduced due to the "software crisis" (lack of skilled engineers).
    • 1970s: Shortage of software developers led to the "coding first and correction later" approach, resulting in defects.
    • The Waterfall model (sequential analysis, design, implementation) was developed.
    • 1980s: Focus on software reusability to boost productivity.
    • 1990s: Emphasis on reducing 'time to market' and concurrent engineering.
    • 2000s: Adoption of agile methodologies to respond to rapid changes.
  • Four Key Elements of Software Engineering:
    • Method: Project planning, estimation, system/software analysis, data structure, algorithm, coding, testing, and maintenance tasks.
      • Language-specific methods and graphical notations are introduced, along with software quality evaluation standards.
    • Tool: Automated or semi-automated methods to improve productivity and consistency.
      • Examples include requirements management, modeling, configuration management, and change management tools.
      • Integrated tools support software development by sharing information.
    • Procedure: Combination of methods and tools for rational and timely software development.
      • Defines applied methods, deliverables, quality controls, coordination, and milestones.
    • People: Software engineering relies heavily on employees and organizations specializing in it.
      • Software development is hard to summarize due to the diversity of issues.

Lifecycle of Software Development

  • Definition:
    • The lifecycle includes the entire process from understanding user needs to operation and maintenance.
    • Composed of feasibility review, development planning, requirements analysis, design, implementation, testing, operation, and maintenance.
  • Purposes:
    • Calculate project costs and create development plans, and establish a basic framework.
    • Standardize terminology.
    • Manage projects.
  • Selecting a Software Lifecycle:
    • Crucial for tailoring the development process.
    • Based on risk and uncertainty assessment.
    • Aim to minimize risks and uncertainties.
    • Representative models: Waterfall, prototype, evolutionary, and incremental.
  • Types of Software Lifecycle Models:
    • V Model:
      • Clarifies activities for project managers and developers.
      • Helps customers understand software development principles.
      • Ideal for clarifying system requirements.
      • Usable when requirements are unclear, but project estimation is limited to the requirement analysis phase.
      • A project implementing a standard communication protocol is suitable.
      • Easy to apply and manage, with clear start/end definitions, emphasizing project verification and validation by performing
      • development activities and corresponding test activities at the same time during the entire development cycle.
    • V Model with Prototyping:
      • Prototyping develops a system part to understand the system and address risks/uncertainties.
      • Leads to common understanding between developers and customers.
      • Can be applied to Waterfall/V models or used independently.
      • Reduces uncertainty factors and risks like requirement implementation, system performance, introducing tools, and outsourcing.
      • Two approaches:
        • Approach 1: Seek and apply solutions when the problem isn't clear. Suitable for new user interfaces or improving system performance.
          1. Define uncertainty factors.
          2. Seek a solution and define how to apply it.
          3. Try to apply the solution. (It can be reiterated.)
          4. Find the cause of the uncertainty factor based on the result of step 3.
        • Approach 2: Enumerate solutions and evaluate them using standards. Appropriate for risks/uncertainties in applying solutions.
          1. Define the uncertainty factors.
          2. Enumerate the solutions that can be selected and define the selection criteria.
          3. Evaluate the solutions according to the selection criteria.
          4. Select the most suitable solution.
    • Incremental Model:
      • Useful when system development time needs to be reduced.
      • Develops core parts first to make the system operable, then implements the remaining functions.
      • System functions are extended several times.
      • The final version incorporates all functions, improving risk reduction of external interfaces (H/W and S/W) in the early phase.
      • The V or Prototyping V model can be applied since requirements are clear.
    • Evolutionary Model:
      • Useful when reducing system development time.
      • Unlike the incremental model, the development phase is reiterated several times.
      • Each system provides all functions to the user. It is suitable when the overall system specification is not certain.
      • Changes are identified through system use and reflected in the next version.
      • Changes includes changes to function, user interface, reliability, and performance.
      • Often used with the incremental model, improving competitiveness by reducing the development period and using the system early and identifying/fixing unexpected problems early.

Software Development Methodology

  • Defines each development phase, activities, deliverables, verification procedures, completion criteria, and standardized procedures and tools for development plan, analysis, design, and implementation.
  • Necessity of the Software Development Methodology:
    • Improving development productivity by accumulating and reusing development experience.
    • Effective project management.
    • Providing communication via formal procedures and standard terminology.
    • Assuring quality by verifying each phase.
  • Comparison of Software Development Methodologies:
    • See Table 1 in the original document.
  • Software development phases:
    • Requirements analysis:
      • Deciding what to develop.
      • Understanding the user's needs.
      • Reduces costs in later phases.
      • Prevents excessive costs and quality deterioration.
    • Design:
      • The first step in physical realization.
      • Determines system structure and component allocation.
      • Directly impacts quality and stability.
    • Implementation:
      • Programming based on the design specification.
      • Writing code according to standards.
    • Testing:
      • Inspecting if the system satisfies requirements using manual or automated methods.
      • Assuring software quality by finding faults.
      • Evaluating and modifying to improve quality.

Agile Development Methodology

  • Types of Agile Methodologies:
    • Scrum, Extreme Programming (XP), Lean software development, Agile Unified Process (AUP).
    • Scrum and XP are commonly used together. Lean is often used with Scrum.
  • Agile Development Methodology - XP
    • XP Overview:
      • Established by Kent Beck in the late 1990s.
      • Lightweight, suitable for small to medium organizations.
      • Focuses on development techniques like Test-Driven Development (TDD), Daily Build, and Continuous Integration.
    • XP Development Procedure and Terminology:
      • User stories: Requirements collection and communication tool.
      • Spike: Simple program to address difficult requirements or potential solutions.
      • Release planning: Establishes a deployment plan, dividing into one to three-week iterations.
      • Acceptance test: Performed by the customer before release.
      • Smaller releases: Provides benefits to the customer early on in the development.
    • XP Values:
      • Communication: Most important at the team level.
      • Simplicity: Keep the design simple and clear.
      • Feedback: Gradual improvement is more effective than perfection.
      • Courage: Cope with changes to requirements and technology quickly.
      • Respect: Essential for proper project implementation.
    • Extreme Programming Practices:
      • See Table 2 in the original document.
  • Scrum Overview:
    * Designed for project management, based on estimation and adjustment.
    * Directly modeled after “The New Product Development Game”.
    * Consists of three fundamental units: Product owner, Scrum master, and Scrum team.
  • Scrum Process:
    * Sprint: Repetitive development period of 1 to 4 weeks.
    * Three meetings: Daily Scrum, Sprint plan, Sprint review.
    * Three deliverables: Product backlog, Sprint backlog, Burndown chart.
  • See Tables 3, 4, and 5 in the original document.
    • Sprint Planning: Goals are set for each sprint and items are selected for execution during a sprint from the product backlog. A person is appointed to take charge of each item and draw up a plan for each task.
    • Daily Scrum: A meeting that is held for 15 minutes each day to share the progress of the project. All of the team members should attend and discuss what they did, what to do and other issues every day.
    • Sprint review: A meeting held to check the work progress and deliverables in order to see if the sprint goal has been achieved. The Scrum team demonstrates what they did during the sprint to the attendees and receives their feedback. It is recommended to run a demo for all works performed during the sprint concermed with the participation of the customer. At this time, the Scrum master conducts a retrospective review to find out what went well, what was disappointing, and what should be improved upon during the sprint.
    • Three Deliverables: The product backlog, sprint backlog and burndown chart help a team to deliver transparency, provide the focus for timeboxing, enable constant communication and remain an empirical model.
  • Transparency: It is difficult to exactly understand the current status of the project, progress compared to the plan, and identified issues. Scrum enables the user to effectively understand the status or problem of a project using various techniques, such as the Scrum meeting, burndown chart, and sprint review.
  • Timeboxing: Concentration on a project only becomes possible by limiting the amount of time it takes to implement Scrum. The daily Scrum is performed for a limited time of 15 minutes each day, and the sprint review is performed periodically for each iteration.
  • Communication: Much effort is made during Scrum to facilitate communication among the team members. One of the characteristics of Scrum that makes communication among team members smooth is the procedure by which developers share their problems during the daily Scrum and discuss the difficulty/time of implementing user stories using the planning poker.
  • Empirical Model: Scrum has its own process model, but many techniques place emphasis on the experience of the individuals participating in the project. As each project has its own intrinsic situation and characteristics, it is difficult to understand the project situation using the existing standardized process. Scrum accepts that something can actually be different for each team even though the basic structure is the same.

Software Reuse

  • Recent Trends: Enterprises increasingly reuse software for globalization and to reduce costs.
  • Learning Objectives:
    • Understand software reuse concepts, purpose, application, and effects.
    • Understand reverse engineering concepts, necessity, strengths, and considerations.
  • Keywords: Reuse, reverse engineering, Code reuse, software standardization, software maintenance
  • Practical Business Preview:
    • Establish a system for creating a reuse culture.
    • Development teams need to change their perception and culture to incorporate software reuse. The following should be performed to fully establish the system.
    • Composition of the reuse management organization: The reuse management organization is needed to establish the reuse-based method of software development. This organization should introduce and establish procedures and standards related to reuse and enact and implement a policy for increasing reusability.
    • Training on reuse: Training on software reuse should be conducted on a regular basis to create an atmosphere or culture conducive to software reuse within the organization. The training should be also provided to project managers and organization managers, in addition to developers. In terms of content, the training for managers should differ from that intended for developers.
    • Introduction of a reward system to increase reusability: Reuse may be perceived with extreme discomfort when first introduced. Therefore, a method should be devised to increase reusability by policy. Introducing an incentive system for reuse is the representative method in this regard.
    • Securing reliability for reused components: To make developers trust reused components, the reliability of the components managed in the reuse library should be sufficiently guaranteed and measures to help them find suitable components should be prepared, in addition to the change of developer's awareness.

Software Reuse

  • Overview of Software Reuse:
    • Developing new software using existing software or knowledge.
    • Reusable assets include design, requirements, inspection, and architecture.
  • Background to Software Reuse:
    • Deterioration of quality and productivity due to the software crisis.
    • Increased use of CASE tools.
    • Efforts to comply with standardization and secure quality.
  • Definition of Software Reuse:
    • Standardizing software development knowledge (function, module, configuration).
    • Increasing development productivity by repeated use.
    • Increasing quality, productivity, and reliability, and reducing development time and cost.
    • Directly reusing modules, programs, and deliverables, or modifying them.
  • Purpose of Software Reuse: See original table.
  • Target of Software Reuse:
    • General knowledge (environmental, external).
    • Design information (system architecture, system design).
    • Data information (system data, test cases).
    • Program code (module, program).
    • Others (cost-benefit analysis, user documentation, feasibility studies, prototypes, people).
  • Principle of Software Reuse:
    • Generality, Modularity (information hiding, abstraction), Hardware independence, Software independence, Self-documentation, Commonality, Reliability.
  • Problems when Reusing Software for Practical Business:
    • Difficulty finding common modules and software standardization.
    • Difficulty understanding internal interface requirements/side effects.
    • High cost of developing reusable components.
    • Delayed recognition of benefits.
    • Impracticality of extracting reusable components.
  • Obstacles to Software Reuse and Countermeasures:
    • Adverse reactions of managers and developers.
    • Lack of motivation and standardization.
    • Social or legal obstacles.
    • Use new design and development methodology.
    • Develop the reuse software library.
    • Use in automation tool (CASE).
    • Establish a compensation system.
    • Active management strategy.
    • Organizational change.
  • Considerations when Reusing Software:
    • Improve productivity, software development process, reuse culture, initial investment, continual improvement, tool support, productivity evaluation, information management.
    • Deliverables: Architecture, source code, data, designs, documents, estimates, human interfaces, plans, requirements, test cases
    • Top-down/bottom-up development approach and Granularity of reusable components are also a factor.
  • Effects of Software Reuse:
    • Reduces the TCO of software production. Creates sharing and utilization effects for producing high-quality software. Promotes the sharing of information on system development and the sharing of deliverables from other projects. Has an educational effect on the system structure and the method of developing a good system.

Reverse Engineering

  • Definition of Reverse Engineering:
    • Deconstructing a developed system to reveal its documents, design techniques, etc.
    • Understanding and modifying a system during software maintenance.
    • Creating deliverables corresponding to initial lifecycle phases using the program or document obtained in the last phase.
    • Opposite of forward engineering.
  • The Main Reasons Why Reverse Engineering is Necessary:
    • Difficulty maintaining a running system.
    • Frequent changes decrease efficiency.
    • Redeveloping file-based systems into relational databases.
    • Downsizing the default mainframe
  • Advantages of Reverse Engineering:
    • Commercialized or previously developed software can be analyzed.
    • Maintainability can be improved, and CASE can be used easily.
  • Types of Reverse Engineering:
    • Logic reverse engineering.
    • Data reverse engineering.

Data Structure and Algorithm

  • Learning objectives:
    • Explain the definition and classification of data structure and use the linear/ nonlinear structure.
    • Understand the role of the algorithm and select an appropriate algorithm depending on the situation.
  • Keywords:
    • Array, list, stack, queue, deque, tree, graph
    • Algorithm definition, algorithm performance analysis, sorting/searching algorithm
  • Preview for practical business:
    • A blackout in northeastern US in 2003 was caused by a software error in the XA/21 system
    • Two programs in the XA/21 system simultaneously wrote and accessed the same data structure, which is a way of structurally expressing data in programming. The error corrupted the data structure, which in turn put the alarm process into an infinite loop. The alarm queue increased indefinitely, and all available memory was consumed after 30 minutes.
    • A data structure is a method of storing data efficiently, considering its characteristics.
    • An algorithm is a calculation process to solve a problem after receiving a certain value.

Data Structure

  • Definition:
    • A method of storing data in a computer's memory device, systematically defining it for efficient expression and utilization.
  • Classification:
    • Linear structure: Data is connected in a row.
    • Non-linear structure: Data has a hierarchical structure. Including tree and Graph.
  • See classification Table 8 in original document.
  • Comparison of Sequential and Linked Data Structures:
    • See Table 9 in the original document.

Stack and Queue

  • Stack:
    • Linear list where data is saved in order of input and the last input data is output first (LIFO - Last In, First Out).
    • Access (insert/delete) to elements stored in the stack can be accessed only from the place designated as the top, and an element is inserted at the top only
  • Operations:
    • top(): Returns the data value at the top of the stack.
    • push(): Inserts data on the stack.
    • pop(): Deletes and returns data from the stack.
    • isempty(): Returns ‘true’ if there is no element on the stack or returns ‘false’ if there is an element on the stack.
    • isfull(): Returns ‘false’ if there is no element on the stack or returns ‘true’ if there is an element on the stack.
  • Queue:
    • Limited insertion and deletion, but unlike a stack, the queue has a structure in which an element can be inserted at the bottom and deleted at the top only
    • Elements are listed in order of insertion, and the element inserted first is at the front and thus is deleted first.
  • Operations:
    • enQueue: Inserts data into the queue. Frees up space in the queue by moving the rear, and inserts data.
    • deQueue: Deletes data from the queue. Moves the front to pass the oldest data to the position of the next data.
  • Comparison of Stack and Queue Operations (insert and delete): See Table 10 in the original document.

Tree and Graph

  • Tree:
    • Hierarchical data structure with a hierarchical relationship between elements. It has a tree-like structure that expands from top to bottom, and the elements have a one-to-many relationship.
    • The topmost node is the 'root node', and the line connecting the nodes is called the 'edge'. Child nodes having the same parent node are called 'sibling nodes', and the tree created when the edge to the parent node is disconnected is called a 'subtree'.
  • Graph:
    • Many-to-many relationship between connected elements.
    • Used to solve problems based on graph theory (electric circuit analysis, shortest distance search, artificial intelligence).
  • Types of Graphs: See Table 11 in the original document.
    • Undirected graph, Directed graph, Complete graph, Weighted graph.
    • Adjacency matrix and adjacency list are two methods of expressing graphs in memory.

Data Structure Selection Criteria & Utilization

  • Data structure selection criteria:
    • Data processing time
    • Data size
    • Data utilization frequency
    • Data update frequency
    • Ease of programming
  • Utilization of data structures:
    • List: Array implementation, DBMS index, problems such as search or sorting, etc.
    • Stack: Interrupt handling, sequence control of the recursive program, saving the return address of the subroutine, calculating an expression represented in postfix notation, undo function of the text editor, etc.
    • Queue: Job scheduling of the operating system, queue processing, asynchronous data exchange (file |/O, pipes, sockets), keyboard buffer use, spool operation, etc.
    • Deque: A data structure that makes the most of the strengths of the stack and queue only, and which is mostly used in the fields related to the stack and queue.
    • Tree: Problems like search and sorting, grammar parsing, Huffman code, decision trees, games, etc.
    • Graph: Computer network (local area network, internet, web, etc.), electric circuit analysis, binary relation, simultaneous equations, etc.

Algorithm

  • Algorithm Overview:
    • Definition: A description of processing procedures to solve a given problem step by step. A specification logically describes a step-wise procedure by abstracting the problem-solving method.
    • Conditions of Algorithms:
      • Input: More than one data needed to execute.
      • Output: More than one result after execution.
      • Definiteness: Instructions are clearly specified.
      • Finiteness: Algorithm must terminate after execution.
      • Effectiveness: Instructions should be basic and implementable.
  • Algorithm Analysis Criteria:
    • Correctness, Amount of work done, Amount of space used, Optimality, Simplicity.
  • Algorithm Expression Method:
    • Description in natural language, Flow chart representation, Pseudocode.

Algorithm Performance Analysis

  • Algorithm Performance Analysis:

    • Analyzed by estimating space complexity and time complexity.

  • Space Complexity:
    * Total storage space needed to execute an algorithm.
    * Space complexity = Amount of fixed space + Amount of variable space

  • Time Complexity:
    * Time is taken to execute an algorithm.
    * Time complexity = Compilation time + Execution time

  • Execution time is expressed as O(n) using the Big Oh notation to compare algorithms: choose best algorithm with smallest time complexity.

    • Table 14 provides the calculated execution times.
    • Table 15 provides algorithm complexity.

Sorting Algorithm

  • Classification of Sorting: See figure 6.
    • Internal sorting and external sorting based on the sorting location, such as with insertion and selection.
  • Comparison of the Execution Times of Internal Sorting Algorithms: See table 16.
    • Selection Sort
      • The largest element is searched in an array A[1…n] and replaced with the A[n] at the end of the array.
        selectionSort (A[ ], n)
        {\
        \ For last = n downto 2 {\
        \The largest number A[k] is replaced with \$A[last];\
        \}\
        }\
    • Bubble Sort: the largest element is continuously moved to the last position.
      bubbleSort (A[ ], n)
      {\
      \ For last = n downto 2 {\
      \ For i = 1 to last -1 {\
      \ if (A[i] > A[i + 1) then A[i] = Afi + 1];\
      \}\
      }\$$

Search Algorithm

  • Search Algorithm Overview:
    • A technique to efficiently find a desired item in a data set.
    • Divided into linear and control search (sorted data).
    • Hashing searches using a key value.
    • Needs optimal search method considering data structure and arrangement.
  • Classification of Search Algorithms: See Table 17.
    • Linear Search, Binary Search, Fibonacci Search, and Interpolation

Graph Search Algorithms

  • Graph Search: Visits and processes all graph vertices once, starting from one vertex.
  • Depth First Search (DFS):Explores one direction as far as possible, then backtracks, using a last-in-first-out stack structure. Low storage space.
  • Breadth First Search (BFS):Searches adjacent nodes first, using a queue to retrieve visited nodes sequentially.

Minimum Spanning Tree

  • Introduction to the Minimum Spanning Tree: A spanning tree is a special form of tree that includes and connects all vertices in an undirected weighted graph.
  • Kruskal’s Algorithm: Select the smallest weighted edge, checking its cycle creation.
  • Prim’s Algorithm: Start from a random vertex, expanding using unvisited vertices and minimum-weighted edges.

Principles of Software Design and Structural Design

  • Recent trends and major issues:
    Quality competition, software design is closely related to software quality. A process for good design is also that of performing quality control and prevention activities frequently in the analysis and design phase, which can significantly reduces the cost possibility of software failure.
  • Learning Objectives:
    • Software design principles.
    • Cohesion and coupling concepts.
    • Structural design methods.
  • Keywords:
    • Division, abstraction, information hiding, stepwise refinement, modularization, structuralization.
    • Cohesion, coupling.
    • Transform-based and transaction-based design, structure chart.
  • Practical Business Preview:
    • Ariane 5's explosion was related to exceptions handling against type mismatch variables and design redundancy variables.

Principles of Software Design

  • Reduce complexity by dividing user requirements and reassembling them into groups.
  • A. Abstraction:
    • Implement product at a high level before going into the deeper details.
    • Express only essential matters, eliminating unnecessary details.
    • Types: Data abstraction, control abstraction, and process abstraction.
  • B. Information Hiding:
    • Content of each module is hidden; messages are transmitted by the interface only.
    • Limits access to internal information.
    • Ensures changes affect a minimum number of modules.
    • Information hiding hides the internal structure of each module (abstraction), and the modules communicate with each other using the predefined interface only.
  • C. Stepwise Refinement: Gradually move from program structure to details, decreasing abstraction. Requires detailed description.
  • D. Modularization:
    • Divides the system into components (modules).
    • Enables intelligent management and complexity resolution.
    • Easier maintenance and modification.
  • E. Structuralization:
    • Related to the principle of divide & conquer, which means dividing first and detailed division during the analysis and design phase.

Cohesion and Coupling

  • Good design = efficient programming/easy adaptation to changes.
  • Maximize functional independence and reduce module merging.
  • Cohesion and coupling affect design quality.
  • A. Cohesion:
    • Measure of module maturity, indicating correlations among internal modules and it performs a task.
    • Types (highest to lowest): Functional, Sequential, Communication, Procedural, Temporal, Logical, Coincidental
  • B. Coupling:
    • Complexity of correlations between modules; increases with more interaction.
    • Data coupling (modules communicate with parameters) is ideal.
    • Content coupling (direct reference) should be avoided.
    • Types (weakest to strongest): Data, Stamp, Control, External, Common, Content.

Structural Design Method

  • Transferring structured analysis results to structured design is data flow-oriented design.

  • Apply a structural method and top-down refinement.

  • A. Transform Flow-Oriented Design:

    • Maps system and its data to world.

    • Divides system components and hierarchy between basic functions (like those that perform calculations, for example.).

      • Structure:
        • Input control module.
        • Transform control module.
        • Output control module.

  • B. Transaction Flow-Oriented Design:

    • Data triggers an action (transaction).

    • Evaluates input and flows the result based on several output paths. Composed of:

      • Transaction center.
      • Module that receives input.
      • Modules corresponding to each operation path.

Software Architecture Design

  • Recent trends and major issues: Software architecture has been highlighted as having a fundamental and useful key role in effectively reflecting changes in information technology and developing high-quality software most effectively in a timely manner. This phase is required to manage the complexity of the system.
  • Learning Objectives:
    • Software architecture (SA).
    • Types of software architecture.
    • Methods of expressing software architecture design.
  • Keywords:
    • Module, component and connector, subsystem, framework Module, component and connector, subsystem, framework Repository structure, MVC (Model-View-Controller) structure, client-server model, package diagram, deployment diagram.
  • Practical Business Preview: Roles of the software architect such as:
    • Creator of a vision
    • Key technical consultant
    • Decision maker
    • Coaches
    • Coordinates
    • Implements
    • Advocates

Software Architecture Design

  • A. Software Architecture Overview:
    • Blueprint for handling factors affecting software development and complexity.
    • Includes modules, processes, data, relationships, technology, implementation, and flexibility, is used as a means of communication and a decision-making tool as well as determining the overall system structure, and organization of a development project.
  • B. Software Architecture Design Procedure:
    • Requirements analysis, architecture analysis and design, architecture verification and approval.
    • Specific requirements must be identified and non-functional requirements specified within project. Quality factors also should be identified and prioritized before a design. Setting the structure of a system that is in the early stages of design is generally encouraged.

Software Architecture Style

  • System Architecture has following structural functions in software design.
  • A. Repository Structure: When one subsystem creates data and other subsystems use that data, the repository is a structure that enables all subsystems to share the data by storing all shareable data in one place. The structure of the shared repository is suitable for sharing a large amount of data.
  • B. MVC (Model - View - Controller) Structure: The client-server model is composed of a set of servers and clients. The model is composed of a client requesting a service and a server providing the service, and there may be multiple client instances. Generally, the client-server model can utilize the network system effectively as it is implemented as a client-server model.
  • C. Client-Server Model: Express in order such that relationship can define
  • D. Hierarchy: A hierarchy can be defined as a system composed of several layers that provide its own specific service. It has the advantage of making problem solving easier when applied. If a problem occurs, it can be checked in an easy layer. Representative example is the OSI

Methods of Expressing Software Architecture Design

  • Setting the boundary between the system and external environment.

  • A. Context Model: The context diagram represents a system as a large process before dividing the system. This model shows system IO data by describing the system area that should be developed, determining the boundary between the system and the external environment, and presenting the interface with the outside.

  • B. Component Diagram: A component that can be reused, so that a well-made part can be purchased from other fields and plugged in, to speed up software development and increase productivity. In essence, reusability is the foundation of this technology.

  • C. Package Diagram: Once defined as a package, the relationship of dependence between packages can be minimized by hiding the inner details of the package from the outside. The package composed of a subsystem is a set of functionally related classes.

    Object-Oriented Design

  • Learning Objectives:

    • Object-oriented analysis and modeling.
    • Object-oriented design concepts and principles.
    • Static and dynamic modeling in UML.
    • Design pattern concepts and representative patterns.

  • Keywords:

    • Use case, sequence diagram, activity diagram, Object, class, encapsulation, inheritance, polymorphism, association
    • Class, property, relationship, association, operation, class diagram
    • Interaction diagram (sequence diagram, communication diagram), state diagram, activity diagram Singleton pattern, factory method pattern, facade pattern, strategy pattern

  • Practical Business Preview: SOLID - Five principles of object-oriented design

    • SRP (the Single Responsibility Principle)
    • OCP (Open Closed Principle)
    • LSP (Liskov Substitution Principle)
    • ISP (Interface Segregation Principle)
    • DIP (Dependency Inversion Principle

Object-Oriented Analysis and Modeling

  • Object Orientation:
    • Models a problem area as a set of real-world objects and their interactions, facilitating reuse and understanding.
  • Modeling:
    • Diagramming system performance or operations to analyze it and provide software views to understand software.
    • Critical for communicating with users, developers, and