5. Scrum Framework

5.1 Scrum Roles

• Scrum development efforts consist of one or more Scrum teams
• Each made up of three Scrum roles: product owner, ScrumMaster, and the development team
  • The product owner is responsible for what will be developed and in what order
    • The single authority responsible for deciding which features and functionality to build and the order in which to build them
    • The product owner maintains and communicates to all other participants a clear vision of what the Scrum team is trying to achieve
    • The product owner is responsible for the overall success of the solution being developed or maintained.
    • To make sure that the most valuable work is always performed
    • The product owner actively collaborates with the ScrumMaster and development team
    • Must be available to answer questions soon after they are posed
  • The Scrum Master is responsible for guiding the team in creating and following its own process based on the broader Scrum framework
    • Helps everyone involved understand and embrace the Scrum values, principles, and practices
    • Acts as a coach, providing process leadership and helping the Scrum team and the rest of the organization develop their own high performance, organization-specific Scrum approach
    • The ScrumMaster helps the organization through the challenging change management process that can occur during a Scrum adoption.
    • As a facilitator, the ScrumMaster helps the team resolve issues and make improvements to its use of Scrum
    • Also responsible for protecting the team from outside interference and takes a leadership role in removing impediments that inhibit team productivity
    • The ScrumMaster has no authority to exert control over the team, so this role is not the same as the traditional role of project manager or development manager (The ScrumMaster functions as a leader, not a manager)
  • The development team is responsible for determining how to deliver what the product owner has asked for
    • Scrum defines the role of a development team, which is simply a diverse, cross-functional collection of people who are responsible for designing, building, and testing the desired product
    • The development team self-organizes to determine the best way to accomplish the goal set out by the product owner
    • The development team is typically five to nine people in size
    • Its members must collectively have all of the skills needed to produce good quality, working software
    • For development efforts that require much larger team size, team members can be organized into several teams with each team nine or fewer team members

5.2 Scrum Activities and Artifacts

Product Backlog:

• The product owner, with input from the rest of the Scrum team and stakeholders, is ultimately responsible for determining and managing the sequence of works (product backlog items) and communicating it in the form of a prioritized (or ordered) list known as the product backlog
• On new-product development the product backlog items initially are features required to meet the product owner’s vision.
• For ongoing product development, the product backlog might also contain new features, changes to existing features, defects needing repair, technical improvements, and so on.
• Product owner collaborates with internal and external stakeholders to gather and define the product backlog items
• High-value items appear at the top of the product backlog and the lower-value items appear toward the bottom.
• The product backlog is a constantly evolving artifact. Items can be added, deleted, and revised by the product owner as business conditions change, or as the Scrum team’s understanding of the product grows
• In practice, many teams use a relative size measure such as story points or ideal days to express the item size

Product Backlog Grooming: The activity of creating and refining product backlog items, estimating them, and prioritizing them is known as grooming

Sprint:

• In Scrum, work is performed in iterations or cycles of up to a calendar month called sprints
• The work completed in each sprint should create something of tangible value to the customer or user
• Sprints are timeboxed so they always have a fixed start and end date, and generally
• They should all be of the same duration
• A new sprint immediately follows the completion of the previous sprint

Sprint Planning:

• During sprint planning, the product owner and development team agree on a sprint goal that defines what the upcoming sprint is supposed to achieve
• Based on the sprint goal, the development team reviews the product backlog and determines the high priority items that the team can realistically accomplish in the upcoming sprint while working at a sustainable pace
• Many development teams break down each targeted feature into a set of tasks. The collection of these tasks, along with their associated product backlog items, forms a second backlog called the sprint backlog
• The team provides an estimate (typically in hours) of the effort required to complete each task

Sprint Execution:

• Once the Scrum team finishes sprint planning and agrees on the content of the next sprint, the development team performs all of the task-level work necessary to get the features done
• “done” means there is a high degree of confidence that all of the work necessary for producing good-quality features has been completed.
• Team members define their own task-level work and then self-organize in any manner they feel is best for achieving the sprint goal

Daily Scrum:

• Each day of the sprint, ideally at the same time, the development team members hold a timeboxed (15 minutes or less) daily scrum
• This inspect-and-adapt activity is sometimes referred to as the daily stand-up because of the common practice of everyone standing up during the meeting to help promote brevity
• ScrumMaster facilitating and each team member taking turns answering three questions:
  • What did I accomplish since the last daily scrum?
  • What do I plan to work on by the next daily scrum?
  • What are the obstacles or impediments that are preventing me from making progress?
• The purpose is for everyone to understands the big picture of what is occurring, how they are progressing toward the sprint goal, any modifications they want to make to their plans for the upcoming day’s work, and what issues need to be addressed.
• Not a problem-solving activity
• Talk about problems after the daily scrum and do so with a small group of interested member
• Not a traditional status meeting
• Communicate the status of sprint backlog items among the development team members
• It is an inspection, synchronization, and adaptive daily planning activity that helps a self-organizing team do its job better.

Sprint Review:

• At the end of the sprint there are two additional inspect-and-adapt activities, sprint review and sprint retrospective
• Sprint review is to inspect and adapt the product that is being built.
• Critical to this activity is the conversation that takes place among its participants, which include the Scrum team, stakeholders, sponsors, customers, and interested members of other teams.
• Focused on reviewing the just-completed features in the context of the overall development effort.
• Everyone in attendance gets clear visibility into what is occurring and has an opportunity to help guide the forthcoming development to ensure that the most business-appropriate solution is created.

