SOFTWARE SYSTEM ARCHITECTURE MODELING ...

IAC-07-D1.3.10

SOFTWARE SYSTEM ARCHITECTURE MODELING USING UML S.Sarma ISRO Satellite Centre, Bangalore, India [email protected]

S.Udupa, V.K. Agarwal, and K.Parameshwaran ISRO Satellite Centre, Bangalore, India {udupa, agrawal,param}@isac.gov.in

Abstract— Model driven software development has been quite popular in the recent years and has been applied in many commercial projects. This paper presents the model driven development methodology by applying modeling techniques in representing system and the software architecture so as to simplify communication of information between teams, requirement management, tackling complexity of design and implementation, traceability of information for large software using Unified Modeling Language (UML) for an embedded spacecraft system as an example case study. The paper contributes by showing how the approach can be used to represent the software and system architecture of complex embedded system with increased quality and with reduced time. It presents a framework for developing software and system architecture using different UML views and patterns with emphasis to embedded real-time systems. Index Terms— Software Architecture, Software Modeling and Design, UML, Embedded Real-Time Systems.

I.

S

INTRODUCTION

OFTWARE development method has been the subject of research for many decades [1-7]. There has been enormous development in the last few years specifically concentrating on the visual modeling of complex, large software systems. Satellite systems with large and complex requirements, stringent performance, reliability, and safety criteria, are increasingly becoming difficult. The ever increasing demand on quality, reliability and reduced time to develop quality on-board software with stringent performance requirements demands use of the best practices [2] for software development. Model driven development is emerging as one of such methods for safety critical systems and this research focuses on this methodology of developing system and software architecture for spacecraft systems using visual modeling technique. Recent trends [3-4] show that 50-60% of the reasons for success of any project are attributed to the requirements. Most of the project failures result from poor requirements gathering, analysis and management. If requirements are not fully defined and documented, it will affect the entire project. Missing requirements lead to missing system requirements, and in turn missing design elements and functions. To overcome this problem, current methodologies involve model driven approach

supported by computer aided software engineering (CASE) tools such as Unified Modeling Language (UML). UML is a visual modeling language that allows the software developers to unambiguously specify system and software architecture, design and behavior. It helps in integrating the flexibility of traditional programming languages with the speed of modeling notation. It establishes one common language for system engineers as well as software developers, which enhances communication and coordination. It also enables work in large and distributed teams while simultaneously keeping control of ongoing changes and having direct visibility of their potential impact as changes through out a project are inevitable. Systems and software engineering practitioners have been using the UML [4-8] for modeling systems since it was released. In [9-10], Lockheed Martin’s use of UML for concept of operations, system requirements, software requirements, and test cases was described. In some cases, UML was used to model the system/segment architectures, including distributed architectures. The applications included “DoD, government, and commercial business, including application to distributed command, control, communications, and information systems, embedded real-time signal and data processing applications for radar and mission avionics subsystems, system simulators, and general business systems. In

IAC-07-D1.3.10 addition, there is at least one application to a hardware-intensive system associated with an aircraft development” [4]. In this paper, a framework is presented for development of the system and software architecture using UML. Different views of the UML are used to represent the system and its software architecture. In the View Driven approach the 4+1 views [8] provides the descriptions of the system and software from different perspective. This approach is reported to deliver significant productivity gains compared to traditional. With the focuses on the architecture and design and not implementation details, it allows system engineers and software developers to understand and simulate the system under development at an early stage. The behavior of the system can be traced and analyzed at an early stage allowing the developers to understand and correct the complex dynamic behavior as well as locate and remove errors where they are easier and cheaper to correct. These can benefit in minimized risk, boosted productivity, enhanced quality, improved predictability, simplified communication and reduced cost. The paper is organized in five sections. Section 2 provides an introduction to basics of modeling with UML applied to software system engineering and defines some of the related terminology. This also gives an introductory survey to some of the popular CASE tools and their features for modeling the architecture. Section 3 introduces the approaches for modeling system and software architectures using UML. Section 5 briefly describes the software architecting methods, while section 5 presents a case study of development of a system and software architecture for a DSP based spacecraft subsystem using the proposed approach. The modeling of such an embedded real-time system development is also briefly described form different perspective. II. BASICS OF MODELS, ARCHITECTURE AND UNIFIED MODELING LANGUAGE (UML) What makes software so complex and so difficult to grasp is the fact that the number of information loaded onto a single person is vastly exceeding the capabilities of the human mind. We are not able to handle thousands of pieces of information at any given time as the human shortterm memory is quite limited in that respect. The 7±2 rule is a well-known example. This rule states that the human mind can usually only handle 7 distinct things (plus or minus 2) at the same time. Given that restriction, one obvious question that arise is how have we managed even the simplest

