» THE SYSTEM ENGINEERING HIERARCHY
» BUSINESS PROCESS ENGINEERING
» SYSTEM MODELING
» DESIGN CONCEPTS

THE SYSTEM ENGINEERING HIERARCHY

System Engineering encompasses a collection of top- down and methods to navigate the hierarchy illustrated in figure 3.1. The system engineering process usually begins with a “world view”. That is, the entire business or product domain is examined to ensure that the proper business or technology context can be established. The world view is refined to focus more fully on a specific domain of interest. Within a specific domain, the need for targeted system elements is analysed. Finally, the analysis, design, and construction of a targeted system elements are initiated. At the top of the hierarchy, a very broad context is established and, at the bottom, detailed activities, performed by the relevant engineering disciplines are conducted.

The world view (WV) is composed of a set of domains (D1), which can each be a system or system of systems in its own right

WV = {D1 D2 D3………,Dn }

Each domain is composed of specific elements (Ej) each of which serves some role in accomplishing the objective and goals of the domain and component:

Di = {E1 E2 E3 …… Em}

Finally, each element is implemented by specifying the technical components (Ck) that achieve the necessary function for an element:

Ej = {C1, C2 C3 …….. C k}

In the software context, a component could be a computer program, a reusable program component, a module, a class or object, or even a programming language statement.

System Modeling

System modeling is an important element of the system engineering process. Whether the focus is on the world view or the detailed view, the engineer creates models that:

• Define the process that serves the needs of the view under consideration.
• Represent the behavior of the processes and the assumption on which the behavior is based.

To construct a system model, the engineer should consider a number of restraining factors:

1. Assumption that reduce the number of possible permutations and variations, thus enabling a model to reflect the problem in a reasonable manner.
2. Simplifications that the model has to create in a timely manner.
3. Limitations that help to bound the system.
4. Constraints that will guide the manner in which the model is created and the approach taken when the model is implemented.
5. Preference that indicate the preferred architecture for all data, functions, and technology.

System Simulations

Many computer- based systems interact with the real world in a reactive fashion. That is, real- world events are monitored by the hardware and software that from the computer- based system, and based on these events; the system imposes control on the machine, process, and even people who cause the events to occur. Real- time and embedded systems often fall into the reactive systems category.

There are many systems in the reactive category- control machine and/or processes (e.g., commercial aircraft or petroleum refineries) that must operate with an extremely high degree of reliability. If the system fails, significant economic or human loss could occur. For this reason system modeling and simulation tools are used to help eliminate surprises when reactive computer- based systems are built. These tools are applied during the system engineering process, while the role of hardware and software, databases, and people is being specified. Modeling and simulation tools enable a system engineer to “test drive” a specification of the system.

System Simulation Tools:

Objective: System simulation tools provide the software engineer with the ability to predict the behavior of a real-time system prior to the time that it is built. In addition, these tools enable the software engineer to develop mock-ups of the real-time system, allowing the customer to gain insight into the function, operation, and response prior to actual implementation.

Mechanics: Tools in this category allow a team to define the elements of a computer- based system and then execute a variety of simulations to better understand the operating characteristics and overall performance of the system. Two broad categories of system simulation tools exist: (1) general purpose tools that can model virtually any computer- based system, and (2) special purpose tools that are designed to address a specific application domain ( e.g., aircraft avionics systems, manufacturing systems, electronic- systems).

Representative Tools: CSIM, developed by Lockheed Martin Advanced Technology Labs (www.atl.external.lmco.com), is a general purpose discrete- event simulation for block diagram- oriented systems.

Simics, developed by Virtutech ( www.virtutech.com), is a system simulation platform that can model and analyze both hardware and software- based systems.

A useful set of links to a wide array of systems simulation resources can be found at http:// www.idsia.ch/-andrea/simtools.html.

BUSINESS PROCESS ENGINEERING

The goal of business process engineering is to define architectures that will enable a business to use information effectively. When taking a world view of a company’s information technology needs, there is little doubt that system engineering is required. Not only is the specification of the appropriate computing architecture required. But the software architecture that populates the organization’s unique configuration of computing resources must be developed. Business process engineering is one approach for creating an overall plan for implementing the computing architecture.

