The preface

In the soft engineering courses, the teacher often mentioned an equation software = program + software engineering (or software = program + document), that is, the birth of a software product is always accompanied by a series of software processes.

So how to fully understand software engineering (process)? From the perspective of the author of this book, MY understanding is that we should always hold the thinking mode of software product life cycle, connect the engineering stages such as requirements, modeling, design, implementation, testing and maintenance, and substitute ourselves into the case environment to simulate a series of activities in the development of software process, rather than separate them. Such a dynamic process is not only a boring learning of theories and methods, but also a problem-oriented theoretical application process required by problems.

Of course, software engineering as an engineering discipline, the biggest gain in the learning process can be said to be the master of the project thinking mode. For example, we can leave the software product category and talk about a real life example: if you need to master a new knowledge or task in a certain amount of time, we can do research, planning, layout, implementation, and acceptance, which is a similar process reusable software engineering method.

Finally, I would like to declare that some of my views and tendencies will inevitably be reflected in the process of learning software engineering. Of course, it also reflects the characteristics of this discipline that requires more communication. If there is any inappropriate or wrong place, we welcome suggestions and corrections.

  • Bibliography:

    • Software Engineering by Ian Sommerville: a series of computer science books, and a classic textbook of Ian Sommerille’s systematic introduction to software engineering theory.
    • The Method of Construction (2nd Ed.) : to be sorted. Paste the book douban review, for friends to judge, make a choice. The Method of Construction (2nd Edition)

  • The update process

    • 2018.05.02 – Complete the first draft;
    • 2018.05.04 – Updated Text: Introduction (Chapter 3/8);

Zero overview

One Software Process

  • Learning goals
    • Three average onesSoftware process model;
    • Understand what is involved in software requirements engineering, development, testing, and evolutionBasic process activity;
    • Understand why software processes are organized effectively to respond to changes in software requirements and design;
    • Rational Unified Process (RUP).
  • The basic activities that a software process must have
    • Software description
    • Software design and implementation
    • Software validation
    • Software evolution
  • There is no “ideal” software process – find the balance
    • Plan-driven process: Plan all process activities in advance, and then review the execution of the process as planned.
    • Agile processes: Planning is incremental and easy to change processes in response to changing customer needs. See for more detailsChapter 3.

Software process model

  • Software process: The sequence of activities that produce a software system.
  • A simplified representation of a software process (abstract representation).

  • Each process model represents a software process from a particular side, so it provides only partial information about the process.

    For example, the process activity model shows these activities and their sequence, but may not show the role of people in these activities.

The waterfall model

  • Plan-driven model;
  • The model views the basic process activities, description, development, validation, and evolution as distinct, independent process phases.
    • Requirements analysis and definition: Establish system services, constraints, and goals by consulting system users and define them in detail to form a system description.
    • System and software design
      • System design – Establish the overall architecture of the system, separating requirements into hardware requirements and software requirements.
      • Software design-Identify and describe some of the basic software system abstractions and their relationships.
    • Implementation and unit testing
      • Software design implementation – Implemented as a set of programs or program units.
      • Unit tests – Verify that each unit fits its description.
    • Integration and system testing
      • Integration – Integration of a single program unit or group of programs.
      • System testing – evaluating system reliability; Whether the software requirements are met.
    • Operation and maintenance

Incremental development

  • It can be plan-driven or agile.
    • The system delta is defined in advance, i.ePlan-driven approach.
    • The initial increments are defined, but the development of subsequent increments depends on the progress of the project and the customer’s priorities, i.eAgile methods.
  • The development of the system is to build a series of versions (increments) each adding some functionality to the previous version.
  • Incremental development characteristics
    • Reduces the cost of adapting to changing user needs.
    • Get feedback from users on what they have done during the development process.
    • Faster delivery and deployment of useful software to customers.

Software engineering for reuse

The general process model based on reuse development is shown in Figure 1-3. The initial requirements description phase and validation phase are similar to other processes, but the intermediate phase of the reuse oriented process is different.

  • Intermediate phase: component analysis, requirements modification, system design, development, and integration with reuse.
    • Component analysis: Requirements description -> Search components (often provide only part of the required functionality).
    • Requirement modification: Analyze requirements based on component information and modify requirements to reflect available components.
    • Design with reusable systems: Design the framework of the system or reuse an existing framework.
    • Development and integration

Process activities