piece of technology that consists of more (much more) than 9 pieces! The answer to that is probably the concept of modeling. If we encounter too much information, we consciously and/or unconsciously group this information in some way which makes it easier for us to recall it later on. The field of Software Engineering uses this human capability of abstraction to create “theories, methods, and tools which are needed to develop software [1].” Those theories, methods, and tools in turn use further abstractions until we have pieces which are small enough for us to comprehend without any further abstraction. Moreover, this need for abstraction is clear in [11] where it emphasizes: “it is not the number of details, as such, that contributes to complexity, but the number of details of which we have to be aware off at the same time.” This is the very reason systems engineers have been modeling systems since the inception of the discipline. Specifically, the reasons for modeling systems include among others: definition of the work to be done (requirements), allocation of responsibilities, documentation of the completed system, and communication with the various disciplines who will create, operate, and maintain the system. Unified Modeling Language has recently been used by Systems Engineers to model systems [12-14]. Many papers and articles have been written on various aspects of systems modeling with UML, most especially Use Cases [14], but little attention has been focused to develop the system and software architecture of embedded real-time systems. Papers that address development and modeling of system and software architecture do so with a “one size fits all” philosophy, by mandating a prescriptive structure that does not address the true needs of a many practical system’s development. The following of such approaches also may some time result into a badly architectured system which can be a serious handicap to the development of a system. A. Basics of Model In the engineering of software, ‘model’ is used in many different contexts. But in essence, a model is an abstraction. It abstracts away all kinds of details that are not relevant. The quality of the model is judged from the purpose of the model. There are different model like ‘system model’, ‘process model’, ‘mathematical model’, ‘platform models’, ‘meta model’ [15] etc used in software engineering for different purpose. A system model is a presentation of particular aspects of (software) systems and their application context that is defined by predefined description techniques based on text, graphics and tables.

IAC-07-D1.3.10 +influences +inhabits +has System Environmnet System

Architectrure

Rationale

+has

1..* Stakeholders +has 1..*

+provides +described by Architectural Description

1..* +is adrress to +organized by

+important to Concern

1..* +participates in +contributes to Viewpoint View Model 1 1 1..* +consists of

1..* +used to cover

Figure 1: IEEE definition of Architecture for Software Systems [16]. A mathematical model of a system or some of its aspects is a mathematical structure, in general, an algebra, consisting of sets, functions, graphs, relations, and/or logical predicates that represents the system in mathematical terms. A Meta model defines the description techniques (syntax) which is set of syntactic concepts (text, formula, graphs, or tables) for the descriptions of systems together with the mathematical models provide the semantic theory for description techniques. Thus the Meta model describes the set of systems that can be represented by modeling techniques. To find good overall approaches to models of particular systems are perhaps the most critical modeling task since this determines the adequacy of model for future development. Being able to abstract information does, however, not mean that we are able to solve a complex problem. To do that, modeling techniques should be used not only to abstract but also to solve problems in the abstraction. B. Model Structures and Theory In the model driven development the emphasis is on the model and the description techniques toolkit providing the modeling techniques that can be used in the development process in the individual task. Each type of model can be used in several places in the development process perhaps with different levels of abstraction. Each description technique enlightens certain properties of the model and can be used in several phases in the development process. It is therefore useful to separate the models, the description techniques

and their usage in the development process with the aim that these models capture the most significant part of the system model. To this regard the following models for systems of different size and complexity and type has been found in literature: Functionality Model, Data Model, Interface Model, Process Model, State Model, Interaction Model, Composed System Model etc. There are number of essential properties needed for a system and software model framework to support. For a lager system like Spacecraft Onboard software the modeling aim is to provide the interface abstraction, hierarchical composition/decomposition, flexible model of time and time abstraction, state model, logical foundation for specification and relating models in the development process. C. System and Software Architecture Definition Recently, there has been some attempt in standardizing what architecting means. The IEEE Draft Standard 1471[16] is one of the latest. Let us provide their definition for architecture, which illustrates some of the challenges in defining the term. Every system has architecture, defined as in Fig.1 [16]: An architecture is the highest-level conception of a system in its environment where: the ‘highest-level’ abstracts away from details of design, implementation and operation of the system to focus on the system’s ‘unifying or coherent form’; ‘conception’ emphasizes its nature as a human abstraction, not to be confused with its concrete representation in a document, product or

IAC-07-D1.3.10 other artifact; and ‘in its environment’ acknowledges that since systems inhabit their environment, a system’s architecture reflects that environment [16].

architecture embodies decisions about quality priorities and trade offs, and represents the earliest opportunity for evaluating those decisions and trade offs.

D. Role of Architecture An architecture plays several important roles in project development, and all of them facilitated by a formal representation of the architecture, such as with an Architecture Description Language (ADL). A formal architecture representation is more likely to be maintained and followed than an informal one, at it can more readily be consulted and treated as authoritative, and can more easily be transferred to other projects as a core asset. The role of an architecture mainly includes: Basis for communication: Project team members, managers, and customers all turn to the architecture as the basis for understanding the system, its development, and how it works during execution. Project blueprint: The choice of architectural components is institutionalized in the developing organization’s team structure, work assignments, management units, schedule and work breakdown structures, integration plans, test plans, and maintenance processes. Once it is made, an architectural decision has an extremely long lifetime and survives even outside of the software that it describes. Blueprint for product line development: An architecture may be re-used on other systems for which it is appropriate. If managed carefully, an entire product family may be produced using a single architecture. In this case, the importance of an appropriate architecture is magnified across all the projects it will serve. Embodiment of earliest design decisions: The architecture represents the first mapping from requirements to computational components. The selection of components and connections, as well as the allocation of functionality to each component, is a codification of the earliest design decisions about a project. All downstream design decisions must be consistent with the architectural choices. As such, architectural decisions are the hardest to change, and have the most far reaching consequences. First approach to achieving quality attributes: An architecture can either allow or preclude the achievement of most of a system’s targeted quality attributes. Modifiability, for example, depends extensively on the system’s modularization, which reflects the encapsulation strategies. Reusability of components depends on how strongly coupled they are with other components in the system. Performance depends largely upon the volume and complexity of the inter component communication and coordination, especially if the components are physically distributed processes. Thus, an

