Describe the following: A) Modeling the architecture of a system B) Modeling Systems C) Models and Views D) Traces

A) Modeling the architecture of a system :- deployment diagram depicts a static view of the run-time configuration of processing nodes and the components that run on those nodes. In other words, deployment diagrams show the hardware for your system, the software that is installed on that hardware, and the middleware used to connect the disparate machines to one another. You want to create a deployment diagram for applications that are deployed to several machines, for example a point-of-sales application running on a thin-client network computer which interacts with several internal servers behind your corporate firewall or a customer service system deployed using a web services architecture such as Microsoft’s .NET. Deployment diagrams can also be created to explore the architecture of embedded systems, showing how the hardware and software components work together. In short, you may want to consider creating a deployment diagram for all but the most trivial of systems. Nodes can contain other nodes or software artifacts. The ApplicationServer node contains EJBContainer (a software node) which in turn contains three software components, a deployment specification, and a software artifact. The software components use the same notation as component diagrams (I could have annotated them with their interfaces although that wouldn’t have added any value in my opinion). Deployment specifications are basically configuration files, such as an EJB deployment descriptor, which define how a node should operate.

B) Modeling Systems :- UML, the Universal Modeling Language, was the first language designed to fulfill the requirement for "universality." However, it is a software-specific language, and does not support the needs of engineers designing from the broader systems-based perspective. Therefore, SysML was created. It has been steadily gaining popularity, and many companies, especially in the heavily-regulated Defense, Automotive, Aerospace, Medical Device and Telecomms industries, are already using SysML, or are plannning to switch over to it in the near future. However, little information is currently available on the market regarding SysML. Its use is just on the crest of becoming a widespread phenomenon, and so thousands of engineers are now beginning to look for training and resources. The proposed book will provide an introduction to SysML, and instruction on how to implement it, for all these new users. It is the first available book on SysML in English. It contains insider information! The author is a member of the SysML working group and has written sections of the specification. It features a special focus comparing SysML and UML, and explaining how both can work together.

C) Models and Views :- We need to consider the primary modelling purposes of UML.

These are:

· Business Process Modelling with Use Cases

· Class and Object Modelling

· Behaviour Modelling

· Component Modelling

· Distribution and Deployment Modelling

Each UML model is designed to let analysts, developers and customers view a system from different perspectives and with varying levels of abstraction. Each diagram will fit somewhere into these five architectural views representing a distinct problem solution space. These can be described as the user model view, structural model view, behavioural model view implementation model view and the environment model view. The UML user model view encompasses the models which define a solution to a problem as understood by the client or stakeholders. This view is often also referred to as the Use Case or scenario view. The main UML model encompassed by this view is the:

· Use Case Diagram: These models depict the functionality required by the system and the interaction of users and other elements (known as actors) with respect to the specific solution. The UML structural view encompasses the models which provide the static, structural dimensions and properties of the modelled system. This view is often also referred to as the static or logical view. UML Models applicable to this view include:

· Class Diagrams: These models describe the static structure and contents of a system using elements such as classes, packages and objects to display relationships such as containment, inheritance and associations.

· Object Diagrams: Depict a class or the static structure of a system at a particular point in time.

The UML Implementation View combines the structural and behavioural dimensions of the solution realisation or implementation. The view is often also referred to as the component or development view. UML Models applicable to this view include:

· Component Diagrams: These depict the high level organisation and dependencies of source code components, binary components and executable components and whether these components exist at compile, link or run time.

D) Traces :- The ability to trace new and changed requirements to their impacted components provides critical support for managing change in an evolving software system. Unfortunately numerous studies have shown the difficulties of maintaining links using traditional traceability methods. Information retrieval techniques can be used to dynamically generate traces and alleviate the need to maintain explicit links, however prior work in this area has focused primarily on establishing intrarequirement links or links between requirements and code. We compare several retrieval techniques for generating links between requirements, code, and UML models. Tracing to UML elements provides a higher perspective on the proposed change than would be possible if links were generated directly to the code and supports the growing trend towards model driven development. Our experiment returned better results for establishing links to UML artifacts than to code, suggesting the usefulness of establishing links to code via UML artifacts. We conclude the paper by discussing the implications of this approach for managing the evolution of a software system.