The different architectures must be analyzed and designed within the context of business objectives and goals:
• Data architecture
• Applications architecture
• Technology infrastructure

The data architecture provides a framework for the information needs of a business or business function. The individual building blocks of the architecture are the data objects that are used the business. A data object contains a set of attributes that define some aspect. Quality, characteristic, or descriptor of the data that are being described.

Once set of data objects is defined, their relationships are identified. A relationship indicates how objects are connected to one another. As an example, consider the objects: customer and product A. The two objects can be connected by the relationship purchases; that is, a customer purchases product A or product is purchased by customer. The data objects (there may be hundreds or even thousands for a major business activity) flow between business functions, are organized within a database, and are transformed to provide information that serves the needs of the business.

The application architecture encompasses those elements of a system that transform objects within the data architecture for some business purpose. In the context of this book, we consider the application architecture to be the system of programs (software) that performs this transformation. However, in a broader context, the application architecture might incorporate the role of people (who are information transformers and users) and business procedures that have not been automated.

The technology infrastructure provides the foundation for the data and application architectures. The infrastructure encompasses the hardware and software that are used to support the applications and data. This includes computers, operating systems, networks, telecommunication links, storage technologies, and the architecture (e.g., client/ server) that has been designed to important these technologies.

Requirement Engineering

Requirements engineering helps software engineers to better understand the problem they will work to solve. It encompasses the set of tasks that lead to an understanding of what the business impact of the software will be, what the customers want, and how end-users will interact with this software.

Understanding the requirements of a problem is among the most difficult tasks that a software engineer faces. When you first think about it, requirements engineering doesn’t seem that hard. After all, doesn’t the customer know what is required? Shouldn’t the end-users have a good understanding of the features and functions that will provide benefit? Surprisingly, in many instances the answer to these questions is no. And even if customers and end-users are explicit in their needs, those needs will change throughout the project. Requirements engineering is hard.

In the forward to a book by ralph young in effective requirements practices, it is written:

“It’s your worst nightmare. A customer walks into your office, sits down, looks you straight in the eye, and says,” I know you think you understand what I said, but what you don’t understand is what I said is not what I mean.” Invariably, this happens late in the project, after deadline commitments have been made, reputations are on the line, and serious money is at stake.”

All of those who have worked in the systems and software business for more than few years have lived this nightmare, and yet, few of them have learned to make it go away. We struggle when we try to elicit requirements from our customers. We have trouble understanding the information that we do acquire. We often record requirements in a disorganized manner, and we spend far too little time verifying what we do record. We allow change to control us, rather than establishing mechanisms to control change. In short, we fail to establish a solid foundation for the system or software. Each of these problems is challenging. When they are combined, the outlook is daunting for even the most experienced managers and practitioners. But solutions do exist.

It would be dishonest to call requirements engineering the “solution” to the challenges noted above. But it does provide us with a solid approach for addressing these challenges.

What is it? Requirements engineering helps software engineers to better understand the problem they will work to solve. It encompasses the set of tasks that lead to an understanding of what the business impact of the software will be, what the customer wants, and how end-users will interact with the software.