E. Architecture Description Languages Architecture description languages (ADLs) are formal languages that can be used to systematically represent the architecture of a software-intensive system. As architecture becomes a dominating theme in large system development and acquisition, methods for unambiguously specifying architecture will become indispensable. Architecture Description Languages (ADLs) are emerging as viable tools for formally representing the architectures of systems. ADL are growing in number, with large differences in terms of the abstractions they support and analysis capabilities they provide. Further, many languages not originally designed as ADLs serve reasonably well at representing and analyzing software architectures. Generally, architectures have largely been represented by informal circle-and-line drawings in which the nature of the components, their properties, the semantics of the connections, and the behavior of the system as a whole are rarely defined or if at all then poorly defined. Even though such figures often give an intuitive picture of the system’s construction, they usually fail to answer such questions as: What are the components? Are they modules that exist only at design-time, but are compiled together before run time? Are they tasks or processes threaded together from different modules, assembled at compile-time, and from run time units? Or are they something as blocks as “functional areas,” as in data flow diagrams or something else entirely? What do the components do? How do they behave? What other components do they rely on? What do the connections mean? Do they mean “sends data to,” “sends control to,” “calls,” “is a part of,” some combination of these, or something else? What are the mechanisms used to fulfill these relations? Many of these questions are answered by a properly architectured system and more systematically and uniformly using such CASE tools, which are considered as some of the useful properties of ADLs. ADLs has the ability to represent components (primitive or composite) along with property assertions, interfaces and implementations; ability to represent connectors, along with protocols, property assertions, and implementations; abstraction and encapsulation; types and type checking; ability to accommodate analysis tools openly. Luckham [17] lists the following as requirements for an ADL: component abstraction, communication abstraction, communication integrity (limiting

IAC-07-D1.3.10 communication to those components connected to each other architecturally); ability to model dynamic architectures; ability to reason about causality and time; hierarchical refinement support; relativity, the mapping of behaviors to (possibly different) architectures, as a first step towards checking conformance. Some ADLs available commercially or otherwise are ArTek from Technowledge [20], Modechart and CODE from University of Texas at Austin [23], Wright and UniCon from Carnegie Mellon University [24-25], Demeter from Northeastern University, PSDL/CAPS from Naval Postgrad. School, Resolve from Ohio State University, ACME [26], Raphide [27], and UML+ROOM [28], SEIAADL [29]. Neither ADLs nor UML constrain the choice of implementation language or require that any two components be implemented in the same language or thread of control. ADLs or styles may assume particular communication protocols and UML typically supports such restrictions. The behavior of architectural constructs (components, connectors, communication ports, and so forth) can usually be modeled with UML’s sequence, collaboration, state chart, and activity diagrams. Existing ADLs are usually able to support only a subset of these kinds of semantic models which gives architects more expressive power. Also, ADLs typically support modeling of a limited number of architectural views, but ensure their full consistency and interchangeability. UML, on the other hand, allows designers to model a system from many perspectives, but does not provide mechanisms for ensuring their consistency. The presence of multiple, possibly inconsistent views in a UML model are very likely to make the task of reverse engineering more challenging [30]. Both UML and ADLs can therefore benefit from techniques for view mismatch identification and reconciliation. One area that rarely has been paid much attention and adequately addressed to date is round-trip software engineering: consistently refining a high-level model of a software system into a lower-level model (forward engineering) and abstracting a low-level model into a higher-level one (reverse engineering). The use of the Unified Modeling Language, an object-oriented design language, to assess its suitability for modeling architectural concepts and provides a framework for identifying and resolving mismatches within and across different UML views, both at the same level of abstraction and across levels of abstraction is also studied.

III. UML AS LANGUAGE FOR MODELING SYSTEM AND SOFTWARE ARCHITECTURE Pictures were used to convey information for tens of thousands of years before writing was invented as understanding them is easy and intuitive. There are many ways of representing information graphically. However, if each team, project or company were to choose its own graphical notation, the overall effect would be to make things worse. The difficulty of translating and communicating information between different notations is apparent as there are many ways of representing information. The choice of UML as an language for architecting is due to the fact that the adoption of UML provides system architects working on Object Analysis and Design with one consistent language for specifying, visualizing, constructing and documenting the artifacts of software systems, as well as for business modeling. Moreover, Object Oriented (OO) design is more and more dominating the market and UML has evolved into the most significant OO analysis and design methodology. The Object Management Group (OMG), furthermore, has standardized UML for the Object Management Architecture (OMA) and there have already been good progress in integrating UML views. A. Architectural Views and Styles in UML Architecting in UML is represented by different views of UML, which is shown in Fig. 2. It shows the analysis, architecture, and design of a software system, implementation and testing, which often are part of the major development stages (from the developers point of view). The arrows depict the dependencies of the views onto information in other views. Architecture is the appropriate level of abstraction at which rules of a compositional style (i.e., an architectural style) can be exploited and should be elaborated. Doing so results in a set of heuristics that if followed will guarantee a resulting system with certain desirable properties. In many literature UML Views are used to mainly represent the following architecture of a system: • •

Function Architecture in which the system is structured into a family of sub functions also called services or features. Logical Component Architecture in which the system is decomposed into sets of components forming architecture. The components are hierarchically decomposed into components and finally modeled by state machines.

IAC-07-D1.3.10

USE CASE VIEW

COMPONENT VIEW

ACTIVIT Y DIAGRAMS

CLASS DIAGRAMS

INT ERACTION DIAGRAMS

ST AT E CHART S

DEPLOYMENT DIAGRAMS

CODE GENERATION

Shows the physical location of the systems artifacts

DIAGRAMS

ITERATIVE AND INCREMENTAL PROCESS Figure 2: UML Views. • •

Code architecture: Each state machine is realized by families of modules or classes which form code architecture. Deployment architecture that maps the components onto a network or hardware systems connected by communication links or bus