Sprint Retrospective

• The second inspect-and-adapt activity at the end of the sprint
• Frequently occurs after the sprint review and before the next sprint planning
• Sprint retrospective is an opportunity to inspect and adapt the process
• The development team, ScrumMaster, and product owner discuss what is and is not working with Scrum and associated technical practices.
• The focus is on the continuous process improvement
• At the end of a sprint retrospective the Scrum team should have identified and committed to a practical number of process improvement actions

Definition of Done

• sprint results as a potentially shippable product increment, meaning that whatever the Scrum team agreed to do is really done according to its agreed-upon definition of done
• This definition specifies the degree of confidence that the work completed is of good quality and is potentially shippable.
• A bare-minimum definition of done should yield a complete slice of product functionality that is designed, built, integrated, tested, and documented
• “potentially shippable” does not mean that what got built must actually be shipped.
• Shipping is a business decision, which is frequently influenced by things such as:
  • Do we have enough features or enough of a customer workflow to justify a customer deployment?
  • Can our customers absorb another change given that we just gave them a release two weeks ago?

---

6. Requirements Engineering

6.1 User requirements and system requirements

High-level description and detail description
As part of a contract for a large software development project, it must define its needs in a sufficiently abstract way. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do.

• User requirements: Statements in a natural language plus diagrams to describe the services and constraint of a system.
• System requirements: More detailed descriptions of the software system’s functions, services, and operational constraints.

Requirements should state what the system should do and the design should describe how it does this.

6.2 Functional & Non-functional requirements

Software system requirements are often classified as functional requirements or nonfunctional requirements

6.2.1 Functional requirements

These are statements of services the system should provide. How the services should react and behave in certain condition. In some cases, the functional requirements may also explicitly state what the system should not do.

When expressed as user requirements, functional requirements are usually described in an abstract way that can be understood by system users. More specific functional system requirements describe the system functions, its inputs and outputs, exceptions, etc., in detail.

The functional requirements specification of a system should be both complete and consistent.

• Completeness means that all services required by the user should be defined.
• Consistency means that requirements should not have contradictory definitions.

6.2.2 Non-functional requirements

These are constraints on the services or functions offered by the system. Non-functional requirements often apply to the system as a whole, rather than individual system features or services.

Often more critical than individual functional requirements failing to meet a non-functional requirement can mean that the whole system is unusable

The implementation of non-functional requirements may be intricately dispersed throughout the system. They may affect the overall architecture of a system rather than the individual components. A single non-functional requirement may generate a number of related functional requirements.

• Product requirements: These requirements specify or constrain the bahavior of the software.
• Organizational requirements: These requirements are broad system requirements derived from policies and procedures in the customer’s and developer’s organization.
• External requirements: This broad heading cover all requirements that are derived from factors external to the system and its development process.

A common problem with non-functional requirements is that users or customers often propose these requirements as general goals

Non-functional requirements often conflict and interact with other functional or non-functional requirements. It is difficult to separate functional and non-functional requirements in the requirements document.

6.3 The Software requirements document

The software requirements document (software requirements specification or SRS) is an official statement of what the system developers should implement. It should include both the user requirements for a system and a detailed specification of the system requirement.

Requirements documents are essential when an outside contractor is developing the software system.

Agile development methods argue that requirements change so rapidly that a requirements document is out of date as soon as it is written. But it is still useful to write a short supporting document that defines the business and dependability requirements for the system

Level of Details
The level of detail that you should include in a requirements document depends on the type of system that is being developed and the development process used.

• Detailed requirements
  • Critical systems.
  • system is to be developed by a separate company.
• Less detailed requirements
  • inhouse
  • iterative development process.

6.4 Requirements egineering processes

• Feasibility study: assessing if the system is useful to the business
• Elicitation and analysis: discovering requirements
• Specification: converting these requirements into some standard form.
• Validation: checking that the requirements actually define the system that the customer wants.

6.5 Requiremets elicitation and analysis

software engineers work with customers and system end-users to find out about:

• the aplication domain
• what services the system should provide
• the required performance of the system
• hardware constrains

may involve a variety of different kinds of people in an organization include:

• end users who will interact with the system
• anyone else in an organization who will be affected by it.
• engineers who are developing or maintaining other related systems
• business managers
• domain experts
• trade union representatives.

Requirements elicitation and analysis is an iterative process with continual feedback from each activity to other activities.

• Requirements discovery: This is the process of interacting with stakeholders of the system to discover their requirements.
• Requirements classification and organization: This activity takes the unstructured collection of requirements, groups related requirements, and organizes them into coherent clusters. (Using a model of the system architecture to identify sub-systems and to associate requirements with each sub-system)
• Requirements prioritization and negotiation: When multiple stakeholders are involved, requirements will conflict. This activity is concerned with prioritizing requirements and finding and resolving requirements conflicts through negotiation.
• Requirements specification: The requirements are documented and input into the next round of the spiral.

6.5.1 Challenges

Eliciting and understanding requirements from system stakeholders is a difficult process for several reasons:

• Stakeholders often don’t know what they want from a computer system except in the most general terms; they may find it difficult to articulate the requirements; they may make unrealistic demands because they don’t know what is and isn’t feasible
• Stakeholders in a system express requirements in their own terms and with implicit knowledge of their own work.
• Different stakeholders have different requirements and priorities, and they may express these in different ways, some of these requirements have commonalities and conflict.
• Political factors may influence the requirements of a system.
• The economic and business environment in which the analysis takes place is dynamic. It changes during the analysis process.