Who does it? Software engineers (sometimes referred to as system engineers or analysis in the IT world) and other project stakeholders (managers, customers, end- users0 all participate in requirements engineering.

Why is it important? Designing and building an elegant computer program that solves the wrong problem serves no one’s needs. That’s why it is important to understand what the customer wants before you begin to design and build a computer-based system.

What are the steps? Requirements engineering begins with inception--- a task that defines the scope and nature of the problem to be solved. It moves onward to elicitation task that helps the customer to define what is required, and then elaboration—where basic requirements are refined and modified. As the customer defines the problem, negotiation occurs--- what are the priorities, what is essential and when is it required? Finally, the problem is specified in some manner and then reviewed or validated to ensure that your understanding of the problem and the customer’s understanding of the problem coincide.

What is the work product? The intent of the requirements engineering process is to provide all parties with a written understanding of the problem. This can be achieved through a number of work products: user scenarios, functions and features lists, analysis models, or a specification.

How do I ensure that I’ve done it right? Requirements engineering work products are reviewed with the customer and end-users to ensure that what you have learned is what they really meant. A word of warning: even after all parties agree, things will change, and thy will continue to change throughout the project.

A Bridge to Design and Construction:

Designing and building computer software is challenging, creative, and just plain fun. In fact, building software is so compelling that many software developers want to jump right in before they have a clear understanding of what is needed. They argue that things will become clear as they build : that project stakeholders will be able to better understand need only after examining early iterations of the software; that things change so rapidly that requirements engineering is a waste of time; that the bottom line is producing a working program and that all else is secondary. What makes these arguments seductive is that they contain elements of truth. But each is flawed, and all can lead to a failed software project.

Fred Brooks: “The hardest single part of building a software is deciding what to build. No part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”

Requirements engineering, like all other software engineering activities, must be adapted to the needs of the process, the project, the product, and the people doing the work. From a software process perspective, requirements engineering (RE) is a software engineering action that begins during the communication activity and continues into the modeling activity.

In some cases an abbreviated approach may be chosen. In others, every task defined for comprehensive requirements engineering must be performed rigorously. Overall, the software team must adapt its approach to RE. But adaptation does not mean abandonment. It is essential that the software team makes a real effort to understand the requirements of a problem before the team attempts to solve the problem.

Requirements engineering builds a bridge towards design and construction. But where does the bridge originate? One could argue that it begins at the feet of the project when user scenarios are described, functions and features are delineated, and project constraints are identified. Others might suggest that it begins with a broader system definition, where software is but one component of the larger system domain. But regardless of starting point, the journey across the bridge takes us high above the project, allowing the software team to examine the context of the software work to be performed; the specific needs that design and construction must address; the priorities that guide the order in which work is to completed; and the information, functions, and behaviors that will have a profound impact on the resultant design.

Requirements Engineering Tasks:

Requirements engineering provides the appropriate mechanism for understanding what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification, and managing the requirements as they are transformed into an operational system. The requirements engineering process is accomplished through the execution of seven distinct functions: inception, elicitation, elaboration, negotiation, specification, validation, and management.

It is important to note that some of these requirements engineering functions occur in parallel and all are adapted to the needs of the project. All strive to define what the customer wants, and all serve to establish a solid foundation for the design and construction of what the customer gets.

Inception:

How does a software project gets started? Is there a single events that becomes the catalyst for a new computer-based system or product, or does the needs evolve over time? There are no definitive answers to these questions.

Capers jones: “The seeds of major software disasters are usually sown in the first three months of commencing the software project.”

In some cases, a casual conversation is all that is needed to precipitate a major software engineering effort. But in general, most projects begin when a business need is identified or a potential new market or serve is discovered. Stakeholders from the business community (e.g., business managers, marketing people, and product managers) define a business case for the idea, try to identify the breadth and depth of the market, do a rough feasibility analysis, and identify a working description of the project’s scope.

All of this information is subject to change (a likely outcome), but it is sufficient to precipitate discussions with the software engineering organization.

The intent is to establish a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired, and the effectiveness of preliminary communication and collaboration between the customer and the developer.

Elicitation:

It certainly seems simple enough- ask the customer, the users, and others what the objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of the business, and finally, how the system or product is to be used on a day-to-day basis. But it isn’t simple—it‘s very hard.

Christel and Kang identify a number of problems that help us understand why requirements elicitation is difficult:

• Problems of scope: The boundary of the system is ill-defined or the customers/ users specify unnecessary technical detail that may confuse, rather than clarity, overall system objectives.

• Problem of understanding: The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be “obvious” specify requirements that conflict with the needs of other customers/ users, or specify requirements that are ambiguous or untestable.

• Problems of volatility: The requirements change over time.

To help overcome these problems, requirements engineers must approach the requirement the requirements gathering activity in an organized manner.

Elaboration:

The information obtained from the customer during inception and elicitation is expanded and refined during elaboration. This requirements engineering activity focuses on developing a refined technical model of software functions, features, and constraints.

Elaboration is an analysis modeling action that is composed of a number of modeling and refinement tasks. Elaboration is driven by the creation and refinement of user scenarios that describe how the end-user (and other actors) will interact with the system. Each user scenario is parsed to extract analysis classes - business domain entities that are visible to the –user. The attributes of each analysis class are defined and the services that are required by each class are identified and a variety of supplementary UML diagrams are produced.

The end- result of elaboration is an analysis model that defines the informational, functional, and behavioral domain of the problem.

SYSTEM MODELING

Because a system can be represented at different levels of abstraction (e.g., the world view, the domain view, the element view), system models tend to be hierarchical or layered in nature. At the top of the hierarchy, a model of the complete system is presented the world view). Major data objects, processing functions, and behaviors are represented without regard to the system component that will implement the elements of world view model. As thee hierarchy is refined or layered, component-level detail (in this case, representations of hardware, software, and so on) is modeled. Finally system models evolve into engineering models (which are further refined that are specific to the appropriate engineering discipline.)