B. Approaches to Architectural Modeling Using UML The suitability of UML as an ADL has been conceived by many as it provides a common platform and notation from architecture through design to implementation. Like any ADLs, as UML also satisfies the requirement of an ADL with the advantage that it supports more views of representation of the system from different perspectives, this paper considers its suitable extension for architectural modeling. The basic promise of software architecture research is that better software systems can result from modeling their important aspects during, and especially early in the development. Choosing which aspects to model and how to evaluate them are two decisions that frame software architecture research. The four-layer metamodeling architecture [21] of UML suggests three possible approaches for modeling software architectures in UML: Using UML as it is, constrain the UML meta model using UML’s built-in extension mechanisms, and augment the UML meta model to directly support the needed architectural concepts. Each approach has certain potential advantages and disadvantages for forward and reverse

engineering, discussed below. Approach 1: Using UML as it is The simplest approach is to use the existing UML model to represent software architectures [22] as it is. A major advantage of the approach is that it results in architectural models that are immediately understandable by any UML user and useable by UML-compliant tools. However, the approach would provide no means for explicitly representing the relationship between existing UML constructs and architectural concepts for which there is no direct UML counterpart (e.g., software connectors or architectural style rules). Rather, this relationship would have to be maintained implicitly by the software architect and convey the same to the design teams from misinterpretation. This approach would thus also present a considerable challenge in trying to reverse engineer a system’s architecture from its UML model as for different ambiguities. None of the UML artifacts would contain any architectural information or explicitly represent architect’s intentions and purpose. Instead, the architecture would have to be inferred from the design elements and their interactions. The repeatability and reliability of such a process is questionable: it is likely that different people would deem different elements of the UML model architecturally relevant, resulting in different architectures when reverse engineered. Approach 2: Constraining UML with Built in Extensions The space of software design situations and concerns for which UML is intended, exceeds that of software architectures. Therefore, one possible approach to modeling architectures in UML is

IAC-07-D1.3.10 to KNOWLEDGE BASE

Requirement Capturing and Analysis

System Acceptance

HILS, Environmental and Integrated Systems of System Tests

System Architectural Analysis and Design Simulation

Software/Hardware Requirement Analysis and Software Architecture Description

SW Testing by QA and Code Verification

Software Design and Implementation

Implementation

Modularizing

g in Te st io n id at

al V

ng

Desi gn

T es t i

esig n

ng sti Te

a ted

iled D

In t e g r

Det a

ng

Conditional

Co di ng

T esti

Direct

Un it

Iterations under Configuration and Version Control

n icatio Verif

& Re

view

Iteration Prototypes

Detaile d Design and Implementation

Figure 3: Model Based Development Process used for the example system. constrain UML via stereotypes to address new concerns in software development. Conceptually, this approach can be represented using UML’s metamodeling architecture. Only the relevant portion of the UML model is made available to the software architect. This approach has been applied to ADLs like Wright [24] , and Rapide [27]. The major advantage of this approach is that it explicitly represents and enforces architectural constraints. Furthermore, an architecture specified in this manner would still be usable by standard UML tools and would be understandable by UML users with some added effort in studying the stereotypes. Finally, the task of reverse engineering the architecture from a UML model with explicitly specified stereotypes would be greatly simplified. A disadvantage of the approach is that it may be difficult to fully and correctly specify the boundaries of the modeling space. Another issue related to this strategy is the manner in which ADL-specific stereotypes are actually used within UML. To resolve this either UML can be used as the primary development

notation, from which excursions are made to various ADLs (with the help of ADL-specific stereotypes) in order to exploit the existing ADL tool support or UML is used as the only development notation and ADL-specific stereotypes are accompanied by ADL-specific tools that have been modified to operate on UML specifications. Approach 3: Augmenting the UML Metamodel One obvious, and therefore tempting, approach to using UML to support the needs of software architectures is to extend UML’s meta model to directly support architectural concepts. Extending the metamodel helps to formally incorporate new modeling capabilities into UML. The potential benefit of such an extension is that it could fully capture every desired feature of every ADL. Furthermore, if features from the extended version are used in modeling a system’s design, the task of reverse engineering the system’s architecture from the design is greatly simplified. However, such an extension to UML would not come without a price. The challenge of standardization is finding a

IAC-07-D1.3.10 language

that

is

general

enough

to

Prototype and Simulation

capture

Interface

Requirements Use Case and

Interaction Data Flow

Deployment

Class and Objects

Physical Objects

State Transition

Implementation

Analysis Architecting and High Level Design Low Level Design

Figure 4: UML Views and Models for Architecting and Design Modeling. needed concepts without adding too much complexity, while such a modification would result in a notation that is overly complex. Moreover, unless the extensions were made part of the UML standard, they would be non-conforming, incompatible with UML-compliant tools, and potentially incomprehensible to architects. In this paper the metamodel of the UML is augmented with the architectural concepts more specific to the aerospace systems. Similar approach is also considered by the SEI-AADL [29] architectural description language. C. Architecting Phase of Model Based Development Process A development process plays a critical role in ensuring the overall success as well as systematic and efficient realization of a system meeting its requirements through out the different stages of a project. There is different development process models from the known Waterfall process model to iterative process model used in developing software-intensive systems. To date, the Model Driven Development (MDD) with Model Driven Architecture as described by the Object Management Group (OMG) has gained more popularity in the software filed because of its clear advantages. Such a development process is shown in Fig. 3. Traditional life-cycle models such as the Waterfall Model is less useful in object oriented

