Method engineering

A method is a systematic process, technique or mode of inquiry that is used to aid in the creation of a satisfactory software product. [Blum94]. In a model-driven development approach we use a method to produce models. Method include technique and process. For example a CRC method includes CRC technique and CRC process.

• Technique: A specific construct supporting a method
• Process: A sequence of actions leading to some result

A methodology is a body of methods. It is meant to support all software development phases.

As we can see in the figure a methodology consists of a set of methods, each having their own technique and a process. A methodological process guides the usage of these methods. Methodologies typically build upon underlying concepts (or paradigms). Examples of such paradigms are: Object-oriented software development, component-based software development and service-oriented software development.

Principles for modern software development

Software development methodologies has evolved gradually over the past years. A modern software development methodology typically follows a set of these principles:

• Architecture-centric, e.g. service-oriented architecture
• Iterative and incremental process
• Service- and component-orientation
• Manage a highly dynamic environment.
  • Processes to support iterative and incremental development.
  • Software system mush be designed to be easy to change.
• Model-based
• “Round-trip” engineering
• Divide and conquer
• Quality check
• Configurable process

Process

The process depends on the type of system. It is very rare that a brand new system is being developed. Most of the cases developers are involved in re-engineering or modification. Re-engineering is a radical process of re-designing an old system while modification is a process of fixing a major problem or changing a feature. Another typical process scenario is to add new functionality to an existing system, by developing and integrating a new module (e.g. component or service).

• The Rational Unified Proces(RUP) is an iterative software development process created by the Rational Software Corporation. It is an adaptable process framework that describes how to develop software effectively using proven techniques.
• KobrA methodology for modeling architectures is a systematic approach to using UML that is refreshingly simple and straightforward. One of the problems on components is that the term "component" is so heavily overloaded . To overcome this, KobrA has introduced a new term "Komponent". Komponents are the "logical" components that represent the logical building blocks of a software system.
• Catalysis is another UML based method for object and component based development.
• Select Perspective is a methodology in agile modelling that uses multiple, best-of-breed modelling techniques, both text and diagram-based.
• The Object Oriented Role Analysise Method (OOram) is a method, based on the concept of role, for performing object-oriented modeling. OOram is a precursor for the Unified Modeling Language (UML). ( Developed by profesor Trygve Reenskaug ).
• Some other lightweight methodologies are eXtreme programing (XP), Adaptive Software Development (ASD), SCRUM – an agile method for project management, and Crystal Clear – an agile developing method.

From the engineering perspective, a method is made up of a set of product models and a set of corresponding process models. A product model represents the concepts that are used in the method, relationships between these concepts as well as constraints that they have to satisfy. A process model represents the way to accomplish the development of the corresponding product.

Method engineering process

In a method engineering process there are two foci:

1. Re-enginering of existing methodolologies into smaller methods or method chunks and describe the methodology as a set of configured modules. These method chunks will be stored in a method chunks repository.
2. Assembly of situation-specific methods based on existing method chunks.

Method chunk

A method chunk is an autonomous and coherent part of a method supporting the realisation of some specific system development or management activity. Such a modular view of methods favours their adaptation, configuration and extension. Moreover, this view permits to reuse chunks of a given method in the construction of new ones.

Problems and opportunities

There exist no authoritative compilations of method chunks that can be assembled to fit particular project contexts, and such that deliverables of applying one method chunk, can be mapped to inputs of another method chunk. Method chunks are rarely presented as elements that are separated from the problems solved with them, or from the cases used to illustrate their application. There is no agreed taxonomy of method chunks. Methods are in the heads of people, and not yet in the services of systems. There are no services to assess which methods to use in a given situation, given the bounded rationality of the engineer, often, sub-optimal methods are selected, making projects expensive and crippling system development.

However, there exists a near-consensus in the Method Engineering community, on the requirements for a method-chunk repository. There exists a wealth of architectural styles (service oriented, agents,...) that can assist the development of an MCR. Platforms such as ATHENA’s MPCE are offering infrastructural services, needs-awareness and proto-communities that are conducive for the MCR development and test.

To support method engineering we need a modelling and execution platform. This platform must provide use case users, developers, method chunk managers and method chunk developers appropriate workplaces with services. We also see the need for both a use case repository and a method chunk repository.

Even if it is used by many, the term “architecture” has no well established definition. Nevertheless, in the field of software engineering there is no shortage of more or less overlapping definitions (see for instance www.sei.cmu.edu/architecture/definitions.html). Here we present one consistent set of definitions targeting architectural descriptions for software-intensive systems, namely the IEEE Std 1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. This recommended practice seeks to become a common frame of reference within which to codify common elements between different architectural description initiatives, and has become influential and used as a baseline for architectural description frameworks, for instance within OMG. It reflects generally accepted trends in practices for architectural description and provides a frame of reference within which future developments in software architectural technology can be deployed.

According to the recommended practice, software-intensive systems are those complex systems “where software contributes essential influences to the design, construction, deployment and evolution of the system as a whole”. The purpose of IEEE Std 1471-2000 is to facilitate the expression and communication of architectures and thereby lay a foundation for quality and cost gains through standardisation of elements and practices for architectural description of software-intensive systems. This is in contrast to past attempts at architecture description where only hardware-related architectural aspects were addressed. With increasingly complex software, architectural integrity of the software should also be addressed and the recommended practice facilitates this.

The figure shows the conceptual model of architectural description as defined in IEEE Std 1471-2000.

Starting with system, it is defined to be “a collection of components organized to accomplish a specific function or set of functions.” For the purposes of the recommended practice, “the
term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, whole enterprises, and other aggregations of interest.” From this it follows that anything can be a system as long as it fulfils some purpose (i.e., accomplishes function(s)) and one chooses to view it as a whole.

A system inhabits an environment, while the environment of a system can influence that system. The environment, sometimes referred to as the context, “determines the settings and circumstances of developmental, operational, political, and other influences upon that system. The environment can include other systems that interact with the system of interest, either directly via interfaces or indirectly in other ways. The environment determines the boundaries that define the scope of the system of interest relative to other systems”. Essentially, one draws a line between the system of interest and anything outside that system that influences it in some way. This line is the interface between the system and its environment.

A system has one or more stakeholders. A stakeholder has one or more concerns relative to the system. Concerns are “those interests which pertains to the system’s development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders.” Typical concerns a stakeholder can have relative to a system are functionality, performance, security, reliability, safety, etc.

A system exists to fulfil one or more missions in its environment. The existence of a system has a purpose; it should meet one or more objectives of one or more stakeholders. Often some of these objectives coincide with enterprise objectives so that using the system is an efficient use of resources in the enterprise. So far, the terminology presented has only been related to systems and their environments. However, most of IEEE Std 1471-2000 is concerned with architectural descriptions, and in the following terminology related to this are presented.

A system has an architecture and this can be described in an architectural description. Note the distinction between the architecture of a system, which is conceptual, from the description of this architecture, which is concrete. Architectural description is defined as “a collection of products to document an architecture”. The architectural description can be divided into one or several views. Each view covers one or more stakeholder concerns. View is defined as “a representation of a whole system from the perspective of a related set of concerns”. A view is created according to rules and conventions defined in a viewpoint. Viewpoint is defined as “a specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis”. The distinction between view and viewpoint is analogous to that between a searchlight and what one sees using the searchlight as shown in the figure below.