System Modeling tools:

Objective: System modeling tools provide the software engineer with the ability to model all elements of a computer-based system using a notation that is specific to the tool.

Mechanics: Tool mechanics vary. In general, tools in this category enable a system engineer to model (1) the structure of all functional elements of the system; (2) the static and dynamic behavior of the system; and (3) the human-machine interface.

Representative Tools: Describe, developed by Embarcadero Technologies (www.embarcadero.com), is a suite UML-based modeling tools that can represent software or complete systems.

Rational XDE and Rose, developed by Rational Technologies ( www.rational.com), provides a widely used, UML- based suite of modeling and development tools for computer–based systems.

Real-Time studio, developed by artisan Software ( www.artisansw.com), is a suite of modeling and development tools that support real-time system development.

Telelogic tau, developed by telelogic (www.tlelogic.com), is a UML-based tools suite that support analysis and design modeling as well as links to software construction features.

Hatley–Pirbhhai Modeling:

Every computer-based system can be modeled as an information transfer using an input- processing- output template. Hatley and Pirbhai have extended this view to include two additional system features-user interface processing and maintenance and self-test processing. Although these additional features are not present for computer- based system, they are very common, and their specification makes any system model more robust.

Using a representation of input, processing, output, user interface processing, and self-test processing, a system engineer can create a model of system components that sets a foundation for later steps in each of the engineering disciplines.

To develop the system model, a system model template is used. The system engineer allocates system elements to each of five processing regions within the template: (1) user interface, (2) input, (3) system function and control, (4) output, and (5) maintenance and self- test.

Like nearly all modeling techniques used in system and software engineering, thee system model template enables the analyst to create a hierarchy of detail. A system context diagram (SCD) resides at the top level of thee hierarchy. The context diagram “establishes the information boundary between the system being implemented and the environment in which the system is to operate.” That is, the SCD defines all external producers of information used by the system, all external consumers of information created by the system, and all entities that communicate through the interface or perform maintenance and self- test.

To illustrate the use of the SCD, consider a conveyor line sorting system (CLSS) described with the following (somewhat nebulous) statement of objectives:

CLSS must be developed in such a way that boxes moving along a conveyor line will be identified and sorted into one of six bins at the end of the line. The boxes will be shunted into the appropriate bins. Boxes pass in random order and are evenly spaced. The line is moving slowly.

A desk-top computer located at the sorting station executes all CLASS software, interacts with the bar-code reader to read part number on each box, interacts with the conveyor line monitoring equipment to acquire conveyor line speed, stores all part numbers sorted, interacts with a sorting station operator to produce a variety of reports and diagnostics, sends control signals to the shunting hardware to soft boxes, and communicates with a central factory automation system.

The system engineer refines the system context diagram by considering the shaded rectangle in moral detail. The major subsystems that enable the conveyor line strong system to function within the context defined by the SCD are identified. The major subsystems are defined in a system flow diagram (SFD) that is derived that enable the conveyor line sorting system to function within the context defined by the SCD are identified. The major subsystems are defined in a system flow diagram (SFD) that is derived from the SCD> Information flow across the regions of the SCD is used to guide the system engineer in developing the SFD—a more detailed “schematic” for CLASS. The system flow diagram shows major sub systems and important lines of information (data and control) flow. In addition, the system template partitions the subsystem processing into each of the five regions discussed earlier. At this stage, each of the subsystems can contain one or more system elements (e.g., hardware, software, and people) as allocated by the engineer.

The initial system flow diagram becomes the top node of a hierarchy of SFDs. Each rounded rectangle in the original SFD can be expanded into another architecture template dedicated solely to it.