(OO) development or do not accurately represent process because of the activity and artifact overlaps. This fact can also be seen in Fig. 4 where some development artifacts, such as classes and objects, are used and shared extensively during the entire development process. This ambiguity and overlapping, in the definition of development stages and phases, is however also a good thing since it provides some continuity between the life cycle stages and, thus, brings the development stages closer together. The conceptual breaks, which so frequently happen between the analysis and design stages, are eased. The development process as described in Fig. 3 is strengthened by using different techniques of modeling using UML at different stages. A modeling framework needs to be defined that guides the model development. Given a modeling framework, methodological steps are useful to apply the models in a development process. Moreover, building models is a complex and laborious task and to get the best out of modeling it should be integrated in the development process such that it supports all steps in the system and software development. IV. ARCHITECTING METHODS The modal driven development process incorporates modeling in the development process

IAC-07-D1.3.10 at suitable stages that plays a defined role for a given modeling technique as shown in Fig. 4. For instance the development of the architecture of a system can be obtained by the use of different modeling techniques for the architecture. The different milestone for architecting the system can be achieved by Function Architecture, Logical Component Architecture, Code architecture etc which give the essential structures of a software system in its different phases using architecting methods as described in the following subsection. A. Artifacts Driven In this method of architectural design, the starting point is the textual requirements that are used to identify the artifacts types in the process and procedure to obtain the objectives. The identified artifacts are grouped into subsystems to represent the architectural components and subsequently, the relation between these subsystems are defines to elaborate the architecture and architectural boundaries. Although the methodology is relatively simpler, however, obstacles often arise as textual requirements are imprecise and less useful as a source of architectural abstraction. B. Domain Driven Most software systems can be classified according to the business area and the kind of tasks they support, e.g. airline reservation systems, medical record systems, portfolio management systems, order processing systems, inventory management systems, etc. Similarly, we can also classify parts of software systems according to their functionality, e.g. database systems, synchronization packages, work flow systems, GUI libraries, numerical code libraries, etc. We refer to areas organized around classes of systems or parts of systems as domains. Obviously, specific systems or components within a domain share many characteristics since they also share many requirements. Therefore, an organization, which has built a number of systems or components in a particular domain, can take advantage of the acquired knowledge when building subsequent systems or components in the same domain. By capturing the acquired domain knowledge in the form of reusable assets and by reusing these assets in the development of new products, the organization will be able to deliver the new products in a shorter time and at a lower cost. Domain Engineering is a systematic approach to achieving this goal. Domain Engineering is the activity of collecting, organizing, and storing past experience in building systems or parts of systems in a particular domain in the form of reusable assets ( i.e. reusable work products), as well as providing an adequate means for reusing these

assets ( i.e. retrieval, qualification, dissemination, adaptation, assembly, etc.) when building new systems. The purpose of Domain Analysis is to select and define the domain of focus and collect relevant domain information and integrate it into a coherent domain model. C. Pattern Driven Experienced developers find when they approach a new problem to solve, that the situation usually has something in common with a solution they have already either created or seen. The problems are not identical and the identical solution will rarely solve the new problems, but the problems are still similar, so a similar solution will probably work. The “similar solution” generalized and formalized, is called a design pattern. Creating design patterns is a problem of abstracting the similarities of the two problems and the solution so that the generic aspects of the original solution can be applied to the new problem at hand. Design patterns codify design expertise and have been used in an intuitive way as long as design has been a recognized activity. The intentional use of design patterns allows us to think about our designs using a vastly richer vocabulary and to this think critically about the trade offs we make during the design process – resulting in better optimized, more robust systems. A design pattern is “a generalized solution to a commonly occurring problem.” To be a pattern, the problem must recur often enough to be usefully generalizable. The solution must also be general enough to be applied in a wide set of application domains. If it only applies to a single application domain, then it is probably an analysis pattern. An analysis pattern is similar to a design pattern but applies to a specific application domain such as finance or aerospace. Analysis patterns define ways for organizing problem-specific object analysis models within a single application domain. For some examples of domain-specific analysis patterns please refer [12, 13]. D. Use Case Driven The use case driven approach has been the widely accepted architecting technique used by the OO development community to define the business and application functionality from user point of view; this is why the technique is so popular. In this method, the architecture shows what the user wants to do, and then design and build an application to help the user do this. Although, there are number of variants of the same concept, however, the main theme to derive an architectural representation by gathering the business requirements in enough details such that the risk to the project is minimized remains the same.

IAC-07-D1.3.10 V.

ARCHITECTURE MODELING OF A DSP BASED

EMBEDDED ON-BOARD SPACECRAFT SUBSYSTEM-A CASE STUDY This section provides a case study carried out in developing software and system architecture of a satellite subsystem based on the architectural methods as discussed in the previous sections using UML views. The system considered performs vibration and structural dynamic analysis of a spacecraft to launch and in-orbit disturbances during different mission phases using the on-board experiments. The system is hence forth referred as the Structural dynamics and vibration analysis system. To start with, a development framework is defined for this particular system as shown in Fig. 3. The models of the framework are represented using the UML notations. The framework models includes the process model of various stages of Fig. 3, including the method of architecting, designing, and testing and are represented using the activity diagram of the UML notations. The framework organizes the architectural models such that multiple teams can contribute to the development in an effective manner, allow team members to use parts of the model for which they are not responsible for developing, provide an efficient build process so that it is easy to construct the system, locate and work on various model elements, and allow the pieces of the system to be effectively reused in other models and systems. Another reason for worrying about model organization are to allow team members to contribute to the model without losing changes made by those or other team members, or in some other way corrupting the model. There are different patterns available to organize the models. Some of the common patterns are the Use Case based model organization, Frame-work based model organization, Logic-model based model organization, and Physical model based model organization. Combinations of the above patters are also common in practice. In this case study we use a combination of the above mentioned patters to organize the models. The model organization was guided by breaking the system into physical and logical area of functionality, defining system Interaction, defining system modes, system constraints, defining concurrency requirements, and physical view as is shown in the following subsections. A. Use Case View and Function Architecture The System Model represents the (UML) model of the designed software system. In the course of forward software engineering, new information is

