Systems Architecture – Real Options perspective

Options thinking is a useful way to approach systems architecture. Although the options approach is nothing new, its usefulness was not well known because of lack of formal framework(applicable to systems engineering/software engineering) for options thinking. This post tries to summarize how options can be used in the systems architecture and development.

Options can be present in the project or in the process or both.

It can be noted here that moving away from a waterfall method of system development to spiral or agile development methodology creates options.  At each spiral you can assess the costs, risks etc to decide whether to proceed or to abandon the project before making too much investment.  You can delay the decisions where there is uncertainty and wait till data is available thus creating options. The presence of options should be considered  while carrying out project valuations. Instead of the traditional all or none kind of thinking about the projects, options thinking enable you a variety of options in between limiting the downside losses and unlimited upside potential gains. It can also help in getting management budget approvals by staging the project/product development rather than project the entire project/product cost upfront.

Systems architecture should be built using the options approach. Since the external environment is changing very fast the system should be able to ‘adapt’ to the new situation very fast. This requires lot of flexibility in the systems architecture.  The system should be able to scale up, scale down, put to alternate uses, addition of new functionalities rapidly with less cost cost are some of the features of systems with ‘options’ built into them. Modular, scalable, open, generic architectures include of these options in them. We still need to discuss, debate and understand the options more in depth. I welcome your suggestions, comments, observations, experiences in this regard!

System,Safety and Software

“Safety is a system issue”(Nancy Levenson). Any system is made of subsystems, components etc. Each subsystem, component contributes to system safety. Hence the system has to be analyzed as a whole with safety in mind. There are techniques like – Fault Tree Analysis( FTA), Software FTA, Failure Mode Effects Analysis( FMEA) etc available for carrying out the analysis.

Note that software is also one of the important components of any system. The software safety needs can be derived from the system safety needs. Some of the typical needs are – software should prevent the system from entering an unsafe state by detecting error conditions, handle wrong user inputs etc.

Generally safety issues are considered as part of the non-functional aspect of the system. Some of safety related needs can be identified from a systems safety analysis System safety analysis usually involves – identifying hazards , their consequences and their causes. The hazards are then analyzed to see if they can be avoided altogether. Many times it is not possible to avoid them. They are then analyzed to see if they can be controlled or eliminated if they do happen. Control mechanisms should also be identified for controlling, eliminating them. Some of the techniques are listed below:

• Safety interlocks
• Hardware lockouts to protect against software errors
• Watchdog timers
• Hardware monitor circuits
• Continuous Built In Tests
• Software check points for recovery

From the system safety needs and safety analyzes, software safety needs to be derived. The software needs thus developed needs further safety analysis. The purpose of this analysis is to identify:

• To verify that the software safety needs are correct
• Software correctly implements the safety related features

With all these, it is still difficult to achieve the required system safety. So, the software can include the following features to make it more safer

• Built in tests
• Heart-beat monitors
• Using pre conditions, post conditions for filtering wrong inputs
• Checking for buffer overflows
• Continuous built in tests
• Checking for wrong or invalid commands
• Checking for out of order data / commands
• Entering a wrong state due to multiple events etc

The question still remains how to identify the system failures and hazards. Some of the guidelines for identifying these are:

• Explore historical records
• Look at energy sources
• Develop “what-if” scenarios

 

There are many known sources of software safety problems that can be addressed explicitly by adding them as requirements. Some of them are listed here for reference.

• Use of wrong engineering units
• Assumptions about the environment
• Assumptions about users
• Assuming that inputs are always correct
• Not following relevant standards

This entry relies on the following sources. These can provide you more information on the subject: http://satc.gsfc.nasa.gov/assure/nss8719_13.html
A Software Fault Tree Approach to RequirementsAnalysis of an Intrusion Detection System
Guy Helmer et al

 

 

Use Case best practices

Use case is a powerful tool for capturing functional requirements of the system. Its primary use is to capture the contract between the stake holders of the system about its behavior. Note, however, that use cases may be used by some teams to capture the requirements in the traditional ‘shall’ based format. Or the use cases themselves can be used as requirements by some teams.

A use case is almost always started by an agent called an actor. A primary actor is a stake holder of the system and initiates an interaction with the system to achieve some goal. As the system interacts with the system its behavior, alternate behaviors, constraints etc are captured as part of that use case. Deciding who is an actor for a given use case is, some times, not trivial. Discovering use cases for a system is not simple. Capturing the use cases effectively requires some skill and an understanding of best practices immensely helps teams/individuals. Use Case is not object-oriented. It has nothing do with object-orientation. Simple text can be used to capture use cases. Refer to Alistair Cockburn’s excellent book “Writing Effective Use Cases” for more information. This post owes much to his excellent book.