6.5.2 Requirements Discovery

Requirements discovery (requirements elicitation) is the process of gathering information about the required system and existing systems, and distilling the user and system requirements from this information.

requirements may also come from the application domain and from other systems that interact with the system

methods:

1) Interview

1. Formal or informal interviews with system stakeholders.
2. The requirements engineering team puts questions to stakeholders about the system that they currently use and the system to be developed.
3. Requirements are derived from the answers to these questions.

• Closed interviews: Where the stakeholder answers a pre-defined set of questions.
• Open interviews: no pre-defined agenda. The requirements engineering team explores a range of issues with system stakeholders.

Interviews are good for:

• getting an overall understanding of what stakeholders do
• how they might interact with the new system
• the difficulties that they face with current systems

It can be difficult to elicit domain knowledge through interviews for two reasons:

• All application specialists use terminology and jargon that are specific to a domain. They normally use terminology in a precise and subtle way that is easy for requirements engineers to misunderstand.
• Some domain knowledge is so familiar to stakeholders that they either find it difficult to explain or they think it is so fundamental that it isn’t worth mentioning

Drawbacks: Not an effective technique for eliciting knowledge about organizational requirements and constraints because there are subtle power relationships between the different people in the organization. most people are generally reluctant to discuss political and organizational issues that may affect the requirements

Effective interviewers have two characteristics:
They are open-minded, avoid pre-conceived ideas about the requirements, and are willing to listen to stakeholders. They prompt the interviewee to get discussions going using a springboard
question, a requirements proposal, or by working together on a rototype system.

2) Scenarios
System user can understand and criticize a scenario of how they might interact with a software system. Use the information gained from the discussion based on a scenario to formulate the actual system requirements. A scenario is the descriptions of example interaction sessions. Each scenario usually covers one or a small number of possible interactions. A scenario starts with an outline of the interaction. During the elicitation process, details are added to this to create a complete description of that interaction.

Scenario-based elicitation involves working with stakeholders to identify scenarios and to capture details to be included in these scenarios. Scenarios may be written as text, supplemented by diagrams, screen shots, etc. Alternatively, a more structured approach such as event scenarios or use cases may be used.

use cases
Use cases are a requirements discovery technique. In their simplest form, a use case identifies the actors involved in an interaction and names the type of interaction. It is supplemented by additional information describing the interaction with the system. (Textual description and one or more graphical models)

Use cases are documented using a high-level use case diagram. The set of use cases represents all of the possible interactions that will be described in the system requirements.

Drawbacks: Use case focus on interactions with the system, they are not as effective for eliciting:

• constrains
• high-level business
• non-functional requirements
• domain requirements

3) Ethnography
Systems are used in a social and organizational context and software system requirements may be derived or constrained by that context. Satisfying these social and organizational requirements is often critical for the success of the system. Ethnography is an observational technique that can be used to understand operational processes and help derive support requirements for these processes. An analyst immerses himself or herself in the working environment to observe the actual tasks in which participants are involved.

Advantages: Ethnography is particularly effective for discovering two types of requirements:

• Requirements that are derived from the way in which people actually work, rather than the way in which process definitions say they ought to work.
• Requirements that are derived from cooperation and awareness of other people’s activities.

Drawbacks: Ethnography focuses on the end-user, this approach:

• is not always appropriate for discovering organizational or domain requirements.
• cannot always identify new features that should be added to a system

6.5.3 Requirements Specification

The process of writing down the user and system requirements in a requirements document. The user and system requirements should be clear, unambiguous, easy to understand, complete, and consistent. Stakeholders interpret the requirements in different ways and there are often inherent conflicts and inconsistencies in the requirements. The user requirements for a system should describe the functional and non-functional requirements in a way they are understandable by system users who don’t have detailed technical knowledge

• Specify only the external behavior of the system.
• Should not include details of the system architecture or design
• Write user requirements in natural language, with simple tables, forms, and intuitive diagrams.
• System requirements are expanded versions of the user requirements
• They add detail and explain how the user requirements should be provided by the system
• They may be used as part of the contract for the implementation of the system

it is practically impossible to exclude all design information. There are several reasons for this:

• You may have to design an initial architecture of the system to help structure the requirements specification. The system requirements are organized according to the different sub-systems that make up the system.
• Systems may interoperate with existing systems, which constrain the design and impose requirements on the new system.
• The use of a specific architecture to satisfy non-functional requirements may be necessary.

To minimize misunderstandings when writing natural language requirements:

• Invent a standard format and ensure that all requirement definitions adhere to that format. Standardizing the format makes omissions less likely and requirements easier to check
• Use language consistently to distinguish between mandatory and desirable requirements
• Use text highlighting to pick out key parts of the requirement.
• Do not assume that readers understand technical software engineering language.
• Associate a rationale with each user requirement. The rationale should explain why the requirement has been included

user requirements can be written on cards, one requirement per card. A number of fields on each card (requirements rationale, dependencies on other requirements, the source of the requirements, supporting materials)

6.5.4 Requirements validation

Requirements validation is the process of checking that requirements actually define the system that the customer really wants. It is important because errors in a requirements document can lead to extensive rework costs when these problems are discovered during development or after the system is in service.