added to the system model and existing views are updated; in the case of reverse engineering, information from existing views is abstracted to create new, higher-level views (View Synthesis). IBM Rational Rose is used in these presented models. Use Case view is used to determine the system boundary as depicted in Fig. 5. The Actors acting on the system are identified and defined. It’s Interfaces with the other subsystems are also shown. This system interfaces with the main Bus Management Unit (BMU) that control the full spacecraft and the Equipment Bay, which house the electronics and systems related to the launch vehicle as shown in figure. The system receives Telecommands from the ground through the BMU system and telemetries the health keeping data to ground. Telecommand and Telemetry systems are represented as actors-as they either acts or are acted upon by the system. Moreover, the system is also acted upon by the Sensors and event triggering interfaces as shown in Fig. 5. The system has a high speed channel, represented as an actor, to transmit its large volume of collected data during the mission, which is independent and outside the described systems.

Ground Control

Telecommand Telemetry Onboard Structural Dynamics Analysis System (OSDE)

Sensors

High Speed Telemetry

LV Equipment Bay

Playback

Figure 5: System Model showing the architectural boundary. Thus system model shows the context of the system and provides the idea of the environment in which it is interacting. It is purposefully kept simple without overloading with much information so that the users of the system can easily understand the objectives. The system model is supported with a system functionality model by defining the use cases of the system as shown in Fig. 6. The system functionality use cases are described to elaborate the functions. At this level only the high level use cases that are architectural are listed out. The relationships between the actors and the uses are clearly shown.

IAC-07-D1.3.10

Ground Control (from Use Case Vi ew)

Telecommand

Telemetry

(from Use Case View)

(from Use Case View)

organize and store data

Communicate status Sensors (from Use Case Vi ew)

Collect vibration data

Repond to Commands form BMU and events Playback

Accelorometers

(from Use Case View)

Transmit data to ground

Monitor Lauch Vehicle Events

Perorm Analysis

Snap (from Use Case Vi ew)

LV Equipment Bay (from Use Case View)

Perform Shock Analysis Perform PSD Analysis

Perform Solar Pannel Frequency Identification

Figure 6: Use Cases representation of system functionalities. B. Logic View representing Logical Architecture The mode of operation of the described system is shown in Fig. 7. The mode shows the dynamic characteristic of the system and the event for which such mode changes happens. There are mainly seven modes of the system in which the software will operate. These are data acquisition and storage, playback, SRS analysis, PSD estimation, and real-time estimation of solar panel modal frequency. Apart from these prime modes, some auxiliary modes are proposed so that this subsystem after its expected three months mission life can be experimented with. These auxiliary modes are BMU parameter monitoring at high rates and real-time monitoring of states of other subsystems using the 1553B bus. The logic architecture also reflects the way the system is organized. For the presented system, combinations of patters are used to organize the logic architecture as shown in Fig. 8-12. A layered architectural pattern in used to identify and organize the major components of the proposed system into three layers, viz. the Hardware dependent software (HDS) layer, the data management layer, and the application layer as

PowerOn

Power On Initialization State

Frequency Identification

Pre - Trigger DAQ Mode

Command Command Suspendend Mode

eventDetected Comand DAQ Mode

High Speed TM Mode

Command Command Command

Playback Mode

Command

PSD Analysis Mode

SRS Analysis Mode

Figure 7: System state diagram to represent the modes of operation of the system. shown in Fig.8. The HDS layer interacts with all the external hardware; implements the driver software for the interfaces and devices and pass the data to the data layer for its management and use by the upper layers. The detail functionality of the HDS layer is shown in Fig. 9 where “include” dependency is shown to indicate the functionalities performed in this layer. A “layer” stereotype is

IAC-07-D1.3.10 introduced to augment in the UML metamodel as described in approach 3 in section 3.

System Configuration Data

Application Layer

Experimental Data



Data Layer

Data Layer (from Use Case View)

Analysed Data

global

global

1553B Data

Telemetry Data

Hardware Dependent Software (HDS)



Snap



Accelerometers

Figure 10: Blackboard architectural patter representation of the data management layer.





TC Interafce

Equipment Bay

BMU

Palyback Channel

Figure 8: Layered Architectural design pattern representation of the proposed system. The data management layer as shown in Fig. 10 is represented using the common architectural blackboard pattern where the data is organized into different packages and are generally globally accessible. This is indicated by the global feature in the data layer properties. Further, the organization of the data into different identifiable packages with associated function to be operated with not only helps in secured access and manipulation but also provides the advantage of software development by large teams as well as faster operation and retrieval for transmission to the ground in different modes of operation of the proposed system. Moreover, this also ensures safety of the critical system data in case of any faulty operations and probable recovery.

The major objective that the system use cases define is organized in the application layer as shown in Fig. 11. It can be observed from Fig.11 that organization of the functionalities are made such that there is correlation with the system mode diagram and the detail design model that includes the class and data models can be suitably organized systematically with reduced cohesion. Furthermore, it is also our experience that unpredictable changes in requirements at later stages related to any system modes can be easily traced and necessary modification like addition or deletion can be easily performed. Additionally, this organization also helps in distributing the responsibility among the developers in an controlled manner. Data Acquision and Storage Mode

SRS Mode



PlayBack Mode

Application Layer (from Use Case View)