Subsystems and the information that flow between them can be specified (bounded) for subsequent engineering work. A narrative description of each subsystem engineer.

The initial system flow diagram becomes the top node of a hierarchy of SFDs. Each rounded rectangle in the original SFD can be expanded into another architecture template dedicated solely to it.

Subsystems and the information that flow between them can be specified (bounded) for subsequent engineering work. A narrative description of each subsystem and a definition of all data that flow between subsystems become important elements of the system specification.

System Modeling with UML: UML provides a wide array of diagrams that can be used for analysis and design at both the system and the software level. For the CLASS system, four important system elements are modeled: (1) the hardware that enables CLASS; (2) the software that implements database access and sorting; (3) the operator who submits various requests to the system; and (4) the database that contains relevant bar code and destination information.

Another UML notation that can be used to model software is the class diagram (along with many class-related diagrams discussed later in this book) at the system engineering level, classes are extracted statement of the problem. For the CLASS , candidate classes might be : Box, Cover Line Bar-code Reader, Shunt Controller, Operator Request , Report, Product, and others. Each class encapsulates a set of attributes that depict all necessary information about the class. A class description also contains a set of operations that is applied to the class in the context of the CLASS system.

The use-case diagram illustrates the manner in which an actor (in this case, the operator, represented by a stick figure) interacts with the system. Each labeled oval inside the box (which represents the CLASS system boundary) represents one use-case- a text scenario that describes an interaction with the system.

DESIGN CONCEPTS

Fundamental software design concept provides the necessary framework for getting the product in a right way.

A) Abstraction
The different levels of abstraction are procedural data abstractions. A procedural abstraction refers to a sequence of instructions that have a specific and limited function. The name of procedural abstraction implies these functions, but specific details are suppressed.

B) Architecture
Software architecture includes the overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” A software architecture is the development work product that gives the highest return on investment with respect to quality, schedule, and cost.”

C) Patterns
Design Patterns describe a design structure that solves a particular design problem within a specific context and amid “forces” that may have an impact of the manner in which the pattern is applied and used.

D) Modularity
Modularity is the single attribute of software that allows a program to be intellectually manageable.

E) Information Hiding
Modules should be specified and designed so that information (algorithms and data) contained within a module is inaccessible to other modules that have no need for such information. This is called information hiding.

F) Functional Independence
Functional independence is achieved by developing modules with “single minded” function and an “aversion” to excessive interaction with other modules. Stated another way, we want to design software so that each module addresses a specific sub function of requirements and has a simple interface when viewed from other parts of the program structure.

G) Refinement
Stepwise refinement is a top –down design strategy that is defined as a program is developed by successively refining levels of procedural detail. A hierarchy is developed by decomposing a macroscopic statement of function (a procedural abstraction) in a stepwise fashion until programming language statements are reached.

H) Refactoring
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.

The Design Model

The design model can be viewed in two different dimensions as process and abstraction. The process dimension indicates the evolution of thee design tasks are executed as part of the software process. The abstraction dimension represents the level of detail as each element of the analysis model is transformed in to a design equivalent and then refined iteratively.

a) Data Design Elements
Data design creates a model of data and/or information that is represented at a high level of abstraction (the customer/ user‘s view of data). This data model is then represented into progressively more implementation- specific representations that can be processed by computer- based system.

b) Architectural Design Elements
Architectural Design Elements give us an overall view of software. The architecture model is derived from three sources (1) information about the application domain for the software to be built; (2) specific analysis model elements such as data flow diagrams or analysis, their relationship and collaboration for the problem at hand, and (3) the availability of architectural patterns.

c) Component-level Design Elements
The component- level design defines data structures for all local data objects and objects and algorithmic details for all processing that occurs within a component and an interface that allows access to all component operations (behaviors).

Summary
• System modeling is one of the important elements in the system engineering process.
• Modeling and simulation tools enable system engineering to test drive a specification or the system.
• The intent of object oriented analysis is to define all classes that are relevant to the problem to be solved.
• The various levels of data flow diagrams determine thee efficient analysis of flow oriented modeling.
• In design model, process dimension indicates the evolution of the design model whereas abstraction dimension represents the level of detail as each element of the analysis model is transformed in to a design equivalent and then refined iteratively.