During the requirements validation process, different types of checks should be carried out on the requirements in the requirements document. These checks include:

• Validity checks: The functions proposed by stakeholders should be aligned with what the system needs to perform. You may find later that there are additional or different functions are required instead.
• Consistency checks: Requirements in the document should not conflict. That is, there should not be contradictory constraints or different descriptions of the same system function.
• Completeness checks: The requirements document should include requirements that define all functions and the constraints intended by the system user.
• Realism checks: Using knowledge of existing technology, the requirements should be checked to ensure that they can actually be implemented.
• Verifiability: To reduce the potential for dispute between customer and contractor, system requirements should always be written so that they are verifiable.

methods:

1. Requirements reviews: The requirements are analyzed systematically by a team of reviewers who check for errors and inconsistencies
2. Prototyping: In this approach to validation, an executable model of the system in question is demonstrated to end-users and customers
3. Test-case generation: Requirements should be testable. If the tests for the requirements are devised as part of the validation process, this often reveals requirements problems

---

7. System Modeling

System modeling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system.

System modeling has now come to mean representing a system using some kind of graphical notation, which is now almost always based on notations in the Unified Modeling Language (UML).

System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers.

Existing and planned system models
Models of the existing system are used during requirements engineering. They help clarify what the existing system does and can be used as a basis for discussing its strengths and weaknesses. These then lead to requirements for the new system.

Models of the new system are used during requirements engineering to help explain the proposed requirements to other system stakeholders. Engineers use these models to discuss design proposals and to document the system for implementation.

In a model-driven engineering process, it is possible to generate a complete or partial system implementation from the system model.

System perspectives

• An external perspective, where you model the context or environment of the system.
• An interaction perspective, where you model the interactions between a system and its environment, or between the components of a system.
• A structural perspective, where you model the organization of a system or the structure of the data that is processed by the system.
• A behavioral perspective, where you model the dynamic behavior of the system and how it responds to events.

UML diagram types

• Activity diagrams, which show the activities involved in a process or in data processing.
• Use case diagrams, which show the interactions between a system and its environment.
• Sequence diagrams, which show interactions between actors and the system and between system components.
• Class diagrams, which show the object classes in the system and the associations between these classes.
• State machine diagrams, which show how the system reacts to internal and external events.

Use of graphical models

• As a means of facilitating discussion about an existing or proposed system
  • Incomplete and incorrect models are OK as their role is to support discussion.
• As a way of documenting an existing system
  • Models should be an accurate representation of the system but need not be complete.
• As a detailed system description that can be used to generate a system implementation
  • Models have to be both correct and complete.

7.1 Context models

• Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries.
• Social and organisational concerns may affect the decision on where to position system boundaries.
• Architectural models show the system and its relationship with other systems.
• System boundaries are established to define what is inside and what is outside the system.
  • They show other systems that are used or depend on the system being developed.
• The position of the system boundary has a profound effect on the system requirements.
• Defining a system boundary is a political judgment
  • There may be pressures to develop system boundaries that increase / decrease the influence or workload of different parts of an organization.
• Context models simply show the other systems in the environment, not how the system being developed is used in that environment.
• Used along with other models, such as business process models.
• UML activity diagrams may be used to define business process models.

7.2 Interaction models

• Modeling user interaction is important as it helps to identify user requirements.
• Modeling system-to-system interaction highlights the communication problems that may arise.
• Modeling component interaction helps us understand if a proposed system structure is likely to deliver the required system performance and dependability.
• Use case diagrams and sequence diagrams may be used for interaction modeling.

Use case diagram

• Use case diagrams and sequence diagrams may be used for interaction modeling.
• Each use case represents a discrete task that involves external interaction with a system.
• Actors in a use case may be people or other systems.
• Represented diagramatically to provide an overview of the use case and in a more detailed textual form.

Sequence diagrams

• Sequence diagrams are part of the UML and are used to model the interactions between the actors and the objects within a system.
• A sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance.
• The objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these.
• Interactions between objects are indicated by annotated arrows.

7.3 Structural models

• Structural models of software display the organization of a system in terms of the components that make up that system and their relationships.
• Structural models may be static models, which show the structure of the system design, or dynamic models, which show the organization of the system when it is executing.
• You create structural models of a system when you are discussing and designing the system architecture.

Class diagrams

• Class diagrams are used when developing an objectoriented system model to show the classes in a system and the associations between these classes.
• An object class can be thought of as a general definition of one kind of system object.
• An association is a link between classes that indicates that there is some relationship between these classes.
• When you are developing models during the early stages of the software engineering process, objects represent something in the real world, such as a patient, a prescription, doctor, etc.

7.4 Behavioral models

Behavioral models are models of the dynamic behavior of a system as it is executing. They show what happens or what is supposed to happen when a system responds to a stimulus from its environment.

You can think of these stimuli as being of two types:

• Data: Some data arrives that has to be processed by the system.
• Events: Some event happens that triggers system processing. Events may have associated data, although this is not always the case.

Data-driven modeling

• Many business systems are data-processing systems that are primarily driven by data. They are controlled by the data input to the system, with relatively little external event processing.
• Data-driven models show the sequence of actions involved in processing input data and generating an associated output.
• They are particularly useful during the analysis of requirements as they can be used to show end-to-end processing in a system.
• Activity diagram and sequence diagram are used in data-driven modeling