Software description

  • Software description or requirements engineering is about understanding and defining what services the system needs to provide and figuring out what constraints are under development and operation.
  • The major phases of the requirements engineering process are shown in Figure 1-4.
    • Feasibility study
    • Requirements derivation and analysis
    • Requirements describe
    • Validation of requirements

Software design and implementation

  • The software design and implementation phase is the process of transforming the system description into an operational system.
  • Software design is a description of the structure of the software, the data of the system, the interfaces between the system components and the algorithms used. This is an iterative, iterative process.

Software validation

  • Program test: Run the system with simulated test data.
  • Test each phase of the process
    • Component (unit) testing: Testing each component individually; A component is a simple entity, such as a function, an object class, or a collection of these entities.
    • System test: integrate components into a complete system and test subsystems composed of components.
    • Acceptance test: customer provides real data test system.

Software evolution/software maintenance

Software engineering is no longer a separate process of development and maintenance, but an evolutionary process. An evolutionary process in which software changes over its lifetime as requirements change.

To cope with change

  • Effectively reduce change costs
    • Change avoidance: Predicting change, as inThe prototype systemIn which customers try prototypes and redefine requirements before incursing high software production costs.
    • Change tolerance:Incremental developmentEven a single incremental (small part of the system) modification to accommodate the change, processing the change at a lower cost.
  • Ways to respond to changing system requirements
    • System prototyping: Rapid development of a system version or part of a system to verify the feasibility of customer requirements and certain design decisions that it supportsChanges to avoid.
    • Incremental delivery: The system is delivered incrementally to the user for review and trial. That it supportsChanges to avoid 和 Change tolerance.

The prototype structure

  • A prototype is an initial version of a software system used to validate concepts, try out design options, and discover more problems and possible solutions.

  • Figure 1-6 shows the process model of prototype development.

    Figure 1-6 Prototype development process

    In the final stage: prototype evaluation, user training must be arranged and an evaluation plan should be developed based on the goals of the prototype. Users need to get used to the new system, and once they are comfortable with it, they are likely to find bugs and missing requirements.

  • There is no requirement that prototypes be executable.

    The user interface of a paper-based model system with which users interact, but their request is passed to a person who interprets the request and outputs the corresponding response.

Incremental delivery

  • Incremental development is a method of software development, as shown in Figure 1-7.

    Figure 1-7 Incremental delivery

  • Benefits of an incremental development process

    • Early increments serve as prototypes from which to gain experience with requirements for later system increments.
    • Each increment meets most of their needs, meaning that the software is ready to use immediately.
    • High-priority services were delivered first and then incrementally integrated, resulting in the most important system services being tested multiple times.
  • Problems with incremental delivery
    • The development of software descriptions along with the software itself is the essence of an iterative process. In the incremental approach, there is no complete description of the system until the final incremental description is complete. The procurement model of many organizations, such as the government, is that the system development contract is accompanied by a complete system description, i.e., conflicting.
    • Most users prefer all the functions of the old system to some of the functions of the new system, that is, it is difficult to get feedback.

Boehm’s spiral model

  • Risk-driven Software Process Framework (Spiral Model)
    • Each loop in the spiral represents a stage in the software process, for example, the most loop may be related to the system feasibility study, the next loop may be related to the system requirements definition, etc.
    • Each loop in the spiral is divided into four parts: 1) goal setting 2) risk assessment and avoidance 3) development and validation 4) planning

Rational Unified Process

  • RUP generally describes processes from three perspectives
    • Dynamic perspective: Gives the stages that the model goes through over time.
    • Static perspective: gives the process activities that take place.
    • Practice perspective: Suggest good practices that can be adopted in the process.

  • RUP is a phased model, as shown in Figure 1-8.

    • start
      • The goal is to build a business case for the system.
      • Identify all external entities (people and systems) that interact with the system and define those interactions.
      • Apply this information to assess the contribution of the system to the business, if the contribution is small, then the project is terminated at this stage.
    • elaboration
      • The objective is to improve the understanding of the problem domain, establish the system architecture, present the project plan, and identify key project risks.
      • Output the requirements model of the system (described use cases, architecture descriptions, and development plans).
    • Construction: system design, programming, and testing.

    • Transformation: Moving a system from a developer to a user and making it work in a real environment.

      1) Phases in RUP are closely related to the business, not to the technical level. 2) RUP combines phases (inception, elaboration, construction, transformation) and workflow (requirements, analysis, design…) Decoupling, that is, the various RUP workflows are potentially accommodated at all stages of the process.

      Figure 1-8 Phases of the RUP

  • Practical perspective

    • Develop software iteratively;
    • Requirement management: record and track customer requirements;
    • Use component-based architecture to organize the system architecture into component form;
    • Modeling software visually: UML model represents the static and dynamic view of software;
    • Checking software quality;
    • Control changes to software: Change management systems, configuration management programs, and tools to manage changes to software.

  • Static perspective

    • Focus on the activities that take place during development, which are referred to in RUP descriptions as workflows.

    • This process consists of six core process workflows and three core support workflows, as shown in Figure 1-9.

      Figure 1-9 Static workflow in RUP