The style of description of use cases might vary depending on how the use case is being put to use. Use cases can be used as white box use cases (ex: a business process or internal working of a system) or also as black-box use cases (ex: system requirements etc). Even the level of detail might vary from project to project or from team to team. For example, projects with safety, regulatory issues might decide to use detailed use cases, where as a project team with experienced developers might decide to use only brief use case descriptions for the system development. Projects following agile development philosophy tend not to generate detailed use case descriptions and instead rely on the good internal communication instead. They tend to keep the rest of the requirements in prototypes, continual communications and frequent incremental releases.

The use case description style can be chosen on a project-by-project basis. It makes sense to tailor the template depending on the project needs. Since use cases are easy to understand even for the non-technical persons, it is the single most important tool for identifying, clarifying, deciding system scope and its requirements.

If use cases are used as requirements, then it need not be converted to traditional ‘shall’ based requirements. Another thing to note here is that, use cases do not capture all the requirements of the system. They do not capture other important aspects of the system – non-functional requirements, quality requirements, external interfaces, rules etc. These requirements have to be captured using the traditional ‘shall’ based requirements.

Following are some of the best practices in designing use cases.

• Write the main success scenario as part of the main scenario. Identify, in each step, things that can go wrong and how the system should respond to them.
• Use discretion while detailing requirements. The mistake is getting too much caught up in precision and rigor when it is not required. If the system to be built is simple and easy to understand the use cases need not be captured with much detail.
• The best way to identify the use cases is through brainstorming. An experienced user can guide the team in identifying them. The idea to keep in mind during the identification stage is to focus on use case identification and not its expansion. Once the use cases are identified, they can be divided among team members for expansion. While detailing individual use cases, team members can take the help of domain experts, stake holders, and business experts etc to cover all the alternative scenarios of the use case. This procedure of identifying the use cases first and detailing them later provides the opportunity for the stake holders to correct any of the wrong assumptions made during the identification process. The thing to remember – once the use case is accurate, you can add precision during its expansion.
• It makes sense to include narratives or concept of operation before writing use cases. They provide context to the requirements and help clarify the environment in which the use case runs.
• Identifying an Actor – An actor is anyone one or anything with behavior. It is external to the system under consideration and its behavior can not be controlled. Note that the actors need not be humans always. It could be an external system, a timer or state based invocation.
• Primary Actor – An actor who initiates the dialogue with the system for achieving goal. The use case starts at the triggering point (initiated by the primary actor) and ends when the goal is fulfilled or abandoned.
• A use case can succeed in a number of ways. A use case can fail in a number of ways. The detailed use case description should enumerate all the possible scenarios. Note however that it is not needed to write all the sequences from start to end. Only those steps that can fail and the alternative steps for them need to be enumerated. In short, use cases contain scenarios and a scenario contains sub use case as its steps.
• The use case as a contract for behavior captures all and only behaviors related to satisfy the stake holder’s interests. It should satisfy all stake holders’ interests including the primary actor. For example: keeping a log will protect the stake holders in the case of any disputes. For a use case to be complete, all the stake holders (that are affected by the use case directly or indirectly) must agree on the success criteria and also the guarantees they want from the system. Listing the stake holders and their interests ensures that none of the required steps are left out in the use case description.
• The name of the use case is best described with primary actor’s goal. Most of the time it’s the primary actor who triggers the use case. It is possible to initiate the use case with the help of an intermediary or it could be time or state based initiation.
• Scope can be added to each use case if the use case context is not clear from its description. The scope could be – for example: enterprise, system, sub system etc. Graphical icons can be added to highlight use case applicability.
• Use cases can be applied even to describe the architecture or design. Many people find it easier to understand the design, architecture this way.
• Use cases can be written at different levels and this can be indicated as the scope to which the use case applies. At the outermost level the use case is said to be a ‘summary’ level use case. Similarly use cases can be written that are applicable to subsystems etc. Note that there are very few outermost level use cases. And these use cases provide context for other use cases.
• Having a clearly defined vision for the system helps in deciding whether some of the features should be part of the system or not. Similarly, having context diagrams, actor-goal list and in/out scope list helps in defining the system scope and helps in arriving at use cases at different levels.
• Use cases need to protect all the stakeholders’ interests even though they are not the primary users of the system.
• Finding the actors and goals is an iterative process. New actors may arise when the use case is being described – for ex: while writing a failure case. Start first with identifying the actors that interact with the system and list their goals. Then as you start detailing each use case, you may discover new actors. Add them to the list of actors and identify their goals. Iterate through this procedure till you can not find new test cases or actors. It is important not to miss any actors and their goals otherwise the system will not meet the expectation of all the stake holders.
• Writing down the backgrounds, skills and job descriptions of each actor would be useful. User interface designers can use this information for designing appropriate user interfaces.
• Use cases can be partitioned into different packages based on the actors and can be handed over to different teams for development.
• It is best to avoid naming actors based on their job titles for ex: dispatch clerk etc. It is best to name them according to the role they play with respect to a goal. Note however that, initially actors names can be identified based on their specific jobs and later can be replaced with more generic roles. The reason behind this is that – an actor may play different roles as part of his job responsibility. Or many actors can play the same role. It may so happen if we name the actors based on their job titles that if one or more of his roles are moved to another person it may pose difficulty in maintaining the use case document and also in the software design. Keeping a table of actor to role list might help in user interface and design phases.
• The system may use other systems to achieve the goal of primary actors. These systems are called secondary actors or supporting actors. When the system uses other systems to realize the goal, the interface between the systems, the data format, protocols etc needs to be captured.

 

