GitHub has features that may help you as you work in teams:

• Project boards for noting and assigning tasks.
• Wikis for documenting your work or planning how to split tasks between team members.
• Issues for tracking tasks and bugs.

You are not required to use any of these features, but the features are available in each of your assigned repos if you would like to use them.

The software life cycle (SLC) covers the time between product conception and end of life for the product.¹ Like all engineering disciplines, engineering high quality software requires process to guide a software process through the SLC. Software engineering is “the systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software”.¹ Software engineers use a software development process to translate user needs into a software product that correctly and securely meets those needs.¹ The process of engineering software involves several phases, which may overlap: requirements, design, implementation, test, and deployment. Software development processes are supported by practices, which are activities, maybe supported by techniques and tooling, that provide a systematic way for developers to develop software as part of a larger software development process.¹

A software process model or life cycle model provides a “simplified, abstracted description of a software development process”.^{1 2} There are two high-level software development models that provide a paradigm and culture of software development: plan-driven and agile. From a software model, a specific software development process (which may also be called a software development methodology) is created that adheres to the spirit of the model and describes the specific practices that support development for each phase. The idea of a software development model is an interface that provides behaviors associated with each major phase. Plan-driven and agile models are the abstract classes that implement the interface and provide the “spirit” of the model. The concrete software development processes are subclasses of the models and provide an interpretation of the processes involved at each phase of development and the associated practices and tools to support development when using the process. Different companies and even different groups within the same company will adopt and/or customize a process that fits the team culture and the type of product that is under development.

Plan-driven models are typically used for projects where there are stable requirements that are known up front, like mission- or safety-critical systems. The phases of development are handled sequentially, but there may be interweaving of some phases like implementation and testing when practices like test-driven development are used. An example plan-driven development model is Team Software Process.

Agile models focus on change as a part of software development. Software is developed in short iterations, with each iteration including the standard phases of development. Agile models value interactions, collaboration, and change over strict processes, contracts, and plans. Products are typically always in a deployable state (e.g., the practice of continuous integration). An example agile development model is Scrum.

Software Development Phases

While there are many different software development processes that developers may use, there are five fundamental areas of concern, or phases, in any process: requirements, design, implementation, test, and deployment. These phases may be distinct or may be integrated depending on the specific software development process used.¹

Requirements Phase

The requirements phase is “the period of time in the software life cycle during which the requirements for a software product are defined and documented”.¹ Requirements define, from the customer perspective, what a software system should do or a capability that a system must have.¹ Requirements are NOT a list of tasks that a developer should accomplish to create a system, but instead describe the system itself. Requirements include a description of the functionality (required behavior) and non-functional aspects of the system (how the software will do the functionality and how the system is constrained).¹

Design Phase

The design phase is “the period in the software life cycle during which definitions for architecture, software components, interfaces, and data are created, documented, and verified to satisfy requirements”.¹

Implementation Phase

The implementation phase is the “period of time in the software life cycle during which a software product is created from design documentation and debugged”.¹

Test Phase

The test phase is “the period of time in the software life cycle during which the components of a software product are evaluated and integrated, and the software product is evaluated to determine whether or not requirements have been satisfied”.¹ While there are several different types of tests, the focus will be on unit tests and system tests. Unit tests focus on evaluation of individual methods or modules and are typically written by the developer.¹ System tests evaluate a completed system to ensure that the requirements are met.¹

Deployment Phase

The deployment phase is the “phase of a project in which a system is put into operation and cutover issues are resolved”.¹ When software is completed, it must be deployed or delivered to the customer. Additionally, software must be maintained such that user problems are addresses after operationalization.

References

Requirements define what a software system should do. Software developers work with various stakeholders for a software system to fully understand the needs of all interested party. Those needs are defined into software requirements - statements of functionality for a software system.

Goal: Understand customer requirements for the software system

Software Artifacts: requirements documents, use cases, user stories

Types of Requirements

There are three types of requirements:

• Functional: Functional requirements define what the system should do or the functionality of the system. There are many ways to write functional requirements. We describe functional requirements in use cases.
• Non-functional: Non-functional requirements describe characteristics that the system should have that are not related to direct functionality. Non-functionality requirements typically fall in the areas of performance, usability, security, and reliability. For example, a page on a website shall load in less than a second would be a non-functional requirement.
• Constraints: Constraints describe limitations on the development of the system. For example, constraints define the operating system or programming language that the system must be developed for/with.