Ii. Agile software development

Before we begin the Agile chapter, here’s an interesting example. The Jazz Band model, similar to the “Agile development model,” can also produce great work. During the performance, Miles Davis plays the theme on his trumpet (as an architect) and then goes to smoke a cigarette. The repertoire was left to others to improvise. Finally, Miles Davis joins in to respond to the theme).

Miles Davis So What

  • Learning goals
    • Understand the fundamentals, core concepts, and differences between agile and plan-driven software development.
    • Extreme programming;
    • Understand agile project managementScrumMethods;
    • Issues and issues when applying scalable agile methods -> Large software system development processes.

Agile methods

  • Agile is a method that focuses on rapid developmentIncremental development.Release software frequently,Reduce process overheadProduce high quality code. They involve the user directly in the development process.

  • The basic principles of agile methods are embodied in the Agile Manifesto:

    • Individuals and interactions over tools and processes;
    • Writing software is better than writing detailed documentation;
    • Customer cooperation trumps contract negotiation;

    • Responding to change is better than following a plan.

      That is, we value the items on the left more than the items on the left.

  • A large number of software engineers strive to maintain and evolve the existing software system. As can be seen from the characteristics of agile methods, the maintenance problems of agile methods are as follows:

    • After the software is delivered, the main difficulty may be to continue to involve the user in the process.
    • Keep the development team consistent, as there is no reference document to follow, if an agile development team dissolves, thenRely on team members to understand the system 的 Implicit knowledgeThe old is lost.
  • Hybrid methods: Agile methods embed certain techniques from plan-driven development.

Plan-driven development and agile development

Plan-driven and Agile are depicted in Figure 2-1.

  • Agile methods:
    • Iterations occur between all activities.

  • Plan-driven methods:

    • Iterations occur within activities, communicating between phases of the software process with formal documentation.

      Formal documentation: Visualization as the output of each stage.

  • To strike a balance between plan-driven and agile approaches, the following technical, people, and organizational questions must be answered.
    • Detailed description and design ->Plan-driven development
    • Interact with users and get feedback quickly ->Agile development
    • The scale of the development system;
    • The type of system developed, such as real-time systems with complex timing requirements, usually requires fairly detailed design to implement analysis ->Plan-driven development
    • The expected lifetime of the system;
    • What technology supports system development (agile methods often rely on tools to track design evolution);
    • Organization of the development team;
    • Cultural issues affecting system development (traditional engineering organization-driven culture);
    • Professional level of development team members;
    • Whether the system is subject to external regulations (e.g., the federal Aviation Administration FAA approves an aviation operating software with high safety requirements);

Extreme Programming (XP)

  • Extreme programming is an agile approach that integrates a set of good programming experiences. For example, frequent software releases, continuous software improvements, and customer participation in software development teams.
  • In XP, all requirements are represented as scripts (called user storylines) that are implemented directly as a series of tasks.
  • An XP process that produces an increment of the system under development, as shown in Figure 2-2.

  • Script cards are the primary input to the XP planning process.
    • The development team put eachThe scriptSplit intotaskAnd estimate the human resources required to achieve it.
    • Talk to customers, define requirements, prioritize scripts.

Testing in extreme programming

  • The testing process for many incremental development methods is quite non-standard.
  • To avoid some testing and system validation issues, the XP approach places more emphasis on the testing process.
  • Key features of testing in XP:
    • Test-first development (write the test program before the code);
    • Incremental test development from scripts;
    • User participation in test development and validation;
    • Use of automatic test system. The test is written as an executable component that stands alone. Automatic test framework is such a system. Eclipse’s JUnit, for example, is used for unit testing.

Pair programming

Pair programming has some quality benefits, but not enough to justify its overhead. But information sharing is important in pair programming because it reduces project risk when a team member leaves.