UML Activity Diagrams 101

One of the unique features offered by the Activity diagrams is – it makes possible to combine non-Object Oriented (referred to as OO) modeling with OO modeling. Most of the times than not, people use specialized non-OO libraries in their OO design. UML activity diagrams make modeling of non-OO library calls possible in their OO designs. Similarly, Activity diagrams can be quite useful for Business Process Modeling for enterprise modelers or for modeling the flow of information, control, energy etc for System Engineers. It can be used, for example, to graphically detail use cases. It can also be quite useful for project managers/system Engineers represent the project/product development process. People who are familiar with Petri nets, Data Flow, Control Flow Diagrams will find themselves at home with Activity Diagrams. Another important addition to Activity diagrams is the addition of parameter nodes (technically, they are object nodes) that allows the invoker to pass parameters to the model and receive output from the Activity. Activity diagrams can be invoked from other Activity diagrams thus making them reusable.

The activity model is defined with semantic variations, which means that the runtime behavior might vary from implementation to implementation and the modeler can choose the behavior that is appropriate. The basic constructs of Activity diagrams are – Action Nodes, Control Nodes (Decision nodes, Fork and Join, Initial Node, Finals Nodes) and Object nodes.

• Action nodes represent behaviors, which can be – Activities, State machines or interaction diagrams. They consume control and data (referred to as tokens) and output control and/or data. Actions could be – create object, set object or invoke some behavior. Note that the actions can be represented as a function in procedural language like – C or as a method in OO languages, or as a class with behavior in OO languages. Actions are the only constructs in UML that can invoke operations on objects. Note that each action node may have more than one input (control and/or action). The action is triggered only when all the inputs are available. When the activity ends data/control is placed on the outgoing nodes (object node or control flow).
• Control nodes are used for controlling data/control flow through the diagram based on decisions or provide parallel paths for data/control flow or terminating an activity.
  • An activity diagram can contain more than one start nodes. An activity will start at all these nodes simultaneously. So, it is better to have a single start node to avoid confusion.
  • Decision nodes help route flow to different paths in the diagram based on the evaluation of guard conditions placed on each path. Care should be taken not to have more than one guard condition evaluating to true at the same time. Another useful thing to remember is – guard conditions should not have any side effects. Decision nodes can be chained. Note also that decisions nodes can invoke other Activities to decide routing.
  • Merge Nodes are used to merge multiple flows. Just like the decision nodes merge nodes can be chained.
  • Fork Nodes split flows into more than one simultaneous flow. Data / Control are simply copied onto each path.
  • Join nodes synchronize multiple flows. Note that if there are multiple control tokens coming into the join nodes they will be merged into a single token. If there are both control and data tokens only data tokes are copied onto the outgoing flow. No control tokens are copied. Also, modelers should pay attention not to have any flow final nodes in one of the join paths, which would otherwise make the next action wait indefinitely if the flow is terminated. Like merge nodes join nodes can also be chained.
  • Flow final nodes receive control / data tokens and do nothing. Effectively, they end the flow in that path.
  • Final nodes end an activity when any token is received. This can be used instead of flow final as this node will terminate the entire activity including other concurrent paths.
• Object nodes act as placeholders for data as it moves along the path. Object nodes can hold single token, multiple tokens, buffering, backup, central data store etc. The object nodes can optionally contain the state of the object. The object can also be a group of data. Object nodes can traverse the edge only when all the input-output pairs are ready. Central buffers can be used when it is necessary to allocate to token to different competing destinations.

Activities can be connected to other activities directly when they carry control or through object nodes when they carry data. As mentioned above Actions start as soon as all the inputs are available. However, streaming parameters are exceptions to this rule. Streaming parameters can accept and output parameters while an action is executing (at least one input must arrive for the action to begin). Apart from normal output parameters the action can also output exceptions as well indicating an exceptional condition. When an exception is output, other outputs are not defined. Note also that exception outputs cannot be streaming. It is also possible to group parameters (called Parameter Sets) such than exactly one of them accept or provide values. Constraints such as pre-conditions, post-conditions can be applied to actions, which can be specific to a particular invocation of a behavior or could apply to all invocations of that behavior. The other useful feature of Activity diagrams is the swim-lane notation. Swim lanes group activities. A swim lane for example could represent a department and its responsibilities or different hardware or different components or different classes or attributes etc.

For more information, interested readers may consult a series of 6 articles by Conrad Bock(Conrad Bock: UML 2 Activity and Action Models” )