Format of Requirements

Formats are from Hull, Jackson and Dick.¹

Functional Requirements

• The [stakeholder type] shall be able to [capability/function].
• The system shall allow the [stakeholder type] to [capability/function].
• The system shall [capability/function].

Nonfunctional Requirements

• Performance/capability: The [system] shall be able to [function] [object] not less than [performance] times per [units].
• Performance/capability: The [system] shall be able to [function] [object] of type [qualification] within [performance] [units]
• Performance/capacity: The [system] shall be able to [function] not less than [quantity] [object].
• Performance/timeliness: The [system] shall be able to [function] [object] within [performance] [units] from [event].
• Performance/periodicity: The [system] shall be able to [function] not less than [quantity] [object] within [performance] [units]
• Interoperability/capacity: The [system] shall be able to [function] [object] composed of not less than [performance] [units] with [external entity].
• Sustainability/periodicity: The [system] shall be able to [function] [object] for [performance] [units] every [performance] [units].
• Environmental/operability: The [system] shall be able to [function] [object] while [operational condition].

Use Cases

Use cases are a user centric way of defining functional requirements. A use case combines together related scenarios about using a software system from the user’s perspective. A use case may be specific to a particular user or general for all users.

A use case is broken into four sections: preconditions, main flow, sub flows, and alternative flows. The only required section is the main flow.

A use case may be referred to by another use case using brackets (e.g, [ and ]). Each use case should be referred to by another use case to connect all parts of the system together.

