The System Engineering Hierarchy - System Modeling

Good system engineering begins with a clear understanding of context - the world view - and then progressively narrows focus until technical details are understood. System engineering encompasses a collection of top-down and bottom-up methods to navigate the hierarchy.
System engineering process begins with a world of view which is refined to focus more fully on a specific domain of interest. Within a specific domain, the need for targeted system elements is analyzed. Finally, the analysis, design, and construction of targeted system element is initiated. Broad context is established at the top of the hierarchy and at the bottom, detailed technical activities are conducted. It is important for a system engineer narrows the focus of work as one moves downward in the hierarchy.

System modeling is an important element of system engineering process. System engineering model accomplishes the following:
- define processes.
- represent behavior of the process.
- define both exogenous and endogenous input to model.
- represent all linkages.

Some restraining factors that are considered to construct a system model are:
- Assumptions that reduce number of possible permutations and variations thus enabling a model to reflect the problem in a reasonable manner.
- Simplifications that enable the model to be created in a timely manner.
- Limitations that help to bound the system.
- Constraints that will guide the manner in which the model is created and the approach taken when the model is implemented.
- Preferences that indicate the preferred architecture for all data, functions , and technology.
The resultant system model may call for a completely automated or semi automated or a non automated solution.

System Modeling - The Hatley Pirbhai Modeling

System models are hierarchical or layered as a system is represented at different levels of abstraction. The top level of hierarchy presents the complete system. The data objects, functions, behaviors are represented. As the hierarchy is refined or layered, component level detail is modeled and finally system models evolve into engineering models.
Hatley-Pirbhay modeling is an extension of the concept that every computer system can be modeled through the usage of an input-processing-output model by including the two additional features of user interface process and maintenance/self testing. These five components are added to a system model template to allow for modeling of the system which allows for proper assignment to the processing regions.

THE HATLEY-PIRBHAI MODELING
- The Hatley-Pirbhai model depicts input processing, and output along with the user interface and maintenance or self-test.
- It includes two more system features: user interface processing and maintenance and self-test processing.
- A system engineer can create a model of system components that sets a foundation for later steps.
- The system engineer allocates system elements to each of five processing regions within the template: user interface, input, system function and control, output, maintenance and self-test.
- A system context diagram(SCD) resides at the top level of hierarchy which 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 interface or perform maintenance and self-test.
- All the major subsystems are defined in a system flow diagram (SFD) which is derived from SCD.
- Information flows across the regions of system context diagram is used to guide the system engineer in developing system flow diagram.
- System flow diagram shows major subsystems and important lines of information.

Component Level Design - Definition, why it is important and what are the steps?

When the first iteration of architectural design is completed, component level design comes into picture. Intent of this phase is to translate the design model into operational software. The internal data structures and processing details of each component are not represented at a level of abstraction that is close to code. Component level design defines the data structures, algorithms, interface characteristics, and communication mechanisms allocated to each software component. A software engineer performs component level design.

Component level design is important because it is necessary to determine whether the software will work before you build it. The component level design represents the software in a way that allows you to review the details of the design for correctness and consistency with earlier design representations. It also provides a means for assessing whether data structures, interfaces and algorithms will work.

It is possible to represent component level design using a programming language. Component level design can also be represented by using some intermediate representation that can be translated easily into source code.

Define Component?
A component is a modular building block for computer software. Components should communicate and collaborate with other components as they reside within the software architecture. The meaning of component will differ depending on the point of view of software engineer using it. There are three different views of defining component :
- An Object oriented view
- The Conventional view
- A Process-related view

Steps in Component Level Design
- Design representations of data, architecture, and interfaces form the foundation of component level design.
- Class definition or processing narrative for each component is translated into detailed design that makes use of diagrammatic or text based forms that specify internal data structures, local interface detail, and processing logic.
- The procedural design is specified using a set of structured programming constructs.

Introduction to System Modeling

A model is a simplified representation of a system at some particular point in time or space intended to promote understanding of the real system. A system is understood to be an entity which maintains its existence through the interaction of its parts. A model is a simplified representation of the actual system intended to promote understanding. Whether a model is a good model or not depends on the extent to which it promotes understanding. Since all models are simplifications of reality there is always a trade-off as to what level of detail is included in the model. If too little detail is included in the model one runs the risk of missing relevant interactions and the resultant model does not promote understanding. If too much detail is included in the model the model may become overly complicated and actually preclude the development of understanding.

System modeling shows how the system should be working. To construct a system model, the system engineer should consider the following factors :
- Assumptions : It reduces the number of possible permutations and variations, thus enabling a model to reflect the problem in a reasonable manner.
- Simplifications : It enable the model to be created in a timely manner.
- Limitations : It helps to bound the system.
- Constraints : It will guide the manner in which the model is created and the approach taken when the model is implemented.
- Preferences : It indicates the preferred architecture for all data, functions, and technology. The preferred solution sometimes comes into conflict with other restraining factors.yet, customer satisfaction is often predicated on the degree to which the preferred approach is realized.