Event-driven modeling

• Real-time systems are often event-driven, with minimal data processing. For example, a landline phone switching system responds to events such as ‘receiver off hook’ by generating a dial tone.
• Event-driven modeling shows how a system responds to external and internal events.
• It is based on the assumption that a system has a finite number of states and that events (stimuli) may cause a transition from one state to another.

State machine diagram

• These model the behaviour of the system in response to external and internal events.
• They show the system’s responses to stimuli so are often used for modelling real-time systems.
• State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another.
• Statecharts are an integral part of the UML and are used to represent state machine models.

7.5 Model-driven engineering

Model-driven engineering (MDE) is an approach to software development where models rather than programs are the principal outputs of the development process.

The programs that execute on a hardware/software platform are then generated automatically from the models.

Proponents of MDE argue that this raises the level of abstraction in software engineering so that engineers no longer have to be concerned with programming language details or the specifics of execution platforms.

Model-driven engineering is still at an early stage of development, and it is unclear whether or not it will have a significant effect on software engineering practice.

Pros:

• Allows systems to be considered at higher levels of abstraction
• Generating code automatically means that it is cheaper to adapt systems to new platforms.

Cons:

• Models for abstraction and not necessarily right for implementation.
• Savings from generating code may be outweighed by the costs of developing translators for new platforms.

7.5.1 Model driven architecture

Model-driven architecture (MDA) was the precursor of more general model-driven engineering.

MDA is a model-focused approach to software design and implementation that uses a subset of UML models to describe a system.

Models at different levels of abstraction are created. From a high-level, platform independent model, it is possible, in principle, to generate a working program without manual intervention.

Types of model

• A computation independent model (CIM): These model the important domain abstractions used in a system. CIMs are sometimes called domain models.
• A platform independent model (PIM): These model the operation of the system without reference to its implementation. The PIM is usually described using UML models that show the static system structure and how it responds to external and internal events.
• Platform specific models (PSM): These are transformations of the platform-independent model with a separate PSM for each application platform. In principle, there may be layers of PSM, with each layer adding some platform-specific detail.

Agile methods and MDA

• The developers of MDA claim that it is intended to support an iterative approach to development and so can be used within agile methods.
• The notion of extensive up-front modeling contradicts the fundamental ideas in the agile manifesto and I suspect that few agile developers feel comfortable with model driven engineering
• If transformations can be completely automated and a complete program generated from a PIM, then, in principle, MDA could be used in an agile development process as no separate coding would be required.

Executable UML
The fundamental notion behind model-driven engineering is that completely automated transformation of models to code should be possible.

To create an executable subset of UML, the number of model types has therefore been dramatically reduced to these 3 key types:

• Domain models that identify the principal concerns in a system. They are defined using UML class diagrams and include objects, attributes and associations.
• Class models in which classes are defined, along with their attributes and operations.
• State models in which a state diagram is associated with each class and is used to describe the life cycle of the class

The dynamic behavior of the system may be specified declaratively using the object constraint language (OCL), or may be expressed using UML’s action language.

Key points

• A model is an abstract view of a system that ignores systemdetails. Complementary system models can be developed to show the system’s context, interactions, structure and behavior
• Context models show how a system that is being modeled is positioned in an environment with other systems and processes.
• Use case diagrams and sequence diagrams are used to describe the interactions between users and systems in the system being designed. Use cases describe interactions between a system and external actors; sequence diagrams add more information to these by showing interactions between system objects.
• Structural models show the organization and architecture of a system. Class diagrams are used to define the static structure of classes in a system and their associations.
• Behavioral models are used to describe the dynamic behavior of an executing system. This behavior can be modeled from the perspective of the data processed by the system, or by the events that stimulate responses from a system.
• Activity diagrams may be used to model the processing of data, where each activity represents one process step.
• State diagrams are used to model a system’s behavior in response to internal or external events.
• State diagrams are used to model a system’s behavior in response to internal or external events.

7.6 Use Case Diagram

• A picture
• describes how actors relate to use cases
• use cases relate to one another
• Diagrams are not essential. They are helpful in giving an overview, but only secondary in importance to the textual description
• They do not capture the full information of the actual use cases
• In contrast, text is essential

Use Case Diagram Objective
Built in early stages of development.

• Specify the context of a system
• Capture the requirements of a system
• Validate a systems architecture
• Drive implementation and generate test cases
• Developed by analysts and domain experts

7.6.1 Actor

Include all user roles that interact with the system. Include system components only if they responsible for initiating / triggering a use case.

• primary: a user whose goals are fulfilled by the system
  • importance: define user goals
• supporting: provides a service to the system
  • importance: clarify external interfaces and protocols
• offstage: has an interest in the behavior but is not primary or supporting, e.g., government
  • importance: ensure all interests (even subtle) are identified and satisfied

Finding Actors
External objects that produce/consume data:

• Must serve as sources and destinations for data
• Must be external to the system

7.6.2 Use Case

• System function (process: automated or manual)
• Named by verb.
• Each Actor must be linked to a use case, while some use cases may not be linked to actors.
  

Linking Use Cases

• Include
• Extend
• Association
• Generalization: One element (child) is based on another element (parent)
  

7.7 Sequence Diagram

• Describe the flow of messages, events, actions between objects
• Show concurrent processes and activations
• Show time sequences that are not easily depicted in other diagrams
• Typically used during analysis and design to document and understand the logical flow of your system