Agile Project Management

  • Criteria for project management: plan-driven.

  • A management approach (framework) suitable for incremental development (Agile) : Scrum.

    • Figure 2-3 shows the management process of Scrum.

      Figure 2-3 Scrum management process

    • The three phases of Scrum

      • Outline planning stage: establish general project objectives and design software architecture.
      • Sprint cycle stage:
        • Each loop develops a system increment;
        • Each cycle is a planning unit, in which the work includes evaluation, feature selection and development, software implementation;
      • Project closure: Improve documentation, such as system help and user manual.

      • Characteristics of the sprint cycle phase:

        • Sprints have a fixed length, typically 2-4 weeks, that corresponds to the development of a system version during XP.
        • The starting point for planning, the Backlog, is also the list of work to be completed in the project.
        • Evaluation phase: Backlogs are reviewed, prioritized and assigned risks.
        • Selection phase: All members of the project participate to select features and functions to be developed in the sprint cycle with the user.
        • Development phase: reach an agreement that software development will be organized, and team development members will meet for a period of time each day to review the development process and reschedule work if necessary. At this stage the development team is isolated from the customer and the organization.

        • At the end of the sprint cycle, the work done is reviewed and delivered to the user.

          All communication takes place through the Scrum Master, SM being understood as the facilitator. Embodies the idea of Scrum that the whole team is empowered to make decisions.

    • Scrum is suitable for distributed development environments.

Extensible agile methods

  • Agile methods are often used for small systems because they are developed for small teams that work and communicate in the same room.
  • Scalable agile methods can also be used to develop large systems.
  • The difference between large and small systems development (understood as the challenge of scalable agile methods applied to large systems).
    • Large systems often consist of independent, interacting subsystems. Different teams develop different subsystems independently, and teams may work in different locations or time zones.
    • Large systems consist of and interact with a series of existing systems, and many system requirements focus on such interactions.
    • When a system is produced by the integration of multiple systems, an important part of the development effort is system configuration rather than raw code development. This is not necessarily compatible with incremental development and frequent system integration.
    • Large systems often have different information holders, and it is necessary to include different information holders in the development process.
  • Two perspectives on scalable Agile methods
    • Copy and magnify, how do you apply these methods to whatA small teamundevelopableA large projectIn the.
    • Penetration, that is, how do you introduce agile methodsTo promoteTo those with years of development experienceBig institutionsIn the.

Iii demand Engineering

  • Learning goals

    • Understand user requirements, system requirements;
    • Understand functional and non-functional requirements;
    • How in the software requirements documentInstitutional demand;
    • Understand the content of requirements engineering activities and their relationships;
    • Understand requirements management.

  • Some of the concepts

    • User requirements: Ca-diagrams in natural language about what services the system needs to provide and what statements constrain system operations.

      High-level (abstract) profile requirements.

    • System requirements: specify the services the system will provide and the constraints on the system. The requirements document of the system is also called the function description.

      A detailed description of what services the system should provide.

Functional and non-functional requirements

  • The functional requirements
    • Describes the functions or services provided by the system.
    • If user requirements, describe functional requirements in an abstract way that can be understood by system users.
    • More specific functional system requirements require a detailed description of system functionality, exceptions, inputs, and outputs.

  • Nonfunctional requirements

    • Requirements that are not directly related to the specific services that the system provides to users. In short, they are rightSystem implementationDefines theThe constraint, such as the capability of the I/O device, and the representation of data interfacing with other systems.

    • Nonfunctional system requirements: Typically regulate or constrain the characteristics of the system in general.

      If a nonfunctional system requirement is not met, the entire system may become unusable.

    • Classification of non-functional requirements: Indicates that non-functional requirements are either derived from required software features (product requirements), from the organization that developed the software (organizational requirements), or from external sources. See Figure 3-1.

      Figure 3-1 Types of non-functional requirements

Software requirements Document

  • Table 3-1 shows the structure of the REQUIREMENTS document based on IEEE standards.
    • The detailed procedure for what is in the requirements document depends on the type of system to be developed and the development process used.