PSD Mode

Cycle Syncronization 1553B Communication



Launch Event Detction

Modal Frequency Identification



BMU Assistance



TC Processing

Hardware Dependent Software (HDS) (from Use Case View)



Port Status Monitoring



TM Processing



PowerOn Initialization

Figure 9: Logical architectural representation of the HDS layer.

Figure 11: Use Case representation of the Application layer in Logical View. C. Implementation Architecture The Implementation architecture is an extension of the architectural system model with regard to software implementation aspects. It is the basis for code generation. In the implementation architecture, each state machine is realized by families of modules or classes which form code architecture. The analysis is driven by what the system must

IAC-07-D1.3.10 types.h

RTE.c

1553Bcomm.asm

Data.h

TMprocessing.asm

TCprocessing.asm

Eventmoni tor.asm

PSD.c

ModeProc.c

PlayBack .c

fft.asm

FreqId.c

SRS.c

pbinterface.asm

cyclesync.asm

DAQ.asm

BMUassist.c

filter.asm

in ss ce ro

ng

g din eco D TC

15

Even t And Monitor in Deco ding g

ces si

M od eP

n tio iza ron nch Sy cle Cy

Telem etry Pro

g

Figure 12: Code architecture representation using the component view. do while design is driven by how well the system it is important to specify the timing of each task for must achieve its requirements. Usually design proper scheduling , for instance, in a small, very pattern are used to organizing a design that low overhead real-time kernel. Such a kernel using improves the optimality of a design with respect to an extended round robbing scheduling scheme that one or a small set of qualities of service for uses time as well as memory portioning is shown in example, object design modeling, package Fig. 13. The real-time executive that performs the dependency diagram, and concurrency design scheduling of the various system tasks in a hard modeling. Additionally, a class diagram can be real-time fashion, where each task is given equal used to show the main implementation classes priority of execution. A software cycle time of T ms along with the code architecture for use by the can be derived by performing the worst case designers. A typical implementation architecture execution time analysis of the simulation model and depicting the code organization is shown in Fig. 12. from rough estimates execution time of each process. These timing aspects of the scheduling Furthermore, in case of real-time systems are represented using a sequence diagrams in Start UML notion, which also describes the interaction of System Reset the different object in time line. Power On Initialization

53

B

Data Man agem ent C om m un ic at io n

Figure 13: A small kernel (also known as Real-Time Executive) using extended round-robbing for hard real-time task scheduling.

D. Deployment Architecture Another aspect of the system and software architecture is to represent the way it is deployed. The deployment architecture maps the components onto a hardware or network systems connected by communication links or bus as shown in Fig. 14. The diagram represents that the presented subsystem is connected to the main system via a 1553B bus to the main system (also know as the Bus controller in Mil-Std-1553B literature [33]). As discussed in section 3, the UML metamodel is augmented with the 1553B bus to represent the deployment architecture. Figure 15 shows the actual deployment of the system connected as the RT through the 1553B bus to the Bus Management Unit (BMU): the BC unit. The complete

IAC-07-D1.3.10 development setup of this proposed DSP based system is shown in Fig. 16, which is used in the subsequent stages of validation and verification.

replay of operation-calls and events originating from actors by an automatic generation of these scenarios, while at the same time monitoring the inter-object communication for compliance against the selected scenarios. Any violations can be observed as a replay of the UML model, animating the selected sequence diagrams.

Figure 14: UML Deployment Architecture.

Figure 16: DSP based structural dynamics and vibration analysis system setup for on-board experiments in GSAT-4 spacecraft. VI. CONCLUSION

Figure 15: The realization of the deployment architecture showing the subsystem connected as 1553B remote terminal (RT) to the main BMU system (Bus controller). Another import issue in the development system architecture is the verification and validation of the software architecture, which was carried out creating and reusing the requirements-related test scenarios all along the top-down design path (scenario-based development). Starting with highlevel definitions (use case scenarios), test scenarios are derived in a model-based development from the verification / validation of respective models, either through simulation or by formal analysis. In this regard, Telelogic's Rhapsody [32] is found to be a useful CASE tool that integrates the UML 2.0 and automated testing features in a single Eclipse based environment. The model developed in Rational Rose was exported to Rhapsody to simulate the operation of the complete architectural functionalities. Recorded scenarios are used to assist the bottom-up integration. Also, using the scenario driven test generation, the user can configure test cases from selected scenarios to automatically derive test cases for feature interaction and stress testing. The test cases thus effectively replaces manual

Design is the process of taking the requirements and producing a system that not only meets the requirements, but also can be delivered on time and within budget. This can be effectively archived by the notion of having system and software architectures that allows us to fulfill two major aims: clearly communicate our understanding, as engineers, of the requirements to the user, describing the system design in a way that can be translated readily into a system implementation. Model driven software system development accelerates this purpose to simplify communication of information between teams, requirement management, tackling complexity of design and implementation, and traceability of information for large software systems. The Unified Modeling Language (UML) is a widely accepted modeling language that has been used in this paper to show how the model driven approach can be used to represent the software and system architecture of complex embedded spacecraft systems with improved quality and reduced time using different UML views and patterns. REFERENCES th

[1] Ian Sommerville, Software Engineering, 5 edition, Adison Wesley, 1996. [2] AT&T “Best Current Practices: Software Architecture Validation,” AT&T, Murray Hill, NJ, 1993. [3] Fokus, UML 2.0 Testing Profile Consortium, 2003. http://www.fokus.gmd.de/u2tp/.

