WO2001033343A1 - A method for describing software architecture - Google Patents
A method for describing software architecture Download PDFInfo
- Publication number
- WO2001033343A1 WO2001033343A1 PCT/IB2000/001581 IB0001581W WO0133343A1 WO 2001033343 A1 WO2001033343 A1 WO 2001033343A1 IB 0001581 W IB0001581 W IB 0001581W WO 0133343 A1 WO0133343 A1 WO 0133343A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- services
- logical
- physical
- service
- set forth
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/10—Requirements analysis; Specification techniques
Definitions
- the present invention relates to software architectures, and more particularly, it relates to a method for describing software system architecture in terms of services at different abstraction levels.
- SW software artifacts
- the software architecture is formed with a hierarchy of SW artifacts that operate at different abstraction levels. The relationship between the system abstractions becomes an important factor when attempting to modify the software system to perform newly desired tasks.
- a service denotes a collaboration between different software artifacts of the software architecture at varying levels of abstractions.
- This service concept provides the ability to trace identified services from one abstraction level to another within the software system, which supports the mapping of features to code and vice versa.
- the method for describing software architecture comprises steps such as determining interfaces between software artifacts that make up the software architecture and structuring the determined interfaces into basic dialogues .
- the dialogues are recorded or written in formal definitions of each, and the purpose and usage of dialogues and interactions as services are documented.
- Each logical service is then mapped to each physical service used in its implementation, and a determination is made as to whether the mapping is simple enough. When the mapping is simple enough, it is formally documented.
- a determination is made as to the interactions between applications within the system.
- the determined interactions become logical services and are defined and utilized in the documentation of the purpose and usage of the dialogues (i.e., interactions between applications refer to the abstract part and become logical services) .
- the present invention enables the identification of the various levels of functionality of the software system and the software components that make up these identified levels of functionality. Once the individual software components of the various levels are identified, the interactions and relationships between the respective components are identified and documented. As a result, a map of the hierarchy of the software system and all relationships between the respective components that make up the system can be created and documented. This map provides a clear and predictable manner in which to implement modifications to the software system and components thereof, and thereby increases efficiency in modification and further development of these systems, as well as enabling the assessment of the architecture. Other objects and features of the present invention will become apparent from the following detailed description considered in conjunction with the accompanying drawings.
- Figure 1 is a diagram of a system hierarchy
- Figure 2 is a flow diagram of the method for describing software architecture in accordance with an embodiment of the present invention.
- FIG. 3 is a flow diagram of the method for using the created description of the SW architecture in accordance with another embodiment of the present invention.
- a software system viewed through services consists of processes or other SW artifacts communicating with each other using some synchronous or asynchronous interface, such as procedure calls or messages.
- the benefits of the service view can be best seen in a large system of several million lines of code, where the code typically includes about a dozen main applications.
- Different applications have typically adopted diverging philosophies in the use of messages and data included in them, resulting in the lack of clear interfaces between some of the applications. This in turn makes further development of the applications a task that cannot be easily carried out in a modular and predictable fashion.
- the present invention creates a way to access the system that is different from conventional program modules. It enables easier evolution of the system, as modifications can be specified and implemented in a rigorously traceable fashion, with the trace starting from the features involved and ending at the final code. Basically, the introduction of the service concept of the present invention can thus be seen as the creation of a map from features and top-level functionalities to actual code through intermediate service abstractions.
- the service concept of the present invention provides a natural framework for abstract description of features as well.
- the dynamic aspect of features can be described in terms of the description of the usage of services from a control point of view. Provided with such descriptions, feature interworking becomes more manageable, as it is possible to automatically pinpoint the services shared by the features.
- feature interworking becomes more manageable, as it is possible to automatically pinpoint the services shared by the features.
- the service hierarchy can also be used to form the structure of documentation of the static aspects of the system.
- Typical software systems can be broken up into a hierarchy of related services.
- the root node of a hierarchy is the full system 12, followed by services 14 representing features, top-level functionalities or programs.
- services 14 representing features, top-level functionalities or programs.
- At the end of the hierarchy is a level of implementations 16 given, for instance, with event traces or scenarios.
- the hierarchy of services enables straightforward representation of the software system in terms of services at different levels of abstraction. Due to the abstract descriptions, re-use of the software is supported at multiple levels of abstraction, i.e., any level of abstraction in the hierarchy can be used as a basis for re-use.
- a system can be seen as a non-cyclic graph, where each node is a service, where three levels of abstraction are used, and F is used to denote feature-level services, and I 3 is used to denote implementation level services.
- lower- level services 16 can be shared by one or more of the higher-level services 14, in which case they may represent, for example, some kind of a library of files or programs .
- the lowest-level services 16 are referred to as "physical services" to highlight the fact that they represent the system at the level of abstraction that can be implemented in a straightforward fashion (i.e., by code).
- logical services or “virtual services”, reflecting their role as abstractions defined in terms of logical or physical services rather than actual sequences of code in different implementation modules.
- virtual services are included in the hierarchy as nodes that have at least one child node
- nodes representing physical services never have child nodes (i.e., the level of functionalities 16) .
- This resembles a composition commonly associated with connectors in architectural descriptions.
- a logical service can be a generalization of the properties of a set of lower-level services, or as a set of operations that needs to be sequentially executed.
- the service hierarchy described above defines the static structure of services, which, however, is not enough for high-level specification. Instead, information on dynamic properties in the model should also be included.
- behavioral descriptions of services must be supported.
- software systems are comprised of behaviors (e.g., applications that perform specific operations) which work together to perform one or more tasks. It is the implementation and organization of these behaviors employed during software development that usually involves some kind of sharing of responsibilities based on a structural decomposition of the system.
- the services of the present invention can express operations that require several components in an implementation-independent fashion. For example, these operations typically represent file accesses and procedure calls, which all can be expressed in a similar fashion at a high level of abstraction.
- FIG. 2 shows a flow diagram illustrating the method 30 for describing software architecture in accordance with an embodiment of the present invention, wherein a service hierarchy of the software architecture is created.
- the introduction of services starts from the levels of abstraction that are the most obvious ones (i.e., the code or SW artifacts implementing physical services in bottom-up fashion and logical services in top-down fashion at the level of different applications) .
- the SW designer can make this initial identification of the levels of abstractions.
- Determinations are then made to find the interfaces between SW artifacts (step 32) of the system by listing the SW artifiacts and identifying where there is communication between two SW artifacts, and to identify the interactions between applications within the system (step 40) by going through different use cases of the system and determining where interactions between applications occur.
- the interfaces between software artifacts Once the interfaces between software artifacts has been determined, they are structured into basic dialogues (step 34) described, for example, in terms of sequence diagrams (written to memory) .
- the basic dialogues are then formally defined
- step 36 the conceptual definitions of the determined interactions between applications are written (step 42) to, for example, a database.
- the purpose and usage of the dialogues and interactions are documented as services in the system (step 38) .
- the logical services are mapped to each physical service used in its implementation using, for example, a database (step 46).
- the most straightforward task is to map implementation-level operations to their corresponding physical services. This basically means that different messages or for example, subroutine calls, used in the system are grouped together into groups which are used to accomplish coherent tasks in the code. These groupings are then defined as physical services.
- the next step is to connect them by composing the intermediate logical services in the hierarchy.
- the number of intermediate levels is typically assumed to range from zero through five, with top values only being used in the most complex applications. However, more than five levels can be achieved which would result in an exponential increase in the number of logical services. As such, it is preferable to have zero - five intermediate levels.
- a determination must then be made at this point as to whether the previous mapping is simple enough (step 48) .
- a mapping is considered simple enough when each logical service is implemented by as few physical services and each physical service participates in implementing as few logical services as possible.
- mapping of n physical services to illogical services is considered simple when n and in are as small as possible.
- a 1 to 1 mapping would be the simplest, but is not always accessible.
- the mapping is simple enough, it is formally documented (step 50) .
- the mapping is not simple enough (meaning that there are more physical services participating in the implementation of a given logical service than already accounted for) at this point (i.e., step 48)
- the logical services are decomposed into lower level logical services by dividing them into several interactions which become logical services (step 44) .
- the formally documented map generated at step 50 is the service hierarchy of the subject software architecture.
- the diagram of Figure 1 shows an example of a service hierarchy having only two levels. One of ordinary skill will recognize that other systems may include many more levels and that the system shown in Figure 1 is for exemplary purposes only.
- restructuring with the services concept of the present invention thus helps to identify potential problem situations with regard to the actual code by analyzing whether the n :m mapping from logical to physical services in the service hierarchy the mapping differs most from a 1:1 ratio. This could mean, for example, that a logical service is implemented as several small parts distributed over the system, or that one physical service is used for many different purposes. Either of these cases are undesirable.
- the services of the present invention can provide a uniform view to the system at different phases of the development. This obviously includes the phases of the development including specification, implementation, and testing.
- Figure 3 shows a flow diagram of the implementation of the service concept of the present invention into the development of the software architecture.
- the service hierarchy When dealing with an existing software architecture, the service hierarchy must be created and mapped (step 62) as described with reference to Figure 2. Once the service hierarchy has been obtained, a determination is made as to whether modifications to the system are required (step 64) . A modification may be needed due to new functional or non-functional requirements or problems with the existing SW architecture. Obviously if none are required, the process ends (step 66) .
- the logical services to be modified are identified using the previously created service hierarchy (step 68).
- an analysis of the side effects to the related services i.e., related to the identified logical services
- the service mappings step 70
- Side effects occur when a physical service participates in implementing several logical services
- the process returns to step 68 where the logical services to be modified are further identified.
- potential places for troubble or potential problem situations as described previously
- all SW artifacts that are necessary to be modified are redesigned and the process returns to step 62 to begin again should another modification be required or desired.
- logical services to be implemented or to be modified are identified (step 68), together with the neighboring services in the service hierarchy. Then, the services are implemented, and ultimately can be used to ensure that all necessary parts are tested whenever new features are incorporated in the system. Additional tools can be implemented to trace services at different levels of abstraction, further facilitating the software system's evolution.
- the service concept of the present invention can be used as the basis for configuration management. This supports feature-based delivery, because the relation of features and actual code is easier to master with a service hierarchy.
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU79400/00A AU7940000A (en) | 1999-11-01 | 2000-10-31 | A method for describing software architecture |
CA002387795A CA2387795A1 (en) | 1999-11-01 | 2000-10-31 | A method for describing software architecture |
EP00969753A EP1221090A1 (en) | 1999-11-01 | 2000-10-31 | A method for describing software architecture |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/432,045 | 1999-11-01 | ||
US09/432,045 US7076788B1 (en) | 1999-11-01 | 1999-11-01 | Method for describing software architecture |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2001033343A1 true WO2001033343A1 (en) | 2001-05-10 |
Family
ID=23714521
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IB2000/001581 WO2001033343A1 (en) | 1999-11-01 | 2000-10-31 | A method for describing software architecture |
Country Status (5)
Country | Link |
---|---|
US (1) | US7076788B1 (en) |
EP (1) | EP1221090A1 (en) |
AU (1) | AU7940000A (en) |
CA (1) | CA2387795A1 (en) |
WO (1) | WO2001033343A1 (en) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10452768B2 (en) * | 2007-11-03 | 2019-10-22 | International Business Machines Corporation | Managing source annotation metadata |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0540487A2 (en) * | 1991-11-01 | 1993-05-05 | Televerket | System design method |
EP0640914A2 (en) * | 1993-08-23 | 1995-03-01 | AT&T Corp. | Method and apparatus for configuring computer programs from available subprograms |
US5875330A (en) * | 1994-02-28 | 1999-02-23 | International Business Machines Corporation | Tool for defining complex systems |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5067072A (en) * | 1987-11-06 | 1991-11-19 | Visystems, Inc. | Virtual software machine which preprocesses application program to isolate execution dependencies and uses target computer processes to implement the execution dependencies |
US5634127A (en) * | 1994-11-30 | 1997-05-27 | International Business Machines Corporation | Methods and apparatus for implementing a message driven processor in a client-server environment |
US5815718A (en) * | 1996-05-30 | 1998-09-29 | Sun Microsystems, Inc. | Method and system for loading classes in read-only memory |
US5987247A (en) * | 1997-05-09 | 1999-11-16 | International Business Machines Corporation | Systems, methods and computer program products for building frameworks in an object oriented environment |
US5953526A (en) * | 1997-11-10 | 1999-09-14 | Internatinal Business Machines Corp. | Object oriented programming system with displayable natural language documentation through dual translation of program source code |
US6096095A (en) * | 1998-06-04 | 2000-08-01 | Microsoft Corporation | Producing persistent representations of complex data structures |
US6083276A (en) * | 1998-06-11 | 2000-07-04 | Corel, Inc. | Creating and configuring component-based applications using a text-based descriptive attribute grammar |
US6542885B1 (en) * | 1998-12-30 | 2003-04-01 | International Business Machines Corporation | Methods, systems and computer program products for controlling variables associates with transactions in a multiple transaction environment |
US6442748B1 (en) * | 1999-08-31 | 2002-08-27 | Accenture Llp | System, method and article of manufacture for a persistent state and persistent object separator in an information services patterns environment |
US6598220B1 (en) * | 1999-12-17 | 2003-07-22 | Dell Products L.P. | System and method for allowing registerable runtime modification of object behaviors |
-
1999
- 1999-11-01 US US09/432,045 patent/US7076788B1/en not_active Expired - Fee Related
-
2000
- 2000-10-31 CA CA002387795A patent/CA2387795A1/en not_active Abandoned
- 2000-10-31 AU AU79400/00A patent/AU7940000A/en not_active Abandoned
- 2000-10-31 EP EP00969753A patent/EP1221090A1/en not_active Withdrawn
- 2000-10-31 WO PCT/IB2000/001581 patent/WO2001033343A1/en not_active Application Discontinuation
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0540487A2 (en) * | 1991-11-01 | 1993-05-05 | Televerket | System design method |
EP0640914A2 (en) * | 1993-08-23 | 1995-03-01 | AT&T Corp. | Method and apparatus for configuring computer programs from available subprograms |
US5875330A (en) * | 1994-02-28 | 1999-02-23 | International Business Machines Corporation | Tool for defining complex systems |
Also Published As
Publication number | Publication date |
---|---|
US7076788B1 (en) | 2006-07-11 |
CA2387795A1 (en) | 2001-05-10 |
EP1221090A1 (en) | 2002-07-10 |
AU7940000A (en) | 2001-05-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6011917A (en) | Method and computer system for generating process management computer programs from process models | |
US7716254B2 (en) | System for modeling architecture for business systems and methods thereof | |
Hnětynka et al. | Dynamic reconfiguration and access to services in hierarchical component models | |
Bosch | Object-oriented frameworks: Problems & experiences | |
Redlich et al. | Research challenges for business process models at run-time | |
Coullon et al. | Integrated model-checking for the design of safe and efficient distributed software commissioning | |
Gill et al. | Modified development process of component-based software engineering | |
US7076788B1 (en) | Method for describing software architecture | |
Bergenthum | Firing partial orders in a petri net | |
Costa et al. | The application of UML and an open distributed process framework to information system design | |
CN114296883B (en) | Light-load virtualized network experimental behavior simulator construction and scheduling method | |
US20100275070A1 (en) | Conversion of a class oriented data flow program with inheritance to a structure oriented data flow program | |
Broy | Architecture driven modelling in software development | |
Häring et al. | Models for Hardware and Software Development Processes | |
Jang et al. | Object-oriented component identification method using the affinity analysis technique | |
France et al. | Metarole-based modeling language (RBML) specification V1 | |
Cimatti et al. | Model-based run-time synthesis of architectural configurations for adaptive MILS systems | |
Belategi et al. | MARTE mechanisms to model variability when analyzing embedded software product lines | |
Larrea et al. | White-Box Testing Framework for Object-Oriented Programming. An Approach Based on Message Sequence Specification and Aspect Oriented Programming | |
Lin et al. | Model replication: transformations to address model scalability | |
Ponnapalli et al. | A comparative study of software architectures for embedded mission critical applications | |
Zinn et al. | Definition of software construction artefacts for software construction | |
Waszkowski | Reference Low-code Development Platform Architecture: Aurea BPM | |
Tse et al. | To wards a 3-dimensional Net-based Object-Oriented DeveLopment Environment (NOODLE) | |
Burgstaller et al. | Using domain driven development for monitoring distributed systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
WWE | Wipo information: entry into national phase |
Ref document number: 2387795 Country of ref document: CA |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2000969753 Country of ref document: EP |
|
WWP | Wipo information: published in national office |
Ref document number: 2000969753 Country of ref document: EP |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
WWW | Wipo information: withdrawn in national office |
Ref document number: 2000969753 Country of ref document: EP |