chapter describe
exordium Define the intended audience of the document, explain the revision history of the version, including why the new version was created, and outline the changes from one version to another
The introduction Describe why the system is needed, briefly describe what the system does, and explain how the system works with other systems. Describe the position and role of the system in the organization’s overall business goals and strategic goals
The term Define technical terms and vocabulary in documents. Assume that the document reader is someone with no expertise or experience
Definition of User requirements This section describes the services the system should provide as well as the non-functional system requirements, using natural language, diagrams, or any other markup system that the customer can understand. The standards that products and processes must follow are also defined here
System architecture This part is to give the architecture framework of the built system, and the architecture is to give the distribution of functions in each module. The components of a structure that can be reused should be visually indicated
System Requirement Description This section describes functional and non-functional requirements in detail. If necessary, non-functional requirements are further described, such as defining interfaces with other systems
The system model This section presents one or more system models that express the relationships among system components, systems, and system environments. These models can be object models, data flow models, and semantic data models
System evolution This section describes the basic assumptions and positioning on which the system is based, as well as changes to hardware and user requirements. This section is useful to system designers because it helps them avoid design decisions that might limit future changes to the system
The appendix This section provides detailed, specialized information about the application being developed. Examples of this appendix are descriptions of hardware and databases. Hardware requirements define the minimum and optimal configuration of the system, and database requirements define the logical structure of the data used by the system and the relationships between the data
The index You can include several indexes of the document. In addition to standard alphabetical indexes, there can be icon indexes, functional indexes, and so on

Requirements describe

  • That is, write down user requirements and system requirements in the requirements document.
    • User requirements: Describe the functional and non-functional requirements of the system from the perspective of users, usually in natural language and graphics.
    • System requirements:
      • Expansion of user needs;
      • The starting point for software engineers to design systems;
      • Explain how the system can provide user requirements.

  • In principle, system requirements should describe the external behavior of the system and its operational limitations, rather than how the system is designed and implemented.

    Of course, it is not impossible not to mention any design information, such as the initial architectural design of the system.

Natural language description

  • When writing requirements in natural language, try toReduce misunderstanding, there should be some simple guidelines:
    • To design aA standard formatAnd ensure that all requirements definitions used are written in this format.
    • Use consistent language to distinguish mandatory requirements from optional requirements.
      • Mandatory requirements: Those that must be supported are used when defining themMust be.
      • Optional requirements: Not necessary, used for definitionShould be.
    • Highlight text (bold, italic, color) to highlight key requirements.
    • Avoid technical terms and acronyms (note if unavoidable).
    • In any case, try to relate the principles of requirements to each user requirement.

Structured description

  • A structured approach to describing system requirements begins by defining one or more of the requirementsStandard templateAnd represent the template as a structured table. Table 3-2 is a structured description of insulin pump requirements.
The project name Insulin pump/control software /SRS/3.3.2
function Calculate insulin dose; Safe insulin levels
describe Calculate the insulin dose to be delivered when the current measured blood glucose level is in the normal range between 3 and 7 units
The input Current blood sugar reading (R2), previous two readings (R0, R1)
source Current blood sugar reading from sensor. Other readings come from memory
The output CompDose: The dose of insulin to be delivered
destination Master control loop
action If the blood sugar level is stable or falling or rising at a decreasing rate, the CompDose is 0. If the blood sugar level is increasing and the rate of increase is also increasing, the CompDose is calculated by taking the current blood sugar level and the previous blood sugar level, dividing by 4 and rounding. If the rounded result is 0, the CompDose is set to the minimum dose that can be delivered
demand Two previous readings so that the rate of change in blood sugar can be calculated
precondition Insulin pools contain at least the maximum of a single delivered dose
postconditions R0 is replaced by R1, and then R1 is replaced by R2
Side effects There is no
  • When describing functional requirements, the standard format should include the following information:
    • A description of a defined function or entity;
    • A description of the input and its source;
    • Description of output and output direction;
    • Information required for calculations and other entity information used in the system;
    • A description of the action taken;
    • If a function method is used, the setting description of preconditions and postconditions;
    • For side effects of the operation, fill in none if none.

Requirements engineering process

  • The requirements engineering process consists of four high-level activities:
    • System feasibility study: Evaluate whether the system is useful to the business.
    • Requirements derivation and analysis: requirements discovery.
    • Requirements description: Transform requirements into some kind of standard format description.
    • Requirements validation: Verify that the requirements correctly define the system the customer wants.
  • In practice, requirements engineering is an iterative process with interlaced activities, as shown in Figure 3-2.