Emphasis on time ordering.

• participant: object or entity that acts in the diagram – diagram starts with an unattached “found message” arrow
• message: communication between participant objects
• axes:
  • horizontal: which object/participant is acting
  • vertical: time (down -> forward in time)

Representing Objects
Squares with object type, optionally preceded by “name :”

• write object’s name if it clarifies the diagram
• object’s “life line” represented by dashed vert. line
• Name syntax: <objectname>:<classname>

Messages Between Objects
messages (method calls) indicated by arrow to other object

• write message name and arguments above arrow
• dashed arrow back indicates return
• different arrowheads for normal / concurrent (asynchronous) calls

Indicating method calls
activation: thick box over object’s life line; drawn when object’s method is on the stack

• either that object is running its code, or it is on the stack waiting for another object’s method to finish
• nest activations to indicate recursion

Selection and loops
box around part of diagram to indicate if or loop

Why not just code it?

• a good sequence diagram is still a bit above the level of the real code (not all code is drawn on diagram)
• sequence diagrams are language-agnostic (can be implemented in many different languages
• non-coders can do sequence diagrams
• easier to do sequence diagrams as a team
• can see many objects/classes at a time on same page (visual bandwidth)

7.8 Class Model / Domain Model

Illustrates meaningful conceptual classes in problem domain. Represents real-world concepts, not software components

Why domain model?

• Gives a conceptual framework of the things in the problem space
• Helps you think – focus on semantics
• It is a static view - meaning it allows us convey time invariant business rules
• Foundation for modelling
• Based on the defined structure, we can describe the state of the problem domain at any time.

Features

• Domain classes: each domain class denotes a type of object.
• Attributes: an attribute is the description of a specified type in a domain class; each instance of the class separately holds a value.
• Associations: an association is a relationship between two (or more) domain classes that describes links between their object instances. Associations can have roles, describing the multiplicity and participation of a class in the relationship.

Steps to Create a Domain Model

1. Identify candidate conceptual classes
   • Identify, classify, and define objects, ideas, and events as Classes by examining the usage scenarios developed in the use case model, glossary, and other diagrams.
     • Reuse an existing domain model
     • Use a conceptual class category list
     • Identify noun phrases
       • Classes are determined by underlining each noun or noun phrase and entering it into a simple table.
       • Synonyms should be noted. Beware of ambiguity.
       • If the class (noun) is required to implement a solution, then it is part of the solution space; otherwise, if a class is necessary only to describe a solution, it is part of the problem space
   • Use six selection characteristics to select classes for the analysis model
     • Retained information: if information about the class must be remembered so that the system can function
     • Needed services: the potential class must have a set of identifiable operation that is needed by the system to operate
     • Multiple attributes: a class with a single attribute may, in fact, be useful during design, but is probably better represented as an attribute of another class during the analysis activity
     • Common attributes: A set of attributes can be defined for the potential class and these attributes apply to all instances of the class.
     • Common operations: A set of operations can be defined for the potential class and these operations apply to all instances of the class.
     • Essential requirements: External entities that appear in the problem space and produce or consume information essential to the operation of the system
2. Draw them in a UML as a Class Diagram
3. Add associations necessary to record the relationships that must be retained. Association is the relationship between 2 separate classes.
   • Association can be further defined to indicate multiplicity.
   • Multiplicity indicate the number of instances exist in an association
   • Use verbs as the Association Name
   • Use arrow to aid the reading of the Association Name
   • Composition and Aggregation are the two forms of association (object made up of another object).
4. Add attributes necessary for information to be preserved
   • Attributes describe an object
   • Study use case to select the attribute belonging to a particular class
   • Some of the attributes are the compounded attribute that you may or may not want to break it down to elementary attributes, and vice versa.
   • In the modeling for requirement analysis, data type and access scope of the attributes are not required
   • Operations define the behavior of an object.
   • 4 broad categories. Operations that
     • manipulate data
     • perform computation
     • inquire about the state of an object
     • Monitor an object for the occurrence of event
   • Operations act on class attributes and/or associations
   • examining the usage scenarios developed in the use case model. Verbs used in the scenario is the potential operations for classes.
   • Decisions on which operations should each classes be responsible is the concern in the design phrase
   • Design concept involving modularity and coupling

7.9 Activity Diagram

An activity represents an operation, a step in a business process, or an entire business process. Action is a named element which represents a single atomic step within activity i.e. that is not further decomposed within the activity. Arrow represents the transition from one activity to the next. Filled circle represent start, bull’s eye represent an endpoint

Decision
Label the condition with a squared bracket

Concurrent Paths
When two or more concurrent paths running at the same time. Use solid bold line to split the transition arrow into multiple concurrently executing paths. Solid bold line also used to merge the concurrent paths

Sending and Receiving Signal
There will be situation when your process need to send or receive signal. Convex polygon – sending signal / output event. Concave polygon – receiving signal / input event

Swimlanes
Use swimlanes to show who responsible for each activity in a process. Separate the diagram into parallel segments called swimlanes. Each swimlane shows the name of a role at the top. Transitions can take place from one swimlane to another

Flow Final Node
Not Activity Final Node. UML 2.0 has an additional control node type called Flow Final that is used as an alternative to the Activity Final node to terminate a flow. It is needed because in UML 2.0, when control reaches any instance of Activity Final node, the entire activity (including all flows) is terminated. The Flow Final simply terminates the flow to which it is attached.

Time Event

7.10 Behavior-based Model

dynamic behavior of the system. function of specific events and time; indicates how software will respond to external events or stimuli

Creating a Behavioral Model

1. evaluate all use cases to fully understand the sequence of interaction within the system
2. identify events that drive the interaction sequence and understand how these events relate to specific objects
   • Scenarios in use case description represent sequence of activities that involves actors and the system
   • The actor and the system exchange information in the sequence of activities
   • The exchange of information is an event.
   • Some event have an explicit impact on the flow of control.
3. build a state diagram for the system
   • A passive state is simply the current status of all of an object’s attributes
   • The active state of an object indicates the current status of the object as it undergoes a continuing transformation or processing.
   • An event (sometimes called a trigger ) must occur to force an object to make a transition from one active state to another.
   • Objects in the system change their state in response to events
   • UML state machine diagram documents these kinds of changes.
4. review the behavioral model to verify accuracy and consistency.

Action and activity

• entry/action: discrete action, perform only once at the entrance to the state
• do/activity: continuous activity throughout the state live span
• exit/action: discrete action, perform only once at the exit of the state

---

8. Design Concepts

8.1 Design in the SE context

Software Design emcompasses the set of

• principles
• concepts
• practices

The goal of design is to produce a model or representation that exhibits

• Firmness (no bugs)
• Commodity (useful or valuable)
• Delight (pleasuarble experience)

Software design is:

• The last software engineering action within the modelling activity and sets the stage for construction (code generation and testing)
• A process to transform user requirements into some suitable form, which helps the programmer in software coding and implementation
• The requirements describe the function of a system as seen by the client.
• For a given set of requirements (analysis), the software development team must design a system that will meet those requirements.
• In practice requirements and design are interrelated. In particular, working on the design often clarifies the requirements.

• Component-level design: transforms structural elements of the software architecture into a procedural description of software components.
• Interface design: describes how the software communicates with systems that interoperate with it, and with humans who use it.
• Architectural design: defines the relationship between major structural elements of the software, the architectural styles and patterns that can be used to achieve the requirements defined for the system, and the constraints that affect the way in which architecture can be implemented.
• Data design/class design: transforms class models into design class realizations and the requisite data structure required to implement it.

8.2 Quality control in the design process

• The importance of software design can be stated with a single word – quality
• Design provides you with representations of software that can be assessed for quality.
• Three goals a design in good quality
  • The design should implement all of the explicit requirements contained in the requirements model, and it must accommodate all of the implicit requirements desired by stakeholders.
  • The design should be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.
  • The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.
• Eight technical criteria for evaluation:
  • A design should exhibit an architecture that
    • has been created using recognizable architectural styles or patterns
    • is composed of components that exhibit good design characteristics
    • can be implemented in an evolutionary fashion, thereby facilitating implementation and testing
  • A design should be modular; that is, the software should be logically partitioned into elements or subsystems.
  • A design should contain distinct representations of data, architecture, interfaces, and components.
  • A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns
  • A design should lead to components that exhibit independent functional characteristics.
  • A design should lead to interfaces that reduce the complexity of connections between components and with the.
  • A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.
  • A design should be represented using a notation that effectively communicates its meaning.
• Five quality attributes (FURPS):
  • Functionality is assessed by evaluating the feature set and capabilities of the program, the generality of the functions that are delivered, and the security of the overall system.
  • Usability is assessed by considering human factors, overall aesthetics, consistency, and documentation.
  • Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of output results, the mean-time-to-failure (MTTF), the ability to recover from failure, and the predictability of the program.
  • Performance is measured using processing speed, response time, resource consumption, throughput, and effi ciency.
  • Supportability combines extensibility, adaptability, and serviceability. These three attributes represent a more common term, maintainability— and in addition, testability, compatibility, configurability, the ease with which a system can be installed, and the ease with which problems can be localized.

8.3 The idea/principles behind software design

• provide the software designer with a foundation form which more sophisticated design methods can be applied
• defines criteria that can be used to partition software into individual component
• establish uniform criteria that define the technical quality of software design

Some general design concepts:

8.3.1 Abstraction

• Abstraction simply means to hide the details to reduce complexity and increases efficiency or quality.
• The higher the level, the less the detail.
• At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment.
• At lower levels of abstraction, a more detailed description of the solution is provided
• As different levels of abstraction are developed, you work to create both procedural and data abstractions
• A procedural abstraction refers to a sequence of instructions that have a specific and limited function. The name of a procedural abstraction implies these functions, but specific details are suppressed.
• A data abstraction is a named collection of data that describes a data object.

8.3.2 Modularity

• Modular design helps us to better organize complex system.
• It basically clusters similar or relative functions together, sets up boundaries and provides interfaces for communication
  • mobile phone as an complex system that is modularized
  • modularity increases manufacture efficiency and save time
• Modularity allows the possibility of the development of system parts to be carried out independently of each other, therefore reducing development time
• Software is divided into separately named and addressable components or modules that are integrated to satisfy requirements.
• In almost all instances, you should break the design into many modules to make understanding easier.
• However, too many modules in a system increase the complexity of modules integration
• Given the same set of requirements, more modules means smaller individual size. However, as the number of modules grows, the effort (cost) associated with integrating the modules also grows. These characteristics lead to a total cost or effort curve shown in the figure.
  
• For modularity, each module needs to support a well-defined
  abstraction and have a clear interface through which it can interact with other modules
• Coupling and cohesion are two modularization criteria, which are often used together

8.3.3 Functional Independence

• Functional independence is achieved by developing modules with “single-minded” function and an “aversion” to excessive interaction with other modules.
• Software with effective modularity, that is, independent modules, is easier to develop, maintain and test
• Independence is assessed using two qualitative criteria: coupling and cohension.

8.3.4 Coupling

• Coupling refers to how focused a class or a module is
• Two modules are considered independent if one can function completely without the other
• If two modules are independent, they are solvable and modifiable separately.
• However, all the modules in a system must interact so that together they produce the desired behavior of the system.
• The more connections between modules, the more dependent they are
• Highly coupled “modules are joined by strong interconnections, while loosely coupled” modules have weak interconnections.
• Coupling increases with the complexity and obscurity of the interface between module
• To solve and modify a module separately, we would like the modules to be loosely couple
• To keep coupling low we would like to minimize the number of interfaces per module and the complexity of each interface.

8.3.5 Cohesion

• Another way to lower the coupling between modules is to strengthen the bond between elements of the same module by maximizing the relationship between elements of the same module
• Cohesion is the degree of how closely the elements of a module are related to each other
• Cohesion refers to how focused a class or a module is.
• Cohesion of a module gives the designer an idea about whether the different elements of a module belong together in the same module.
• Method cohesion
  • a method that implements a clearly defined function, and all statements in the method contribute to implementing this function.
  • it focuses on the methods you write inside the class. A method should clearly state the intention of why it is written
• Class cohesion
  • A high class cohesion is the class that implements a single concept or abstraction with all elements contributing toward supporting this concept
  • Highly cohesive classes are usually more easily understood and more stable
  • Whenever there are multiple concepts encapsulated within a class, the cohesion of the class is not as high as it could be, and a designer should try to change the design to have each class encapsulate a single concept

8.3.6 Object-oriented design

• An object-oriented system is made up of interacting objects that maintain their own local state and provide operations on that state
• Object-oriented design processes involve designing object classes and the relationships between these classes
• When the design is realized as an executing program, the objects are created dynamically from these class definitions
• To develop an object-oriented design from concept to detailed, here are several things that you need to do
  • Understand and define the context and the external interactions with the system.
  • Design the system architecture.
  • Identify the principal objects in the system
  • Develop design models
  • Specify interfaces

8.3.7 Design classes

• As the design model evolves, you will define a set of design classes that refine the analysis classes by providing design detail that will enable the classes to be implemented, and implement a software infrastructure that supports the business solution.
• Five different types of design classes, each representing a different layer of the design architecture, can be developed
  • User interface classes define all abstractions that are necessary for human-computer interaction (HCI) and often implement the HCI in the context of a metaphor
  • Business domain classes identify the attributes and services (methods) that are required to implement some element of the business domain that was defi ned by one or more analysis classes
  • Process classes implement lower-level business bstrac_x0002_tions required to fully manage the business domain classes.
  • Persistent classes represent data stores (e.g., a database) that will persist beyond the execution of the software.
  • System classes implement software management and control functions that enable the system to operate and communicate within its computing environment and with the outside world.
• “Well-formed” design classes should:
  • Complete and sufficient. A design class should be the complete
    encapsulation of all attributes and methods that can reasonably be expected (based on a knowledgeable interpretation of the class name) to exist for the class. Suffi ciency ensures that the design class contains only those methods that are suffi cient to achieve the intent of the class, no more and no less.
  • Primitiveness. Methods associated with a design class should be focused on accomplishing one service for the class.
  • High cohesion. A cohesive design class has a small, focused set of
    responsibilities and single-mindedly applies attributes and methods to
    implement those responsibilities.
  • Low coupling. Within the design model, it is necessary for design classes to collaborate with one another.

8.4 Elements in design model

• Data design elements
• Architectural Design Element
• Interface Design Element
• Component-Level Design Element
• Deployment-Level Design Element

• Like other software engineering activities, data design (sometimes referred to as data architecting) creates a model of data and/or information that is represented at a high level of abstraction (the customer/user’s view of data).
• It is then refined into progressively more implementation-specific representations that can be processed by the computer-based system
• Program-component level: essential to the creation of high- quality applications
• Application level: pivotal to achieving the business objectives of a system
• Business level: enables data mining or knowledge discovery that can have an impact on the success of the business itself
• The architectural design for software is the equivalent to the floor plan of a house. The floor plan depicts the overall layout of the rooms; their size, shape, and relationship to one another; and the doors and windows that allow movement into and out of the rooms. The floor plan gives us an overall view of the house. Architectural design elements give us an overall view of the software.
• Three sources:
  • information about the application domain for the software to be built;
  • specific requirements model elements such as use cases or analysis classes, their relationships and collaborations for the problem at hand;
  • the availability of architectural styles and patterns
• The interface design for software is analogous to a set of detailed drawings (and specifi cations) for the doors, windows, and external utilities of a house
• The interface design elements for software depict information flows into and out of a system and how it is communicated among the components defi ned as part of the architecture
• Three important elements:
  • the user interface (UI),
  • external interfaces to other systems, devices, networks, or other producers or consumers of information
  • internal interfaces between various design components

• Deployment-level design elements indicate how software
  functionality and sub-systems will be allocated within the physical computing environment that will support the softwar