Sub flows and alternative flows are also referenced using brackets. Each sub flow and alternative flow should be referred to at least once from another element of the use case. If a sub flow or alternative flow is part of the use case, then only the [S#] or [E#] is needed. If a sub flow or alternative flow from another use case is referred to, then the use case is used in the reference (i.e., [UC-S#]).

Preconditions

The preconditions describe how to reach a given use case.

Main Flow

The main flow describes the high level set of scenarios for a use case. Details are described in sub flows and alternative or error paths are described in the alternative flows.

Sub Flows

Sub flows provide details to portions of the main flow. The sub flow describes the functionality and provides references for what should happen if there’s an error. Those are defined in the alternative flows.

Alternative Flows

Alternative flows provide details about error conditions, or how the program should fail gracefully if the user provides invalid or incorrect information.

User Stories

• Describe software functionality that will be important for the users
• Allow software engineers to gain an understanding of what the software may include
• A written description of the story used for planning and as a reminder
• Conversations about the story that serve to flesh out the details of the story
• Tests that convey and document details and that can be used to determine when a story is complete

References

System testing ignores the internals of the program and instead focuses on the inputs and the expected results of the program as defined by the requirements. The tester treats the program as a “black box”; the program implementation that generates the program output is unknown. The tester identifies the expected program output from the requirements and can compare the actual output with the expected output.

• Slides TODO: Add links to resources (in _data/comprehensive-exercise.yml)
• Other Resources TODO: Add links to resources (in _data/comprehensive-exercise.yml)

After requirements are defined for a software system, developers start working on a design. The goal of a software design is to decide on the structure of the software and the hardware configurations that support it. There are three main levels of software design: architecture, high-level design (HLD), and low-level design (LLD). All software designs model the structure of a system. The structure includes components, interfaces, and relationships. We use several diagrams to support the analysis model of the requirements and our representation of a software design. The diagrams, and other software artifacts related to design, will be detailed further below.

Software design evolves over time and may be refined as designers learn more about the system. A well-formed design provides functionality for the software system described in the requirements. A class in an object-oriented design should be complete and sufficient for the appropriate encapsulation of the class’ state and behaviors. Additionally, each class should be focused on one idea, abstraction, or service and the behaviors of the class should be cohesive and support that single responsibility. Finally, a class should have low coupling or minimize it’s collaborations or relationships with other classes. If classes in a software system are highly coupled, in that they have relationships with all other classes in the system, then the system is vulnerable to failures when one component of the system changes. Software systems with low coupling are more resilient to changes.

When creating a software design, you want to understand the requirements so that you know how the application will be used. The design of a stand-alone application is very different from the design of a web application.

Goal: Decide the structure of the software and the hardware configurations that support it

Software Artifacts: design documents, class diagrams, other UML diagrams

Architecture

Architecture provides a representation or abstraction of a software system at a very high-level. The architecture can characterize a software system and provides a common language for communication. There are several common architectures:

• Data-Centered: All components of the system interact with a common data repository, typically a relational database.
• Call and Return: Components consist of subprograms invoked through a main program. Subprograms may invoke other subprograms forming a hierarchical or tree structure.
• Layered: Components are layered by their functionality. Most web applications use a layered architecture.
• Model-view-controller: Components are divided into the model (e.g., business logic), the view (e.g., the user interface), and the controller (e.g, the connection between the view and model). Model-view-controller architectures are also common in web applications.

All applications developed in CSC116 are stand-alone Java applications that use the model-view-controller (MVC) architecture. Since we are developing in Java, the view and controller are tightly coupled. That means they are represented in a single class which is the GUI class. The view is the look and feel of the application and includes the standard form components and the layout of those components. The controller portion of the GUI class are the methods that are executed when a component, like a button, is interacted with by the user. When a button is clicked the controller method will call a method in the underlying model. We typically have a class that represents the overarching model of the system that the controller methods interact with. The overarching model class will then delegate to the other classes in the system as appropriate for their abstraction.

Low-level Design

For object-oriented systems, low-level design describes the classes, including their state and behaviors, and the relationship between those classes. Our low-level design must conform to the model-view-controller architecture and the classes will each belong to a package described in the high-level design. When creating a low-level design, we start by discovering classes and their state. The next step is to determine the responsibilities of each class. Finally, we describe the relationships between each class.

There are several diagram types that describe low-level design.

• Class Diagrams: Class diagrams are a type of UML diagram, which describe the classes, states, behaviors, and relationships between classes for a software system.
• Control-flow Diagrams: Control-flow diagrams model the flow-oriented elements of a software system. Control-flow diagrams can model the flow of control between methods or within a method and may be used to estimate the number of unit tests needed to fully exercise all paths in a method.
• State Diagrams: State diagrams describe the behavioral elements of a software system. State diagrams are frequently used to model finite state machines and show how inputs to the system can change the internal state of a class. State diagrams are typically implemented using the State Pattern.
• Sequence Diagrams: Sequence diagrams describe the behavioral elements of a software system by modeling the call chain of methods for a scenario. A scenario is a single path through a use case; system tests are scenarios exercised against the system to evaluate if the validity of the software. A sequence diagram models a series of method calls and returns for a given scenario.

Class Diagrams

Class diagrams are a type of UML diagram, which describe the classes, states, behaviors, and relationships between classes for a software system. When analyzing requirements, we identify nouns which could represent objects or an object’s state and verbs which could represent a class’ behaviors. We then create a UML diagram to represent classes as an abstraction of a single responsibility and the relationships between classes.

Supporting tool: UML Editors, such as Draw.io - Online tool to draw diagrams

Classes

In a UML class diagram, classes are represented by a box divided into three sections stacked vertically. The top section contains the class name, and in some diagrams may also include the package name. The middle section contains the class’ state or fields. The bottom section lists the class’ behavior.

The state and behaviors of a class are written so that you can directly translate them to the code for fields and methods. Both state and behaviors have a leading symbol that represents the visibility of the item. A + (or green circle) represents public, - (or red square) represents private, # represents package, and no symbol represents default access.

Recall:

• public: Any class can use the field or method through an instance of the object or the class itself (if the field or method is static).
• private: No external class can use the field or method.
• protected: An external class that is a subclass of the given class or in the same package as the given class can use the field or method through an instance of the object or the class itself (if the field or method is static).
• default: An external class that is in the same package as the given class can use the field or method through an instance of the object or the class itself (if the field or method is static).

The visibility is followed by the name of the element. For example, there is a field named eventName and two methods named isConflict. A method’s name is followed by parentheses that may include a parameter list. The parameter list could just list the types of the parameters in order. The parameters may also include names. If so, the name is listed first, followed by a colon (e.g., :), then the type.

The type of the state or behaviors is listed at the end of the line following a colon (e.g., :). The method’s type is the return type, which means the method can also be treated as that type in code!

A static field or method (e.g., the main method) is annotated with an underline. There is not a specific notation for final fields.

Composition (has-a)

A composition relationship is when one class has or uses an instance of another class. There are several connectors that are used to model a composition relationship depending on the nature or strength of the relationship. All connectors, except the dependency connector, represent when a class has a field (is a container) that is an instance of another class (the contained). That means the connector is annotated with information about the field like the field name. Since the connector represents the field, it is redundant to list the field in the container class. The connector may also be annotated with numbers that represent the multiplicity of the connection. If there is only a single instance of the contained in the container, the multiplicity is noted as a 1. If there are multiple objects of the contained type in the container, the multiplicity is noted as 0..*, or zero to many. That means the container stores the contained type in some type of collection like an array or object from the Java Collections Framework.

Association Connector

An association connector is a solid line between the container and the contained. If the relationship is bi-directional, which means that each class contains an instance or collection of the other, the connector is a solid line. The connector is annotated with the field names for each class. In the example below, Course would have a field called enrolledStudents which would contain a collection of Students. Student would have a field called courseSchedule containing a collection of Courses.

If the relationship is uni-directional, the arrow points to the contained class. In the example below, Schedule has a field called events which would contain a collection of Events.

Aggregation Connector

An aggregation connector is a solid line between the container and the contained with an open diamond at the end next to the container. An aggregation connector models a whole-part relationship where the contained class represents a part of the container or whole class where the part can exist separate from the whole. For example, a car has wheels or the wheel is part of a car. But the wheel can exist separate from the car. In an above example, we showed that a schedule has events. If we consider a schedule as a whole that is made up of events, the more appropriate connector for the relationship would be aggregation.

Composition Connector

A composition connector is a solid line between the container and the contained with a solid diamond at the end next to the container. Like an aggregation connector, a composition connector models a whole-part relationships where the contained class represents a part of the container or the whole class. Unlike the aggregation connector, a composition connector should be used when the part cannot exist separate from the whole or when the whole controls the entire life cycle of the part. For example, a line item doesn’t exist separate from an invoice. If we consider a schedule as controlling the life cycle of events and that an event cannot exist outside of a schedule, we could model the relationship using a composition connector. A composition connector may be used to model inner classes since the outer class controls the life cycle of the inner class.

Dependency Connector

A dependency connector is a dashed line between the container and the contained. The arrow points to the contained. A dependency connector is used to show when a class uses an instance of another class as a local variable or a parameter type, but not as a field. Since there are usually many dependencies between classes in a design, the dependency connector is frequently omitted from class diagrams.

The following are helpful hints¹ for working on your design:

1. Determine the classes that your implementation will use.
   • Begin by noting the nouns in the requirements/analysis documentation (or problem statement).
   • These nouns give us a good starting point for considering possible classes.
   • Not all nouns will become classes. Some nouns may become attributes/fields (see 3). Other nouns may not become classes or attributes/fields.
   • Not all classes will correspond to nouns of problem statement.
   • Once you have a list of possible classes, consider different design options along with the pros and cons of each. We often do not come up with the best design on our first attempt.
2. Determine the methods for each class.
   • “As the nouns indicate classes, the verbs of the problem statement help determine class responsibilities.”¹
   • Consider:
     • What service does the class provide?
     • What is each class’s responsibility?
     • What are the actions and behaviors of each class?
     • What attributes/fields used in the methods?
   • Not all verbs will become methods.
   • Not all methods will correspond to verbs in the problem statements.
3. Determine the attributes/fields of each class by observing which classes need to send messages to which.
   • Nouns can also help with these
   • Remember, not all nouns will become classes or attributes/fields.
   • Not all attributes/fields will correspond to nouns in the problem statement.
4. Refine your design. Write headers for all methods, but do not implement the methods.
5. It may be helpful to consider particular algorithms that you may need and write pseudocode. Do not write actual code!

Reference

The implementation phase is the “period of time in the software life cycle during which a software product is created from design documentation and debugged.”¹

Goal: Translate design into a concrete system (i.e., code)

Software Artifacts: source code, documentation, configuration files, media, executables, bug database, source code repository

References

The test phase is “the period of time in the software life cycle during which the components of a software product are evaluated and integrated, and the software product is evaluated to determine whether or not requirements have been satisfied”.¹ While there are several different types of tests, the focus will be on unit tests and system tests. Unit tests focus on evaluation of individual methods or modules and are typically written by the developer.¹ System tests evaluate a completed system to ensure that the requirements are met.¹

Goal: Execute software with intent of finding errors

Software Artifacts: test code (including test harnesses, scaffolding, etc.), bug database, test database, test inputs and outputs, documentation

• Slides TODO: Add links to resources (in _data/comprehensive-exercise.yml)
• Other Resources TODO: Add links to resources (in _data/comprehensive-exercise.yml)

References