Requirements derivation and analysis process

  • An iterative process can also be viewed as aSpiral movement.
  • Requirements discovery (Requirements export)
    • The process of collecting information about systems to be built and systems in use and extracting user and system requirements from them.
    • withInformation holderInteract through conversation and observationUse cases 和 The prototypeTo help the other person understand the system.
  • interview
    • Closed interview: the information holder answers a groupLocking problems.
    • Open interview: Requirements engineering teamAn impromptu visit“To get a deeper understanding of what the other person needs.
  • The script
    • The script is toInteraction instance fragmentIn the description.
    • The script starts with oneThe interaction frameworkDetails are added during the export process until a complete interaction description is produced.
    • Contents of the script
      • The beginning section has a description of the system and user expectations;
      • Description of the standard event flow;
      • Description of handling errors;
      • Description of system status after completion.
  • Use cases
    • Basic features of unified Modeling Language (UML).
    • The set of use cases represents all the interactions that will occur in the system requirements. The role in the process can be human, other systems, and so on.
    • UML is an established standard for object-oriented models, so use-case-based export is widely used in requirements export.
  • Deep practice: The deep practice method and prototype method for requirements analysis are shown in Figure 3-3.

Validation of requirements

  • Validation checking: Any set of requirements will inevitably be negotiated between different users.
  • Conformance checking: Requirements should not conflict with each other.
  • Completeness checks: Requirements documents should include all functionality and constraints desired by system users.
  • Authenticity checking: Checking requirements to ensure that they are actually implemented.
  • Testability checks: Check method -> verify that the system to be delivered -> meets defined requirements.
    • Requirements review: mainly error checking and inconsistencies checking.
    • Prototype: Provide an executable system model on which customers and end users can examine the system.
    • Test case generation.

Demand management

  • The requirements of large software systems are always changing, and these systems are developed to address intractable problems that cannot be fully defined. Figure 3-4 shows the process of requirement evolution.

Demand Management planning

  • Requirement identification: Every requirement hasUnique identifier.
  • Change management process: Activities to assess the impact and cost of change.
  • Traceability strategy:strategyDefines between requirements and between requirements and system designRelationship between; Relationships are to be recorded and documentedMaintenance methods.

  • Tool support

    • Demand for storage
    • Change management: As shown in Figure 3-5, the change process is supported by effective tools.

    • Traceability management: Relationships between requirements

      Figure 3-5 Requirement change management

Requirements Change Management

  • Problem analysis and change description: Problem or change -> validate -> feedback to change requester -> results in two things:
    • More detailed requirements changes and proposals;
    • Cancel this change.
  • Change analysis and costing: cost estimates for requirements document modification, system design and implementation.
  • Change implementation: Similar to writing programs, documentationtraceability 即 Correlation betweenThis is done by minimizing external references and making them as modular as possible.

Four system modeling

  • Learning goals
    • How to use graphical model to represent software system;
    • Basic modeling perspectives (context, interaction, structure, behavior, etc.);
    • Unified Modeling Language (UML);
    • Model driven engineering.
  • System modeling: The process of creating an abstract model of a system
    • Graphic modeling;
    • Formal modeling (mathematical model).Discussed in detail in Chapter 11
  • Describe the system in different waysSimilar to the "4+1" view in Chapter 6
    • externalContext model: system context; System environment;
    • interactionInteraction model: between the system and the environment; Between the components of the system;
    • structureStructural model: system architecture;
    • behavior– Behavior model: the dynamic behavior of the system and its response to events.

Context model

  • Define system boundaries: Define the system context and dependencies between the system and the environment.
  • The context model represents an environment that includes several other automated systems (ignoring the types of relationships between subsystems and the systems to be described and between them).
  • Incorporate business process models
    • Activity diagrams

Interaction model

  • Modeling user interactions -> Identify user requirements.
  • Modeling the interaction between the parts of the system -> Whether the system architecture can achieve the required functionality of the system and its reliability.

Use case modeling

  • Use case diagram
  • Sequence diagram

Structural model

  • Static model
  • The dynamic model

The class diagram

  • A class diagram represents classes in a system and the relationships between those classes.

    Links between classes indicate that there is some kind of relationship between classes.

  • A simple class diagram

  • Extend the class diagram

generalization

  • Infer some common characteristics of the members of some classes and give a general description of all the members of the class.

The aggregation

  • An object can be composed of other objects. A Patient’s record, as consisting of a Patient and an uncertain Consulation.

Rely on

Behavioral model

Data-driven modeling

Event-driven model

Model Driven Engineering (MDE)

Model-driven architecture

Executable UML: xUML