IAC-07-D1.3.10 [4] Paul C. Clements , “A Survey of Architecture Description Languages,” Eighth International Workshop on Software Specification and Design, Germany, March, 1996. [5] Booch, G., Jacobson, I., and Rumbaugh, J. “The Unified Modeling Language for Object-Oriented Development,” Documentation set, version 1.0, Rational Software Corporation, 1997. [6] J. Rumbaugh, I. Jacobson, and G. Booch. The Unified Modeling Language Reference Manual. Addison Wesley, Reading, Mass., 1999. [7] D. Garlan & M. Shaw, “An Introduction to Software Architecture,” Advances in Software Engineering and Knowledge Engineering, Vol. 1, World Scientific Publishing Co., 1993. [8] Ph. Kruchten, “Architectural Blueprints—The “4+1” View Model of Software Architecture,” ,” Paper published in IEEE Software 12 (6) ,pp. 42-50, November 1995. [9] Ph. Kruchten & Ch. Thompson, “An Object-Oriented, Distributed Architecture for Large Scale Ada Systems,” Proceedings of the TRI-Ada Conference, Baltimore, ACM, p.262-271, November 6-11, 1994. [10] NASA “Software Formal Inspection Process Standard,” NASA-STD-2202-93, 1993. [11] Shaw, DeLine, Klein, Ross, Young, Zelesnik “Abstractions for Software Architectures and Tools to Support Them,” Carnegie Mellon University, SEIreport, Feb. 1994. [12] Stevens, Systems engineering: coping with complexity. Prentice Hall Europe, ISBN 0-13-095085-8, 1998. [13] Rechtin, E. “System Architecting, Creating & Building Complex Systems,” Prentice Hall, Englewood Cliffs, NJ, 1991. [14] Jacobson, I., Christerson, M., Jonsson, P., Övergaard, G. Object-Oriented Software Engineering-A Use Case Driven Approach, Addison-Wesley Publishing Company, 1992. [15] IEEE Std 610.12, IEEE Standard Glossary of Software Engineering Terminology, September, 1990. [16] IEEE “Recommended Practice for Architectural Description,” Draft Std. P1471, IEEE, 1998. [17] Luckham, David, Vera, James. “An Event-Based Architecture Definition Language,” IEEE Transactions on Software Engineering, Vol. 21, Issue. 9, pp.717-734, Sept.1995. [18] Garlan, D., Monroe, R.T., Wile, D. “ACME: An Architecture Description Interchange Language,” Proceedings of CASCON’97, November, 1997. [19] Kruchten, P. B. “The Common Misconceptions about Software Architecture,” Proceedings of the 2nd Ground Systems Architecture, El Segundo, CA, 1998. [20] Terry, Hayes-Roth, Erman, Coleman, Devito, Papanagopoulos, Hayes-Roth “Overview of Teknowledge’s DSSA Program,” ACM SIGSOFT Software Engineering Notes, October 1994. [21] Finkelstein, A, Kramer, J., Nusibeh, B., Finkelstein, L., and Goedicke, M. “Viewpoints: A Framework for Integrating Multiple Perspectives in System Development,” International Journal on Software Engineering and Knowledge Engineering, pp. 31-58, March, 1991. [22] Jahanian, F., and Mok, A. “Modechart: A Specification Language for Real-Time Systems,” IEEE Transactions on Software Engineering, vol. 20, no. 12, pp. 933-947, December 1994. [23] Harel, D.; Lachover, H.; Naamad, A.; Pnueli, A.; Politi, M.; Sherman, R.; Shtul-Trauring, A.; “STATEMATE: a working environment for the development of complex reactive systems” Proceedings of the 10th International Conference on Software Engineering, Singapore, April, 1988. [24] Kang, Kyo C.; Cohen, Sholom G.; Hess, James A.; Novak, William E.; & Peterson, A. Spencer. Feature- Oriented Domain Analysis (FODA) Feasibility Study (CMU/SEI-90-TR-21, ADA235785). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, Nov. 1990. [25] R. Schwanke, “Industrial Software Architecture with Gestalt,” technical report, Siemens Corporate Research,

Princeton NJ, http://www.sei.cmu.edu/architecture/ IWSSD8.Gestalt.paper.html. [26] Vestal, S. A Cursory Overview and Comparison of Four Architectural Description Languages, technical report, Honeywell, Feb. 1993. [27] Luckham, David, John J. Kenney, Larry M. Augustin, James Vera, Doug Bryan, Walter Mann. “Specification and Analysis of System Architecture Using Rapide,” Stanford University technical report, 1993. [28] B. Rumpe, M. Schoenmakers And A. Radermacher, A. th Sch urr, “UML + ROOM as a Standard ADL?,” 5 International Conference on Engineering of Complex Computer Systems (ICECCS), pp.43-53, 18-12 Oct, 1999. [29] P.H. Fieler, D.P.Gluch, and J.J. Hudak, “The architecture analysis and design language (AADL): An introduction.” Technical Note, Carnegie Mellon University. CMU/SEI2006-TN-01, 2006. [30] Gacek, C. “Detecting Architectural Mismatches During System Composition,” Doctoral Dissertation, Center for Software Engineering, University of Southern California, Los Angeles, CA 90089-0781, USA, 1998. [31] Vestal, S. “Mode Changes in a Real-Time Architecture Description Language,” Proceedings, Proc. International Workshop on Configurable Distributed Systems, Pittsburgh, March 1994. [32] Raphsody User Guide, Telelogic Inc, http://www.telelogic.com/, 2006. [33] Yunfeng Bai , Zucheng Zhou , and Junbi Chen , “The implementation of MIL STD 1553B processor, “ ASIC, 1996. 2nd International Conference on, pp.231-234., Shanghai, China, 21-24 Oct 1996.